ポストモーテムとは？やり方・テンプレート・実例で学ぶプロジェクト振り返り【2026年版】

障害対応が終わった後、プロジェクトが完了した後、「振り返りをやろう」と言いながら実施されないまま次の案件が始まる。実施されても、報告書がフォルダに保存されて終わり、次のプロジェクトで同じ失敗が繰り返される。ポストモーテムはこの悪循環を断つための実践的な手法です。

本記事では、ポストモーテムの意味と由来、KPTやレッスンズラーンドとの違い、5ステップの進め方、会議で使える問いかけ、そのまま使えるテンプレート、そして記録をAIで自動化する方法までを一気に解説します。障害対応後のふりかえりにも、プロジェクト完了時の総括にも使える内容です。

⚠️ 本記事は、2026年8月時点の公開情報やユーザーフィードバックを基に独自にまとめたものです。

目次

1. ポストモーテムとは？
2. ポストモーテムとKPTとレッスンズラーンドの違い
3. ポストモーテムの進め方：5つのステップ
4. 振り返り会議のアジェンダと問いかけ
5. そのまま使えるポストモーテムテンプレート
6. ポストモーテムの実例
7. よくある失敗と対策
8. 記録をAIで自動化する
9. よくある質問（FAQ）
10. まとめ

ポストモーテムとは？

ポストモーテム（postmortem）とは、障害やプロジェクトの完了後に、何が起きたのか・なぜ起きたのか・次にどう活かすのかを構造的に記録し、組織の学びに変える振り返りの手法です。原義は「検死」で、そこから転じて「事後検証」を指すビジネス用語として定着しました。

この手法を広く知らしめたのは、GoogleのSRE（Site Reliability Engineering）の実践です。Googleが公開しているSRE本では、障害のたびにポストモーテムを書き、そこから得た対策を仕組みに反映することが、信頼性向上の中核として位置づけられています。そして最も重要な原則が「非難しない（blameless）」です。誰が悪かったのかを探し始めた瞬間、人は事実を隠すようになり、ポストモーテムは機能しなくなります。対象はあくまで仕組みとプロセスであり、個人ではありません。

もともとはシステム障害の文脈で使われてきましたが、現在ではプロジェクト完了時の総括にも同じ枠組みが使われています。マーケティング施策の振り返り、イベント運営の総括、開発プロジェクトの完了レビューなど、「一区切りついた仕事から学びを抽出する」場面すべてがポストモーテムの対象です。

使える学びは、次の3点セットで構成されます。

• 事実: 何が起きたか（評価や感想ではなく、観測できた事実）
• 原因と影響: なぜ起きたか。時間・費用・品質にどんな影響が出たか
• 提言: 次のプロジェクトや障害対応で、具体的に何をどう変えるか

ポストモーテムとKPTとレッスンズラーンドの違い

似た文脈で使われる3つの言葉は、実施のタイミングと目的が異なります。

3つは競合ではなく補完関係にあります。スプリントごとにKPTを回しているチームでも、プロジェクト完了時にはスプリント横断で大きな学びを抽出するポストモーテムが有効です。逆に、ポストモーテムだけを年に数回やっても、日々の進め方は改善されません。定期的な振り返りと事後検証を両輪にするのが実務的な運用です。

なお、日本の現場では「ポストモーテム」「振り返り」「反省会」「レッスンズラーンド」が混ざって使われることが多く、呼び方の統一より「事実で語る」「非難しない」「提言に落とす」という原則の共有のほうがはるかに重要です。

ポストモーテムの進め方：5つのステップ

ポストモーテムが失敗するのは、会議そのものより前後の設計です。プロセス全体を5つのステップで押さえます。

ステップ1: 記録は最後ではなく、進行中から集める。 最も価値ある観察はプロジェクトの途中に生まれ、完了時には忘れられています。プロジェクト開始時点で共有の記録ログを作り、気づいたことをメンバーが随時2〜3行で書き込める場所を用意しましょう。定例会議の議事録も、ブロッカーや想定外の出来事がすでに記録された貴重なソースです。

ステップ2: 事前に論点を絞る。 会議の前に、主催者がログを読み、テーマを分類（計画・コミュニケーション・技術・外部パートナーなど）して、影響の大きい3〜5個に絞ります。90分の会議で扱える論点は多くありません。

ステップ3: 振り返り会議を実施する。 プロジェクトに関わった主要な視点を全員そろえます。発注側・関係部署・必要なら外部パートナーも含めます。進行の詳細は次のセクションで解説します。

ステップ4: 学びを文章化する。 会議のメモを「事実・原因・影響・提言」の形式に整え、それぞれの学びに宛先を付けます。次のプロジェクトチーム、PMO、特定の部署など、誰がこれを読むべきかを明示しない学びは、誰にも届きません。

ステップ5: 仕組みに反映し、追跡する。 ここで価値が決まります。プロセス変更が必要な提言には担当者と期限を付ける。ドキュメントは古いプロジェクトのフォルダではなく、新しいプロジェクトが始まる場所（キックオフのチェックリスト、プロジェクト手順書、Wiki）に置く。新規プロジェクトのキックオフで、類似案件の過去のポストモーテムを読むことを定例にすると、学びのサイクルが閉じます。

振り返り会議のアジェンダと問いかけ

8人までのチームなら、プロジェクトの規模に応じて60〜120分を確保します。

1. 前提の共有（5分）。 対象期間・扱うテーマ、そして最重要ルールを宣言します。「この会議で扱うのは仕組みとプロセスであって、個人ではない」。問いは「誰が」ではなく「何が」「どうすれば」で始めます。

2. タイムラインの再構成（10分）。 マイルストーンと転換点を並べた簡単な時系列を全員で確認します。評価の前に記憶をそろえるステップで、これを飛ばすと8人が8つの違うプロジェクトについて議論することになります。

3. 先に書いてから共有（20〜30分）。 「うまくいったことと、その理由」「うまくいかなかったことと、その理由」を、まず各自が黙って書き出します。書いてから話すことで、声の大きい人がプロジェクトの解釈を先に固定してしまう事態を防げます。

4. 原因の深掘り（20〜30分）。 重要な論点について「なぜそうなったのか」「影響は何だったのか」を掘り下げます。症状ではなく対処可能な原因にたどり着くまで、「それはなぜ？」を重ねるのがコツです。

5. 提言の作成（15〜20分）。 優先テーマごとに、次のプロジェクトが実行できる提言をまとめます。「コミュニケーションを密にする」のような標語は禁止。「実装開始後の要件変更は、工数見積もりつきのチケット経由のみ受け付ける」のように、実行されたかどうかを後から判定できる形にします。

6. クロージング（5分）。 誰がドキュメントを仕上げるか、誰に届けるか、担当者が必要な項目はどれか。この3つを口頭で確認してから解散します。

議論が停滞したときの予備の問いかけも用意しておくと便利です。「このプロジェクトで一番驚いたことは？」「やり直せるとしたらどの意思決定？」「明日同じプロジェクトを始めるチームに何を伝えたい？」

そのまま使えるポストモーテムテンプレート

Wikiや共有ドキュメントにそのまま貼り付けて使えます。進行中のログと完了時の総括の両方をカバーする構成です。

# ポストモーテム – [プロジェクト名/障害名]
対象期間: [開始 – 終了] | 作成日: [日付]
参加者: [名前/役割]

## 学び[番号]: [短いタイトル]
- テーマ: [計画 / コミュニケーション / 技術 / 外部パートナー / ...]
- 事実: [何が起きたか]
- 原因: [なぜ起きたか]
- 影響: [時間・費用・品質・チームへの影響]
- 提言: [次のプロジェクトが具体的に何をすべきか]
- 宛先: [次のプロジェクトチーム / PMO / 〇〇部門]
- ステータス: [記録済み / 対策担当あり / プロセス反映済み]

## 続けること トップ3
- [うまくいったので標準化したいこと]

## 二度と繰り返さないこと トップ3
- [次回から変えること]

## 対策と担当者
- [ ] [担当者] – [対策] – [期限]

運用のコツは2つです。文章化する学びの数は絞ること。良質な10個は浅い40個に勝ります。そして「記録済み」と「プロセス反映済み」を厳密に区別すること。実際に何かを変えるのは後者だけです。

ポストモーテムの実例

「事実・原因・提言」の形式で書くと、学びはこうなります。

実例1: ソフトウェア開発プロジェクト。 事実: 2回のリリースの両方で、テスト工数が約40%超過した。原因: 外部システム2つとの連携仕様が固まる前に工数を見積もっていた。提言: テスト工数の見積もりは連携仕様レビューの後に行い、プロジェクト計画の独立した項目として管理する。宛先: 部門内の全プロジェクトリーダー（PMOチェックリスト経由）。

実例2: マーケティングキャンペーン。 事実: ランディングページの公開承認が2週間遅延した。原因: 法務レビューが工程として計画されておらず、担当部署が公開直前に案件を知った。提言: すべてのキャンペーン計画に、1週間のリードタイムを持つ法務レビューをマイルストーンとして組み込む。宛先: マーケティングチームのキャンペーン手順書。

実例3: システム障害対応。 事実: 深夜の障害発生から一次対応の開始まで40分を要した。原因: オンコールの引き継ぎ手順にモニタリングツールの権限確認が含まれておらず、担当者がログにアクセスできなかった。提言: オンコール引き継ぎチェックリストに主要ツールへのアクセス確認を追加し、四半期ごとに棚卸しする。宛先: SREチームのオンコール運用ガイド。

「コミュニケーションを改善する」「もっと早く計画する」といったよくある記述との違いは明白です。上の3つは、プロジェクトを知らないチームが読んでも、質問なしでそのまま実行できます。

よくある失敗と対策

• すべてを最終週に回す。 完了時にまとめて思い出そうとすると、観察ではなく記憶の穴が集まります。ステップ1の進行中ログが対策の半分を占めます。
• 問題だけを見る。 成功にも原因があります。なぜうまくいったのかを言語化しないと、再現できません。
• 事実ではなく評価を集める。 「ベンダーの対応が悪かった」は評価であり、相手を防御的にするだけです。「5回の納期のうち3回が事前連絡なしに延期された」は事実であり、提言につながります。
• 犯人探しになる。 「誰が」を問い始めた瞬間、正直な発言は止まります。ファシリテーターが積極的に止めなければ、会議は慎重な発言だけを生む場になります。
• ドキュメントをプロジェクトフォルダに埋葬する。 最も多い死因です。完成した、きれいな、誰にも見つけられないドキュメント。学びは新しいプロジェクトが始まる場所に置きます。
• 担当者を決めない。 プロセス変更を求める提言に持ち主がいなければ、それは願望のままです。
• 会議中の記録を取らない。 議論を記録しなければ、書記役が夜に思い出せた内容しか残りません。プロセスで最も費用のかかる部分、つまり議論そのものが失われます。

記録をAIで自動化する

ポストモーテムには慢性的なボトルネックが2つあります。プロジェクト進行中に観察を書き留める人がいないこと。そして会議中、1人がファシリテーションと思考と書記を同時にこなそうとして、議論の半分が失われることです。どちらも今は自動化できます。

SuperInternは、PCのデバイス音声から直接会議を記録するボットレスのデスクトップアプリ（Mac/Windows対応）です。会議にボットが参加しないため、Zoom・Google Meet・Microsoft Teams・Webexのどのプラットフォームでも、会議室での対面ミーティングでも同じように動作します。ポストモーテムの文脈では、次のような一気通貫のワークフローになります。

• 進行中ログが副産物として生まれる。 プロジェクトの定例会議はどのみち開催されます。議事録が自動で残っていれば、ブロッカーや意思決定や想定外の出来事は、振り返りの時点ですでに記録済みです。記憶からの再構成が不要になります。
• 振り返り会議が自分たちの構造で記録される。 AIキャンバス（AI Canvas）にフォーマットを一度だけ登録します。「これはポストモーテムの会議。テーマごとに事実・原因・影響・提言を分類し、対策には担当者を付けて記録する」と指定すれば、議論と同時にライブノートがその構造で書き上がっていきます。

• 書記役でメンバーが1人潰れない。 ファシリテーターは進行に、チームは議論に集中でき、会議終了と同時に記録が完成しています。生ログを最終的な学びに編集する作業は残りますが、再構成の作業は消えます。
• 会議横断の質問ができる。 「このプロジェクトの定例で繰り返し出たブロッカーは？」「完了時の振り返りで外部パートナーについて何を記録した？」のように、AIチャットで複数の会議をまたいだ質問ができます。
• 多国籍チームの振り返りにも対応。 50以上の言語をリアルタイム翻訳できるため、海外拠点を交えたポストモーテムでも、要約は自分の言語で受け取れます。

正直な注意点も書いておきます。SuperInternはライブの会議とその後処理に特化したデスクトップアプリで、ナレッジベースやプロジェクト管理ツールの代替ではありません。多くのチームは、SuperIntern MCP経由でClaudeやChatGPTなどのエージェントと接続し、学びや対策をConfluence・Notion・Jira・Linearに直接反映する使い方をしています。無料プランがあるので、次の定例会議から試すコストはかかりません。

よくある質問（FAQ）

ポストモーテムとはどういう意味ですか？

原義は「検死」で、そこから転じて、障害やプロジェクトの終了後に何が起きたか・なぜ起きたか・次にどう活かすかを検証して記録する「事後検証」を指します。IT業界ではGoogleのSREの実践を通じて広まりました。

ポストモーテムはいつ実施すべきですか？

障害対応なら復旧後できるだけ早く、記憶が新しいうちに実施します。プロジェクトの場合は、完了時に加えて、6か月を超える案件ならフェーズや四半期ごとの中間実施がおすすめです。記憶は急速に薄れ、中間で得た学びは同じプロジェクト内でまだ活かせます。

「非難しない（blameless）」とはどういうことですか？

個人の責任追及をせず、仕組みとプロセスの改善に焦点を当てる原則です。ミスをした個人を罰する組織では、次から事実が報告されなくなり、検証に必要な情報自体が集まらなくなります。「人は誰でもミスをする。ミスが事故につながった仕組みを直す」が基本の考え方です。

ポストモーテムとKPTはどう使い分けますか？

KPTはスプリントごとなど定期的にチームの進め方を改善する手法で、ポストモーテムは障害や案件の完了という節目に原因と学びを深掘りする手法です。日常はKPT、節目はポストモーテムという併用が実務的です。

ポストモーテムのドキュメントはどう管理すべきですか？

学びごとに「事実・原因・影響・提言・宛先・ステータス」の統一フォーマットで記録します。フォーマット以上に重要なのは置き場所です。古いプロジェクトのフォルダではなく、新しいプロジェクトの計画時に必ず目に入る場所（キックオフのチェックリストやWiki）に置き、キックオフで読む運用を定例化します。

障害が起きていなくてもポストモーテムはやるべきですか？

有効です。成功したプロジェクトにも「なぜうまくいったのか」という検証価値があり、再現可能な成功要因の言語化は失敗分析と同じくらい価値があります。成功時こそ関係者が協力的で、率直な議論がしやすいという利点もあります。

まとめ

ポストモーテムは、報告書を書くための儀式ではなく、組織が同じ失敗に二度コストを払わないための仕組みです。成立条件はシンプルです。進行中から記録を集める。事実で語り、非難しない。提言には宛先と担当者を付ける。そしてドキュメントは、古いプロジェクトの墓場ではなく、新しいプロジェクトの出発点に置く。

そのなかで最も手間のかかる部分、つまり会議と議論の漏れのない記録は、もう人間が手作業でやる必要はありません。ボットレスのAIアシスタントにポストモーテムのフォーマットを一度教えれば、定例も振り返り会議も構造化されたノートとして自動で残り、チームは本来の仕事である「原因を理解し、変える」に集中できます。

SuperInternを無料で試す 。会議にボットは入れず、ポストモーテムのフォーマットどおりにライブノートを自動作成。プロジェクトの全会議を横断して検索できます。