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

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

新しいサービスをリリースする直前、スケジュールが逼迫している場面でよく起きる話です。監視ダッシュボードやアラート設定を工数として積んでいたところ、事業側やPMから次のように言われることがあります。

「監視は後回しでいいので、まずはリリースを優先してください。何か問題が起きたら、その時に対応すればいいですよね？」

一見、合理的な提案に聞こえます。実際、監視設定にはそれなりの工数がかかり、リリース直後は機能そのものの完成度を上げたいという気持ちも理解できます。しかし「障害対応は起きてから考える」という発想と、「障害が起きたことに気づく仕組みを事前に用意しておく」という話は、まったく別のレイヤーの問題です。ここを混同されたまま押し切られると、後で取り返しのつかない事態になりかねません。

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

これは「火事が起きたら消火すればいい」と「火災報知器をつけるかどうか」を混同しているのに近い状況です。

火災報知器がなくても、消防車を呼べば火は消せます。でも、報知器がなければ「火事が起きたこと」自体に気づくのが遅れます。気づいたときには、すでに部屋の半分が燃えている、隣の部屋にも燃え移っている、という状態になっているかもしれません。

障害対応も同じです。「対応する体制」があっても、「異常が起きたことを知る手段」がなければ、対応の開始が致命的に遅れます。ユーザーからの問い合わせで初めて気づく、SNSで炎上して初めて気づく、という展開になれば、対応そのものの難易度も、信頼回復のコストも跳ね上がります。

もう一つ近い例え話をするなら、健康診断です。「体調が悪くなったら病院に行けばいい」という考え方自体は間違っていません。ただし、健康診断（＝監視）をしていない人は、症状が出た時点ですでに病状がかなり進行していることが多い。早期発見できていれば軽い処置で済んだものが、発見が遅れたことで大掛かりな治療が必要になる。監視の目的は「病気を防ぐこと」ではなく「悪化する前に気づくこと」なのです。

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

こうした場面では、いきなり反論するのではなく、まず相手の意図を受け止めてから、認識のズレをたとえ話で埋め、現実的な段階案に落とし込むという流れが効果的です。

受け取り 「リリースを優先したいお気持ち、よくわかります。工数が限られている中で、まず機能を届けることを優先するのは自然な判断だと思います。」

たとえ 「ただ一点だけ整理させてください。障害対応の体制と、障害に気づく仕組みは別物なんです。火災報知器がなくても消防車は呼べますが、火事が起きたこと自体に気づくのが遅れると、被害の規模がまったく変わってきます。」

言い換え 「つまり『監視を用意する』というのは、『何か起きた時にすぐ対応するための準備』ではなく、『何かが起きたことを一番早く知るための仕組み』を作るという話なんです。対応体制を後回しにするのは理解できますが、気づく手段まで後回しにしてしまうと、対応が始まる前の時間がブラックボックスになります。」

段階案 「なので、フル装備の監視基盤を今すぐ作るという話ではなく、最低限『サービスが落ちていることに数分で気づける』アラートだけは先に入れさせてください。詳細なダッシュボードや細かい閾値のチューニングはリリース後でも構いません。まずは『気づく』の部分だけ確保する、という優先順位でいかがでしょうか。」

このように、要求を全否定するのではなく「対応の準備」と「検知の準備」を切り分け、最小限のスコープに絞って合意を取りに行くのが現実的です。

4. ミーティングで使える一文

「障害対応は後からでも始められますが、障害に気づくタイミングだけは後から取り戻せません。まずは『気づく仕組み』だけ先に入れさせてください。」

この一文は、相手の「対応は後でいい」という前提を否定せずに、監視の本質的な役割（検知）だけを切り出して優先度を上げてもらうための言い回しです。対立構造を作らずに、論点を「対応体制の話」から「検知の話」へずらすことができます。

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

このたとえや主張が常に正しいわけではありません。次のようなケースでは、むしろ相手の「後付けでいい」という判断を尊重すべきです。

• 社内向けの検証環境や、利用者が限定された小規模なツール：影響範囲が小さく、問題が起きても関係者に直接聞けば気づける場合、大掛かりな監視は過剰投資になります。
• 明確に「使い捨て」と決まっている短期キャンペーンサイトやPoC：稼働期間が数日〜数週間で、終了後に破棄することが決まっているものに、恒久的な監視体制を作るのは工数の無駄です。
• すでに上位のインフラ側で十分な監視が効いている場合：クラウドプロバイダやAPMツールが基本的な死活監視を自動でカバーしているなら、追加の監視をゼロから作る必要性は薄れます。この場合は「すでにある監視で十分カバーできているか」を確認する会話に切り替えるべきです。
• リリース直後の数時間だけ開発者が張り付いて手動確認する運用が明言されている場合：一時的に人間の目が監視の代わりを果たすと合意できているなら、それは立派な検知手段であり、自動監視を無理に急がせる理由にはなりません。

大事なのは「監視は常に最優先」と主張することではなく、「検知の空白期間がどれだけのリスクを持つか」を影響範囲に応じて判断することです。

6. まとめ表

このように、監視の必要性を訴えるときは「対応」と「検知」という言葉を意識的に分けて使うことがポイントです。相手が拒否しているのは往々にして「体制構築の工数」であり、「気づく仕組み」そのものへの反対ではないことが多いからです。論点をずらさず、最小限のスコープで合意を取りに行く姿勢が、現場での説得力を高めます。