「障害対応は後付けでいい」と言われたときに、事前監視の必要性をどう伝えるか

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

新機能のリリース直前、スケジュールが詰まっている中でプロダクトマネージャーからこう言われることがあります。

「監視の設定とか、アラートの仕組みとか、今は後回しでいいよ。まずは機能を出そう。何か起きたら、その時に対応すればいいから」

悪意はなく、むしろスピード重視の前向きな判断のつもりで言っています。本人の中では「事後対応＝柔軟でアジャイルな姿勢」であり、「事前監視＝念のための保険、今は不要なコスト」という整理になっています。ここで「いや、監視は絶対必要です」と押し返すだけでは、平行線になりがちです。必要なのは、相手が持っている「後で直せばいい」という感覚そのものに、別の角度から光を当てることです。

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

これは「煙探知機」に似ています。

家に煙探知機をつけるのは、火事が起きてから火を消すためではありません。火事が「起きていることに、できるだけ早く気づく」ためです。探知機がなくても、最終的には煙や炎に気づいて消火活動はできます。でも、気づくのが5分遅れるか、2秒で気づくかで、被害の規模はまったく変わります。

障害対応における監視も同じ役割を果たします。障害が起きたときに「どう直すか」の腕前（対応力）は後からでも磨けます。しかし「障害が起きたことに気づく速さ」は、監視の仕組みがなければどうやっても買えません。ユーザーからの問い合わせで気づく、SNSでの炎上で気づく、翌朝の売上レポートで気づく――これはすべて、煙探知機のない家で、隣の人の通報や焦げ臭さで火事に気づくようなものです。

もう一つ付け加えるなら、これは健康診断にも似ています。治療（対応）は症状が出てからでも始められますが、健康診断（監視）がなければ「症状が出ていることにすら気づかない」期間がずっと続いてしまいます。

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

受け取り 「スピード優先で機能を早く出したい、というのはすごく分かります。リリースを遅らせたいわけじゃないです」

たとえ 「ただ、障害対応って『火を消す力』の話で、監視は『煙に気づく力』の話なんです。消す力は後から鍛えられますが、気づく力がないと、そもそも火が広がってから気づくことになります」

言い換え 「なので『監視を今すぐ完璧に作る』という話ではなくて、『何かあったときに、ユーザーより先に私たちが気づける最低限の仕組みだけ、先に置いておく』というイメージです」

段階案

• 第1段階（リリース前・最低限）: サーバーが落ちた／エラー率が急増した、など致命的な異常だけを検知するアラートを1〜2個だけ設定する
• 第2段階（リリース後1〜2週間）: 実際に出たエラーや問い合わせ内容を見ながら、監視項目を増やす
• 第3段階（安定稼働後）: ダッシュボード化やオンコール体制など、本格的な運用に拡張する

「全部を先に作る」のではなく「気づくための最低限」を先に置き、残りは後から育てる、という提案にすると受け入れられやすくなります。

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

対応の腕前は後からでも鍛えられますが、気づく速さだけは、仕組みを先に用意しておかないと手に入らないんです。まずは『異常に気づくための最低限』だけ、リリースと同時に置かせてください。

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

• 本当に影響範囲が小さい検証用リリースのとき: 社内の数人しか使わない実験的機能や、短期間で役目を終える使い捨てのプロトタイプであれば、「後で見ればいい」という判断は合理的です。ここで煙探知機の話を持ち出すと、過剰な慎重論に聞こえてしまいます。
• すでに上位システムが監視範囲をカバーしているとき: インフラ全体の監視基盤や親サービスのアラートが、新機能の異常もある程度拾える設計になっている場合は、個別に監視を足す緊急性は下がります。この場合はまず「今の監視がどこまで拾ってくれるか」を一緒に確認するほうが建設的です。
• 相手がすでに『最低限の監視』の必要性を認めているとき: 「監視は要らない」ではなく「全部は今作らなくていい」という発言であれば、それはむしろ正しい優先順位づけです。このときは説得ではなく、段階案（3.の第1〜3段階）をそのまま提示して合意を取るほうが早いです。

6. まとめ表

監視の話は、押し付けると「エンジニアの保険好き」という印象を与えがちです。けれど「気づく速さ」という切り口にすると、スピード重視の相手にも「それはむしろ早く動くための準備だ」という形で伝わりやすくなります。全部を先に作ろうとせず、最低限から段階的に育てる提案にすることが、現場で通りやすい落としどころです。