「すみません。間に合いません。」炎上前夜のボヤを隠す部下のバグと正しいアラート設計

バグの構造解析

2026.10.13

「すみません。間に合いません。」――。この記事では、ビジネスの現場で起きるこの現象の裏にある「OSのバグ」を、アーキテクトの視点で解剖します。

よくある場面

引っ越しをしてまだ日が浅く、荷ほどきも終わっていない時期のことです。時計の針が0時を回ろうとしていた時、パートナーが突然こう言ってきました。

「明日、〇〇を持っていきたいんだけど」

私は絶望しました。未開封の段ボールが山積みで、何がどこにあるか全くインデックス化（整理）されていない状態です。

「え、急に言わないでよ。こんな状況で、もう0時なんだけど……」
「じゃあ、あきらめるしかないの？（涙）」
「…………（はぁ、徹夜コースだ）」

結果として、私は本来払う必要のなかった膨大なリソース（徹夜）を強制的に支払わされ、強引にタスクを完了させました。

実はこれ、ビジネスの現場でPMやマネージャーの寿命を最も縮める「サイレント障害（アラート遅延）バグ」と全く同じ構造です。

納期の当日、あるいは数時間前になって

「すみません、トラブルがあって間に合いません」

と特大の爆弾を落としてくる部下や外注。

数日前に「ボヤ（小さな火）」が出た瞬間に報告してくれれば、PMである私がコップ一杯の水をかけるだけで鎮火できたはずです。

しかし、彼らが報告を怠り、ギリギリまで隠蔽した結果、火の手はシステム全体に広がり、最終的にPMが徹夜という【甚大な消火リソース】を投下して鎮火するハメになります。

なぜ、彼らは火事が出た瞬間に「出火しました」とアラートを鳴らせないのでしょうか？彼らのOSを解析すると、そこには2つの錯覚（バグ）が存在します。

QA層（実行者）はエラーを極端に恐れます。トラブルが起きたことを報告すれば「自分の無能さを証明してしまう」「怒られる」と思い込み、無意識にエラーログを握りつぶしてしまいます。

実はこちらの方が厄介です。彼らはトラブルを甘く見積もり、「自分でなんとかして挽回しよう」「自分に対処させてほしい」という謎の責任感を発揮して、一人で火と戦い始めます。

誤解しないでいただきたいのですが、この「自分で解決しようとするチャレンジングな姿勢」自体は、本来評価すべき尊いものです。

しかし、システム設計の観点から言えば、そのチャレンジが許容されるのは「万が一失敗しても、システム全体がフェイルセーフ（安全な状態）に保たれ、すぐに誰かが助けてくれるセーフティネット」が担保されている時だけです。

PMの監視の目をすり抜け、自分一人ですべてを抱え込んだまま行うチャレンジは、ただの「命綱なしの綱渡り（システムの私物化）」であり、明らかな設計違反です。

では、この「悪気なく火事を隠蔽する部下」に対して、PMはどのようにアラートのルールを再定義し、ボヤの段階で強制的にSOSを出させる（ログを吐かせる）べきでしょうか？

ここから先の具体的な解決策・コマンドは、noteの記事「アーキテクトの過去問」として公開しています。

『失敗の科学』（マシュー・サイド）
失敗を責めずに「報告される仕組み」をつくる組織の考え方がわかる一冊。