失敗シナリオの事前シミュレーション

プレモーテム（事前検死）プロンプトが防ごうとしているのは、過度な楽観主義です。計画書を渡して「どう思う？」と聞くと、AIは良い点を3つ挙げたあとに「ただしスケジュールがタイトかもしれません」と添える程度にとどまります。すでに失敗したと前提を固定して始めることで、回答の方向性が根本から変わります。原因を究明する担当者には、長所を述べる理由がないからです。

最初の段落の役割は、アドバイザーではなく事後分析の専門担当者です。アドバイザーはバランスを取ろうとしますが、調査員はずれた箇所だけを追及します。コンテキストの段落こそがこのプロンプトの核心です。「失敗するかもしれない」ではなく「すでに失敗した」と時制を過去に変えることで、モデルは可能性を天秤にかけるのをやめ、失敗に至る経緯を描写し始めます。

ステップの段落は、表面的な症状から最初の決定へと時間を遡らせます。失敗の原因を単に尋ねると「リソース不足」のような最終的な症状で止まりがちです。4つの項目を順に埋めさせることで、そのリソース不足がどの決定から始まったのかまで掘り下げられ、私たちが今日変更できるのは大抵その最初の決定の中にあります。

フォーマットの段落でシナリオを3つに分けているのは、原因が一つの方向に偏るのを防ぐためです。1つだけにすると、一番ありがちなスケジュールの話だけで終わってしまいます。異なる原因にすべきという条件を設けることで、技術、人間関係、外部環境など多角的な軸が引き出されます。最後の共通原因の段落は、3つのストーリーが最終的に同じ本質を指し示している場合にそれを可視化してくれます。シナリオごとに予防策を2つに絞っているのも意図的です。10個も提示されたところで、今日着手できるものは一つもないからです。

このように聞くと、褒め言葉が2段落続いた後に「スケジュールがやや厳しそうです」と1行添えられる程度の結果になりがちです。これでは失敗原因の事前予測には程遠い内容です。仮に指摘が出たとしても計画書内の表現を言い換えるレベルにとどまり、計画書から完全に抜け落ちている盲点は最後まで浮き彫りになりません。

「失敗した」という前提を無視して、成功のためのアドバイスを一緒に書いてしまう場合があります。その際は「成功要因は省き、失敗に至った経緯のみを再度記述してください」と続けて指示してください。