フレームワーク活用ガイドひとことで言うと#
プロジェクトの終了後やインシデント発生後に「何が起きたか」「なぜ起きたか」「次にどう防ぐか」を体系的に振り返り、教訓を文書化して組織全体で共有する手法。「犯人探し」ではなく「仕組みの改善」が目的。
押さえておきたい用語#
- Blameless（ブレイムレス）
- 個人を責めず、仕組みやプロセスの改善に焦点を当てる文化のこと。ポストモーテムの大前提となる考え方。
- タイムライン（Timeline）
- インシデントやプロジェクトの主要イベントを時系列で整理した記録のこと。事実のみを記載し、解釈は入れない。
- 5 Whys（ファイブ ホワイズ）
- 「なぜ」を5回繰り返して表面的な原因から根本原因まで掘り下げる分析手法を指す。
- アクションアイテム（Action Items）
- 教訓から導き出される具体的な改善策のこと。担当者・期限を明記し、短期対策と長期対策に分ける。
ポストモーテムの全体像#
こんな悩みに効く#
- 同じような失敗やトラブルが何度も繰り返される
- プロジェクトの経験が属人化して、次のチームに活かされない
- インシデント対応が場当たり的で、根本解決につながっていない
基本の使い方#
何がいつ起きたかを時系列で整理する。
- プロジェクト/インシデントの開始から終了までの主要イベントを並べる
- 事実（ファクト）のみを記載する。解釈や評価は入れない
- 参加者全員の記憶を持ち寄って、正確な時系列を構築する
ポイント: **「誰がミスした」ではなく「何が起きた」**に焦点を当てる。人を責めない（Blameless）が大原則。
「なぜそれが起きたのか」を深掘りする。
- 「5つのなぜ（5 Whys）」で表面的な原因から根本原因まで掘り下げる
- 人的ミスの背景にある「仕組みの問題」を探す
- 複数の原因が絡み合っている場合は、すべて洗い出す
ポイント: 「担当者の不注意」で終わらせない。なぜ不注意が起きる仕組みだったのかを問う。
根本原因に対する具体的な改善策を決める。
- 「うまくいったこと」と「改善すべきこと」の両方を記録する
- 各改善策に担当者と期限を設定する
- 短期対策（すぐやる）と長期対策（仕組みを変える）に分ける
ポイント: 「気をつける」は対策ではない。チェックリスト、自動化、プロセス変更など、仕組みで解決する。
ポストモーテム報告書を作成し、組織全体でアクセスできるようにする。
- 概要、タイムライン、根本原因、教訓、アクションアイテムをまとめる
- 社内Wiki やドキュメント管理システムに保存する
- 関連チームやマネジメント層にも共有し、横展開できる学びは全社に広める
ポイント: 報告書は**「将来の誰か」が読んで役に立つ**ように書く。背景知識がない人にも伝わる文章に。
具体例#
タイムライン:
- 14:00 デプロイ実施（DBマイグレーション含む）
- 14:05 アラート発報（レスポンスタイム急増、平均200ms→3,500ms）
- 14:10 ユーザーからの問い合わせ42件受信
- 14:20 原因特定（インデックスが削除されたことによるフルスキャン発生）
- 14:35 ロールバック完了。サービス復旧
- 影響: 35分間のパフォーマンス劣化、推定売上損失85万円
根本原因（5 Whys）:
- なぜパフォーマンスが劣化した？→ インデックスがなくなった
- なぜインデックスが消えた？→ マイグレーションスクリプトに削除が含まれていた
- なぜレビューで見落とされた？→ DB影響の確認がレビュー項目にない
- なぜテストで検出されなかった？→ テスト環境のデータが100件しかない
- なぜテスト環境のデータが少ない？→ テストデータ整備の仕組みがない
アクション:
| 区分 | 施策 | 担当 | 期限 |
|---|---|---|---|
| 短期 | DBスキーマ変更PRにDBAレビュー必須化 | Aさん | 今週中 |
| 長期 | テスト環境に本番相当データ（10万件）投入 | Bさん | 来月末 |
| 長期 | スロークエリ自動検出をCI/CDに組み込み | Cさん | 来Q |
結果: 3ヶ月後のフォローアップで、DB関連障害がゼロに。テストデータ整備によりパフォーマンス劣化の事前検出率が100%に向上した。
プロジェクト概要: 自治体向け申請システムの受託開発。当初6ヶ月の計画が8ヶ月に延長、予算超過1,500万円。
タイムライン（主要マイルストーン）:
- 1ヶ月目: キックオフ。要件定義開始
- 3ヶ月目: 要件定義が2回やり直し。スケジュールに1ヶ月の遅延
- 5ヶ月目: 結合テストで重大バグ63件検出。追加工数が発生
- 7ヶ月目: UAT。ユーザーから「使いにくい」との大量フィードバック
- 8ヶ月目: 修正完了、リリース
根本原因分析:
| 問題 | 根本原因 | 構造的要因 |
|---|---|---|
| 要件定義のやり直し | 利用者の業務理解が浅いまま進めた | PM経験者がプロジェクトに1名のみ |
| 結合テストのバグ多発 | 単体テストのカバレッジが32%と低い | テスト工数が当初計画から30%カット |
| ユーザーの不満 | プロトタイプ検証を省略した | 「時間がない」で意思決定 |
アクション:
- [短期] 受託PJ開始時チェックリストに「利用者インタビュー5名以上」を追加
- [長期] テスト工数は全体の30%以上を確保する組織ルールを策定
- [長期] 200万円以上のPJはプロトタイプ検証を必須化
結果: 次の受託案件でチェックリストを適用したところ、要件定義のやり直しゼロ、計画通りの5ヶ月で完了。ポストモーテム報告書は社内のPM研修教材としても活用。
背景: 食品メーカーの新工場立ち上げ。50名体制、予算15億円。計画18ヶ月のところ20ヶ月で稼働開始（2ヶ月遅延）。稼働後の生産効率が目標の72%にとどまった（目標90%）。
ポストモーテムセッション: プロジェクト完了後1週間以内に、1日かけて全関係者30名で実施。
教訓（成功）:
- 建屋建設は計画通り完了。建設会社との週次進捗確認が有効だった
- 安全設備の設計では規制当局との早期相談が功を奏した
教訓（失敗）:
| カテゴリ | 状況 | 根本原因 | アクション |
|---|---|---|---|
| 設備調達 | 製造ラインの納品が3ヶ月遅延 | 発注時期が遅く、半導体不足の影響を受けた | 主要設備は計画開始6ヶ月前に発注 |
| 人材育成 | オペレーター教育が間に合わず稼働率低迷 | 教育計画が設備導入後に開始された | 設備導入と並行して教育を開始する |
| 試運転 | 試運転期間が1ヶ月では不十分だった | 初回で問題なく動く前提の計画だった | 試運転期間は最低2ヶ月を確保する |
結果: 次の工場立ち上げ（翌年）でこの教訓を全面適用。設備の早期発注で納期遅延ゼロ、並行教育で稼働初月から生産効率88%を達成。教訓データベースは社内の「工場立ち上げマニュアル」として定着した。
やりがちな失敗パターン#
- 犯人探しになる — 「誰がミスしたか」に議論が集中すると、次回から人がミスを隠すようになる。Blameless（人を責めない）文化がポストモーテムの前提条件
- アクションアイテムが実行されない — 教訓をまとめて満足し、改善策を実行しない。担当者と期限を明確にし、次の定例で進捗を確認する仕組みを作る
- 成功プロジェクトでやらない — 失敗時だけでなく、成功したプロジェクトでもポストモーテムを行う。「なぜうまくいったか」の分析が、成功の再現性を高める
- フォローアップを忘れる — アクションアイテムを設定しても、3ヶ月後に効果検証しないと改善が定着しない。フォローアップの日程をポストモーテム時に決めておく
まとめ#
ポストモーテムは、プロジェクトやインシデントから教訓を抽出し、組織全体の学びに変える振り返り手法。「犯人探し」ではなく「仕組みの改善」に焦点を当てるBlameless文化が前提。タイムライン→根本原因分析→教訓→アクションアイテムの流れで進め、報告書を組織に共有することで、同じ失敗の再発を防ぎ、チームの成熟度を高めていこう。