PoC止まりになる7つのパターン

AI関連の相談で最も多いのが、「前にPoCをやったが、そこで終わってしまった」という話です。技術的にはそれなりの結果が出ていたのに、本番化の議論が進まないまま予算の年度が変わり、いつのまにか誰も話題にしなくなる。この流れは、驚くほど同じ形で繰り返されます。

止まる原因は、たいてい技術の限界ではありません。体制と合意の設計が抜けていることが原因です。しかもその多くは、着手前の30分の確認で潰せる性質のものです。本記事では、よく見かける7つのパターンと、それぞれを事前に潰す手を整理します。

パターン1: 本番化を決める人が関わっていない

PoCを進めているのは現場の担当者で、本番化の予算を決めるのは役員。この構図で、役員がPoCの経過を一度も見ていない場合、結果が出てから説明することになります。説明を受ける側は判断材料を持っていないので、「もう少し検討しよう」という結論になりがちです。

潰す手は単純で、着手前に「これがうまくいったら、誰が本番化を決めるのか」を名前で確認することです。その人が中間報告の場に一度でも顔を出していれば、最終判断の質は大きく変わります。名前が出てこない場合、そのPoCはまだ始める段階にありません。

パターン2: 成功基準を後から決めている

「精度80%を超えたら本番化」のような基準を、結果が出てから議論し始めるケースです。結果を見てから基準を決めると、人はどうしても結果に引きずられます。良い数字が出れば「まあ十分だろう」となり、微妙な数字が出れば「基準はもっと高いはずだ」となる。どちらに転んでも、判断としての信頼性が失われます。

基準は着手前に文書にします。このとき、「精度」のような一つの数字だけでは足りません。次の三つを揃えて書いておくと、後から揉めにくくなります。

• どの指標が、どの水準に達したら成功とみなすか
• その水準に達しなかった場合、何をやめるか
• 判断に使うデータをいつ、誰が、どう集めるか

三つ目が抜けていると、「そのデータは手元にない」という理由で判断が延期されます。

パターン3: 使う業務側が、使う気がない

技術部門やDX推進部門が主導し、実際にその業務を担当している部署が蚊帳の外というパターンです。PoCとしては動いても、本番運用の段になって「今のやり方のほうが速い」「この画面では現場が入力しない」といった反対が出て止まります。

この反対は、多くの場合正しいものです。現場は自分の業務の制約を知っています。問題は、それが検証の最後に出てくることです。業務側の担当者を最初から検証に参加させ、実際に手を動かしてもらうと、この種の問題は初期に表面化します。

参加のさせ方にもコツがあります。完成したものを見せて意見を聞くのではなく、途中の粗い状態で触ってもらうほうが率直な反応が得られます。完成品を見せられると、人は遠慮して褒めてしまうものです。

パターン4: きれいなデータで検証している

検証用に整えたデータで良い結果が出て、本番のデータを入れたら使い物にならなかった。これも典型です。実際の業務データには、表記の揺れ、抜け、スキャンの傾き、前任者の独自ルールといった汚れが必ずあります。

対策は、検証用データを作らないことです。本番のデータをそのまま、量だけ絞って使います。個人情報を含む場合は匿名化やマスキングが必要ですが、それは「整える」のとは別の作業です。汚れ方を保ったまま、識別できる情報だけを落とします。

もう一つ、データの量にも注意が必要です。20件で試して良かったものが、2000件では傾向が変わることがあります。少なくとも、業務で一日に発生する量は流してみてください。

パターン5: 運用費用を誰も計算していない

AIのAPIを使う機能は、使うほど費用がかかります。PoCの規模では月に数千円でも、全社で使えば桁が変わります。この計算を誰もしていないまま結果報告に進み、経営側に「で、月いくらかかるの」と聞かれて答えられずに持ち帰り、そのまま止まる。よく見る展開です。

PoCの段階で正確な見積もりは出せませんが、概算の桁は出せます。一回の処理でどれだけの入出力が発生するか、それが一日何回発生するかを掛け合わせれば、月額の規模感は分かります。人件費の削減見込みと並べて書いておけば、判断の材料になります。

パターン6: 担当者が抜けたら再開できない

異動、退職、他プロジェクトへの配置換え。半年のうちに担当者が変わるのは珍しいことではありません。問題は、PoCの過程で得た知見がその人の頭の中にしかない場合です。何を試して何がだめだったか、なぜその設定にしたかが残っていないと、後任は最初からやり直すことになります。そして、やり直す予算はたいてい出ません。

記録として残すべきは、うまくいった手順よりも、試してだめだったことと、その理由です。この記録があれば、後任は少なくとも同じ失敗を繰り返しません。記録の形式は問いませんが、「担当者のPCのローカルにしかない」状態だけは避けてください。

パターン7: 次に何をするかが決まっていない

「PoCで検証する」までが計画で、その先が白紙というケースです。結果が出た瞬間に、次は何を、誰が、いつまでに、いくらでやるのかという議論が始まり、その議論に数か月かかります。その間に熱量が冷めます。

着手前に、成功した場合の次の一手を一行で書いておきます。「営業部の1チームで3か月、実業務で使ってみる」程度で構いません。この一行があるだけで、結果報告の場が「やるかどうか」ではなく「いつ始めるか」の議論になります。この限定的な本番運用をどう設計するかは、PoC成功後、最初に作るもので詳しく扱っています。

止まる原因は着手前に見えている

7つのパターンを並べると、共通点が見えてきます。どれも技術の問題ではなく、着手前に決めておけたことです。そして、着手前なら30分の会話で確認できることばかりです。

PoCを始める前に、この記事のチェックリストを上から確認してみてください。答えられない項目が三つ以上ある場合、そのPoCは高い確率で止まります。止まると分かっているものに予算と時間を使うより、まず答えられない項目を埋めるほうが、結果として速く進みます。

弊社はAI活用開発として、既存のAIサービスを組み込んだ機能の実装をお引き受けしています。その前段として、そもそも作るべきかどうかの整理からご相談いただくことも多くあります。判断に迷う段階でも、お問い合わせからお気軽にご相談ください。ご相談・お見積りは無料です。