フレームワーク活用ガイドひとことで言うと#
障害やミスが起きたとき、個人を責めず、仕組みの問題に焦点を当てて振り返る手法。GoogleのSREチームやEtsyのエンジニアリング文化から広まった。「誰がやらかしたか」ではなく「なぜシステムがそれを防げなかったか」を問う。
押さえておきたい用語#
- ポストモーテム（Postmortem）
- もともと医学用語で「死後検査」を意味し、ITでは障害やインシデント発生後に行う振り返りを指す。
- ブレイムレス（Blameless）
- 個人を非難しないという原則。ミスをした人を罰するのではなく、ミスを誘発した環境や仕組みの改善にフォーカスする考え方。
- タイムライン
- インシデント発生から復旧までの時系列記録。誰が・何時に・何をしたかを客観的に並べたもので、ポストモーテムの土台になる。
- アクションアイテム
- 振り返りの結果として決まる具体的な改善施策。担当者・期限・完了条件を明記する。
ブレイムレス・ポストモーテムの全体像#
こんな悩みに効く#
- 障害が起きるたびに犯人探しになり、チームの雰囲気が悪化する
- 同じような障害が繰り返し発生している
- 振り返りはしているが、改善策が実行されずに終わる
基本の使い方#
時間が経つと記憶が薄れ、感情も冷めて「もういいか」となる。早めに開催する。
- 対応に関わった全員を招集（エンジニア、運用、カスタマーサポートなど）
- ファシリテーターは当事者以外が望ましい
- 冒頭で「この場は個人を責める場ではない」と明言する
「誰が悪かったか」ではなく「何が起きたか」をファクトベースで並べる。
- アラートのログ、Slackの会話、デプロイ履歴を時系列に整理
- 「10:03 Aさんがデプロイを実行」は事実。「Aさんがテストを怠った」は解釈（この段階では書かない）
「なぜ」を5回繰り返すなどして、表面的な原因の奥にある構造的問題を掘る。
- なぜデプロイ後にエラーが出た？ → テストが不足 → なぜ？ → CIにそのテストがなかった → なぜ？ → テスト追加のプロセスが未定義
- 着地点は必ず「仕組み・プロセス・ツール」にする
「気をつける」は改善策ではない。具体的なタスクに落とす。
- 各アクションに担当者・期限・完了条件を設定
- 次の週次ミーティングで進捗を確認する
- ポストモーテムドキュメントは全社に公開する
具体例#
インシデント概要: ブラックフライデーセール中に決済APIがタイムアウトし、約2時間で 推定売上450万円 を失った。
タイムライン（抜粋）
| 時刻 | 事象 |
|---|---|
| 14:02 | セール開始、トラフィックが通常の8倍に急増 |
| 14:15 | 決済API応答時間が3秒を超過、アラート発報 |
| 14:22 | エンジニアAがスケールアウトを試みるがDB接続数上限に到達 |
| 14:45 | DB接続プールの上限を引き上げ、復旧開始 |
| 16:10 | 完全復旧を確認 |
根本原因の分析（ブレイムレスで）
- 「Aさんの対応が遅かった」→ ではなく「セール時の負荷見積もりプロセスがなかった」
- 「DBの設定が甘かった」→ ではなく「負荷テストがセールの想定トラフィックをカバーしていなかった」
アクションアイテム
- セール前に想定トラフィックの2倍で負荷テストを実施する手順書を作成（担当: インフラチーム、期限: 2週間）
- DB接続プールの動的スケーリングを導入（担当: SRE、期限: 1か月）
翌年のブラックフライデーではトラフィックが前年比 1.5倍 に増えたが、決済障害はゼロで乗り切った。
インシデント概要: 自動車部品メーカー（従業員200名）で、出荷前検査をすり抜けた不良品が顧客に届いた。回収コスト 約300万円。
従来の振り返り（ブレイムあり）
- 「検査担当のBさんが見落とした」→ Bさんが始末書を提出 → 翌月、Bさんが退職
ブレイムレスに切り替えた振り返り
- 検査は1人体制で1日200個を目視チェック → 疲労によるエラー率は 午後に3倍 になるデータが判明
- 検査基準書のフォントが小さく、照明も暗かった → 物理的に見えにくい環境
- ダブルチェック体制がなく、1人のミスが即出荷に直結する構造だった
アクションアイテム: 午前・午後で担当を交代する2人体制の導入、検査エリアの照明を500ルクスに改善、画像検査AIの導入検討（3か月以内にPoC）
導入半年後、不良品の顧客到達件数は 月3件 → 月0.2件 に減少した。
インシデント概要: 社員15名のHRテックスタートアップで、テスト環境に本番の顧客データがコピーされていることを新入社員が発見。実害はなかったが、個人情報保護法違反のリスクがあった。
ポストモーテムで判明したこと
- テスト環境構築手順書に「本番DBのダンプを使ってよい」と記載されていた（3年前に書かれたまま放置）
- 手順書のレビュー体制がなく、誰も内容を更新していなかった
- 新入社員は「おかしい」と思ったが、2日間言い出せなかった → 入社オンボーディングで「問題を報告する文化」の説明がなかった
アクションアイテム
- テスト環境は匿名化済みデータのみ使用するルールを策定し、CIで自動チェック（2週間）
- 全手順書を半年に1回レビューするカレンダーリマインダー設定（1週間）
- オンボーディング資料に「問題を見つけたらすぐ報告」のセクション追加（1週間）
発見した新入社員を全社ミーティングで称え、「見つけてくれたおかげで大事に至らなかった」とCTOが直接伝えた。
やりがちな失敗パターン#
- 「ブレイムレス」と言いながら犯人探しをする — 「ブレイムレスですが、なぜAさんはテストしなかったのですか？」は結局責めている。主語を「人」から「プロセス」に変える習慣が必要
- アクションアイテムが「気をつける」で終わる — 人間の注意力に頼る対策は再発を防げない。仕組み・自動化・チェックリストなど、構造的な改善に落とす
- ドキュメントを書いて終わりにする — 書いた文書が読まれず、同じ障害が再発する。全社公開し、類似チームに「うちでも起きうる」と自分事化してもらう
- ポストモーテムを開催しない — 「軽微だったからいいか」と省略すると、小さな問題が積もって大障害になる。影響度に関わらず実施する文化が大事
まとめ#
ブレイムレス・ポストモーテムは「人を罰する文化」から「仕組みを改善する文化」への転換。個人の責任を問わないことで正直な情報が集まり、根本的な改善につながる。「止めた人を称える」アンドンコードと同じ思想で、失敗を組織の学びに変えていく仕組みだ。