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

新機能のリリース前ミーティングで、事業部の責任者からこう言われることがあります。

「監視の仕組みを作る時間があるなら、その分早くリリースしてほしい。障害が起きたら、そのときに対応すればいいじゃないか」

これは決して無責任な発言ではありません。むしろ、限られた予算とスケジュールの中で「今すぐ価値を出したい」という真剣な思いの表れです。エンジニア側からすると、監視体制（アラート、ログ収集、ダッシュボード、ヘルスチェックなど）は事故を未然に防ぎ、起きたときの被害を最小化するための土台ですが、これを事前に用意しても「何も起きなければ成果が見えない」という性質があります。だからこそ、非エンジニアの目には「保険をかけすぎて動きが遅い」ように映ってしまうのです。

ここで「監視がないと危険です」とだけ伝えても、抽象的すぎて響きません。相手はリスクを軽視しているのではなく、リスクの「解像度」がエンジニアと違うだけです。この解像度の差を埋める言葉が必要になります。

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

こういうときによく使うのが、次のようなたとえです。

「これは、火災報知器をつけずにビルを運営するようなものです。火が出てから消火器を探しに走っても、もう部屋は煙でいっぱいです。報知器があれば、煙が出た瞬間に気づいて、小さな火のうちに消し止められます」

もう一つ、事業寄りの人に響きやすいたとえとして、健康診断があります。

「監視は、会社の定期健康診断のようなものです。症状が出てから病院に駆け込むより、血液検査で数値の異常に早く気づくほうが、治療も回復も圧倒的に楽になります」

どちらのたとえも共通しているのは、「事後対応そのものを否定していない」という点です。消火器も病院も必要です。ただ、それだけに頼ると、被害が大きくなってから気づく、という構造になってしまう。監視体制は「事後対応をやめろ」という話ではなく、「事後対応が始まるタイミングを早める仕組み」だという点を伝えるのがポイントです。

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

いきなり反論すると「エンジニアがまた慎重論を言っている」と受け取られがちです。次の順番で話すと、相手の意図を尊重しつつ論点を動かせます。

① 受け取る

まず、相手の言葉をそのまま認めます。

「なるほど、今はスピードを最優先したい、というのはよくわかります。実際、障害が起きてから直すという選択肢自体は間違っていません」

② たとえで翻訳する

先ほどの火災報知器や健康診断のたとえを一つ選び、状況に当てはめます。

「ただ、これは火災報知器のない状態でビルを開業するのに近くて、火が出たこと自体に気づくまでに時間がかかってしまうんです」

③ 言い換える

相手の要望を否定せず、論点を「対応の有無」から「気づくまでの時間」にずらします。

「なので論点は『事後対応するかどうか』ではなくて、『何かがおかしいと、どれくらい早く気づけるか』なんです。気づくのが1時間後になるか、5分後になるかで、影響を受けるユーザー数もリカバリーの工数もまったく変わってきます」

④ 段階案を出す

いきなりフル装備の監視基盤を求めるのではなく、最小限の一歩を提示します。

「なので今回は、監視の仕組みを全部作り込むのではなく、『サービスが止まったらSlackに1件通知が来る』というだけの最小限の仕組みだけ、半日で入れさせてください。それ以上の作り込みはリリース後の様子を見て判断しましょう」

この「受け取り→たとえ→言い換え→段階案」の型は、相手の予算感や納期感を壊さずに、最低限の安全網を確保するための交渉として機能します。

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

長く説明する時間がない場面では、次の一文だけでも効果があります。

「障害が起きてから対応するのは前提として、その"起きたこと"に気づくまでの時間だけは、今のうちに短くしておきたいです」

もう少し柔らかく伝えたい場合は、こちらも使えます。

「消火器を探す前に、まず煙が出たことに気づく仕組みだけ、今回入れさせてください」

どちらも「事後対応の否定」ではなく「気づきの速さ」に焦点を当てているのが共通点です。この一言があるだけで、相手は「監視=コスト増」ではなく「監視=リカバリー時間の短縮」という文脈で受け止め直してくれることが多いです。

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

このたとえがどんな場面でも通用するわけではありません。以下のようなケースでは、無理に監視の必要性を主張せず、相手の判断を尊重すべきです。

  • 社内向け・低頻度利用の小規模ツールの場合：利用者が数人で、止まってもすぐに本人から連絡が来るような環境では、専用の監視基盤を作るコストのほうが割に合わないことがあります。この場合は「気づく人がすでにいるので、追加の仕組みは不要」と正直に伝えるほうが信頼を得られます。
  • PoCやβ版など、そもそも「壊れてもいい」前提の検証段階：検証の目的が「早く動くものを見せて反応を得ること」であれば、監視より速度を優先する判断は合理的です。ここでたとえ話を持ち出すと、逆に「石橋を叩きすぎるエンジニア」という印象を与えかねません。
  • すでに他の仕組み（クラウドサービス側の標準監視、外部ベンダーのSLA保証など）でカバーされている場合：車輪の再発明になるだけなので、相手の「監視は後でいい」という判断のほうが正しいこともあります。

大事なのは、「監視は常に正義」ではなく、「気づくまでの時間が短いほうが得なケースかどうか」を都度判断することです。判断を誤ると、たとえ話自体が説教くさく響き、次回以降の提案が通りにくくなります。

6. まとめ表

相手の言葉 たとえ 返し
監視より先にリリースしよう 火災報知器なしでビルを開業する 「起きたら直す、は前提でいいので、気づくまでの時間だけ縮めさせてください」
問題があれば連絡が来るから大丈夫 症状が出てから病院に行く健康管理 「連絡が来る=すでに困っている人がいる状態なので、その手前で気づける仕組みが1つあると安心です」
監視は後回しでいい、まずは動くものを 保険は事故の後からでも入れると思っている状態 「最小限、通知が1件来るだけの仕組みだけ先に入れて、それ以外は様子を見ながら決めましょう」
そこまでやる必要はない（小規模ツールの場合） （たとえを使わない） 「たしかにこの規模なら不要ですね、必要になったタイミングでまた相談させてください」

監視体制の話は、放っておくと「エンジニアの自己満足」か「事業側の軽視」かという対立構造になりがちです。しかし本質は、どちらも「限られたリソースの中で、何を優先するか」という同じ土俵に立っている、ということです。たとえ話は、その土俵を揃えるための翻訳ツールにすぎません。段階案とセットで使うことで、相手の意思決定を尊重しながら、必要な安全網だけを確保できます。