インシデントを学習機会として扱う
ルール
インシデントが発生したとき、以下の問い方を徹底する：
- NG：「誰がやらかしたのか」「なぜ確認しなかったのか」
- OK：「どんな条件が重なって障害が起きたか」「システムのどこが人間のミスを誘発したか」
そのうえで、ポストモーテムを通じて得た知識をチーム全体で共有し、再発防止策を実行する。
理由
個人を責めると：
- エンジニアが失敗を隠す or 過度にリスクを避けるようになる
- 表面的な「注意する」という再発防止策に終わる
- 組織の学習機会が失われる
「システムの問題」として捉えると：
- 根本原因にたどり着ける（「なぜミスを誘発する設計になっているのか」）
- チームの心理的安全性が高まり、詳細な経緯が共有される
- 同じパターンの障害を組織全体で防げる
実践
- インシデント後48〜72時間以内にポストモーテムのドラフトを作成
- ポストモーテムを社内で公開し（オプトインで通知）、他チームの学習にも使う
- 特に重要な教訓は「障害のレポート」として定期的にまとめ組織に共有
例外
- 意図的な悪意ある行為（sabotage）は別途対処が必要
- ただし、ほとんどのインシデントはシステム・プロセスの問題であり、個人の悪意ではない
関連パターン
- 非難のないポストモーテム — 学習を実践するための具体的なプロセス
出典
Google SRE Workbook（Betsy Beyer他）第10章「Postmortem Culture: Learning from Failure」