こちらは『LITALICO Advent Calendar 2025』11日目の記事です

こんにちは、@haru614 と @zacky_50 です。この記事は二人で共同執筆しました。

先日、上司である @kazuis さんが、童話『3匹のこぶた』を題材に、ポストモーテム（事後検証会）の本質について書いた記事を公開しました。

ポストモーテムの目的は「再発防止」ではない

この記事では、吹き飛んでしまった家から「組織として何を学ぶか」が語られています。

私のチームでもポストモーテム文化を導入しはじめており、2回目のポストモーテムが開催されました。
しかし、私が先日ファシリテーションを担当したポストモーテムでは、さらに手前の非常に厄介な状況に直面しました。

それは、わらの家を建てた当人のこぶたが、すでにチームを離れて森にいなかったという状況です。

本記事では、この「不在のこぶた問題」によって議論が迷走してしまった失敗談と、そこから学んだ「仮説という名のレンガ」についてお話しします。

事件：設計図とは違う家が建っていた

状況

ある日、オオカミ（障害）がやってきて、システムの一部である「わらの家」を吹き飛ばしてしまいました。
調査の結果、「設計図（ドメイン資料）」にはレンガで作るよう書いてあったのに、実際の設計はわらで作られていた（資料と設計の乖離） ことが判明しました。

直面した壁

当然、最大の疑問はこうです。

「なぜ、設計図があるのに、それを無視してしまったのか？」

しかし、その設計をしたエンジニアはすでにチームを離れていました。
なぜ資料と違う設計にしたのかは、本人に理由を聞くことは不可能です。

私の失敗：「わからない」で片付けてしまった

私はファシリテーターとして、この状況をこう整理してしまいました。

根本原因：資料と乖離した理由は、本人がいないため不明とする（見落とし？意図的？わからない）
対策検討：原因が特定できないため、とりあえず家作りに関する全工程（資料確認〜設計〜実装〜テスト）を総点検する

これが、迷走の始まりでした。

※今回の記事の対象範囲は、「設計図（ドメイン資料）」と「実際の設計」が食い違ったこの一点に絞ります。
法改正対応や体制設計など周辺の論点も本当は重要ですが、それらを同時に扱うと議論が発散しやすいからです。

迷走：オオカミではなく、森全体を疑い始める

「なぜ設計図通りにしなかったか」というアンカーを失った議論は、とんでもない方向に発散し始めました。

「お城から新しい『建築基準法（法改正）』が届いた（＝外部ルールが変わった）が、どこをどう読み解くかのルールがなく、担当のこぶたの『勘と経験』に依存してしまった」
「工期があまりにも短すぎた」
「なぜここをこう設計したかという議論の記録が残っておらず、担当者が森を去った今、誰もその意図を追えなくなっていた」

といった、いつの間にか「ドキュメント管理のあり方」や「周辺事情」にまで話が広がり、不満大会へと変貌してしまったのです。

結果、出てきた対策は次のようなものになりました。

「森のすべての資料を一元管理できる『建築マスター台帳（マスターシート）』を新規作成する」
「来年の建築基準法（法改正）対応に備えて、年単位で『村の居住区画（チーム編成）』を見直し、準備を進める」
「具体的な作業の話をする前に、『そもそも議論の論点とは何か』という定義から全員で認識を合わせ直す」

結果として巨大すぎて明日すぐには着手できないToDoリストを作り上げるだけで終わってしまいました。
（※もちろん意思決定プロセスの保存自体は重要なのですが、今回は“どの穴から落ちたか”を特定しないまま混ぜてしまったのが敗因でした）

これらはすべて正論であり、組織が抱える真の課題です。
しかし、これらを一度にすべて解決しようとしたことが間違いでした。

本来議論すべきは「今回の設計乖離は、上記のどの穴から落ちたのか」だったはずです。
しかし私たちはあれもできてない、これも足りないと、結局明日やれる一手が決まらないまま終わってしまいました。

反省：こぶたの気持ちを「ロールプレイ」するべきだった

上司の記事にある通り、ポストモーテムの目的は「学習」です。
「本人がいないから不明」として思考を停止させた時点で、私は組織としての学習機会を放棄していました。

では、どうすればよかったのか。
たとえ本人がいなくても、「推測」でいいから仮説を立てるべきだったのです。

ここでいう仮説は、当てずっぽうで断定することではありません。
「なぜなぜ分析」は真実が確定できなくても、状況証拠に基づいて仮説として立て、仮説であることを明記したうえで議論を前に進めるためのものだと思います。

「もし自分が、あのこぶただったら？」

残されたメンバーで、こう問いかける必要がありました。

「もし自分が彼だったら、なぜあの資料を読み違えただろう？」
「資料の第3章と第5章で、矛盾したことが書いてなかったか？」
「あの時期、仕様変更が多くて、古い版の資料をつかまされたのではないか？」

そうやって状況証拠から推測を重ねると、

「ドメイン資料の構成が複雑で、該当の定義が小さく書かれていたため、彼は見落としたのだろう（あるいは別紙を参照してしまったのだろう）」

といった 「納得解」 が見えてきたはずです。

結論：仮説があれば、次はレンガを積める

もし原因が複雑怪奇な仕様のせいであれば、仕組みを大きく変える必要があります。
しかし今回のケースは、あまりに些細な箇所でした。

そこで私たちは、単純すぎるがゆえに、誰も「ここを疑って見るべき（レビュー観点）」だと認識していなかった、という仮説を立てました。
簡単な場所だから、きっと合っているだろうというバイアス（思い込み）が、チェックの目をすり抜けさせたのです。

この場合、対策に「巨大なマニュアル」も「認識合わせ」も必要ありません。
「設計時のチェックリストに、『この項目はドメイン資料と指差し確認したか？』という一行（観点）を追加する」。

やることはシンプルですが、「個人の注意」に頼るのではなく「ルールの項目」にすることで、魔のバイアスは解除されます。
次は誰でも、設計図通りのレンガの家が建てられるようになります。

まとめ：上司の記事へのアンサー

上司は「再発防止策を書くだけが目的ではない」と説きました。
私はそこから一歩進んで（あるいは転んで）こう付け加えたいと思います。

「真実がわからなくても、『仮説』という名のレンガを積み上げろ」

担当者が不在でも、「たぶんこうだったんじゃないか？」と組織として合意形成すること。
それこそが、吹き飛んだわらの家から得られる最大の「学習」であり、迷走しないポストモーテムの秘訣なのだと思います。