「0件」の報告には、分母を書かせる

🕳️数えていないのに、0件と言っていた

あとから手で数えたら98本ありました。チェックはその間ずっと0件と言い続けていました。

原因は、絞り込みの条件が実態から少しだけずれていたことでした。名前の書き方が想定と1文字違うだけで、対象が一件も引っかからなくなる。引っかからなければ該当も0件です。出てくる文字は「0件」で、正しく動いているときとまったく同じでした。

別の日には、外部のコマンドが認証エラーで何も返さないことがありました。返ってきたのは空っぽの出力です。それを受け取った側は、そのまま0件として扱いました。

どちらも同じ形をしています。「N件を調べて0件だった」と「そもそも1件も調べていない」が、出力の上で見分けられない。この2つが同じ顔で並んでいたのが問題でした。

➗直したのは、検査でなく出力の書式

件数を出すなら、分母も一緒に出す。これを心構えではなく、出力の決まりにしました。

やったことは単純です。件数を報告する処理は、「何件を調べたか」を必ず添えるようにしました。0件なら「120件を調べて該当0件」と書く。分母が付いていない0件は、そもそも報告として成立していないことにしました。

そのうえで、調べた対象が0件だったときは正常として扱わないことにしました。走査対象が空なのは、たいてい設定か経路が壊れているサインです。静かに緑で通り過ぎるのがいちばん困ります。

もうひとつ変えたのが、絞り込みで拾う設計そのものです。対象を先に列挙して絞る書き方は、実態がずれた瞬間に何も拾わなくなるうえ、ずれたこと自体に誰も気づけません。だから、いったん全部を走査してから分類する形へ寄せていきました。分母が勝手に減らない書き方です。

🚦答えを2つでなく3つにする——通過・不合格・実測不能

「わからない」を「合格」に混ぜていたのが、いちばん深いところの原因でした。

検査の答えを「通った／落ちた」の2つで設計すると、判断がつかなかったときの行き先がありません。道具が入っていない、ネットワークが繋がらない、取得に失敗した——本来どれも「わからない」なのに、落とす理由が無いので通ってしまいます。

壊れているときほど静かに緑になる、という嫌な性質がここから生まれます。そこで、答えを3つにしました。通過、不合格、そして実測不能。実測不能は通過として扱わず、人が見に行く合図にしています。

副作用として、報告は少しうるさくなりました。前は毎朝きれいに「0件」で終わっていたものが、今は「調べられなかった」と言ってくる日があります。それでも、こちらの方がずっと読める報告になったと思っています。

📚参考

失敗を握りつぶして正常に見せてしまう、という失敗の型には名前が付いています。

例外を受け取ったのに何もせず通してしまう書き方はエラーの握りつぶし（error hiding）として整理されています。今回の「空の出力を0件と読む」も、形としては同じ話でした。

また、監視の設計で何を見るべきかについてはGoogle の SRE 本の監視の章が参考になりました。値そのものより、その値が取れているかどうかを先に見る、という視点は今回の分母の話と地続きだと感じています。

🧭まとめ: 分母のない数字は、報告として受け取らない

一人で会社を回していると、自動化された報告をそのまま状態として受け取る場面が増えます。読み手が私ひとりしかいないので、おかしさに気づく機会も一度きりです。だからこそ、報告の側に「何件のうちの何件か」を語らせておく価値がありました。

今の運用では、分母のない0件は信じないことにしています。数えた形跡が見えない0件は、良い知らせではなく、ただの沈黙かもしれないからです。