協業PoCの多くは、技術で失敗するのではなく「評価の設計」で失敗しているのではないか、と考えられます。何を、いつ、どの数字で判断するのか。大手側の稟議とスタートアップ側のリソース、双方の事情を踏まえたKPI・マイルストーン設計を、両面から整理します。
大手企業・商社・SIerの新規事業／オープンイノベーション部門で、スタートアップとの共同PoCを立ち上げた経験のある方なら、一度は見た光景があると思います。デモは盛り上がり、経営層への報告も好評だった。それなのに、いざ次年度の本格導入や事業化の話になると、社内のどこからともなく「で、結局いくら儲かるの？」「効果が数字で見えないよね」という声が上がり、プロジェクトが静かに止まる。いわゆる「PoC死」です。
この現象は、技術が力不足だったから起きるとは限りません。むしろ、検証すべきだったことと、評価に使った物差しがズレていたために起きているケースが多いのではないか、と考えられます。初期のPoCに「売上」「導入台数」「ROI」といった事業KPIを置いてしまうと、まだ技術仮説すら固まっていない段階の取り組みを、事業の物差しで採点することになります。当然、良い点数は出ません。結果として、本来は有望だった芽まで「効果不明」として刈り取られてしまう。
協業のKPIは、単なる目標管理ツールではありません。立場も時間軸も違う大手とスタートアップが「何をもって成功とするか」を共有するための、いわば共通言語です。ここが曖昧なまま走り出すと、大手側は「事業インパクト」を、スタートアップ側は「技術の実証」を、それぞれ勝手に成功のイメージとして描き、半年後にすれ違いが表面化します。協業の全体像は製造業×スタートアップ協業の進め方でも整理していますが、その中でもKPI設計は「最初にズレると最後まで響く」論点だと考えます。
「なんとなくうまくいかなかった」で片づけると、次のPoCでも同じ失敗を繰り返します。まずは、協業PoCが事業化に進まない構造を分解して見ておくのが有効だと考えます。事業化しない理由の類型はオープンイノベーションPoCの失敗構造でも扱っていますが、KPIの観点からは大きく4つに整理できると考えられます。
最も多いのが、事業性の評価軸を検証の初期に持ち込むパターンです。技術がそもそも成立するかを確かめる段階なのに、収益性や投資回収を問うてしまう。これは、種をまいた翌週に「実がならないじゃないか」と畑を掘り返すようなもので、評価のタイミングそのものが誤っていると考えられます。
「とりあえずデータを入れて動かしてみよう」で始まると、何を確かめたかったのかが曖昧になります。仮説がなければ、結果を見ても「成功／失敗」を判定できません。数字は出るのに、その数字が良いのか悪いのか誰も断言できない、という宙ぶらりんの状態に陥りがちです。
「どの水準を超えたら次に進むのか」を事前に決めていないと、PoC終了時に評価が政治的になります。推進派は「十分いける」と言い、慎重派は「まだ不十分」と言う。判断基準が事前になければ、その場の力関係や声の大きさで結論が決まってしまい、合理的な意思決定になりにくいと考えられます。
大手の稟議・予算サイクルは年単位で動くのに対し、スタートアップの手元資金は月単位で減っていきます。この時間感覚の差が、KPIの達成期限にそのまま反映されずに走ると、「大手が意思決定する頃にはスタートアップの体力が尽きている」という悲しいすれ違いが起きうると考えられます。
では、どう設計すればよいのか。出発点として提案したいのは、KPIを「事業の指標」ではなく「検証すべき仮説の指標」から組み立てる、という発想の転換です。協業PoCの初期に本当に問うべきは「儲かるか」ではなく「そもそも成立するか」「現場で回るか」であり、それらは検証仮説として言語化できます。
良い検証仮説は、成否を客観的に判定できる形をしています。たとえば外観検査の文脈であれば、「この不良種は、現場と同等の照明条件・撮像条件で、目標の見逃し／過検出の水準に収まるか」といった具合です。ここで重要なのは、精度目標を先に数字で握るより前に、検証の前提条件（サンプル数、撮像環境、判定基準、正解ラベルの定義）を握ることだと考えます。前提が揃っていない数字は、良くも悪くも意味を持ちません。
数値目標を置く場合でも、それは「モデル前提の一例」であり、必ず現物・現場での検証が前提になる、という位置づけを両者で共有しておくことが誠実だと考えます。カタログ的な精度と、その顧客の現物・その現場のライティングでの精度は別物であり、後者を確かめるのがPoCの本質だからです。この撮像条件・照明条件を詰める工程は、元キーエンス画像処理事業部の現場知見 × VLM × Jetsonエッジ × 産業用カメラ × 現場ライティングという観点でNsightが最も価値を出せる領域だと考えています。
見落とされがちですが、PoCの成果は「成功／失敗」だけではありません。「この不良種は現状の手法では難しいと分かった」「この工程は自動化より人の目を残す方が合理的だと分かった」といった学びも、次の意思決定を精度高くする立派な成果です。No-Goでも学びが資産として残る設計にしておけば、PoCは「賭け」ではなく「投資」になります。段階設計の実務はPoCから事業化までのフェーズ設計も併せて参照いただくと、フェーズごとの学びの積み上げ方がイメージしやすいと考えます。
KPI設計の核は、フェーズごとに評価軸を切り替えることだと考えます。一つの物差しで最初から最後まで測ろうとするから無理が出る。段階に応じて「今、何を問うべきか」を変えていく設計が、PoC死を防ぐうえで有効だと考えられます。
最初のフェーズで問うのは、技術仮説が成立するかどうか、その一点です。KPIは精度・処理速度・再現性など、技術指標に絞る。ここで売上や台数を語るのは時期尚早です。ただし技術指標も「実データ・実条件で」測ることが前提で、理想的な実験室データだけで良い数字が出ても、それは次フェーズへの通行手形にはならないと考えます。
技術が成立しても、現場で使えるとは限りません。第2フェーズでは、実際の作業者が使えるか、既存の工程・システムに無理なく組み込めるか、例外ケースやイレギュラーにどう対応するか、を問います。KPIは業務適合の指標に切り替わります。現場のオペレーターの負荷、判定に迷ったときの運用、システム連携の手離れ――技術デモでは見えなかった「運用の摩擦」が、ここで初めて可視化されます。多くのPoCは技術検証で満足して業務検証を飛ばすため、いざ本番でつまずくのだと考えられます。
技術が成立し、現場で回ることが確認できて、ようやく事業性の物差しを持ち出す段階になります。ここで初めて、コスト構造・投資回収・スケール時の展開性といった事業KPIが正当な意味を持ちます。逆に言えば、フェーズ1・2をきちんと通過していれば、事業性検証で使う前提数字は「机上の空論」ではなく「検証済みの実測に基づく試算」になり、社内稟議の説得力が段違いになると考えられます。
フェーズを切り替える設計にしたら、次に決めるべきは各フェーズ間のGo/No-Go基準です。ここでの鉄則は一つ、「基準は結果を見る前に、文章で合意しておく」ことだと考えます。結果を見てから基準を語ると、人はどうしても自分に都合よく解釈してしまうからです。
Go/No-Go基準は、評価指標・合格水準・判定時点の3点セットで書き出すのが実務的だと考えます。「精度がある水準を、現場相当の条件で、この時期までに達成できたらGo」というように、条件付きで明文化する。同時に、水準に届かなかった場合の分岐も決めておきます。No-Goなら撤退か、条件を変えて再挑戦か、対象を絞り込んで継続か。分岐を先に決めておくと、いざその局面で感情的な綱引きになりにくいと考えられます。
現実には、明快なGoでもNo-Goでもない「グレー」な結果が最も多いと考えられます。ある不良種は良好だが別の種は課題が残る、といった具合です。この場合に「対象範囲を絞ってGo」とするのか「もう一度条件を変えて検証」とするのかを、あらかじめ話し合っておく。グレーゾーンの扱いを決めていないPoCほど、終了時に「成功だったのか失敗だったのか」で揉めやすいと考えられます。判定は担当者個人ではなく、両社の合意プロセスとして設計するのが望ましいと考えます。
なお、契約や知財、データの取り扱いに関する取り決めは、KPIとは別に早い段階で整理しておくことが重要です。これらは一般的な解説の範囲を超える部分も多く、契約・法務・制度の具体は専門家や最新の公式情報でのご確認を推奨します。KPIの合意と契約上の取り決めは車の両輪だと考えます。
KPI設計でもう一つ見落とされやすいのが、時間軸の非対称性です。ここはスタートアップ側の内情に触れておく価値があると考えます。私たちNsight自身も、大手企業・商社との協業や共同出展、オフラインの勉強会を実践しているスタートアップの立場から、この時差の痛みを実感しています。
大手側は、予算取り・稟議・意思決定が四半期〜年単位で動くのが通常です。一方でスタートアップは、手元のランウェイ（資金が尽きるまでの残り時間）を月単位で意識しながら動いています。この時差を無視してKPIの達成期限を引くと、「大手が次の予算を確保する頃には、スタートアップは別の案件にリソースを振らざるを得なくなっている」という事態が起きうると考えられます。
対策として有効なのは、フェーズを短く区切り、各フェーズの成果を大手側の意思決定サイクルに乗せやすい形で出すことだと考えます。年に一度の大きな判断ではなく、数ヶ月ごとに「ここまで分かった」という節目を作り、その都度小さくGo/No-Goを回す。こうすると、スタートアップ側は長期の不確実性を抱え込まずに済み、大手側も小刻みにリスクを取れるため、双方の時間感覚の折り合いがつきやすくなると考えられます。
善意の担当者でも陥りがちなのが、「まずは無償で、成果が出たら本契約で」という進め方を長期間にわたって求めてしまうことです。スタートアップにとって、期限の見えない無償検証はそのまま資金の消耗を意味します。フェーズごとに適切な費用負担や役割分担を設計し、双方が身銭を切って本気で取り組める構造にすることが、結果的にPoCの質を上げ、事業化の確度を高めると考えられます。フェアな時間軸と費用の設計は、信頼という無形資産を積み上げる行為でもあると考えます。
最後に、実務でよく見る落とし穴を挙げておきます。いずれも「分かっていても、走り出すと忘れがち」なものばかりだと考えます。
ここまでの整理を、実際に動かすための順序に落とし込みます。完璧な設計を机上で作り込むより、小さく始めて回しながら精度を上げていく方が、協業では現実的だと考えます。
まず、このPoCで確かめたい仮説を、両社で1枚の紙に書き出すことから始めるのが有効だと考えます。「何が成立すれば次に進むと言えるのか」を言語化する。この段階で、大手側とスタートアップ側で成功イメージがズレていることに気づくことも多く、それ自体が大きな収穫になります。
次に、華やかな目標数値を置く前に、現物と現場の現状を客観的に把握します。実際のワーク、実際の照明、実際の作業の流れを見る。ここを飛ばして数値目標だけ先に握ると、後で「前提が違った」となりがちです。出発点は常に現物・現場の把握だと考えます。
仮説と現状把握を踏まえ、技術検証→業務検証→事業性検証のフェーズを区切り、各フェーズ間のGo/No-Go基準を文章で合意します。期限は大手の意思決定サイクルとスタートアップの体力の両方を見て、無理のない刻みにする。ここまで揃えば、PoCは「やってみないと分からない賭け」から「設計された学習プロセス」に変わると考えられます。
こうしたKPI・マイルストーンの設計と、現物・現場を起点にした検証の進め方は、外から伴走する第三者がいると議論が整理されやすい面もあると考えます。もし具体的なテーマで検証仮説の言語化やフェーズ設計を一緒に詰めたい場合は、PoC伴走支援の枠組みでご一緒することもできますし、まずは論点整理だけでも相談するところから始めていただければと思います。
技術仮説や業務仮説がまだ固まっていない初期段階に売上や導入台数といった事業KPIを置くと、本来検証すべきことが評価されないまま「効果が見えない」と判断されがちだからだと考えられます。評価軸は技術検証→業務検証→事業性検証とフェーズごとに切り替え、収益性は最後に問うのが有効だと考えます。売上KPIそのものが不要なのではなく、置くタイミングの問題だと考えられます。
結果を見る前、つまりPoC開始前に文章で合意しておくのが望ましいと考えます。評価指標・合格水準・判定時点の3点セットで明文化し、水準に届かなかった場合の分岐（撤退・条件変更で再挑戦・対象を絞って継続）まで先に決めておく。さらに明快な成否ではない「グレーゾーン」の扱いも話し合っておくと、終了時の政治的な綱引きを避けやすくなると考えられます。
成否を客観的に判定できる「反証可能」な形にするのが基本だと考えます。画像検査であれば、現場相当の照明・撮像条件で、対象の不良種が目標水準に収まるか、といった形です。数値目標を置く場合も「モデル前提の一例」とし、必ず現物・現場での検証が前提であることを両社で共有しておくのが誠実だと考えます。前提条件（サンプル数・撮像環境・判定基準）を先に握ることが重要だと考えられます。
大手の稟議は年単位、スタートアップの資金は月単位で動くため、この非対称を設計に織り込む必要があると考えます。フェーズを短く区切り、数ヶ月ごとに成果の節目を作って小刻みにGo/No-Goを回すと、双方の時間感覚の折り合いがつきやすくなると考えられます。期限の見えない長期の無償検証を暗に求めない配慮も、協業の信頼を保つうえで大切だと考えます。
KPIの合意と契約上の取り決めは車の両輪だと考えます。KPIは「何をもって成功とするか」を共有するもので、契約・知財・データ利用は成果や責任の帰属を定めるものです。いずれも早い段階で整理しておくことが望ましいですが、契約・法務・制度の具体的な内容は一般的な解説の範囲を超える部分も多く、専門家や所管省庁・関係機関の最新の公式情報でのご確認を推奨します。
協業PoCの成否は、華やかな目標数値ではなく「何を、いつ、どの物差しで判断するか」の設計で大きく変わると考えます。まずは現物・現場を客観的に把握し、検証仮説を1枚に書き出すところから。論点整理だけでもお気軽にご相談ください。
協業PoCのKPI設計について相談する