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

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

新機能のリリースが立て込むタイミングで、事業側や上長からこう言われることがあります。

「監視の仕組みを作る時間があるなら、先に機能を出してほしい。障害が起きたらそのとき対応すればいいじゃないか」

一見合理的に聞こえます。監視体制の構築には工数がかかり、目に見える成果（新機能）を生みません。「起きるかどうかわからない障害のために、今の工数を使うのはもったいない」という感覚は、非エンジニアの立場からは自然な発想です。

ここでエンジニアが「監視は基本ですから」「後で痛い目を見ますよ」とだけ返すと、抽象的な精神論に聞こえてしまい、説得力を持ちません。相手が本当に知りたいのは「監視を先にやることで、具体的に何を防げるのか」という一点です。

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

これは「火災報知器を後から付ければいい」という発想に近いものです。

家を建てるとき、「火事が起きたらそのとき消火器を買いに行けばいい」とは誰も考えません。なぜなら、火事は「起きたことに気づいた時点」ではすでに手遅れになっているケースが多いからです。火災報知器の役割は、火を消すことではなく、被害が小さいうちに気づかせることにあります。

障害対応も同じ構造を持っています。障害そのものは「後付け」で対応できても、障害に気づくタイミングが遅れることそのものは、後から取り戻せません。監視がない状態で障害が起きたとき、実際に困るのは「対応する技術力」ではなく、「対応を始めるべきタイミングがわからないこと」です。

もう一つ、経理の比喩も有効です。「レシートは後でまとめて整理すればいい」と考えて日々の記録を怠ると、決算のときに数か月分の取引を一つひとつ思い出す羽目になります。監視のない障害対応は、まさにこの「後でまとめて整理する経理」と同じで、対応コストが後ろに行くほど雪だるま式に膨らみます。

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

受け取り 「機能開発を優先したいお気持ち、よくわかります。今リリースが多く、限られた工数をどこに割くかはシビアな判断ですよね。」

まず「工数がもったいない」という相手の感覚そのものを否定しないことが大切です。相手は間違ったことを言っているのではなく、優先順位の情報が足りていないだけです。

たとえ 「監視がない状態というのは、火災報知器のない家に住むようなものなんです。火事そのものは消防車が来れば消せますが、報知器がないと『火事が起きたこと』に気づくのが遅れて、被害が数倍に広がってしまう。障害対応も同じで、直す技術より先に、気づくタイミングが勝負を分けます。」

言い換え 「なので、これは『障害対応の準備』というより『気づくまでの時間を短くするための投資』と捉えていただけると近いです。実際、障害はいつか必ず起きます。問題は起きるかどうかではなく、起きたときに1分で気づくか、1時間後にユーザーからの問い合わせで気づくかの差です。」

ここで重要なのは、「障害が起きるかどうか」の議論から「気づくのが何分後か」という議論に土俵を移すことです。前者は水掛け論になりがちですが、後者は具体的な数字で合意しやすくなります。

段階案 「いきなりフル装備の監視基盤を作る必要はありません。まずは①エラー率とレスポンスタイムのアラートだけ最小構成で入れる、②リリース直後の24時間だけ手動で見る体制を取る、③落ち着いたら段階的に自動化する、という3段階でどうでしょうか。初期コストは半日程度で収まります。」

いきなり「全部やらせてください」と言うと、相手の「工数を使いたくない」という懸念にそのままぶつかります。最小構成から始める提案は、相手のリソース感覚を尊重しながら実質的な安全網を確保する現実的な着地点になります。

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

「障害対応そのものは後からでも直せますが、“気づくタイミング”だけは後から取り戻せません。だからこそ、最小限でいいので先に監視だけは入れさせてください。」

この一文の強みは、相手の主張（後付けでいい）を真っ向から否定せず、「対応」と「気づくこと」を切り分けている点です。相手が譲歩しやすい形に論点を絞り込んでいます。

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

すべての場面でこの理屈を持ち出すべきではありません。以下のようなケースでは、むしろ相手の判断を尊重すべきです。

• 社内向けの検証環境や、影響範囲が極めて限定的な小規模ツールでは、監視の優先度を下げてスピードを取る判断は合理的です。障害が起きても影響がユーザーに届かないなら、火災報知器より先に家具を運び込んでも問題ありません。
• すでに上位のインフラ層（クラウド基盤やプラットフォームチーム）が全社的な監視を提供している場合、個別機能でさらに監視を重ねる必要性は薄れます。この場合は「既存の監視でどこまでカバーされているか」を確認するのが先です。
• 本当にリリースの成否が事業の存続を左右するようなクリティカルな期限がある場合、最小限のログ出力だけ残して監視は翌週に回す、という判断もあり得ます。この場合は「後付けでいい」という判断自体を尊重し、リリース後すぐに監視を入れる約束だけ取り付けるのが現実的です。

大切なのは、「監視は常に最優先」という原則論を振りかざすのではなく、影響範囲とリスクの大きさに応じて主張の強さを調整することです。

6. まとめ表