はじめに
皆さんは事前検死というものをご存じでしょうか？
私は直近で自社の新規プロダクト開発のプロジェクトにメインのエンジニアとして参画していました。
そして、参画してすぐあたりにこの事前検死というものを知りました。
「これは面白い考え方だ」
と思って私も事前検死をやってみたのですが、残念ながらそのプロジェクトは上手くいかず撤退のフェーズに入ってしまいました。
そこで、事前検死の内容を振り返りつつ、
- どうして失敗してしまったのか？
- 失敗を予見できていたのか？
といった、事前検死に関連する経験談を共有していこうと思います。
この記事で伝えたいこと
結論から言えば、浅い知識で雑に事前検死をした結果、全然検死が足りてませんでしたという話をします。
本当に恥ずかしい限りですが、プロジェクトが上手くいかなかったことを通して、事前検死を含む自分の行動がいかに甘かったかということを痛感しました。
この記事が皆さんにとって何かを得られる記事になれば嬉しいです。
注意
私が担当していたプロジェクトは上から撤退の判断が出たのですが、現在も一部で後片付けが続いています。
そのため、プロジェクトの詳細は伏せています。
その点だけご了承ください。
事前検死とは？
まずは、事前検死とは一体何かという部分について整理しておきます。
「もう知ってるよ！」という方は読み飛ばしてしまって大丈夫です。
事前検死を知ったきっかけ
私が事前検死というものを知ったきっかけは、株式会社 THE GUILD の代表取締役である深津 貴之さんが note.にて公開していた記事でした。
私が担当していた新規プロダクト開発のプロジェクトが始まってすぐあたりの時期は、ちょうど 「ChatGPTのGPTsっていう機能がすごいぞ！」 と盛り上がりを見せていた時期で、この記事もその流れに乗って公開されたものでした。
最近、Spotifyなどで公開されている深津 貴之のGUILD TALKというポッドキャストでも話題に出てましたね。今ならこっちの方が情報の入手は楽かもしれません。
圧倒的に忙しい「立ち上げ」。何より優先してやるべき"お葬式"【事前検死】 - 深津 貴之のGUILD TALK
当時の私は、非常に純粋に「事前検死って面白い考え方だな～」程度の軽い気持ちで、深津さんが公開していた事前検死 GPTs を使って遊んでいました。
そしてすぐに、当時のプロジェクトでも事前検死を取り入れたいなと考えるようになりました。
失敗学と事前検死
さて、私が事前検死を知ったきっかけはほどほどに、事前検死とは何なのかについて整理し、ついでに関連が深いと思われる失敗学というものについても簡単に触れておきます。
事前検死（pre-mortem） とは、プロジェクトの開始前に「これから始めるプロジェクトが失敗した」と仮定して、なぜ失敗したのかを事前にチームで洗い出す技法です。
SRE サイトリライアビリティエンジニアリング等で語られるポストモーテム（Postmortem） の逆の考え方と言えます。
失敗学とは、「失敗」から学び、事故や失敗発生の原因を解明することを目的とした学問です。
特定非営利活動法人の失敗学会では、設立趣旨というページで失敗学について次のように説明されています。
｢失敗学｣は、こういった事故や失敗発生の原因を解明する。 さらに、経済的打撃を起こしたり、人命に関わったりするような事故・失敗を未然に防ぐ方策を提供する学問である。
"設立趣旨" 特定非営利活動法人 失敗学会 https://www.shippai.org/shippai/html/index.php?name=h_nn_shushi （参照 2025-07-11）
失敗学では、単なる反省や責任追及ではなく、「なぜ失敗したのか」を解き明かして再発防止をすることを目的としているということですね。
ここまでの情報をまとめると、失敗学は失敗後の事例を体系化するものであり、事前検死は失敗前に回避策を考えるものという前後関係の違いがあるということがわかります。
ポストモーテム（事後検証）との違い
事前検死（Premortem）とポストモーテム（Postmortem）の違いについても整理しておきます。
事前検死と失敗学との違いでもそうであったように、事前検死とポストモーテムにも前後関係の違いがあります。
ポストモーテムについては、SRE サイトリライアビリティエンジニアリングによって次のように説明されています。
ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因（群）、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。
John Lunney、Sue Lueder 執筆、Gary O'Connor 編集、SRE サイトリライアビリティエンジニアリング Google の信頼性を支えるエンジニアリングチーム. オライリージャパン, 2017, p.175.
やはり、事前検死がプロジェクトの開始前に実施するものであるのに対し、ポストモーテムはインシデントの発生後に書くものだということがわかります。
| 用語 | 説明 |
|---|---|
| 事前検死 | 失敗"前"に、起こりうる失敗パターンを想定・洗い出し、回避策を考える。 |
| 失敗学 | 失敗"後"に、失敗事例からパターン・教訓を抽出・体系化する。 |
| ポストモーテム | システムに障害発生後などに行われる、事後検証や根本原因分析を含む振り返り手法。 |
事前検死のやり方・進め方
事前検死は次のような流れで行われます。
- プロジェクト開始時や重要な意思決定の前に、「このプロジェクトは失敗した」と仮定する。
- チームでどうしてそんな失敗が起きたのか？ を思いつく限り挙げる（ブレスト）。
- 洗い出された失敗パターンごとにリスク対策・備え・アクションを練る。
事前検死は失敗の芽を事前に摘み取ることが目的だと言えます。
プロジェクト撤退の経緯と事前検死
プロジェクトの概要
ここからは、私が実際に参画していた新規プロダクト開発のプロジェクトでの話を書いていきます。
まず、書ける範囲で私が参画していたプロジェクトについて説明すると、プログラミングなどを教えるための新しいサービスの展開を目指すプロジェクトでした。
教育系のサービスなので、教師となるコーチがいて受講生を受け入れる形のサービスです。
私は主に、教材開発やツール準備など、立ち上げに必要な様々な業務を担当していました。
「プログラミング等の教育系のサービス」という時点でレッドオーシャンに飛び込むような判断であることは間違いなく、初手から懸念を払拭しきれない部分はありました。
そこで発見したのが事前検死という手法だったということです。
どのような事前検死をしたのか？
事前検死自体は、ChatGPT と壁打ちのような形で事前検死をしました。
一部抜粋にはなりますが、その結果は次の通りです。
失敗ポイントと予防策
-
カリキュラムの範囲と深さ
- 失敗ポイント:Java, JavaScript, Git, Linux といった広範な技術スタックを展開することにより、カリキュラムが広すぎて深い知識まで教えることが難しくなる可能性がある。
- 予防策：カリキュラムをモジュール化して、基礎的な内容からスタートし段階的に深い知識に進む構造を作る。受講生の興味や目標に応じて選択科目を設ける。
-
実践的スキルの不足
- 失敗ポイント：理論的な知識は豊富でも、実際のプロジェクトで使える実践的なスキルが不足している。
- 予防策：実際の開発プロジェクトを模した演習を取り入れる。また、業界で活躍するエンジニアを招いてのワークショップやセミナーを定期的に開催し、現場の知識と経験を直接学べる機会を提供する。
-
更新される技術トレンドへの対応
- 失敗ポイント：IT 技術は急速に進化しているために、カリキュラムがすぐに古くなってしまう可能性がある。
- 予防策：最新の技術トレンドに常に目を光らせて、カリキュラムを定期的に更新する。また、自学自習の重要性を受講生に伝えて、学習リソースの提供を継続することで、卒業後も自己成長を促す。
-
受講生のモチベーション維持
- 失敗ポイント：長時間の学習プログラムで受講生のモチベーションが途中で下がる。
- 予防策：パーソナライズされたフィードバック、目標設定と進捗の可視化、達成感を得られるマイルストーンの設定などによって、モチベーションを維持する仕組みを作る。
-
継続的なサポート体制の不足
- 失敗ポイント：学習が終了した後のフォローアップやキャリアサポートが不十分で、受講者が実際の職場で活躍するまでのサポートが欠けている。
- 予防策：卒業後も受講者が利⽤できるメンタリングサービス、キャリア相談、就職活動のサポートなど、⻑期的なキャリア⽀援プログラムを提供する。
-
受講者間のコミュニティ形成
- 失敗ポイント：受講者が孤⽴して学習することで、相互学習や経験の共有が⾏われず、学習効果が低下する。
- 予防策：オンラインフォーラムやグループプロジェクト、定期的なミートアップの開催など、受講者が互いに学び合い、経験を共有できるコミュニティを形成する。
-
コーチの質と経験
- 失敗ポイント：コーチの質が不均⼀であるか、教育経験が不⾜していることにより、受講者に⼀貫した学習経験を提供できない。
- 予防策: コーチの選定基準を厳格に設け、教育スキルのトレーニングを実施。また、定期的なフィードバックと評価システムを導⼊し、コーチングの質を継続的に向上させる。
-
資⾦調達とサステナビリティ
- 失敗ポイント: 運営資⾦の不⾜により、質の⾼いコーチの確保や最新の教材の提供が困難になる。
- 予防策: 多様な収益モデルを検討し、受講料だけでなく、企業スポンサーシップや公的資⾦の活⽤を模索する。
-
受講者の多様性とインクルージョン
- 失敗ポイント: 経験や背景が異なる受講者に対して、均⼀な教育アプローチを取ることで、⼀部の受講者が取り残される。
- 予防策: 受講者の多様性を認識し、個々の学習スタイルやニーズに合わせたサポートを提供。多様性と包括性を重視したコミュニティ作りを⼼がける。
振り返って思う「見落とし」
実態としては生成 AI と壁打ちしただけなのですが、その時点でかなり痛い部分も突かれていたこともあり、私はこの結果にそこそこ満足してしまっていました。
今思えば、それが良くありませんでした。
この事前検死の結果には、まだまだ様々な観点が抜け落ちています。
例えば、次のような観点が抜け落ちて、見落とされていると言えます。
- 認識齟齬・コミュニケーションの失敗
- 役割、責任範囲、業務分担が曖昧になる可能性
- 納品物や成果物仕様の共通理解、明文化の不足
- 進捗やタスク管理に不備が発生し、運用が形骸化する可能性
- 品質・マイルストーン管理（レビュー・検収）の弱さ
- リーダーが不在になったり、責任の所在が曖昧になる可能性
- 情報共有、ナレッジ蓄積、伝達手段の不備
- （外部含む）ステークホルダー間の合意形成の不備
- リスクマネジメント、リスクログ管理の欠如
- プロジェクト定例会議や課題抽出の場の形骸化
- 急なメンバー変更、人員流動への対応設計の不備
- 成功基準（KPI 等）の認識ズレ
今回のプロジェクトが上手くいかなかった過程で、これらの中のうちで実際に発生したこともいくつかあります。
事前検死のやり方について甘い認識だったということを加味しても、ただ数回の壁打ちで満足するのではなく、何度も足りていない観点について考えてチーム内に共有していくべきだったと、今になって思います。
なぜ事前検死が十分に機能しなかったのか
今回のプロジェクトの始めでは事前検死をしてその内容をチーム内に共有しましたが、事前検死の内容以外にも、事前検死が十分に機能しなかった理由があると考えています。
１．事前検死の文化が広がらない
チームは他社のメンバーなども含めた小規模なものでした。
それぞれ、会社の文化的な背景などが違うこともあるかと思いますが、事前検死について理解されていないというか、軽んじられているような雰囲気がチーム内にありました。
ここで私が事前検死の有用性についてしっかりと説明できればよかったのかもしれません。
他にも、
- プロジェクトの進行に必要な時間に限りがある
- 立ち上げに向けて、失敗をケアしているほど予算に余裕がない
というような外的な要因もありました。
「あの時、もっとちゃんと説明できていれば……」
「もっと先々を見通して予算の配分などを考えられていたなら……」
など、考えても仕方がないと分かっていますが、つい頭をよぎってしまいます。
２．「失敗」に対するアレルギーのような反応
新規プロジェクトの立ち上げにおいて、
「成功することを考えるんじゃなく、なんで失敗をすることを考えるんだ」
というような、ある意味で 「失敗」に対するアレルギー反応のような意識も、チーム内にはあったかもしれません。
「～かもしれません」というのは、こういった意見を明言されたわけではないからなのですが、
- 「失敗について考えてもどうしようもない」
- 「どうやったら成功するかを考えましょう」
というような、ポジティブに見える意見によって事前検死の内容がかき消され、チーム内共有が上手く進みませんでした。
特に 「どうやったら成功するかを考えましょう」というのは全くもって正論というか、その通りだとしか言いようがありません。
私自身、これに対抗しうる、事前検死の有用性を説く方法を持ち合わせていないというのが事実なので、他の人はどうしているのかなと考えあぐねています。
それでも、事前検死を組織・プロジェクトで活かしたい
事前検死はどう行うべきなのか？
まず大前提として、事前検死はチーム全員でやるべきことです。手元で AI と壁打ちしたものをチームに共有するというだけでは弱かったと反省しています。
実際のプロジェクトで事前検死を活かす上では、次のようなことを実践してみるといいかもしれません。
- 事前検死の結果を１度チーム内で共有するだけではなく、チーム全員で定期的に事前検死の振り返りに取り組む。
- ワークショップなどの形で、チーム全員で事前検死をする。
- 過去の失敗事例や失敗学の知見を取り入れる。
事前検死を実際にやる際は、できるだけ多様な立場のメンバーを巻き込んで、現場・管理側・外部関係者などの複数の視点で「どんな失敗があり得るか？」を徹底的に洗い出すと良さそうです。
注意点・陥りやすい罠
事前検死は、プロジェクトの開始前に失敗を洗い出す機会を設ける非常に有意義な取り組みですが、次のような点には注意する必要があると思いました。
- 「１度やって共有しただけ」というように、事前検死が形骸化すること
- 「とりあえず事前検死をやった」と安心して、実際のアクションまでたどり着かない
- 失敗について考えたり話したりすることを避けようとする心理
- いろいろな物事を正当化して、「自分たちの現場は大丈夫」と思い込むこと
- 見落としなどに目を向けず、「やってみたけど役立たなかった」と納得しようとすること
もし、また事前検死をするならどうするか？
もしまたチャンスがあって事前検死をすることがあれば、事前検死そのもののやり方をしっかり理解して、周囲に有用性を熱心に伝えた上で進めようと思います。
この記事は、知見の共有や自身の反省もそうですが、自社のメンバーへの共有の目的もあって書いています。
こればかりは積み上げでしかないですが、事前検死の意義や目的を繰り返し説明して、文化として根付くように努力していきたいです。
最後に
ここまで長々と、拙い文章を読んでいただきありがとうございました。
あまり記事を書く機会がなく、読ませる文章ではなかったかと思いますが、この記事がプロジェクトの現場で事前検死を取り入れたいと考える皆さんのヒントになれば幸いです。
私自身も、これからも失敗から学び、より良い環境を作っていきたいと思います。
Discussion