障害対応は「起きてから考えればいい」への処方箋 ― 事前監視体制がなぜ必要か

1. 状況（非エンジニアからの要望）

新機能のリリース判定会議で、事業側の責任者からこう言われた。

「監視の仕組みを作る工数、今回は削っていいよ。障害対応は起きてから考えればいいから。まずはリリースを優先しよう」

悪気があるわけではない。むしろ合理的な発言に聞こえる。まだ何も起きていない問題のために工数を使うより、目の前の機能開発に集中したい、というのは自然な判断だ。

しかし現場のエンジニアからすると、これは「火災報知器を付けずに、火が出たら消火器で対応すればいい」と言っているのに近い。問題は、その火がいつ、どこで、どれくらいの規模で起きるかを、誰も見ていないと分からないという点にある。

ここで「いや、監視は必要です」とだけ返しても、なぜ必要なのかが伝わらず、単なる工数の押し問答になってしまう。相手が持っている「事後対応で十分」という前提そのものに、たとえ話で橋をかける必要がある。

2. たとえ（日常・ビジネスの比喩）

こう考えてみてほしい。

健康診断を受けずに、体調が悪くなってから病院に行けばいい、という人はあまりいない。それは「症状が出た時点ではすでに進行している」ことを、経験的に知っているからだ。健康診断は「病気を治す」ためのものではなく、「悪化する前に、小さいうちに気づく」ためのものだ。

システム監視もまったく同じ構造をしている。障害対応（＝治療）は、症状が出てから始めても間に合うことが多い。しかし、症状が出たことに気づくまでの時間が長ければ長いほど、患部は広がる。監視がないというのは、「健康診断なし・自覚症状が出るまで放置」という状態で日々の業務を回しているのと同じことになる。

さらに言えば、事後対応だけの体制は「火事が起きてから消防車を呼ぶ」ことはできても、「煙が出た時点で気づいて初期消火する」ことはできない。後者ができるかどうかが、被害が数万円で済むか、建物ごと失うかの分かれ目になる。監視体制とは、この「煙感知器」の役割を担っている。

3. 提案の型（受け取り→たとえ→言い換え→段階案）

受け取り 「たしかに、まだ起きていない障害のために今工数を使うのはもったいない、という感覚は分かります。リリースを優先したい気持ちも当然だと思います」

たとえ 「ただ、これは健康診断と似ていて、監視を入れないというのは“症状が出るまで放置する”という選択に近いんです。健康診断そのものは病気を治しませんが、悪化する前に気づけるかどうかを決めるものなので」

言い換え 「なので今回のご提案は、“障害対応の仕組みは後回しでいい”というより、“何が起きているかに誰も気づけない状態でリリースする”という意味に近くなります。障害が起きた後に頑張って直すのはもちろんできますが、気づくまでの時間が長いほど、ユーザーへの影響も、直すためのコストも大きくなります」

段階案 「なので、フルの監視体制は確かに今回は見送っても構わないと思います。ただ、最低限、以下の3点だけは残させてください。

1. サービスが完全に止まったことが分かるアラート（死活監視）
2. エラー率が急上昇したときの通知
3. 誰が最初に気づいて、誰が対応するかの連絡フロー

これだけなら数時間の工数で済みます。詳細なダッシュボードやログ分析基盤は、リリース後の様子を見てから段階的に足していく形でどうでしょうか」

このように「全部やる／全部やらない」の二択ではなく、「最低限の煙感知器だけは付ける」という第三の選択肢を出すことで、相手の工数感覚を尊重しつつ、リスクの急所だけを塞ぐ提案にできる。

4. ミーティングで使える一文（引用ブロック）

障害対応そのものは後付けでも間に合いますが、「何かが起きたことに気づく」仕組みだけは後付けにできません。気づくのが3分遅れるか3時間遅れるかで、対応コストもユーザーへの影響も桁が変わるので、そこだけ先に用意させてください。

この一言は、「監視全体」対「対応全体」という粗い対立を、「気づく」対「直す」という時間軸の違いに分解している。相手が納得しやすいのは、後者の切り口であることが多い。

5. 例外（このたとえを使わない／肯定すべきケース）

すべての場面でこの説明が最適とは限らない。次のようなケースでは、むしろ相手の判断を支持すべきだ。

• 社内向けの検証用環境や、影響範囲が極めて小さい実験的機能の場合。ユーザー影響がほぼゼロで、失敗しても即座に気づける（開発者が使うだけの機能など）なら、健康診断のたとえを持ち出すまでもなく、事後対応で十分というのは正しい判断である。
• リリースまでの時間が本当に切迫していて、最低限の死活監視すら数時間で用意できない場合。この場合は「監視ゼロでリリースするリスク」を明示した上で、経営判断として受け入れるのが誠実な対応であり、無理に食い下がる場面ではない。
• すでに全体を監視する仕組み（APM や外形監視など）が存在していて、今回追加したい監視が重複や過剰である場合。「後付けでいい」という相手の感覚のほうが正しく、エンジニア側が過剰品質に寄っていることもある。

このたとえの目的は「監視は常に最優先」と主張することではなく、「気づく仕組み」と「直す仕組み」を切り分けて、リスクの所在を正しく合意することにある。

6. まとめ表