PoCを中止する判断の下し方

PoCを途中で止めるという判断は、実務では驚くほど下されません。結果が芳しくないまま期間が延び、条件を変えて試し直し、報告のタイミングだけが後ろにずれていく。最終的には予算の期限で自然消滅する、という終わり方をよく見ます。

これは判断を下す人が弱いからではありません。止める判断が下しにくい構造が、組織の側にあるからです。本記事では、その構造と、中止を下せるようにするための設計を整理します。

検証の目的は、続けるかどうかを早く決めること

前提を確認します。PoCの目的は、本番化することではありません。本番化するかどうかを、少ない費用で早く決めることです。

この定義に立つと、「本番化しない」という結論に早く到達したPoCは、成功した検証です。半年分の開発費と、その後の運用にかかる費用を使わずに済んだのですから、成果として計上できます。

ところが実務では、この結論が「失敗」として扱われます。担当者は上長に説明しにくく、上長は役員に説明しにくい。結果として、誰も止めると言い出さないまま続きます。

サンクコストに引きずられる構造

すでに使った費用は、続けても戻りません。判断すべきは、これから使う費用に見合う成果が見込めるかどうかだけです。これは経済学の初歩の話で、言葉としては誰もが知っています。それでも実際には引きずられます。理由は三つあります。

一つ目は、説明責任の非対称性です。 中止を決めた人には「なぜ投資を無駄にしたのか」という問いが向きます。続けることを決めた人には、しばらく何も問われません。同じ判断でも、問われるタイミングが違うのです。この非対称がある限り、合理的な個人は続けるほうを選びます。

二つ目は、投じた労力が評価を代替することです。 担当者が半年間まじめに取り組んだプロジェクトを止めると、その半年の評価が下がるように感じられます。実際には、止める判断ができる人のほうが評価されるべきなのですが、そういう運用になっている組織は多くありません。

三つ目は、「あと少し」の錯覚です。 AIを使う検証では、プロンプトや設定を変えると結果が少し動きます。この小さな変化が、改善の途上にいるという感覚を生みます。しかし多くの場合、最初の数回で得られた水準が実力に近く、その後の調整で桁が変わることはあまりありません。

撤退条件を着手前に書く

構造の問題は、個人の意志では解決できません。設計で対処します。最も効くのは、着手前に撤退条件を文書にしておくことです。

撤退条件は、次のような形で書きます。

• 4週目の時点で、業務担当者による確認の手間が現行より減っていない場合
• 運用費用の概算が月額で想定の3倍を超えた場合
• 対象業務の入力データを整えるために、現場の作業が新たに発生すると判明した場合

重要なのは、条件を「判断の引き金」として使うことです。条件に触れたら自動的に中止するのではなく、条件に触れたら必ず一度、中止するかどうかを議論する場を開く。この運用にすると、柔軟性を失わずに、議論を始めるきっかけを確保できます。

着手前に書いておく効果は、判断が人格の問題にならないことです。「あなたが止めると言った」ではなく「決めておいた条件に触れた」という形になるので、言い出すコストが大きく下がります。

判断する場を、日程として押さえる

条件を書いただけでは足りません。議論する場がないと、条件に触れても誰も言い出さないからです。

PoCの開始時点で、判断のための会議を日程に入れてください。中間と終了時の二回で十分です。この場には、PoC止まりになる7つのパターンでも触れたとおり、本番化の予算を決める人が参加する必要があります。

会議の議題は、進捗報告ではなく「続けるか、止めるか、条件を変えるか」の一つに絞ります。議題が進捗報告だと、報告して終わりになり、判断が行われません。

判断に使う数字を誰が集めるかも、あわせて決めておきます。会議の当日に「そのデータは取っていません」となると、判断はまた次回に持ち越されます。

中止しても残るもの

中止したPoCから何も残らないわけではありません。次のものは確実に残ります。

• 対象業務の実態についての理解（どこに時間がかかっているか、どこが例外だらけか）
• 現在の技術で何が届かないかという事実
• 自社のデータがどういう状態にあるかという把握
• AIを使わずに改善できる箇所の発見

四つ目は特に多く見られます。検証の過程で業務を分解すると、AI以前の問題として、二重入力や不要な承認が見つかることがあります。これはPoCの副産物ですが、実際の改善効果としてはこちらのほうが大きい場合もあります。

これらをPoC報告書に書いておけば、中止の報告が「何も得られなかった」ではなく「次の判断材料が揃った」という内容になります。

中止を評価する仕組みを作る

構造の話に戻ります。中止が下せる組織にするには、中止を評価する必要があります。評価といっても、大がかりな制度は要りません。次のような運用で変わります。

• 判断の会議で中止が決まったとき、その場で「早く分かってよかった」と明示的に言う
• 中止によって使わずに済んだ費用を、金額として記録する
• 担当者の評価において、検証の結論ではなく、判断の速さと記録の質を見る

三つ目が肝心です。結論で評価すると、担当者は良い結論を出そうとします。判断の速さと記録の質で評価すると、担当者は正直に書くようになります。評価の対象を何にするかで、行動は変わります。

止められる設計が、次の挑戦を可能にする

止める判断が下せない組織では、一つのPoCが長く居座り、次の検証に手を出せません。逆に、早く止められる組織は、同じ予算で複数の検証を回せます。どちらが先に当たりを引くかは明らかです。

中止は失敗ではなく、検証という手段が正しく働いた結果です。撤退条件を着手前に書き、判断の場を日程で押さえ、中止を評価する。この三つを設計しておけば、止める判断は個人の勇気を必要としなくなります。

弊社はAI活用開発として、既存のAIサービスを組み込んだシステムの実装をお引き受けしています。そのうえで、検証の段階で「この規模なら作らないほうが安く済みます」とお伝えすることもあります。判断に迷う段階でのご相談も承っていますので、お問い合わせからご連絡ください。ご相談・お見積りは無料です。