ポストモーテムのファシリテーション：「犯人探し」にならない振り返りの進め方

プロジェクトが炎上した後のポストモーテム（事後分析）は、適切に行えば組織の最大の学習機会になる。しかし適切に行われなければ「犯人探し・つるし上げ・逃げの言い訳大会」になって、誰も本音を言わないまま終わる。

本稿では、ポストモーテムを「犯人ではなく原因を探す」場にするためのファシリテーション手順を解説する。

ポストモーテムの前提：Blameless（責任追及なし）の宣言

Googleが「Site Reliability Engineering（SRE）」の文化として広めたBlameless Post-mortemの概念は、「問題が起きた時、個人を責めるのではなくシステム・プロセスの改善に焦点を当てる」というものだ。

これはポストモーテム開始前に、ファシリテーターが明示的に宣言する。

「今日の振り返りのルールを確認します。

1. 個人を責めません——問題はシステムとプロセスにあります
2. 正直に話すことを評価します——本音を言ってくれることがチームを強くします
3. 今日の目的は犯人を特定することではなく、
   同じ問題が二度と起きないための改善策を見つけることです」

Phase 1：タイムラインの構築（20分）

何が・いつ・どんな順序で起きたかを、全員で一緒に時系列に整理する。

ホワイトボードやMiroのタイムラインで視覚化する。各イベントを「何が起きたか（事実）」として書き、「なぜ起きたか（原因）」はここでは書かない。

目的：記憶の統合と共通認識の形成。「あの時こうだった」という食い違いをここで解消する。

Phase 2：インパクトの確認（10分）

炎上がどんな影響を与えたかを整理する。

感情的にならずに数字と事実で整理する。「これは深刻だったのか軽微だったのか」を全員が共通認識として持つことが次のフェーズに必要だ。

Phase 3：根本原因の探索（30分）

5 Whys（なぜなぜ分析）を使って根本原因を探る。

重要なファシリテーションのコツ： 「なぜこれが起きたのか？」と問う時、個人の名前を出さない。「〇〇さんがチェックしなかったから」ではなく「チェックのプロセスがなかったから」という言い方にリフレームする。

個人の名前が出てきた場合のリフレームフレーズ：「〇〇さんがその判断をした時、判断を支援する情報・プロセス・権限はありましたか？」

Phase 4：改善策の策定（20分）

根本原因に対して、具体的な改善策を決める。

改善策のフォーマット：
- 課題：[根本原因]
- 改善策：[具体的なアクション]
- 担当者：[誰が実施するか]
- 期日：[いつまでに]
- 完了基準：[何をもって完了とするか]

Phase 5：クロージング（10分）

今日の振り返りで「良かったこと」を1〜2点確認して終わる。炎上の後は「全てが悪かった」という空気になりがちだが、「うまく機能した部分」を認識することも重要だ。

書籍紹介

著者: PMI — ウォーターフォール・アジャイル・ハイブリッド対応の業界標準PM教科書

セッション後24〜48時間以内に、ポストモーテムレポートをまとめて関係者に共有する。

レポートの構成：

このレポートは社内の他チームとも共有する価値がある。「別のチームで同じ問題が起きないように」という組織学習への貢献が、ポストモーテムの最大の価値だ。

ポストモーテムの品質はファシリテーターの姿勢に直結する。「Blameless」の宣言と、個人ではなくシステム・プロセスへのフォーカスを徹底することで、参加者が本音を話せる場が作れる。本音が出る場からこそ、真の根本原因が発見される。