閾値を決めるのは意思決定

⚖️閾値は、技術ではなく判断

どう測るかは技術の問題。でも、どこを合格にするかは「何を守りたいか」という価値の問題です。

ゲートを作るとき、二つの問いが出てきます。 一つは「どう測るか」。これは技術の問題です。 もう一つは「どこを合格ラインにするか」。こちらは、技術ではありません。

合格ラインは、「何をどこまで守りたいか」という価値の表明です。 品質をどれだけ大事にするのか、そのためにどれだけの手間を許すのか。 これは、数式では出てきません。その事業が何を優先するかから決まる、立派な意思決定です。

だから私たちは、閾値を「エンジニアリングの細部」として流さないようにしています。 むしろ、経営として向き合うべき数字だと考えています。

🕳️ゆるすぎる閾値は、無いのと同じ

何でも通ってしまうゲートは、通過の安心感だけを配って、実際には何も守っていません。

合格ラインを下げすぎると、どうなるか。ほとんど何でも通ってしまうゲートができあがります。これは、一見すると平和です。誰も止められず、全部が前に進む。

でも、これは危険です。「ゲートを通った」という安心感だけを配って、中身は何も守っていない。通過の記録が、品質の証拠のように見えてしまう。むしろ、ゲートが無いより厄介かもしれません。 無ければ、少なくとも人は自分で警戒します。

ゲートは、置くだけでは意味がない。 ちゃんと「落とすべきものを落とす」線が引けて、はじめて仕事をします。

🧱厳しすぎる閾値は、全部を止める

誤検知が増えると、人は警告を読み飛ばす。厳しすぎるゲートは、やがて無視されて死にます。

では、逆に厳しくすればいいのか。これも違いました。 合格ラインを上げすぎると、本当は問題ないものまで止まりはじめます（誤検知）。

誤検知が増えると、何が起きるか。人は、警告を信じなくなります。 「どうせまた空振りだろう」と、中身を見ずに読み飛ばすようになる。そうなったゲートは、たとえ稼働していても、実質的には死んでいます。厳しさが、信頼を殺すのです。

私たちは、この失敗を避けるために、 ゲートを入れる前に「正しいものを誤って止めないか」を必ず確かめます。 現に運用している成果物を全部そのゲートに通してみて、誤検知が出ない線に合わせてから、本番に入れる。厳しさは、正しさとは違います。

最初の線をどこに置くか迷ったときは、理想から引かず、現実から引きます。 まず今ある本物の成果物をひととおりそのゲートに通してみて、合格すべきものが全部通り、落とすべきものだけが落ちる位置を探す。そこを起点にして、あとは運用しながら少しずつ締めていく。 頭の中の理想値からスタートすると、たいてい厳しすぎて、初日から現場が止まります。

📉閾値は動かしていい。ただし記録する

状況が変われば線も動かす。でも「ゆるめる」ときだけは、こっそりやらず、記録に残すと決めています。

一度引いた線が、ずっと正しいとは限りません。 事業のフェーズが変われば、守りたいものも変わる。だから、閾値は動かしていいと考えています。固定するほうが、かえって危うい。

ただし、一つだけルールを決めています。合格ラインを「ゆるめる」ときは、こっそりやらない。厳しくする分には、まだいい。でも下げるときは、目の前のものを通したいがための、 その場しのぎであることが多いからです。

だから、閾値を下げる変更は必ず記録に残し、あとから「なぜここで下げたのか」を辿れるようにしています。 線を動かす自由と、動かした責任。この両方を持っておくのが、健全だと考えています。

🧭「誰が線を引くか」を手放さない

目標をどこに置くかは、技術ではなく事業の選択。だからこそ、線を引く手綱は自分で握っておく。

目標となる合格ラインをどこに置くかは、技術ではなく事業の選択だ—— この考え方自体は、私たちの発明ではありません。 サービスの目標水準（Google の SRE ブックが解説する SLO）の議論でも、「どこを目標に据えるかは技術者だけで決めず、事業判断として選ぶ」と語られています。

私たちの実感も、まったく同じでした。 閾値は、ゆるすぎれば意味をなくし、厳しすぎれば全部を止める。 その間のどこに線を引くかは、「自分たちが何を大事にするか」の表明にほかなりません。

あなたのチームのゲートは、誰が合格ラインを決めていますか。 もし「なんとなく」で決まっているなら――そこは、技術の設定ではなく、 あなたの意思決定の場所です。いちど、自分の手で引き直してみてください。