フレームワーク活用ガイドひとことで言うと#
「このプロジェクトは大失敗しました」と仮定して、なぜ失敗したかを事前に考える手法。ポストモーテム（事後検証）の逆で、失敗が起きる前に原因を洗い出す。「うまくいかない理由」を考える方が、人は具体的かつ率直に意見を出せるという心理を活用している。
押さえておきたい用語#
- ポストモーテム
- プロジェクト終了後に成功・失敗の原因を分析する振り返り手法。プレモーテムはこれを開始前に実施する逆転の発想。
- 楽観バイアス
- 「うまくいくはず」と都合よく見積もってしまう認知の偏り。プレモーテムは「失敗した」と断定することでこのバイアスを打破する。
- 予防策・検知策・対応策
- リスクへの3段階の対策。起きないようにする（予防）、兆候を早く見つける（検知）、起きた場合のプランB（対応）を分けて考える。
- 心理的安全性
- チーム内でネガティブな意見も安心して言える状態。「失敗した前提」で話すことで、リスク指摘が「批判」ではなく「貢献」になる。
プレモーテムの全体像#
こんな悩みに効く#
- プロジェクト開始時に「うまくいくはず」の楽観論で突っ走ってしまう
- リスクを指摘すると「ネガティブだ」と言われて発言しづらい雰囲気がある
- 過去に「事前に気づけたはず」の失敗を繰り返している
基本の使い方#
プロジェクト関係者を集めて、ファシリテーターが以下のように宣言する。
「**時間を半年後に早送りしてください。このプロジェクトは大失敗しました。**盛大に失敗しています。さて、何が原因で失敗したのでしょうか？」
ポイント: 「失敗するかもしれない」ではなく**「失敗した」と断言する**のが重要。仮定形ではなく確定形にすることで、心理的に「リスクを指摘してもOK」な空気が生まれる。
5〜10分間、全員が個別に失敗の原因を書き出す。
- 付箋やメモに1つずつ書く
- 技術的な問題、人間関係、リソース不足、外部環境など何でもOK
- 他の人の意見に影響されないよう、まず個人ワークで行う
- 「言いにくいけど本当はリスクだと思っていること」を特に意識して書く
ポイント: グループディスカッションから始めると、声の大きい人の意見に引っ張られる。個人で書いてから共有が鉄則。
書き出した失敗原因を一つずつ発表し、分類する。
- 全員の付箋をボードに貼り出す
- 似た原因をグルーピングする
- 「発生確率」×「影響度」でリスクの優先順位をつける
- 特に複数の人が同じリスクを挙げたものは要注意
ポイント: ここで「それは起きないよ」と否定しない。すべてのリスクを平等に扱う。
優先度の高いリスクに対して具体的な対策を決める。
- 予防策: リスクが起きないようにする施策
- 検知策: リスクの兆候を早期に発見する仕組み
- 対応策: リスクが現実化した場合のプランB
対策をプロジェクト計画の中に正式に組み込み、担当者を決める。
ポイント: プレモーテムの価値は「リスクを見つけること」ではなく**「対策をプロジェクト計画に反映すること」**。見つけただけで終わったら意味がない。
具体例#
状況: 関東に8店舗を展開するラーメンチェーン。9号店の出店を2ヶ月後に控え、投資額3,500万円。幹部7名でプレモーテムを実施。
宣言: 「2ヶ月後、9号店をオープンしましたが大失敗しました。開店3ヶ月で月商目標400万円に対し、180万円しか売れていません」
出された失敗原因と対策:
| 失敗原因 | 挙げた人数 | 対策 |
|---|---|---|
| 店長候補の経験不足で品質がブレる | 4名 | 既存店で2週間の集中OJT＋マニュアル整備 |
| 駅前の競合ラーメン店3軒と差別化できない | 3名 | 開店前にSNSで限定メニューを事前告知 |
| 工事遅延でオープンが遅れる | 2名 | 工事の中間チェックポイントを3回設定 |
| 初期の口コミが悪いと挽回困難 | 2名 | 開店1週間はエリアマネージャーが常駐 |
オープン月の月商は目標の105%（420万円）。4名が同じリスクを挙げた「店長のOJT不足」に2週間投資しただけで、この結果が出た。
状況: 従業員120名のSaaS企業。3ヶ月後に主力プロダクトの大型アップデートをリリース予定。開発チーム15名、影響顧客2,000社。
宣言: 「3ヶ月後、大型アップデートをリリースしましたが、大失敗しました。解約率が3倍に跳ね上がっています」
出された失敗原因と対策:
| 失敗原因 | 発生確率 | 影響度 | 対策 |
|---|---|---|---|
| UIの大幅変更に既存ユーザーが混乱 | 高 | 極大 | 段階的リリース（10%→30%→100%）に変更 |
| パフォーマンス劣化で速度が2倍遅くなる | 中 | 極大 | リリース前に負荷テストを3回実施 |
| ドキュメントが追いつかず問い合わせ殺到 | 高 | 大 | リリース2週間前にヘルプセンター完成 |
| 特定の業種で使うカスタム設定が消える | 中 | 大 | 全カスタム設定の移行テストを全件実施 |
もし段階的リリースにせず全展開していたら、解約率は3倍に跳ね上がっていたかもしれない。10%リリース時にUX問題を修正し、解約率は通常の1.1倍に抑えた。プレモーテムの30分が数千万円の損失を防いだ。
状況: 人口5万人の地方自治体。マイナンバーカードを使った行政手続きのオンライン化を6ヶ月後に開始予定。担当部署10名でプレモーテムを実施。
宣言: 「6ヶ月後、オンライン申請を開始しましたが大失敗しました。利用率は目標の1/10で、窓口の混雑は変わっていません」
出された失敗原因と対策:
| 失敗原因 | 挙げた人数 | 対策 |
|---|---|---|
| 高齢者がオンライン申請の方法がわからない | 6名 | 公民館で月2回の操作説明会を開催 |
| システム障害で信頼を失う | 3名 | 窓口申請は残したまま並行稼働 |
| 職員がシステムを使いこなせず二重作業 | 4名 | 開始3ヶ月前から職員向け研修を実施 |
| そもそもオンライン化を知らない住民が多い | 5名 | 広報誌・回覧板・LINE公式で3ヶ月前から告知 |
開始3ヶ月でオンライン利用率は目標の85%を達成。説明会参加者に限れば92%。教訓: 「使えない」のではなく「使い方がわからない」だけ。事前の不安解消が利用率を決定的に左右する。
やりがちな失敗パターン#
- 「失敗した」と宣言せずに普通のリスク洗い出しをする — 「リスクはありますか？」と聞くと楽観バイアスが働いて出てこない。「大失敗した」と断定することで初めて本音が出る
- 声の大きい人の意見だけが残る — プレモーテムの価値は「全員の視点を集める」こと。必ず個人ワークから始め、全員の意見を平等に扱う
- リスクを出して満足する — リスクを可視化しただけで「いいワークショップだった」と終わるケースが多い。対策を決めてプロジェクト計画に反映するまで完了しないと意味がない
- 一度きりで終わらせる — プロジェクトの状況は変化する。マイルストーンごとにミニ・プレモーテムを実施し、新たなリスクを継続的に洗い出す
まとめ#
プレモーテムは「失敗した未来」から逆算してリスクを洗い出す、シンプルだが強力な手法。楽観バイアスを打破し、「ネガティブなことを言ってもいい」空気を作ることで、チームの知恵を最大限に引き出す。プロジェクトを始める前の30分の投資が、数ヶ月後の大失敗を防ぐ保険になる。