フレームワーク活用ガイドひとことで言うと#
障害やミスが起きたとき、個人を責めず、仕組みの問題に焦点を当てて振り返る手法。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が直接伝えた。
ポストモーテム・テンプレート#
実際の会議で使えるドキュメントテンプレート。Google Docs やNotionにコピーして使う。
# ポストモーテム: [インシデント名]
**作成日:** YYYY-MM-DD **作成者:** ___
**影響期間:** YYYY-MM-DD HH:MM ～ YYYY-MM-DD HH:MM（合計 ___時間）
**影響範囲:** 例）決済機能が全ユーザーに利用不可／○件の注文が処理不能
**重大度:** P0（サービス停止）/ P1（主要機能障害）/ P2（一部機能障害）
---
## タイムライン（事実のみ記録）
| 時刻 | 事象 | 対応者 |
|------|------|--------|
| HH:MM | 〇〇が発生 | ─ |
| HH:MM | △△がアラートを確認 | Aさん |
| HH:MM | □□を実施 | Bさん |
| HH:MM | 復旧確認 | ─ |
---
## 根本原因（仕組み・プロセス・ツールの問題として記述）
- 直接原因: 例）デプロイスクリプトのXXXが誤作動した
- 根本原因: 例）デプロイ前のチェックリストにXXXのテスト項目がなかった
- 要因（なぜ防げなかったか）:
1. ___
2. ___
---
## 影響の見積もり
- ユーザー影響: 例）約○○人が○○できなかった
- ビジネス影響: 例）推定売上損失○○万円、サポート問い合わせ○○件増
- 評判影響: 例）SNSで○件の言及
---
## 今後行うこと（アクションアイテム）
| # | 内容 | 担当者 | 期限 | 完了確認 |
|---|------|--------|------|---------|
| 1 | ___ | ___ | MM/DD | [ ] |
| 2 | ___ | ___ | MM/DD | [ ] |
| 3 | ___ | ___ | MM/DD | [ ] |
---
## 今後行わないこと（What went well / What to keep）
- ___（迅速な対応など、うまくいったことも記録する）
---
## このドキュメントの公開範囲: 全社公開 / エンジニア限定やりがちな失敗パターン#
- 「ブレイムレス」と言いながら犯人探しをする — 「ブレイムレスですが、なぜAさんはテストしなかったのですか？」は結局責めている。主語を「人」から「プロセス」に変える習慣が必要
- アクションアイテムが「気をつける」で終わる — 人間の注意力に頼る対策は再発を防げない。仕組み・自動化・チェックリストなど、構造的な改善に落とす
- ドキュメントを書いて終わりにする — 書いた文書が読まれず、同じ障害が再発する。全社公開し、類似チームに「うちでも起きうる」と自分事化してもらう
- ポストモーテムを開催しない — 「軽微だったからいいか」と省略すると、小さな問題が積もって大障害になる。影響度に関わらず実施する文化が大事
まとめ#
ブレイムレス・ポストモーテムは「人を罰する文化」から「仕組みを改善する文化」への転換。個人の責任を問わないことで正直な情報が集まり、根本的な改善につながる。「止めた人を称える」アンドンコードと同じ思想で、失敗を組織の学びに変えていく仕組みだ。
参考・原典#
- Allspaw, J. (2012). “Blameless PostMortems and a Just Culture.” Etsy Engineering Blog. — ブレイムレス文化をエンジニアリング組織に広めた先駆的ブログ記事。元EtsyのCTOによる実践報告。
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media. — GoogleのSRE実践書。第15章でポストモーテム文化と具体的なテンプレートを詳述。無料公開版
- Dekker, S. (2006). The Field Guide to Understanding ‘Human Error’. Ashgate Publishing. — 航空・医療分野の安全工学から「ジャスト・カルチャー」の理論的基盤を提供した原著。
- Google SRE: Postmortem Template — Googleが公開するポストモーテムのテンプレート例。