「やってよかった」と思える振り返り会議は、なぜこんなに少ないのか
プロジェクトが無事に完了した。納品も終わった。チームメンバーもほっと一息ついている。そのタイミングで「振り返り会議をやりましょう」と声がかかる。
会議室に集まって、ホワイトボードに「良かったこと」「悪かったこと」「次にやること」と書き出す。数人が当たり障りのない感想を述べ、30分ほどで終了。議事録はSharePointに保存されるが、次のプロジェクトで誰かがそれを読み返すことはない。
この光景に心当たりがある方は多いのではないでしょうか。
プロジェクトの振り返り、いわゆるポストモーテム（post-mortem）は、本来とても価値の高い活動です。同じ失敗を繰り返さず、うまくいった方法を組織の資産にできる。しかし現実には、「やること自体が目的化」して形骸化しているケースがほとんどです。
この記事では、なぜ振り返りが形だけで終わるのかを構造的に分析し、次のプロジェクトに確実に活かせるポストモーテムの進め方を具体的に解説します。
ポストモーテムとは何か
ポストモーテムは元々、医療分野で使われていた「死後検査」を意味する言葉です。ソフトウェア開発やプロジェクト管理の文脈では、プロジェクト完了後（あるいは障害発生後）に実施する振り返り分析を指します。
GoogleのSRE（Site Reliability Engineering）チームがポストモーテム文化についてのドキュメントを公開したことで、IT業界を中心に広く知られるようになりました。ただし、この手法はIT企業だけのものではありません。製造業、建設業、サービス業など、プロジェクト単位で仕事を進める組織であれば、どこでも活用できます。
似た概念としてレトロスペクティブ（retrospective）があります。アジャイル開発では各スプリント終了後にレトロスペクティブを行いますが、ポストモーテムはプロジェクト全体や重大インシデントを対象とする点で、より大きなスコープを扱います。
振り返りが形骸化する3つの構造的原因
「うちの振り返りは意味がない」と感じている場合、その原因は参加者の意識ではなく、仕組みの問題であることがほとんどです。
原因1: 心理的安全性が確保されていない
従業員80名、営業拠点3箇所の専門商社での話です。四半期ごとの大型案件が終わるたびに振り返り会議を実施していましたが、出てくる意見はいつも「コミュニケーションをもっと密にすべきだった」「スケジュールに余裕を持つべきだった」といった抽象的なものばかりでした。
原因を掘り下げてみると、振り返り会議にプロジェクトオーナー（部長クラス）が同席しており、メンバーが本音を言えない状況になっていました。「あの判断が遅れたせいで2週間押した」という事実を、判断した本人の前では言いにくい。これは個人の勇気の問題ではなく、会議設計の問題です。
Googleの研究プロジェクト「Project Aristotle」でも、チームの生産性に最も影響する要因は心理的安全性だと報告されています。振り返りの場でこれが欠けていれば、表面的な意見しか出てこないのは当然です。
原因2: 振り返りの成果物が「議事録」で止まっている
振り返りで出た改善案が、会議後にどこに行くのか。多くの場合、議事録としてファイルサーバーに保存されて終わりです。
問題は「保存されること」ではなく、「次のプロジェクトの計画フェーズで参照される仕組みがないこと」にあります。議事録を書くこと自体は悪くありませんが、それが次のプロジェクトのキックオフ資料やチェックリストに反映されなければ、学びは組織に定着しません。
原因3: 開催タイミングが遅すぎる
プロジェクト完了から振り返りまでに2週間以上空くと、記憶が曖昧になります。さらに、メンバーはすでに次のプロジェクトに入っており、「前のプロジェクトの振り返り」にモチベーションを持てません。
逆に、完了直後すぎるのも問題です。疲労が残った状態では冷静な分析ができず、感情的な議論になりやすくなります。適切なタイミングは、プロジェクト完了後3〜5営業日以内です。
成果につながるポストモーテムの5ステップ
形骸化を防ぎ、次のプロジェクトに活かせるポストモーテムの進め方を、具体的な手順で解説します。
ステップ1: 事前に「事実」を集めておく
会議の場で「何が起きましたか？」と聞くのは非効率です。記憶に頼ると、声の大きい人の印象が全体の認識になってしまいます。
会議の2〜3日前に、参加者全員に以下のフォーマットで事前アンケートを送りましょう。
うまくいったことを具体的に1〜3つ（「何を」「どうした」結果「どうなった」の形式で）
うまくいかなかったことを具体的に1〜3つ（同じ形式で）
次回やるなら変えたいことを1〜2つ
ポイントは「具体的に」という指定です。「コミュニケーションが不足していた」ではなく「要件変更がSlackの個別DMだけで共有され、チームの半数が把握していなかった」のように、事実ベースで書いてもらいます。
ステップ2: 「人」ではなく「プロセス」にフォーカスするルールを宣言する
ポストモーテムの冒頭で、ファシリテーターが必ず以下を宣言します。
「この振り返りは、誰かの責任を追及する場ではありません。プロセスや仕組みの改善点を見つけることが目的です。」
これは形式的な前置きではなく、会議中に実際に守らなければならないルールです。「あの人がレビューを遅らせた」という発言が出たら、「レビューが遅れた原因はどんな仕組みの問題だったか」に変換するのがファシリテーターの役割です。
PMI（Project Management Institute）のガイドラインでも、blame-free（非難しない）環境の構築がレトロスペクティブ成功の鍵であると強調されています。
ステップ3: KPTではなく「タイムライン分析」から始める
多くの振り返りで使われるKPT（Keep/Problem/Try）は優れたフレームワークですが、いきなりKPTから始めると議論が散漫になりがちです。
代わりに、まずタイムライン分析を行います。プロジェクトの主要なマイルストーンを時系列で並べ、各フェーズで何が起きたかを可視化します。
例えば、従業員150名の製造業でERPシステムの導入プロジェクトを振り返った際のタイムラインはこのような形になりました。
4月: 要件定義開始 → 予定通り
5月: ベンダー選定 → 2週間遅延（評価基準の合意に時間がかかった）
6月〜8月: 開発・カスタマイズ → 予定通り
9月: 受入テスト → 3週間遅延（テストデータの準備不足、テストシナリオの網羅性不足）
10月: 本番移行 → 1週間遅延（データ移行で想定外のエラー）
タイムラインを見ると、遅延の主因が「受入テスト」フェーズに集中していることが一目でわかります。ここに改善の優先度をつけるべきだと、参加者全員が納得できます。
タイムラインで全体像を共有した後に、KPTやその他のフレームワークで深掘りすると、議論の焦点が定まり、実効性の高い改善案が出やすくなります。
ステップ4: 改善アクションは「担当者・期限・次のプロジェクト名」をセットで決める
振り返りから出た改善案を「次はこうしよう」で終わらせると、確実に忘れ去られます。改善アクションには必ず以下の3要素を付けてください。
担当者 — 誰がこの改善を実行するか
期限 — いつまでに完了させるか
適用先 — 次のどのプロジェクトで最初に適用するか
たとえば「受入テストのテストシナリオを事前にレビューする」という改善案なら、「品質管理チームの山田さんが、4月15日までにテストシナリオのレビューチェックリストを作成し、5月開始のB社案件で初適用する」まで決めます。
ステップ5: 改善アクションを「プロジェクト開始チェックリスト」に組み込む
ここが最も重要なステップです。改善アクションを議事録とは別の場所、具体的にはプロジェクト開始時のチェックリストやテンプレートに反映します。
新しいプロジェクトが始まるとき、マネージャーがチェックリストを開くと「過去の振り返りから: 受入テストのシナリオレビューを計画フェーズで実施すること」と書かれている。これなら、振り返りの成果が自然に次のプロジェクトに引き継がれます。
プロジェクト開始時のチェックリストの設計方法については、プロジェクトの炎上を防ぐキックオフ会議チェックリストでも詳しく解説していますので、あわせて参考にしてみてください。
IPA（独立行政法人情報処理推進機構）が公開しているソフトウェア開発プロセスのガイドラインでも、過去プロジェクトの教訓を組織的に蓄積・活用する仕組みの重要性が指摘されています。
振り返りの「質」を上げるファシリテーションのコツ
ポストモーテムの質は、ファシリテーターの力量に大きく左右されます。いくつかの実践的なテクニックを紹介します。
「5 Whys」で表面的な原因を掘り下げる
「スケジュールが遅延した」→「なぜ？」→「テスト工程が長引いた」→「なぜ？」→「テストデータの準備に時間がかかった」→「なぜ？」→「本番環境のデータ構造が想定と違った」→「なぜ？」→「要件定義時にデータ移行の調査が不十分だった」
トヨタ生産方式で有名なこの「なぜを5回繰り返す」手法は、プロジェクトの振り返りでも非常に有効です。表面的な症状ではなく、根本原因にたどり着くことで、本質的な改善策が見えてきます。
沈黙を恐れない
質問を投げかけた後、すぐに誰かが答えないと気まずくなって、ファシリテーター自身が話し始めてしまうケースがよくあります。しかし、沈黙は参加者が考えている時間です。最低10秒は待ちましょう。
良かったことにも同じ時間をかける
改善点ばかりに時間を使い、「良かったこと」を流してしまう振り返りは少なくありません。しかし、これは非常にもったいないことです。うまくいったことを分析し、「なぜうまくいったのか」を言語化することで、再現性のある成功パターンを組織の資産にできます。
成功を「たまたまうまくいった」で片付けず、成功の要因を構造的に理解する。これがポストモーテムの見落とされがちな価値です。
ポストモーテムを組織文化として定着させるために
個別のプロジェクトで良い振り返りができたとしても、それが一度きりでは組織の力になりません。文化として根付かせるためのポイントを整理します。
経営層が「学びの場」として認知する
振り返りを「反省会」ではなく「学びの場」として位置づけることが重要です。経営層が「振り返りで見つかった改善点を報告してほしい」と求めるのか、「振り返りで誰が悪かったのか教えろ」と求めるのかで、組織全体の姿勢が決まります。
振り返りの「成功事例」を共有する
「前回の振り返りで出た改善策が、今回のプロジェクトで実際に効果を発揮した」という事例を社内で共有することで、振り返りの価値が目に見えるものになります。すると、他のチームも「自分たちもしっかりやろう」という動機が生まれます。
カスタマーサポート領域でも、対応品質の振り返りと改善の仕組みを体系化している組織は顧客満足度の向上が顕著だという調査があります。振り返りの文化は、プロジェクトマネジメントに限らず組織全体の改善力を底上げします。
テンプレートを用意し、ハードルを下げる
振り返りのフォーマットが毎回バラバラだと、ファシリテーターの負担が大きく、質にもばらつきが出ます。組織として標準的なテンプレート（事前アンケート、タイムライン分析シート、改善アクションシート）を用意しておくと、誰がファシリテーターを務めても一定の質を保てます。
経済産業省のDXレポートでも、組織的な学習サイクルの確立がデジタルトランスフォーメーション推進の基盤になると述べられています。ポストモーテムの仕組み化は、まさにこの学習サイクルの実装そのものです。
まずは来週、ここから始めてみてください
直近で完了したプロジェクト（あるいは完了間近のプロジェクト）が一つはあるはずです。
来週、そのプロジェクトのメンバーに「15分だけ、振り返りの事前アンケートに回答してもらえませんか」と声をかけてみてください。アンケートのフォーマットは、この記事で紹介した3項目（うまくいったこと、うまくいかなかったこと、次回変えたいこと）で十分です。
アンケートの回答が集まったら、それをもとに1時間の振り返り会議を設定する。そのとき「プロセスの改善が目的であって、個人の責任追及ではない」と冒頭で宣言することだけは忘れないでください。
小さく始めて、一度でも「この振り返りは意味があった」とチームに感じてもらえたら、次からは自然と続いていきます。完璧なポストモーテムをいきなり目指す必要はありません。まず一歩、始めてみることが大切です。