どの流れも、目指しているものは同じです。経験を、組織の資産に変えること。違うのは、扱う対象がプロジェクトか障害か、いつやるか、そして「人をどう扱うか」にどこまで踏み込んでいるかです。

プロジェクトの学びを保存する

1990年代〜／Norman L. Kerth『Project Retrospectives: A Handbook for Team Reviews』(2001)

プロジェクトが終わったあと、そこで得た学びを保存するための方法として整理されました。失敗だけでなく成功も含めて扱うのが特徴です。

この本がよく知られているのは、最優先指令（Prime Directive）の出どころだからです。

Kerthは、レトロスペクティブとポストモーテムを呼び分けていました

あまり知られていませんが、この本にはポストモーテムのための章が2つあります。第7章「Leading a Postmortem（ポストモーテムを率いる）」と、第8章「Postmortem Exercises（ポストモーテムの演習）」です。なお、この本には「レトロスペクティブとポストモーテムの重要な違い」という節もあります。

第7章の中身は、スペースシャトル・チャレンジャー号の話から始まり、「失敗したプロジェクトの経験を変換する」と続きます。つまりKerthにとって、ポストモーテムとは失敗したプロジェクトを扱うものでした。通常のプロジェクトは retrospective（レトロスペクティブ）、失敗したプロジェクトは postmortem（ポストモーテム）、という呼び分けです。

さらに注目したいのが、第7章に「ポストモーテムを率いる資格」という節があることです。失敗の場は感情が強く出るため、誰がファシリテートしてもよいものではない、という立場が最初から示されています。

「とりあえず反省会をやろう」と言われたとき、思い出したい話です。失敗を扱う場は、通常のふりかえりより難しい。20年以上前から、そう言われています。

いま

Kerthが想定していたのは、プロジェクト全体を終えたあとの、数日がかりの大きな場でした。その後アジャイルが広がるなかで、レトロスペクティブはスプリントごとの短いサイクルへと姿を変えていきます。大きく1回から、小さく何度も、という方向です。

一方で、失敗を扱う場の難しさについての指摘は、いまも古びていません。この本には「レトロスペクティブの暗い側面」という節や、「法務部門を巻き込むべきとき」という記述まであります。記録を安全な場所に置く（人事評価に使われないようにする）という配慮も、当時から書かれていました。

教訓として、組織に残す

1996年〜／PMI『PMBOK Guide』

プロジェクトマネジメントの標準では、ポストモーテムにあたるものを「教訓」と呼びます。プロジェクトやフェーズの終結プロセスの中で、教訓を特定して文書化し、組織が将来使えるようにアーカイブする、という位置づけです。

教訓登録簿は、失敗の記録簿ではありません

教訓をまとめた文書を教訓登録簿と呼びます。書く内容は、成功、失敗、うまくいく条件、失敗する条件、遂行上の注意事項。加えて、実際の状況や背景、実際に行った行動、本来行うべきだった行動、影響範囲です。

ここで押さえておきたいことが2つあります。

• 「教訓」という名前ですが、成功も書きます。成功した方法や条件も、プロジェクトから学んだことであり、組織で共有すべきものだからです
• プロジェクトの終了時に作るものではありません。期間中に随時アップデートしていくものです。終了後に「教訓リポジトリ」として保管され、次に似た案件をやる人が参照します

長く苦しい案件ほど、納品した瞬間に「終わった、次へ行こう」となり、ふりかえりの機会が消えます。そして学びは個人の頭の中だけに残り、組織には残りません。終わってから慌ててまとめるものではない、というのは標準の側にも書かれています。

いま

PMBOKの考え方は、この10年ほどで大きく動きました。

第8版（2025年11月）では、終結の活動が予測型（ウォーターフォール）と適応型（アジャイル）で分けて書かれるようになりました。適応型のほうには「知識の移転とレトロスペクティブ」という活動が置かれ、そこで教訓と改善の機会を特定し、残っているリスクを次のイテレーションにどう引き継ぐかまで議論する、とされています。

「PMBOKは重厚長大で、ふりかえりとは無縁」という理解は、もう成り立ちません。教訓は「終わってから文書にまとめるもの」から「区切りごとにふりかえりで見つけて、次に渡すもの」へ寄ってきています。

障害のあとに、人を責めずに学ぶ

2012年〜／John Allspaw（Etsy）→ Google SRE

いま「ポストモーテム」と聞いて多くの人が思い浮かべるのは、この流れでしょう。2012年、当時EtsyのCTOだったAllspawが「Blameless PostMortems and a Just Culture」を書きました。土台になっているのは、安全工学のSidney DekkerによるJust Culture（公正の文化）の研究です。

2016年にはGoogleの『Site Reliability Engineering』第15章「Postmortem Culture: Learning from Failure」が出て、実務の標準形になりました。この章から使えるものを3つ挙げます。

成果物は「会議」ではなく「文書」です

ポストモーテムとは、インシデントの記録文書のことです。何が起きたか、どんな影響があったか、緩和や解決のために何をしたか、原因は何か、再発を防ぐために何をするか。日本で言う「反省会」と大きく違うのは、ここです。集まって話して終わり、ではありません。

やるかどうかの基準は、事前に決めておきます

基準を先に決めておけば、いつポストモーテムが必要かを全員が分かります。Googleの例では、ユーザーに見える停止があった、データが失われた、オンコール対応が必要だった、解決に一定時間以上かかった、といった条件が挙げられています。

やるかやらないかを都度もめていると、判断そのものが感情的な話になります。基準を先に決めるのは、感情を持ち込まないための仕組みです。

共有されないポストモーテムは、なかったのと同じです

SRE本には、レビューされていないポストモーテムは存在しなかったのと変わらない、という趣旨の記述があります。そしてポストモーテムの価値は、それが生む学びに比例する、とも。過去のインシデントから学べる人が多いほど、再発しにくくなるからです。

いま

土台であるJust Cultureの考え方自体が更新されています。提唱者のDekkerは、応報的なやり方から修復的なやり方へと軸を移しました。書名も『Just Culture』から『Restorative Just Culture』へと変わっています。責めないだけでは足りず、壊れた信頼と関係を修復するところまでが説明責任だ、という方向です。

もうひとつ、原因の捉え方も変わってきました。Allspawは2014年の「The Infinite Hows」で、一本道の因果の鎖ではなく枝分かれして絡み合う要因の網として見るべきだと論じています。個々の部品の振る舞いを「原因」とラベリングするのは危うく、問題は部品そのものではなく、別々の仕組みが予測できない形で噛み合ったことにある、という見方です。

研究では、どう見られてきたか

ソフトウェア工学の研究でも、ポストモーテムは扱われてきました。Torgeir Dingsøyrは2005年の論文で、ポストモーテムは組織学習のための単純で実践的な方法であると位置づけたうえで、こう指摘しています。実施している企業は多くなく、調査では実施方法に満足している企業はごく少数だった、と。

20年前の指摘ですが、いまの日本の現場を見ても、あまり変わっていないように思います。

研究の側から実務に持ち込めそうなのは、軽さの考え方です。研究者たちが提案した軽量ポストモーテムは、半日の1回のミーティングで大半を終え、個人の事前準備は不要という設計でした。重たい儀式にしないことが、続けるための条件だという発想です。

ここまでのまとめ

• Kerth系：プロジェクトの学びを保存する。レトロスペクティブとポストモーテムを呼び分け、失敗を扱う場は難しいと最初から言っていた
• PMBOK系：教訓として文書化し、組織の資産にする。第8版でふりかえりが明示された
• SRE系：非難なきポストモーテム。文書にして、広く共有する
• どの流れもいま動いている。共通して向かっているのは、人を責めることから離れ、学びを組織に渡す方向