PoCの失敗は「結果が悪いこと」ではなく「判断できないこと」
PoCの失敗というと、期待した精度が出なかった、技術的に動かなかった、という場面を思い浮かべるかもしれません。しかし、前提が成り立たないと早く分かったのであれば、それは大きな投資の前に危険を見つけたという意味で、PoCとしては役目を果たしています。
本当に困るのは、終わったのに次をどうするか決められない状態です。動くものはできた、報告書もある、しかし本開発に進む根拠としては弱く、やめる理由にもならない。担当者は追加の検証を提案し、同じような検証が続く。この状態こそが、PoCの失敗として扱うべきものです。
この記事では実在の失敗事例は紹介しません。外から見える情報だけでは、本当の原因を確かめられないためです。代わりに、判断できないPoCを生む原因を構造として整理し、着手前に確認できる形にします。
原因1：目的が「技術的にできるか」だけになっている
PoCの問いが「この技術で実現できるか」だけだと、結果は「できました」で終わります。ところが、事業として進めるかどうかを決める人が知りたいのは、できるかどうかだけではありません。それを使う人がいるか、現場の仕事に収まるか、続けるための費用に見合うか、です。
防ぎ方は、PoCの問いを、その後の投資判断から逆に書くことです。
- PoCの後に決めたいことを書く（本開発に進むか、対象を変えるか、止めるか）。
- その決定に必要な根拠を挙げる。
- そのうち、今回のPoCで確かめるものを選ぶ。
- 今回は確かめないものを明記し、いつ確かめるかを書く。
技術の確認だけを目的にすること自体は問題ではありません。問題は、技術の確認しかしていないのに、事業として進める根拠がそろったかのように扱うことです。そもそも今の問いに合う手段がPoCなのかどうかは、PoC・試作画面・MVPを答えたい問いから選ぶ考え方で確認できます。
原因2：合格・不合格の条件を決めずに始めている
合否の条件がないまま始めると、結果が出てから基準を考えることになります。すると、出た結果に合わせて評価が甘くなったり、反対に、もともと慎重だった人が後から高い基準を持ち出したりします。どちらの場合も、結果は判断の材料として使われなくなります。
始める前に決めておくことは次のとおりです。
- 何を測るか（指標）
- どの水準なら合格か、どの水準なら不合格か
- その中間だった場合にどうするか
- 誰が、いつ、その判断をするか
とくに忘れられやすいのが中間の扱いです。検証の結果は、はっきり合格でもはっきり不合格でもない形になることがあります。その場合に「対象を絞って再検証する」「条件を変えて一度だけ延長する」などの選択肢を先に決めておくと、終わりのない検証を避けられます。決め方の詳細はPoCの終了日に次の投資を決められる評価設計にまとめています。
原因3：現場や利用者が検証に入っていない
企画部門と開発者だけで進めたPoCは、整った条件のもとでは動きます。しかし、実際の仕事の中に置くと、想定していなかった事情が出てくることがあります。入力するデータが日によって欠けている、確認のための時間が現場にない、例外の処理が思ったより多い、などです。
これらは技術ではなく仕事の流れの問題であり、現場の人が検証に加わっていなければ、終わるまで見えません。
防ぎ方は、次の二点です。
- 計画の段階で、実際に使う立場の人に業務の流れを聞き、例外と手戻りの多い場面を把握する。
- 検証の期間中に、その人たちが実際のデータや実際の場面で使う時間を確保する。
現場の協力を得るには、相手の負担を先に示すことが欠かせません。どの期間に、どれくらいの時間、何をしてもらうのかを計画に書き、上長の了解を得ておきます。
原因4：運用と本番への道筋を考えていない
PoCの環境では、人が手でデータを整え、開発者が不具合をその場で直していることがあります。その状態で得られた結果は、運用が始まった後の姿を表していません。本番では、誰がデータを用意し、誰が誤りに気づき、誰が問い合わせに答え、誰が費用を負担するのかを決める必要があります。
PoCの段階で運用の全部を作る必要はありません。ただし、次の問いには答えを用意しておくと、PoCの後で話が止まりにくくなります。
- 本番で使う場合、運用を担う部門はどこか。その部門はこのPoCを知っているか。
- 続けるために必要な費用（利用料、保守、人の作業）を誰が負担するか。
- 社内の情報管理やセキュリティの審査は、いつ、誰に相談するか。
- PoCの後に必要な予算は、どの会議で、いつ決まるか。
予算の決定時期とPoCの終了時期がずれていると、結果が良くても次の予算の時期まで動けないことがあります。終了日を決めるときは、社内の意思決定の日程から逆に置くと安全です。
AI・生成AIのPoCで起きやすいこと
AIや生成AIのPoCでも、上の四つの原因はそのまま当てはまります。加えて、次の点でつまずきやすくなります。
- 評価の物差しがない：出力を見た人の印象で良し悪しを決めてしまう。評価に使う入力と、期待する出力の見本を先に用意していないと、改善したのかどうかも分かりません。
- 誤りの扱いを決めていない：AIの出力には誤りが含まれることがあります。誤りが起きたときに誰が気づき、どう直すかを決めずに精度だけを追うと、どこまで精度を上げれば十分なのかが決まりません。
- 試しやすさが目的を曖昧にする：生成AIは短時間で動くものが作れるため、目的を決める前に試作が進みがちです。動く画面ができたことと、業務で使えることは別です。
- データと権限の確認が後回しになる：使いたいデータを、その用途で使ってよいかの確認が遅れ、途中で止まります。
生成AIを組み込んだサービスの設計は、生成AIのMVPで失敗時の仕事まで設計する考え方でも扱っています。
着手前に確認する項目
ここまでの内容を、始める前の確認項目にまとめます。一つでも答えられないものがあれば、着手を急ぐ前に埋めることをおすすめします。
- このPoCが終わったら、何を決めるのか。
- 合格・不合格・中間のそれぞれで、次に何をするか。
- 判断するのは誰で、その人は条件に同意しているか。
- 実際に使う立場の人が、計画と検証の両方に関わっているか。
- 本番で運用を担う部門と、続けるための費用の負担者は見えているか。
- 終了日は、社内の予算や会議の日程と合っているか。
- 今回は確かめないことが明記されているか。
よくある質問
Q. すでに始めてしまったPoCに合否条件がありません。途中から決めても意味はありますか。
あります。結果が出そろう前であれば、関係者で条件を確認する価値は十分にあります。すでに一部の結果が見えている場合は、その結果を見たうえで決めた条件であることを記録に残し、判断する人に正直に伝えてください。隠して進めると、後で判断の信頼が損なわれます。
Q. 不合格だった場合、社内でどう説明すればよいですか。
確かめた前提、分かったこと、避けられた投資、次に取り得る選択肢の順で説明します。不合格は担当者の失敗ではなく、前提が成り立たなかったという発見です。始める前に合否の条件を合意しておけば、この説明はずっと楽になります。
Q. PoCを何度も繰り返していて、前に進みません。どこから見直せばよいですか。
まず、これまでのPoCがそれぞれ何を決めるためのものだったかを一覧にしてください。決めることが書けないものが続いているなら、原因は検証の中身ではなく、判断する人と条件が定まっていないことにあります。次のPoCを計画する前に、誰が何をもって決めるのかを先に合意することが近道です。
Otsumuに相談できること
Otsumuは、新規事業の検証・MVP開発・運用の自動化を、戦略と開発を分けずにひとつのチームで支援しています。PoC / MVP Sprintでは、検証目的と機能範囲の合意から始め、主要画面と利用シナリオ、検証用のPoC / MVPシステム、効果測定の項目・計測設計、公開・運用に向けた引き継ぎ、検証結果と次フェーズの改善方針までを成果物としています。参考価格は税別300万円〜、6週間を目安に設計し、正式な見積もりは相談後にお出しします。
上の確認項目を社内で埋められ、作る体制もあるなら、外部の支援は必要ありません。項目が埋まらない、あるいは過去のPoCが判断につながらなかった理由を整理したい場合は、30分の無料診断でお話をうかがいます。今の段階を手早く確かめたい場合は、5つの質問による診断も使えます。回答は送信も保存もされません。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。記載の価格はOtsumuの税別・参考価格で、正式なお見積もりはご相談後にご案内します。法務・税務・会計・補助金などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.09.21