新しいプロジェクトが始まるときは、期待が先に立ち、気になる点があっても口に出しにくいものです。「縁起でもないと思われそう」「担当者を責めているように聞こえそう」と考え、違和感を飲み込んだ経験がある方もいるのではないでしょうか。ところが、開始前の小さな懸念は、納期が迫ってから大きな問題として表れることがあります。
プレモーテム（Pre-mortem）は、プロジェクトがすでに失敗した未来を仮定し、その原因を参加者が先に洗い出す会議手法です。成功を前提に「何かリスクはありますか」と聞くよりも、失敗したという設定から考えることで、普段は言いにくい懸念を挙げやすくなります。目的は悲観することではなく、避けられる失敗を予防策へ変えることです。
ただし、失敗要因を大量に並べるだけでは不安が増えるばかりです。プレモーテムでは、個人で考える時間を取り、意見を共有して分類し、重要なリスクを予防策、早期兆候、担当者まで落とし込みます。会議後に誰が何を確認するかが決まって、初めてプロジェクトの運営に役立ちます。
この記事では、初めて実施するチームでも使える60分の進行、責任追及を避ける声かけ、架空の新サービス公開プロジェクトを使った具体例まで整理します。リスク管理やポストモーテムとの違いも確認しながら、自分たちの会議へ取り入れられる形を作っていきましょう。
対象は大規模なプロジェクトに限りません。ウェブサイトの公開、社内制度の変更、イベント開催、システム移行など、複数の担当者が関わり、途中で前提が変わり得る仕事に使えます。重要なのは、想像した失敗を不安のまま残さず、観察できる兆候と具体的な行動へ変えることです。
この記事を読むと次のことがわかります
プレモーテムは失敗した未来から現在を見直す
通常の計画会議では、成功に必要な作業や日程を前向きに組み立てます。その姿勢は大切ですが、すでに決まった案へ反対するように感じられ、懸念が表に出にくくなることがあります。プレモーテムは視点を反転させ、「半年後、この計画は失敗しました。何が起きたのでしょう」と問いかけます。
失敗を仮定すると、参加者は反対意見ではなく原因の推測として話せます。営業は顧客への説明不足、開発は仕様変更、運用は問い合わせ体制など、それぞれの立場で見える問題を持ち寄れるため、計画書だけでは見つけにくい依存関係も見えやすくなります。
この発想は、計画を否定するためのものではありません。むしろ、いまの計画が成立するために必要な条件を確認する作業です。「失敗した理由」を裏返すと、「成功のために維持したい条件」や「早めに確認したい前提」が見えてきます。
リスク管理は一覧表、プレモーテムは発見の場として使う
リスク管理では、リスクの内容、発生可能性、影響度、対応策などを表にまとめ、継続的に更新します。プレモーテムは、その表へ入れる候補をチームから引き出すための対話です。どちらか一方を選ぶのではなく、会議で発見した内容をリスク台帳へ移すと運用がつながります。
すでにリスク台帳がある場合も、記載済みの項目を読み上げるだけにしないことが大切です。台帳を一度閉じ、参加者が個別に考えてから照合すると、既存の分類に引っ張られず、新しい懸念を発見しやすくなります。
ポストモーテムは発生後、プレモーテムは開始前に行う
ポストモーテムは、障害や失敗が起きた後に経緯と原因を振り返り、再発防止へつなげる活動です。一方、プレモーテムは開始前や重要な節目で、まだ起きていない失敗を想像します。事実を分析するポストモーテムに対し、プレモーテムでは仮説を扱う点が異なります。
仮説は外れることがあります。それでも、兆候を決めて観察すれば、思い込みのまま対策を増やさずに済みます。予測を当てることより、見落としていたリスクへ早く気づける状態を作ることが重要です。
悲観的な会議にしないために目的をそろえる
冒頭で「失敗の責任者を探す場ではなく、チームが成功しやすい条件を作る場です」と明言します。人の性格や能力ではなく、情報、手順、期限、役割、外部条件など、変更や観察ができる要素へ意見を向けます。
「担当者が弱い」ではなく「承認者が不在のとき判断が止まる」、「営業が悪い」ではなく「顧客へ伝える仕様変更の窓口が決まっていない」と書き換えます。具体的な状態として表現すれば、責任追及を避けながら対策を考えられます。
責任者や管理職も、自分の判断が失敗要因になり得ることを先に認めると、発言のハードルが下がります。「私の承認が遅れる可能性も含めてください」と促せば、立場の弱い参加者だけに率直さを求める状態を避けられます。
60分のプレモーテム会議を準備する
会議は長くするほど多くのリスクが見つかるわけではありません。対象と時間軸を絞り、参加者が同じプロジェクト像を持てる資料を用意します。初回は、意思決定に関わる5〜8人ほどで60分を確保すると進めやすいでしょう。
ファシリテーターは議論の正解を決める人ではなく、発言量の偏りを抑え、曖昧な表現を具体化する役割を持ちます。プロジェクト責任者が進行すると反対意見が出にくい場合は、別のメンバーへ進行を頼む方法もあります。
参加者は責任者だけで固めず、実際に作業する人や後工程を受け持つ人も含めます。外部委託や顧客対応が重要なら、その事情を理解する担当者も必要です。人数を増やしすぎると共有に時間がかかるため、当日は代表者に絞り、事前に周囲から懸念を集める方法もあります。
対象、失敗時点、成功条件を一枚にまとめる
会議前に、対象プロジェクト、公開日や完了日、主要な成果物、成功とみなす条件を一枚にまとめます。「新サービスが失敗した」だけでは、売上不足なのか、品質問題なのか、公開延期なのかが参加者ごとに変わります。
たとえば「公開3か月後、利用者数が目標の半分で、問い合わせ対応も遅延している」と設定すれば、集客と運用の両面を考えられます。扱う範囲が広すぎる場合は、公開準備、移行、初月運用など、今回検討する期間を限定します。
付箋と評価表は匿名性と記録のしやすさで選ぶ
対面なら付箋とホワイトボード、オンラインなら共同編集できるボードを使います。最初の個人ブレストでは、誰が書いたかを表示しない設定にすると、役職差があるチームでも率直な懸念を出しやすくなります。
記入欄は「失敗要因」「起きる前の兆候」「予防策」「担当者」に分けます。最初からすべてを書かせると発想が止まりやすいため、原因の洗い出しと対策の検討は時間を分けましょう。
オンライン会議では、参加者が同じボードを操作できるかを開始前に試します。操作に不慣れな人にはチャット投稿を認め、進行役が代理で貼り付けます。ツールの扱いが発言機会の差にならないよう、入力方法を複数用意しておくと安心です。
進行役が使う声かけを先に決める
「もし失敗したとすれば、私たちは何を見落としていたでしょう」「個人名ではなく、起きた状態を書いてください」「少数意見も一度ボードへ置きましょう」といった声かけを準備します。懸念へすぐ反論せず、まず内容を理解する姿勢を示します。
実現可能性が低く見える意見にも、「絶対に起きない」と返さず、「どの条件が重なると起きそうですか」と尋ねます。発言を防御する会話から、条件を明らかにする会話へ変えることで、心理的安全性を保ちやすくなります。
失敗要因を予防策へ変える60分の進行
当日は、失敗の場面を具体的に共有した後、個人ブレスト、共有と分類、優先順位付け、対策決定の順に進めます。声の大きい人の意見だけで始めないため、必ず個人で考える時間を先に取ります。
時間配分は一例です。参加人数や対象の複雑さに応じて調整できますが、対策を決める時間を最後に残してください。原因の議論で時間を使い切ると、会議後に行動が残りません。
重要な論点が見つかっても、その場で原因を完全に解明しようとすると時間が足りなくなります。追加調査が必要な項目は、確認する担当者と期限を決めて別に残します。会議では、いま判断できることと、調査してから判断することを分けるのが現実的です。
0〜15分は失敗の設定共有と個人ブレストに使う
最初の5分で目的とルールを確認し、プロジェクトが失敗した場面を読み上げます。その後10分間、参加者は会話せず、一枚の付箋に一つずつ原因を書きます。技術、顧客、体制、日程、外部依存などの観点を示してもよいでしょう。
個人ブレストを先に行うと、最初の発言へ全員が引っ張られるのを防げます。書けない人には「開始直後」「中盤」「公開直前」「公開後」に時間を分けて考えてもらうと、出来事を想像しやすくなります。
15〜35分は共有して似た原因をまとめる
付箋を一枚ずつ短く読み上げ、似た内容をまとめます。この段階では解決策の議論を始めず、意味が曖昧な箇所だけ質問します。「連携不足」なら、誰から誰へ、どの情報が、いつ届かないのかまで具体化します。
分類名は、体制、要件、品質、顧客対応など、後で見返して分かる言葉にします。同じ原因が複数の参加者から出たことは重要ですが、票が少ないから無視できるとは限りません。専門担当者だけが気づけるリスクも残します。
35〜45分は発生可能性と影響度で優先順位を決める
各リスクを、発生可能性と影響度の二軸で高・中・低に評価します。両方が高いものを優先しつつ、影響が極めて大きいものや、後から対応しにくいものも確認します。数字を精密に見せることより、チームの認識差を話し合うことが目的です。
評価が割れたら、低く見積もる人と高く見積もる人に前提を一つずつ話してもらいます。見ている情報や経験が異なると分かれば、追加調査そのものを対策にできます。すべてを同じ優先度にせず、当日扱う上位3〜5件を選びます。
発生可能性が低くても、法令違反、重大な情報漏えい、人身事故など、影響を受け入れられないリスクは別枠で扱います。単純な点数だけで順位を決めず、組織として許容できる範囲と、直ちに専門部署へ相談すべき条件を確認します。
45〜60分は予防策、兆候、担当者を決める
選んだリスクごとに、発生を減らす予防策と、起き始めを知る早期兆候を決めます。さらに、確認する担当者と期限を置きます。「注意する」ではなく、「毎週金曜に未確定仕様の件数を確認し、5件を超えたら責任者へ共有する」のように行動へ落とします。
完全に防げないリスクには、発生後の対応も用意します。代替担当、切り戻し手順、顧客への連絡文などを決めておけば、問題が起きたときの判断時間を短くできます。最後に、会議記録をリスク台帳やプロジェクト計画へ反映する担当を確認します。
担当者は一人にしますが、その人だけが対策を実行するという意味ではありません。確認の起点と報告先を明確にするための役割です。必要な協力者、判断を依頼する責任者、期限を合わせて書くと、担当名だけが残る状態を防げます。
架空の新サービス公開計画で考える
ここでは、法人向け予約サービスを3か月後に公開するプロジェクトを例にします。開発、営業、サポート、法務が参加し、失敗の設定を「公開が1か月遅れ、初月の問い合わせが想定の3倍になり、解約が増えた」としました。
個人ブレストでは、「営業資料と実際の仕様が違う」「利用規約の確認が遅れる」「サポート用の検証環境がない」「移行データの欠損に公開直前まで気づかない」などの原因が出ました。これらを要件、承認、運用、データへ分類します。
分類した時点で、複数の失敗要因に共通する問題も見えます。資料の食い違いと規約確認の遅れが、どちらも変更連絡の経路が曖昧なことから生じるなら、個別対策だけでなく変更管理の流れそのものを見直せます。共通原因へ対処できれば、少ない施策で複数のリスクを下げられる可能性があります。
対策を選ぶときは、実施コストと新たに生まれる負担も確認します。すべてを二重承認にすれば見落としは減るかもしれませんが、判断が遅くなるおそれがあります。確認対象を重要な変更に絞る、期限を定めて自動通知するなど、リスクを下げながら日常運用を続けられる形へ調整します。
仕様の食い違いは変更件数を兆候として追う
営業資料と製品仕様の食い違いに対しては、毎週の仕様変更を営業と開発が共同で確認し、公開資料の修正担当を決めます。早期兆候は「説明資料へ反映されていない仕様変更が3件を超える」としました。
担当者を営業だけにすると、技術的な変更を把握できない可能性があります。開発側の変更承認者と営業資料の管理者を組にし、変更時に通知される経路まで決めることで、部署間の隙間を小さくできます。
問い合わせ急増には公開前の質問収集で備える
サポート負荷への予防策として、試用ユーザー10社から質問を集め、公開前にFAQと一次回答の判断表を作ります。兆候は、試用期間中に同じ質問が週5件以上発生すること、回答に15分以上かかる質問が増えることです。
単に担当者を増やすより、質問の種類と回答に必要な権限を先に把握します。製品不具合、契約、操作説明を分け、どこまで一次窓口で答えられるかを決めれば、公開後の転送や待ち時間を減らせます。
会議後はリスク台帳と定例会議へ接続する
プレモーテムで選んだ上位リスクは、担当者、期限、兆候とともにリスク台帳へ登録します。週次会議ではすべてを読み上げず、兆候が変化した項目と期限が近い対策だけを確認すると、形だけの管理になりにくくなります。
環境が変わったときは、短いプレモーテムを再実施します。大きな仕様変更、担当者交代、公開日の前倒しなどは、当初の前提を変えます。30分版で追加リスクだけを洗い出せば、最初からやり直す必要はありません。
反対に、兆候が一定期間見られず、前提も変わったリスクは優先度を下げます。リスク台帳を増やし続けるだけでは重要項目が埋もれるため、追加と同じように、監視を終える判断も定例会議で行います。
プレモーテムを行動につながるリスク管理の入口にしよう
プレモーテムは、プロジェクトが失敗した未来を仮定し、現在の計画に潜むリスクをチームで発見する会議手法です。悲観することが目的ではなく、言いにくい懸念を早い段階で共有し、変更可能な行動へ変えるために使います。
60分で行うなら、個人ブレスト、共有と分類、発生可能性と影響度の評価、予防策の決定へ時間を分けます。責任追及を避けるため、人ではなく状態や仕組みを扱い、少数意見も一度は記録に残しましょう。
会議後は、上位リスクごとに予防策、早期兆候、担当者、期限を決め、既存のリスク台帳や定例会議へ接続します。まずは次の重要なプロジェクトで、対象を一つに絞った60分のプレモーテムを試してみてはいかがでしょうか。
初回からすべてのリスクを網羅する必要はありません。会議後に兆候を確認し、前提が変わったときに短く見直すことで、プレモーテムは一度きりのイベントではなく、計画を現実へ合わせる仕組みになります。対策が増えすぎた場合は、優先順位と担当者の負荷も合わせて調整しましょう。
実施後には、挙がった意見の数だけで成果を判断しないことも大切です。重要な懸念を一つでも早く発見し、担当者が確認を始められたなら価値があります。次回は、見つけられなかったリスクや使われなかった兆候を振り返り、問いと参加者の構成を改善します。
今回のポイント
