障害後の犯人探しを禁ずる「Blameless（非難なき）」ポストモーテムのSOP

導入前の課題（摩擦のピーク）

本番環境でのシステムダウン（障害）が発生した後、「なぜこんなミスをしたのか」「もっと注意しろ」と、ミスをしたエンジニア個人を詰問する会議（反省会）が開かれていました。 この「犯人探し（感情のノイズ）」は、個人の萎縮と「次からミスを隠そうとする隠蔽体質」を生み出し、根本的なシステム改善（パイプラインの修復）が放置されたまま、再び同じ障害が繰り返される最大の原因となっていました。

アルゴリズム化された「余白生成」へのアプローチ

1. 「人は必ず間違える」という前提の公式化（シキ） 「ヒューマンエラーは障害の原因ではない。ヒューマンエラーを許容してしまった『システムの脆弱性』が原因である」というBlameless（非難なき）の価値観を、組織の絶対ルールとして宣言します。

2. ポストモーテム（事後検証）ドキュメントのフォーマット化 障害復旧後、必ず「ポストモーテムの定型テンプレート（定位置）」をGoogle Docs等に作成します。

   • 書くこと: 「何が起きたか（タイムライン）」「根本原因（なぜそのミスが可能だったのか）」「再発防止のための具体的なシステム改修タスク（Todo）」
   • 禁止事項: 担当者の実名や「〇〇の不注意」といった属人的な表現（ノイズの完全排除）。

削除された摩擦と、創出された余白

| 項目 | 導入前（摩擦） | 導入後（余白） | | :--- | :--- | :--- | | 障害後の会議 | 担当者の謝罪と、精神論による「再発防止」（数時間） | ドキュメントベースでの「仕組みのバグ取り」 （淡々とした30分） | | 心理的安全性 | ミスを報告すれば怒られるため、ギリギリまで隠定する | ミスは「システムのバグを見つけるチャンス」として即時共有 | | 再発防止策 | 「ダブルチェックを徹底する」（手作業の摩擦増強） | 「CI/CDでその操作を弾くコードを書く」（アルゴリズム化） |

ROI（投資対効果）

「怒り」や「恐怖」という人間の感情の摩擦（ノイズ）を障害対応フローから完全に剥奪し、純粋な「工学的アプローチ（デバッグ作業）」へと昇華させました。

ポストモーテムのSOP化により、障害報告のスピード（MTTA）が飛躍的に向上。また、「個人の気合い」に依存した無意味なルールの増加が止まり、「自動テストの追加」や「権限の最小化」といったシステム的な解決策（堅牢なパイプラインの構築）だけにリソースが投資されるため、同種の障害に対する完全な再発防止率がほぼ100%に達します。