プレモーテムでAI導入の負け筋を出す｜失敗した前提で始める

「着手の会議でリスクを出し合ったのに、半年後に止まった理由はその一覧に載っていなかった」「懸念はあったが、立ち上げの場で水を差すことは言いにくかった」。AI推進や情シスの担当者が、案件を止めた後の振り返りで口にする言葉です。どちらの声も、会議でリスクを尋ねなかったことを嘆いているわけではありません。問題は尋ね方にあります。プレモーテムは、リスク洗い出しの会議の別名だと思われがちですが、そうではありません。本当は、「失敗するとしたら何か」ではなく「もう失敗した。なぜか」と過去形で問うことで、言いにくい懸念を一覧に残す進め方です。この記事では、AI導入の着手の会議でプレモーテムを回す段取り、負け筋の型ごとに出す問い、出た負け筋を着手条件と中止条件に移す方法を整理します。

プレモーテムとリスク洗い出しは、問いの形が違う

着手前のリスク洗い出しでは、ふつう「この案件で何がうまくいかない可能性があるか」と尋ねます。プレモーテムを提唱した心理学者ゲイリー・クラインは、この普通の批評の会議との違いを、患者がすでに亡くなったと仮定して「何がうまくいかなかったか」を尋ねる点だと説明しています。問いが、未来の可能性の話から、起きた出来事の説明に変わるわけです。

この違いは言葉の綾ではありません。可能性として尋ねると、出された懸念には「そこまでは起きないだろう」という反論が返り、言った人が悲観的な人に見えます。失敗を前提にすると、出席者の仕事は起きた理由のもっともらしい説明を作ることになり、懸念を言うことが案件への貢献に変わります。立ち上げの場の前向きな空気に逆らわずに、弱いところを口にできます。

もう一つの違いは出し方です。リスク洗い出しは議論しながら一覧を作ることが多く、声の大きい人の見立てに沿った項目が並びがちです。プレモーテムは、最初に各自が黙って書き、そのあとで1人1つずつ読み上げます。議論するのは全部が出そろってからです。この順番が、口数の少ない担当者の懸念を一覧に残します。

本稿はこの進め方を、AI導入の案件を始める会議に絞って使います。手法そのものの一般的な解説は次の節の1つにとどめ、残りはAI案件で出てくる負け筋の型と、会議で出させる問い、出た項目の行き先に充てます。試作が本番に進まない原因そのものは、別の記事「本番に進まない原因と対策」で5つに分けて整理しているので、本稿では原因の解説はしません。

原典で確かめる：2007年の論考が示した手順

プレモーテムの初出として広く引かれるのは、クラインがハーバード・ビジネス・レビューの2007年9月号に寄せた短い論考「プロジェクトのプレモーテムを行う」です。論考は、計画の段階で懸念を口にしたがらない人が多いことを案件が失敗する理由の一つに挙げ、事情に詳しい人が安心して異論を言える場を作れば、成功の見込みを上げられると述べています。

根拠として引かれているのが、1989年の研究です。ペンシルベニア大学ウォートン校のデボラ・ミッチェルらは、出来事がすでに起きたと想像する「見通しの後知恵」によって、将来の結果の理由を正しく挙げる力が30%高まると報告しました。この30%は理由を挙げる力についての研究の数字で、案件の成功率が30%上がるという意味ではありません。

手順は簡素です。計画の説明を受けたあと、進行役が「この案件は見事に失敗した」と告げます。出席者は数分のあいだ、思いつく失敗の理由を各自で書きます。原典は、特に普段なら角が立つので口にしない種類の理由を書くよう求めています。続いて進行役は、案件の責任者から順に1人1つずつ理由を読み上げさせ、全部が記録されるまで回します。

会議のあとは、責任者が一覧を見直し、計画を強める方法を探します。原典は、長い立ち上げの会議で黙っていた担当者が、ある処理が現場の持ち運び用の計算機に収まらず結果が出るまで何時間もかかると指摘し、計画が改められた例を紹介しています。プレモーテムの成果は一覧そのものではなく、一覧を受けて書き換えた計画です。

• 原典：ゲイリー・クライン「プロジェクトのプレモーテムを行う」ハーバード・ビジネス・レビュー2007年9月号（題は日本語に訳して表記）
• 30%の数字は、原典が引く1989年の研究（ミッチェル、ルッソ、ペニントン）のもので、理由を正しく挙げる力についての結果です

AI導入の着手の会議に置く理由

AI案件は、始めた後に止まる割合が高いと見られています。米ガートナーは2024年7月、生成AIの案件の少なくとも30%が2025年末までに実証の段階の後で放棄されるとの予測を公表し、理由にデータの質の低さ、危険の管理の不十分さ、膨らむ費用、事業上の価値の不明確さを挙げました。2025年6月には、AIエージェントの案件の40%超が2027年末までに中止されるとも予測しています。

これらは予測であって実績の集計ではないので、数字そのものより、挙げられた理由の並びが参考になります。止まる理由の多くは、モデルの性能ではなく、データ・費用・価値の説明・管理の側にあります。どれも、着手の会議に出ている業務の担当者や情シス、予算の担当が、うすうす気づいていることの多い種類です。

それでも着手の会議で出てきにくいのが、AI案件の難しさです。経営層が旗を振っている案件では、反対に聞こえる発言は控えられます。AIに詳しくない業務の担当者は、技術の話に口を挟みにくいと感じます。逆にAIに詳しい担当者は、業務の側の事情を知りません。懸念は人ごとに別々の場所にあり、誰も全体を持っていないのが普通の姿です。

そこで、プレモーテムを置く場所は、着手の承認の直前の会議にします。承認の後では、出た負け筋が中止条件ではなく、後で使う言い訳の材料になりがちです。承認の前なら、負け筋を着手条件に移すことも、範囲を狭めて始めることも、見送ることもまだ選べます。案件の計画書が1枚にまとまった時点が、開く目安です。

会議の前に決める4つ：対象・参加者・進行役・時間

対象は、計画書がまとまった1つの案件です。複数の案件をまとめて扱うと、負け筋が一般論に寄ります。計画書には少なくとも、使う業務、使う人、渡すデータ、期待する効果、期間、費用の見込みが書かれている必要があります。計画の中身がないまま回すと、出てくるのは「AIは間違える」という感想だけになります。

参加者は、計画を作った人だけでなく、実際に使う業務の担当者、データを持つ部署、情シス、費用を見る予算の担当を入れます。原典は人数を決めていませんが、全員が1つずつ読み上げて何周か回せる規模にすると、時間内に収まります。経営層が同席する場合は、読み上げの最中に評価の言葉を挟まないよう、事前に進め方を伝えておきます。

進行役は、案件の責任者以外の人が務めます。責任者が進めると、出た負け筋に即座に答えたくなり、場が弁明の会議に戻ってしまうからです。一方で原典は、読み上げを責任者から始めます。責任者が先に自分の案件の弱いところを口にすることで、他の人が言いやすくなる順番と読めます。進行と最初の発言を、別の人に分けるわけです。

時間は、計画の説明を除いて1時間ほどを見込みます。原典の書く時間は数分ですが、AI案件は業務・材料・費用・管理と筋が多いので、少し長めにとります。時間割の例は次のとおりです。

時間の目安	やること	気をつけること
5分	失敗の宣言と、失敗とみなす状態の確認	宣言で原因を示さない
10分	各自が黙って書く	話さない、他人の欄を見ない
20分	1人1つずつ読み上げ、記録する	反論も評価もしない、要約しない
15分	似た負け筋を束ねる	束ねるだけで、捨てない
10分	行き先の仮置きと、決める人・期限の確認	決定は持ち帰ってよい

冒頭の宣言は、時点と失敗の中身まで書く

「この案件は失敗した」とだけ告げると、思い浮かべる失敗が人によって違います。ある人はAIの誤りで事故が起きた場面を、別の人は誰も使わずに放置された場面を想像し、同じ一覧の中で粒度がばらばらになります。そこで宣言文には、いつの時点の話かと、失敗とみなす状態を書き込みます。

たとえば「今日から1年後、問い合わせの一次回答にAIを使う案件は止まっていた。予定した担当者の半分以上が使っておらず、来期の予算は付かなかった。何が起きたのかを書いてください」です。時点は、効果を判定する時期か、次の予算を決める時期に合わせます。半年後と1年後で止まり方が違う案件なら、2つの時点に分けて書かせるのも手です。

失敗の状態は、1つに絞りすぎないことも大切です。「使われなかった」だけを示すと、費用や事故の筋書きが出にくくなります。宣言では1つの状態を例に挙げつつ、止まった理由は何でもよいと添えます。原典が求めているのも、思いつく理由を全部書くことです。

逆に、失敗の原因を宣言文の中で示してはいけません。「データが揃わず失敗した」と言えば、全員がデータの話を書きます。宣言文に書くのは結果だけで、原因は書きません。進行役は事前に宣言文を1回声に出して読み、誘導になる言葉が入っていないかを確かめておきます。

黙って書く時間と、1人1つずつ読み上げる回し方

書くのは付箋か共有の表の自分の欄で、1枚に1つの理由を書きます。書いている間は話さず、他人の欄も見ません。他人の項目を見ると、同じ方向の理由に引っ張られるからです。リモートの会議なら、共有の表に1人1列を割り当て、書き終えるまで他の列を見ないと決めておきます。

1つの理由は「誰が、何をしなかった、その結果どうなった」の形で書かせます。「現場が使わない」ではなく、「窓口の担当者は、回答案を直すより自分で書いた方が早いと判断し、3か月目から開かなくなった」です。筋書きの形にしておくと、後で着手条件や中止条件に移すときに、何を見張ればよいかが分かります。

読み上げは1人1つずつ、全員の分が出尽くすまで何周も回します。同じ理由がすでに出ていたら、読まずに次の項目に移ります。この段階では、どの理由にも反論も評価もしません。「それは起きない」という声が出たら進行役が止め、記録だけを続けます。

記録係は、読み上げられた理由をそのまま書き写し、要約しません。要約すると、言った人の固有の観察が一般論に変わってしまいます。束ねるのは全部が出そろった後で、似た理由を並べ直すだけにします。束ねる作業の下書きはAIに任せられますが、その使い方は後の節で扱います。

負け筋の型1：使われない。会議で出させる問い

AI案件でよく出てくる筋書きの1つが、作ったが使われなかった、です。ただし「使われない」と書いただけでは、何も決められません。会議では、使われなくなった場面を具体にする問いを進行役が用意しておき、書く時間の後半に投げかけます。問いの例は次の4つです。

1. 1年後、最初に使うのをやめたのは誰で、何がきっかけだったか
2. AIの出力を直す時間と、自分で一から作る時間を比べて、どちらが短かったか
3. 使うたびに、どの画面を開き、何回貼り付けをしていたか
4. 使わなくなっても、誰からも何も言われなかったのはなぜか

最後の問いは、見落とされやすい筋を引き出します。使うことが業務の手順に組み込まれておらず、使っても使わなくても仕事の結果の見られ方が変わらないなら、忙しい時期に元のやり方へ戻るのは自然なことです。使われない理由は、AIの品質より業務の手順の側にあることが少なくありません。

出た筋書きの行き先も、ここで見当を付けておきます。「直す時間の方が長かった」という筋なら、着手条件に「試験の期間に、修正にかかる時間を測る」を入れられます。「誰も困らなかった」という筋なら、業務の手順のどこで使うかを計画書に書くことが着手条件になります。

負け筋の型2：材料が揃わない。会議で出させる問い

2つ目の型は、AIに渡すはずの材料が揃わなかった、です。試験のときは担当者が手で整えた文書を使えたのに、本番では古い版や重複した文書が混ざる。社外秘の区分が付いておらず、渡してよい範囲が決まらない。材料の持ち主の部署が、更新を続ける約束をしていなかった。どれもAI案件で起きやすい筋です。

1. 1年後、AIが答えを間違えた原因をたどったら、どの文書に行き着いたか
2. その文書を最後に更新したのは誰で、更新を続ける約束はあったか
3. 渡してはいけない情報が混ざっていたと分かったのは、いつ、誰が見つけたときか
4. 試験で使った材料と本番の材料は、件数と新しさがどれだけ違ったか

これらの問いは、データを持つ部署や情シスの参加者に答えてもらう前提で用意します。業務の担当者は材料の状態を知らず、AIの担当者は材料の持ち主の事情を知りません。材料の負け筋は、持ち主が会議にいないと出てきません。参加者を決める段階で、材料を持つ部署を必ず入れるのはこのためです。

行き先の例としては、「本番と同じ材料で試験する」を着手条件に、「材料の更新が3か月止まったら利用の範囲を見直す」を縮小の条件に移す形があります。材料の更新は案件の外の部署の仕事になるので、着手の前に相手の部署の了承を文書でとっておくことも、条件の1つになります。

負け筋の型3：費用が膨らむ。会議で出させる問い

3つ目の型は、費用が見込みを超えて止まった、です。AIの利用料は使った量に応じて払う形が多く、利用者が増えたり、長い文書を読ませたりすると、試験のときの見込みから外れます。加えて、出力を確かめる人手、指示文の手入れ、材料の更新といった、利用料以外の手間も費用として積み上がります。

1. 1年後、予算の担当から最初に問い合わせが来たのは、どの費目か
2. 利用者1人あたり、または1件あたりの費用は、試験のときの何倍になっていたか
3. AIの出力を確かめる人の時間は、どの部署の予算から出ていたか
4. 提供元が料金や提供の形を変えたとき、誰が最初に気づいたか

費用の負け筋は、予算の担当が会議にいると具体になります。利用料の単価より、利用量の伸び方と、確かめる人手の費用が見込みから外れやすいからです。読み上げで「利用者が倍になった」「1件の入力が長くなった」といった筋が出たら、どの数字を毎月見るかまで記録しておきます。

行き先は、着手条件なら「1件あたりの費用の上限を決めてから始める」、縮小の条件なら「月の費用が上限を2か月続けて超えたら、範囲を見直す会議を開く」といった形です。上限の金額そのものは会議の場では決めず、責任者と予算の担当が持ち帰って決めます。

負け筋の型4：止められない。会議で出させる問い

4つ目の型は、うまくいっていないのに止められなかった、です。ほかの3つと違い、これは失敗が長引く筋です。止める判断を誰がするかが決まっていない。業務の手順がAI前提に組み替わり、元の手順で回せる人がいなくなった。経営層に成果を報告した手前、止めると言い出せない。どれも、案件の中にいる人ほど気づきにくい筋です。

1. 1年後、この案件を止めるべきだと最初に気づいたのは誰で、その人は誰に言えたか
2. 止めると決めたとき、元の手順で仕事を回せる人は何人残っていたか
3. 提供元の仕様の変更で前提が崩れたとき、続けるかを決める会議は開かれたか
4. 止められなかった間に、毎月いくら払い、何件の手直しが出ていたか

この型は、プレモーテムでしか出てこないことが多いのが特徴です。リスク洗い出しの会議で「止められない可能性」を尋ねても、始める前の案件について止める話をするのは縁起が悪いと受け取られます。失敗を前提にした場なら、止めなかったから傷が広がったという筋を口にしやすくなります。

行き先は、中止条件と止めるときの段取りです。止める判断をする人の名前、元の手順を残しておく期間、提供側の変更があったときに見直す会議の開き方を、着手の時点で書きます。何を基準に止めるかの中身は、別の記事「AIの利用をやめる基準5つ」で整理しているので、本稿では出た負け筋を基準に移すところまでにとどめます。

出た負け筋を4つの行き先に振り分ける

読み上げが終わると、数十の負け筋が並びます。似たものを束ねたうえで、1つずつ行き先を決めます。行き先は4つです。着手の前に満たす条件にする、続けている間に見張る中止や縮小の条件にする、担当と期限を付けて課題として持つ、起きても受け入れると決めて記録だけ残す、の4つです。

行き先	向いている負け筋	書き方の例	決める人
着手条件	始める前に確かめられるもの	本番と同じ材料で試験し、修正にかかる時間を測ってから承認する	承認する人
中止・縮小の条件	続けている間に数字や出来事で観測できるもの	月の費用が上限を2か月続けて超えたら、範囲を見直す会議を開く	案件の責任者と予算の担当
課題	担当と期限を決めれば手を打てるもの	材料の持ち主の部署と、更新の約束を文書で交わす	案件の責任者
受け入れる	起きても損が小さい、または手を打つ費用の方が大きいもの	受け入れた理由と、見直す時期を記録する	承認する人

振り分けで気をつけるのは、全部を課題にしないことです。課題には担当と期限が付くので、数十の項目を全部入れると誰も読まない表になります。案件を止める力のある負け筋だけを着手条件と中止条件に移し、残りは課題にするか受け入れるのが目安です。課題として持つ項目の書き方は、別の記事「AI導入の課題管理表に書く7項目」を参照してください。

受け入れると決めた負け筋も、記録から消さないでおきます。原典は、プレモーテムが案件の始まった後に問題の兆しに気づきやすくする効果も挙げています。受け入れた負け筋の一覧は、途中で似た兆しが出たときに、想定の内側の出来事か外側の出来事かを見分ける材料になります。

中止条件は、観測できる形と決める人まで書く

負け筋を中止条件に移すときは、3つのことを書きます。何を見るか、どこまで来たら会議を開くか、誰が決めるか、です。「使われなくなったら止める」では、どれだけ減ったら使われなくなったと言えるのかが分からず、結局誰も止めません。観測できる数字か出来事、線を越えたときに開く会議、決める人の名前まで書いて、初めて条件になります。

数字を書くときは、自動的に止めるための数字にしないことも大切です。線を越えたら、止めるかどうかを決める会議を開く、という書き方にします。季節の繁忙や提供元の一時的な障害で、数字が動くこともあるからです。線を越えたことは決める合図であって、決定そのものではありません。

観測する手段も同時に決めます。利用の回数は管理画面で見られるのか、修正にかかる時間は誰がどう測るのか、月の費用は誰が集計するのか。見る手段のない条件は、書いても働きません。測り方を決めるのが難しい負け筋は、中止条件ではなく着手条件に回し、測れるようになってから始めるという判断もあります。

最後に、条件を書く場所を決めます。承認の書類の本文に1行ずつ入れ、別紙に回さないのが基本です。別紙にすると、承認の後で誰も開きません。条件を点検する日も、効果を判定する日と同じ日に置いておくと、判定の会議の中で自然に条件の点検が行われます。

AIに負け筋の案を出させる手順

生成AIは、失敗の筋書きの案出しに使えます。ただし、人が書く前にAIの案を見せると、全員がその案に引っ張られます。使う順番は、人が書いて読み上げた後です。人の一覧に抜けている型がないかを確かめる、二人目の点検役として使います。

気をつけたいのは、AIは頼まれた方向に話を合わせやすいことです。計画書を良い案として渡すと、筋書きが甘くなることがあります。誰の案かを伏せ、失敗した前提で問うのは、この性質を和らげる工夫です。AIが間違いを指摘しにくい性質と、その引き出し方は、別の記事「AIは間違いを指摘してくれない」で扱っています。

AIの出す筋書きの数の多さにも惑わされないようにします。AIが20の筋書きを出しても、自社の材料に根拠のあるものが3つなら、価値があるのはその3つです。会議の参加者が気づいていなかった筋が1つでも見つかれば、AIを使った意味は十分にあります。

どれを中止条件にし、着手するかはAIに決めさせない

AIに任せてよいのは、案出し、束ね、転記の下書きまでです。どの負け筋を中止条件にするか、どれを受け入れるか、そもそも着手するかは、AIに決めさせません。これらは、案件の結果に責任を持つ人が、自社の事情を踏まえて引き受ける判断だからです。AIは、止まったときに誰が困るのか、どの部署との約束が崩れるのかを知りません。

AIに優先度の点数を付けさせることも避けます。起きやすさや影響の大きさに点数が付くと、数字があるぶん人の議論より確かに見えてしまいます。けれど点数の根拠は渡した材料の範囲に限られ、会議で語られた現場の事情は入っていません。点数が要るなら、人が付けた点数の付け方の抜けを、AIに指摘させる向きで使います。

人が確かめる範囲も先に決めておきます。AIが下書きした中止条件の文は、条件を書いた責任者と、観測する担当者の2人が読むことにし、見る数字、開く会議、決める人の3つが書かれているかを確かめます。用途ごとのAIの危険度の評価は、別の記事「AIのリスク評価を進める5工程」の領分なので、本稿の負け筋とは分けて行います。

プレモーテムでやりがちな失敗

手順どおりに回しても、効き目がなくなる進め方があります。次の5つは、AI案件の着手の会議で起きやすいものです。

• 案件の承認が済んだ後に開き、負け筋が後で使う言い訳の材料として残るだけになる
• 宣言文に原因を書き、全員が同じ方向の負け筋だけを書く
• 読み上げの最中に責任者が反論し、2周目から誰も読まなくなる
• 出た負け筋を全部課題に入れ、誰も開かない一覧ができる
• AIの出した筋書きを先に配り、人の観察が一般論に置き換わる

このうち多いのは、最初の2つです。承認の後に開くと、プレモーテムは念のための確認の儀式になり、着手条件に移す余地が残りません。宣言文の誘導は、進行役がよかれと思って例を挙げすぎることで起きます。宣言で示すのは結果だけ、という線を守ります。

一度回したら終わり、という扱いも惜しい使い方です。効果を判定する時期に、受け入れた負け筋と中止条件の一覧をもう一度開くと、想定の内側で進んでいるのか、外側に出たのかを確かめられます。同じ顔ぶれで15分ほど、当時の一覧を読み返すだけでも足ります。

よくある質問

ポストモーテムとは何が違いますか

ポストモーテムは、案件が終わった後に原因を調べる振り返りです。プレモーテムは、始める前に失敗を仮定します。原典は医療の死後の検証を引き合いに出し、患者以外の全員が学べる振り返りに対して、プレモーテムは計画をまだ直せる段階で行う点が違うと説明しています。

小さなAI案件でも行うべきですか

月の費用が小さく、止めても困る人がいない案件なら、30分ほどの短い形で足ります。宣言、書く時間、読み上げだけを行い、着手条件と中止条件を1つずつ決めれば十分です。業務の手順を組み替える案件や、社外の人に出力が届く案件では、省略しない方が安全です。

参加者がなかなか書かないときはどうしますか

宣言文の時点と失敗の状態をもう少し具体にし、普段なら角が立つので言わない理由こそ書いてほしい、と原典の言い方をそのまま添えます。名前を伏せて書ける形にするのも手です。それでも出ない場合は、4つの型の問いを1つずつ読み上げ、型ごとに1つは書く、と決めて進めます。

まとめ

プレモーテムは、リスクの可能性を尋ねる会議ではなく、案件がもう失敗したと仮定して理由を書かせる進め方です。AI導入では、着手の承認の直前に開き、時点と失敗の状態だけを宣言し、各自が黙って書いてから1人1つずつ読み上げます。使われない、材料が揃わない、費用が膨らむ、止められないの4つの型で問いを用意し、出た負け筋を着手条件・中止条件・課題・受け入れるに振り分けます。中止条件は観測できる数字と会議と決める人まで書き、承認の書類の本文に入れます。案出しと束ねはAIに任せ、どれを中止条件にし着手するかは人が決めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。