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

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

リリース計画の会議で、こんな一言が出ることがあります。

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

これは決して無茶な意見ではありません。限られたリソースの中で、ユーザーに価値を届けるスピードを優先したいという気持ちは、むしろ健全な経営判断です。ただし、ここには一つの前提のズレがあります。それは「障害は起きてから気づける」という前提です。実際には、監視体制がなければ、障害が起きたことにすら気づけないケースが珍しくありません。気づいたときにはすでにユーザーからの問い合わせが積もっていて、「対応」ではなく「炎上の後始末」から始まることになります。

ここで「監視は大事なんです」と正面から訴えても、相手には「エンジニアがまた安全側に倒したがっている」としか聞こえません。必要なのは、相手の優先順位（スピード）を否定せずに、監視が実はスピードを守るための装置だと理解してもらう伝え方です。

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

事前監視の必要性を説明するときに効くのが、「煙検知器と消火活動」のたとえです。

火事が起きたときに消火活動をすることに異論はありません。問題は、消火活動を始めるタイミングです。煙検知器がない家では、火事に気づくのは「隣の家の人が煙を見て知らせてくれたとき」や「部屋が真っ黒な煙で覆われたとき」です。その時点ではもう初期消火では済まず、消防車を呼ぶしかありません。

煙検知器がある家では、コンセントの焦げ臭いにおいや小さな発煙の段階でアラームが鳴ります。ボヤの段階で気づけるので、消火器一本で済み、家財もほとんど失わずに済みます。

つまり「障害対応は後付けで良い」という発言は、「消火活動は後付けで良いので、消防車だけ用意しておけば十分」と言っているのに近いのです。消火活動そのものは後からでもできますが、その消火活動を"初期消火"で終わらせられるかどうかは、煙検知器——つまり事前監視——があるかどうかで決まります。監視は「障害を防ぐもの」ではなく、「障害対応のコストを小さく保つためのもの」だと言い換えると、対応の軸で話が噛み合います。

もう一つ、ビジネス寄りのたとえも使えます。健康診断です。病気になってから病院に行くのは当然ですが、健康診断で早期発見できれば、治療は軽くて済み、入院も不要になることが多い。健康診断を「後付けでいい」と言う人はあまりいません。監視体制も同じで、"発見を早めることで、対応そのものを軽くする"役割を担っています。

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

受け取り 「スピードを優先したい、というのはすごく理解できます。実際、全部を事前に固めてからリリースしていたら、今期の目標には間に合いません」

まず相手の優先順位そのものには同意します。ここで「でも監視は必要です」と反論すると、相手は防御的になります。

たとえ 「ただ、障害対応って、火事で言うと消火活動の部分なんです。消火活動自体は後からでもできますが、それが"ボヤで済む消火"になるか"全焼してから呼ぶ消防車"になるかは、煙検知器——つまり事前の監視——があるかどうかで決まってしまうんですよね」

言い換え 「なので『監視を先に作る』というのは、実は『障害対応を軽くするための投資』であって、スピードを落とす話ではないんです。むしろ、監視なしでリリースして大きな障害になった場合、原因調査だけで数日かかることもあるので、トータルで見ると監視込みで出す方が早いケースが多いです」

段階案 「とはいえ、最初から完璧な監視基盤を作る必要はありません。今回は最低限、"エラー率"と"レスポンス時間"の2つだけアラートを飛ぶようにして、リリースはそのまま進めるのはどうでしょう。これなら追加でかかる時間は半日程度です。本格的な監視強化は、リリース後の様子を見てから優先度をつけて進めます」

このように、全否定でも全肯定でもない「最小限の事前監視＋リリース続行」という中間案を置くことで、相手は「スピードを失わずに安全弁を得られる」と感じられます。

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

「障害対応そのものは後からでも始められますが、それが"小さなボヤ"で済むか"全焼"になるかは、事前に煙を検知できる仕組みがあるかどうかで決まります。なので、最低限のアラートだけ先に仕込んでから出しましょう」

この一文は、相手の「後付けでいい」という前提を否定せず、「対応のサイズをコントロールするための前提条件」として監視を位置づけているのがポイントです。

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

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

• 影響範囲が極めて小さい機能：社内の一部ユーザーしか使わない管理画面や、失敗してもビジネスへの影響がほぼゼロな実験的機能。この場合、監視コストの方が割高になることがあります。
• すでに上位の監視網でカバーされている：インフラ全体や主要APIの監視がすでに整っていて、今回追加する機能もその監視範囲に自然に含まれる場合は、追加の仕組みは不要です。
• 検証目的のPoC・短命な機能：数日〜数週間で役目を終えると分かっている検証コードに、本番運用並みの監視を作るのは過剰投資です。
• リリース頻度が高く、即時ロールバックが前提の運用：フィーチャーフラグで即座に切り戻せる体制がすでにあり、異常の検知より先に「切り戻してから調べる」運用が確立している場合、事前監視より即時ロールバックの方が合理的なこともあります。

こうしたケースでは「それなら今回は後付けで大丈夫ですね」とはっきり同意する方が、エンジニアとしての判断の信頼性が上がります。何でも監視を主張すると「いつも安全側に倒す人」という印象がつき、本当に必要な場面での説得力が落ちてしまいます。

6. まとめ表

重要なのは「監視か速度か」の二択に見せないことです。事前監視は、障害が起きたときの対応コストを小さくするための前提条件であり、スピードを落とすものではない——この一点を、相手の言葉に合わせたたとえで伝えられれば、議論は対立ではなく協力に変わります。