PoC失敗で終わる新規事業の共通点と本開発への進み方

PoC（Proof of Concept、概念実証）まで進んだのに、その先の本開発や事業化に進めない新規事業には、いくつかの共通点があります。この記事では、PoCで止まる典型的な原因と、本開発へ進むために始める前に決めておきたい判断の考え方を整理します。技術的に動くかどうかだけでなく、「次の判断をどう下すか」という視点から見ていきます。

PoCで終わる新規事業では何が起きているのか

PoCとは、新しい技術やアイデアが実現できるのかを、小さな範囲で試す取り組みです。AIの活用のように、やってみないと分からない技術的な不確実性が大きいテーマで、よく使われます。

「PoCがうまくいかなかった」と言われる場面は、大きく二つに分けられます。

• 検証した結果、技術面や事業面で難しいと分かった
• 検証は終わったが、結果をどう受け止め、何を決めればよいか分からず止まった

前者は、検証として成立しています。難しいと分かったのも成果のひとつです。この記事で主に扱うのは後者です。動かすところまでは進んだのに、本開発にも撤退にも判断が下りないまま時間が過ぎてしまう状態を、私たちは「PoC止まり」と呼んで整理します。

PoC・プロトタイプ・MVPは確かめることが違う

PoC止まりを考えるうえで、まず用語の違いを整理しておきます。会社やプロジェクトによって使い方に幅はありますが、確かめる対象で分けると分かりやすくなります。

種類	主に確かめること	主な見る人
PoC	技術的に実現できるか	開発・技術の担当者
プロトタイプ	形や使い勝手が構想どおりに伝わるか	決裁者・利用者候補
MVP	顧客が価値を感じ、使い続けるか	実際の顧客

MVPは Minimum Viable Product の略で、顧客に価値を確かめるための最小限の製品のことです。プロトタイプとMVPの違いはプロトタイプとMVP・モックの違いを整理｜新規事業の使い分けで詳しく扱っています。

ここで大切なのは、PoCで「技術的にできる」と分かっても、それは「事業になる」と同じ意味ではないという点です。PoCが確かめた範囲と、本開発の判断に必要な材料の間にすき間があると、結果が出ても次に進めなくなります。

PoC止まりの新規事業に共通する5つの点

PoCで止まってしまう新規事業には、始める前の設計に共通する点があります。ひとつずつ見ていきます。

1. 問いが「作れるか」に偏り、「事業になるか」を確かめていない

もっとも多いのが、検証の問いが技術の実現性だけに偏っているケースです。「この技術で精度が出るか」「このデータで動くか」といった問いに答えが出ても、「その機能に顧客が価値を感じるか」「継続して使われるか」「事業として成り立つか」は分かりません。

技術の検証は、事業の検証の一部にすぎません。PoCの結果が良好でも、本開発の判断に必要な材料がそろっていなければ、決裁者は判断を下せません。結果として、「技術的にはできそうだが、もう少し様子を見よう」という結論に落ち着きやすくなります。

2. 終わりの基準と、次の一手を決めずに始めている

次に多いのが、「何が分かれば終わりか」を決めないまま始める進め方です。

基準がないと、結果が出ても評価の物差しがありません。「精度が思ったほど高くない」という結果に対して、本開発に進むのか、手法を変えて再検証するのか、撤退するのかを、結果が出たあとで議論することになります。その時点では、関係者それぞれの期待が違っていて話がまとまらず、「追加で検証しよう」と二度目、三度目のPoCに入ってしまうこともあります。

3. 本開発を判断する人が、検証の途中を見ていない

PoCは現場や開発の担当者が進め、結果だけが報告書として決裁者に上がる、という形もよく見られます。このとき決裁者は、実物を触らないまま資料だけで判断することになります。

新規事業では、経営陣と現場が同じ目的を見ていても、判断の材料や進める速度が違うために話が噛み合わなくなることがあります。ズレているのは目的ではなく進め方です。この構造は新規事業で経営陣と現場がすれ違う原因は進め方のズレで、企画書だけで決裁を取る難しさは新規事業の決裁を企画書だけで取るのが難しい理由で整理しています。PoCの報告書も、企画書と同じ弱点を持っています。

4. 使う人や買う人に触れないまま終わっている

PoCが社内のテストデータや、限られた担当者だけの環境で完結していると、実際に使う人の反応が得られません。

画面の使いにくさ、業務の流れとの食い違い、そもそも課題として感じられていないことなどは、使う人に触れて初めて分かります。これらは、本開発に進んでから見つかると大きな手戻りになります。反対に言えば、PoCの段階で使う人の反応が得られていないと、「本開発に進んでよいという根拠」が足りないままになります。

5. 本開発の姿が見えず、PoCの成果物が宙に浮いている

PoCは、検証用のデータや限られた環境で動かすのが普通です。本番の運用では、ユーザーごとの権限管理、既存システムとの連携、セキュリティ、保守の体制など、PoCでは扱わなかった要素が必要になります。

これらを一度も整理しないままPoCを終えると、「本開発には何がどれだけ必要なのか」が誰にも見えません。見えないものに予算を付けるのは難しく、PoCの成果物は評価されても次の予算に結び付かない、という形で止まります。PoCのコードをそのまま本開発に使えるのか、作り直すのかが決まっていないことも、判断を重くする要因です。

PoCで終わること自体は失敗なのか

ここまで「止まる」ことを問題として書いてきましたが、PoCで終わること自体が悪いわけではありません。

検証の結果、この技術では課題を解決できない、あるいは事業として成り立たないと分かったなら、本開発に進まない判断は正しい判断です。大きな開発費を投じる前に分かったという意味で、PoCは役目を果たしています。

問題になるのは、次のような終わり方です。

• 何を確かめて、何が分かったのかが記録に残っていない
• 進むのか止めるのかが決まらないまま、自然消滅している
• 「うまくいかなかった」という印象だけが残り、次の企画の参考にならない

撤退も判断のひとつです。判断として下されたかどうか、そしてそこから学びが残ったかどうかが、PoC止まりと健全な撤退を分けます。そのために、始める前に「結果によって何を決めるのか」を言葉にしておくことが重要になります。

本開発へ進むための4つの考え方

ここからは、PoC止まりを避けて本開発の判断につなげるための考え方を整理します。

1. PoCの前に「次の判断」を決めておく

結果が出てから意味づけを考えるのではなく、結果の見え方ごとに次の判断をあらかじめ決めておきます。たとえば次のような形です。

検証の結果	次の判断の例
基準を満たした	本開発の範囲と進め方を決める
基準に届かないが、改善の見込みがある	原因を絞って期間を区切り、再検証する
基準に届かず、見込みも薄い	撤退し、分かったことを記録する

数値や期間の具体的な基準は、事業ごとに異なります。ただ、「どの結果ならどちらに進むか」を決裁者と現場が事前に合意しておくだけで、結果が出たあとの議論は大きく軽くなります。

2. 問いを分けて、順番に確かめる

新規事業の不確実性は、一種類ではありません。大きく分けると次の三つです。

• 技術：作れるのか
• 利用者：使う人が価値を感じるのか
• 事業：継続して成り立つのか

これらを一度のPoCで全部確かめようとすると、検証が重くなり、結果の解釈もあいまいになります。いま最も不確実なのはどれかを見極め、その問いに絞って小さく確かめるのが基本です。小さく作って確かめながら投資判断を進める考え方は、新規事業の開発は小さく作って確かめる投資判断の進め方で、動くシステムで確かめる手順は新規事業のアイデア検証方法｜動くシステムで確かめる手順で扱っています。

技術的な不確実性がすでに小さいなら、PoCを飛ばして、利用者に触れてもらえるプロトタイプやMVPから始める選択肢もあります。PoCを行うこと自体を目的にしない姿勢が大切です。

3. 判断する人と、実物を見ながら進める

決裁者が報告書だけで判断する構造を変えるには、検証の途中から実物を見てもらう方法が有効です。動くものを触りながら「ここはこう」「これは想定と違う」とやり取りできれば、資料では伝わらない部分が共有されます。

言葉だけで要件を決めると認識違いが起きやすく、使ってみて初めて分かる「これじゃない」が後工程で見つかる、という事故にもつながります。実物を見ながらすり合わせる利点はシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで、社内の稟議にプロトタイプを使う考え方は稟議を通すシステム開発｜プロトタイプの使い方で詳しく書いています。

4. 最初から本開発の姿を見据えて、範囲を絞る

PoCの段階で本開発の完成形をすべて描く必要はありません。ただ、本開発で何が必要になりそうかの見取り図は、早めに持っておきたいところです。

具体的には、本番で必要になりそうな要素を一覧にして、PoCで確かめたものと、まだ確かめていないものを分けておきます。そのうえで、最初に作る範囲は最小限に絞ります。機能の絞り方の基準はMVP開発の機能の絞り方｜最初に作るものと後回しの基準にまとめています。

システムそのものが事業の中核になる新規事業では、とくに重要です。PoCで確かめる対象が、事業の価値を生む部分と一致しているかを問い直します。システムを軸にした事業の組み立て方は新規事業のシステム設計とビジネスモデルの作り方が参考になります。

PoCを始める前に決めておきたい項目

上の考え方を、実際に始める前のチェック項目にまとめます。すべてを細かく埋める必要はありませんが、空白のまま始めると止まりやすくなります。

• 確かめたい問い：技術・利用者・事業のどれを確かめるのか、一文で言えるか
• 終わりの基準：どの状態になれば検証は十分と言えるのか
• 結果ごとの次の判断：基準を満たした場合、届かなかった場合に何を決めるのか
• 判断する人：誰が最終的に進退を決めるのか、その人は途中経過を見られるか
• 触れてもらう相手：実際に使う人や買う人の反応を、どの段階で得るのか
• 期間と範囲：いつまでに、どこまでを確かめるのか。延長する条件は何か
• 本開発への引き継ぎ：PoCの成果物を本開発に使うのか、作り直す前提なのか
• 記録の残し方：確かめたこと、分かったこと、次の問いをどう残すのか

この中でも特に、「結果ごとの次の判断」と「判断する人」は、あとから補いにくい項目です。始める前の準備全般については、システム開発を依頼する前の準備と流れ｜新規事業編も参考になります。

本開発に進む段階で整えたいこと

PoCの結果を受けて本開発へ進むと決まった場合にも、押さえておきたい点があります。

要件を整理し直す

PoCで見えた課題や、使う人から得た反応をもとに、本開発で作るものを整理します。PoC時点の前提がそのまま残っていると、抜け漏れや食い違いが生まれやすくなります。進め方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で解説しています。

PoCの成果物の扱いを決める

PoCのコードや設計を本開発にそのまま使えるのか、検証用として割り切って作り直すのかは、早めに決めておきたい論点です。独自に作る部分と、既存の仕組みを使う部分の見極めは、スクラッチ開発とは？新規事業で独自に作る部分の見極め方が参考になります。

開発の依頼先を選ぶ

PoCを行った会社と本開発を行う会社が同じとは限りません。PoCの結果や記録を、次の開発会社にどう引き継ぐのかも考えておきます。選ぶときの視点はシステム開発会社の選び方｜新規事業で失敗しない7つの視点に、外注全体の流れはシステム開発の外注ガイド｜依頼の流れと失敗の防ぎ方にまとめています。

納品後に育てる前提を持つ

新規事業のシステムは、公開した時点が完成ではありません。使われ方を見ながら機能を足し、直していくことで事業に合った形になります。この前提があると、最初から完璧を目指さずに範囲を絞りやすくなります。考え方はシステムは納品後の改善で育てる｜新規事業の考え方で扱っています。

AIを使った開発の動きも踏まえる

近年は、AIを活用して試作や開発を進める方法が広がり、動くものを早く作りやすくなっています。新規事業の立ち上げがどう変わるかはAI駆動開発で新規事業の立ち上げはどう変わるかで整理しています。ただし、動くものが早くできることと、品質や判断が確かなことは別です。人による確認が必要な理由はAI開発でも品質には人の確認が必要な理由で触れています。

まとめ

PoCで止まる新規事業の共通点と、本開発へ進むための考え方を整理しました。

• PoCで止まるのは、技術的に動かなかったからとは限らない。検証の結果を次の判断につなげる設計が不足していることが多い
• 共通点は5つ。問いが技術に偏っている、終わりの基準がない、判断する人が途中を見ていない、使う人に触れていない、本開発の姿が見えていない
• 撤退もひとつの判断であり、確かめたことと分かったことが記録に残っていれば、PoCは役目を果たしている
• 始める前に、確かめたい問い、終わりの基準、結果ごとの次の判断、判断する人を決めておく
• 問いは技術・利用者・事業に分け、いちばん不確実なものから小さく確かめる
• 判断する人と実物を見ながら進めると、報告書だけでは伝わらない部分を共有できる

PoCは、それ自体がゴールではなく、本開発や事業化の判断をするための材料づくりです。その材料が、判断する人に届く形になっているかを、始める前に見直しておくことが近道になります。

JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスです。「先に作って、後から決める（PROTOTYPE FIRST）」の考え方のもと、構想をもとに約1ヶ月で実際に動くプロトタイプを先に開発し、実物を見てから契約するかを判断できる進め方をとっています。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。システムを軸にした新規事業の進め方にお悩みの場合は、JustFitのサービス紹介もあわせてご覧ください。