PoCの進め方とは？5ステップと、無償PoCを事業化につなげる判断基準

PoCを進めるには、「何を、どの順序で、どう判断するか」 を最初に決めることが最も重要です。この記事では、PoCを5ステップで進める手順を解説します。

ただし一点、留意すべきことがあります。無償PoCは「進め方」が正しくても、収益を生むことの証拠には、必ずしもなりません。

無料で受け取られたことは、顧客が対価を払ってでも導入したいことの意思表明にはなりえないからです。

この記事では、無償PoCを、どの前提仮説のテストとして設計するかを合わせて解説します。

PoCとはそもそも何か？

ビジネスの現場で頻繁に耳にする「PoC」ですが、まずはその定義と役割を正しく理解することが、成功への第一歩です。

新規事業の実現性を検証する手法

PoCとは、簡単に言えば、「このビジネスアイデアは、本当にビジネスとして長期間 持続的に回りそうか？」を、最初の一歩として、小規模の投資で確かめる作業です。

ある素材メーカーで実際にあった話です。時間とコストをかけて研究開発した新製品サンプルを、技術展示会で無料配布したところ、飛ぶように「売れ」ました。手応えを感じたチームは、そのまま量産に進みました。ところが実際には、想定したほど売れず、何年も損益分岐点に届かない状態が続いているそうです。厳しい言い方をすれば、この「PoC」は、街角のティッシュ配りに近かったのです。無料で受け取った人が多いことと、対価を払って買う人が多いことは、まったく別の話だからです。

だから、無償PoCは、そのすぐ先にくるべき有償の検証や導入判断につなげるために、「ビジネスとして、長期間、持続的に成り立ち続けられるかどうかの諸条件」を確かめる段階なのです。

本開発のリスクを最小限に抑える

PoCを実施する最大のメリットは、本格的な開発や投資を行う前にリスクを洗い出し、最小化できる点にあります。いきなり大規模な予算を投じてシステム開発や製品製造を行ってしまうと、万が一失敗した際の損失は計り知れません。

小規模かつ低予算でPoCを行うことで、致命的な欠陥や想定外の課題を早期に発見できます。もし実現不可能だとわかれば、その段階でプロジェクトを中止したり、方向修正したりすることが可能です。つまり、PoCは成功を確約するためだけでなく、「賢く失敗する」ための手段でもあります。

実証実験やMVPとは目的が違う

PoCと混同されやすい言葉に「実証実験」「プロトタイプ」「MVP（Minimum Viable Product）」などがありますが、それぞれ目的や実施フェーズは異なります。これらの違いを明確にしておくことで、プロジェクトメンバー間での認識ズレを防ぎやすくなります。

以下の表に、それぞれの用語の定義と主な目的を整理しました。

特にMVPは、「最低限の機能を持つ製品」と雑に理解されがちですが、本来はそうではありません。MVPとは、市場からある特定の情報を学びとるためだけに設計された最小セットの提供物なのであって、「可能な限り機能を削った未完成品」などではありません。

【関連記事】MVPの重要性：新規事業 成功の秘訣を徹底解説

なぜ今PoCが重要視されるのか？

近年、PoCが重要視されている理由は、技術や市場の不確実性が高まり、いきなり本開発や本格投資に進むことのリスクが、ようやく広く認識されてきたからです。そもそも新規事業開発の世界では、仕様を固め、一直線に開発を進め、技術を実現してから最後に市場へ出せばよい、という進め方で、無数の失敗が積み上がってきました。
その結果、「まず造ってからから売れるかどうかを見る」のでは遅すぎる、という当たり前のことが、遅ればせながら共通認識になってきて、そのアイデアが現実の条件の中で本当にビジネスとして成り立つのかを、小さく確かめる PoC が重要視されるようになりました。

開発の手戻りを防ぎコストを削減

PoCがないまま本開発に進むと、最後の段階で、

• 想定した条件では使えない
• 様々な理由で、導入条件を満たし得ない／顧客の運用に乗らない
• 原価が合わない

といった、その時点では今更どうにもならない問題が発生しやすくなります。こうなると、設計の見直し、営業方針の変更、場合によっては事業方針の修正まで必要になり、最悪その事業は取り潰し……となりかねません。
PoCを行えば、こうした致命傷を本格的に投資する前に見つけやすくなります。つまりPoCは、間違った前提のまま大きく進まないためにも重要なのです。

スピーディな意思決定を促進する

新規事業では、判断が遅れること自体がリスクですが、材料が足りないまま「行けそうだ」で突っ込むのも危険です。PoCはこの隙間を埋めます。机上の検討ではなく、実際にお客様に試していただいた結果として、この条件なら成立しそうか、どこに無理があるか、どこを次に確認すべきか、が見えてくると、Go / No-Go の判断がしやすくなるのです。

特に初期段階のPoCでは、最終結論を出そうとしてはいけません。次に進むに値するかどうかを判断する材料を得ることが重要なのです。

関係者間の具体的な合意を形成

PoCは、顧客だけでなく、社内の認識合わせにも役立ちます。

新規事業では、経営は採算を見ており、営業は売りやすさを見ており、技術は実現可能性を見ています。PoCがないと、それぞれが違う前提のまま議論し、話が噛み合いにくくなります。実物、試作、評価結果、反応といった具体物があると、あらかじめ諸条件を同じ土俵で話せるようになります。

以下の表は、PoCを実施することで得られる主なメリットを、ステークホルダー別に整理したものです。

要するに、PoCには、不確実なものを、いきなり大きな賭けに出ずに、すべてのステークホルダーが、前提を一つ一つ確かめながら進められるメリットがあるのです。

PoCの進め方5つのステップ

PoCを成功させるためには、体系的なステップに沿って進めることが不可欠です。ここでは、計画から評価までを5つの手順に分解し、各フェーズでやるべきことを具体的に解説します。

手順１目的とゴールを明確化する

最初にやるべきことは、「このPoCで何を確かめたいのか」を一文で言えるようにすることです。ここが曖昧だと、PoC全体の目的がピンボケになり、ずるずると続くことになりかねません。この案は顧客にとって導入価値がありそうか、あるいは顧客のRoIを満たせそうか、といった、検証テーマを具体化的に言語化しておく必要があります。

この段階で、PoCの終了／中断条件も決めておきましょう。「採算が合うと判断できれば成功」なのか、「何パーセントの顧客が有償に移りたいと言ったら成功」なのか、成功の定義を関係者と合意しておく必要があります。

なお、「ユーザー満足度が一定を超えれば成功」などという、曖昧な評価基準は避けましょう。有償でもないのに、そんなアンケートをとったところで、本音がわかるはずがありません。上記の「ティッシュ配り」の事例のように、フォルスポジティブ（偽陽性）による担当者の勘違いを呼び、プロジェクトを成功から遠ざけるだけです。

手順２検証範囲と評価基準を設定

次に、今回何をどこまで検証するのか？をギリギリまで絞ります。

PoCでありがちなのは、気になることを全部一度に確かめようとして、結局何が確かめたかったのか、後で誰もわからなくなることです。この意味で、複数機能を具備したプロトタイプをPoCにかけるのは、決してやってはいけないことの一つです。顧客がどの機能がなければ使い物にならないと思うかを、判断しにくくなり、かつ、「これらの機能、全部そろっていたところで、うちはこのプロダクトは買わない」という、最も重要なフィードバックをとり損ねるリスクがあります。

そこで、今いちばん不安な論点は何で、そこが分からないと次へ進めないのはどこか、を整理して、範囲を絞り込みます。同時に、計測するポイントをKPIとして決めておきます。数値で置けるものは数値で、そうでないものは観察項目として置いておくと、議論がぶれにくくなります。

＜KPIの例＞

• この案は、顧客の抱えた課題を、対価を十分に支払ってくれるレベルで解消するか？例：PoC前後での、工数の削減値
• 自社が利益を十分に載せた上で、顧客の RoI を満たせるか？→規模の経済が働くまで赤字が続くとしたら、何年くらい損益分岐点まで届かないのか？
• 実際の現場で使い続けられる（最初の１年で契約解消では意味がない）ための条件を満たしそうか？
• 顧客が必要としている、成果の数値目標を達成できそうか？
• 相手が、期間内に、次の段階である有償PoCに進む意思を示すか？

ここで重要なのは、

ことです。上掲の記事に書いたイリジウムは、衛星電話としては当時超高性能でしたが、無惨にチャプター１１の最悪記録を更新する大失敗を喫しました。品質の基準値は、お客様が決めるものです。お客様が真に求めているプロダクトは、往々にして、低品質でもヒットします。IKEAの家具や初代 iPhone が、その典型例です。

手順３実施計画を策定し体制を構築

目的と見る範囲が決まったら、実際にどう回すかを決めます。PoCは短く回す方がよいとはいえ、準備なしで始めると、かえって時間と工数を失います。

また、開発側だけで完結させないことも大切です。現場で使う人、評価する人、場合によっては導入判断に関わる人まで視野に入れておかないと、「造れたけれど、進まない」で終わりやすくなります。

以下は、実施計画書に入れておくと便利な項目の一例です。

手順４計画に基づきPoCを実行する

準備が整ったら、PoCを実行します。

実際に動かすと、机上では見えなかったことが出てきます。技術的には可能でも運用が重すぎるかもしれないし、逆に想像以上に手応えがある部分もあるでしょう。だからPoCでは、うまくいったかどうかだけでなく、どこで止まり、何が想定と違い、どこに改善の余地があるのかを記録します。数字だけでなく、現場の反応や違和感も重要な材料です。

手順５結果を評価し次を判断する

PoCが終わったら、結果を振り返ります。

ここで避けたいのは、「成功」「失敗」の二択で雑に終わらせることです。大事なのは、何が確認できて、何がまだ曖昧で、次に進める材料がそろったのかどうかを見ることです。結論は三つです。

• 有償のPoCに進む
• 条件に不具合があったと科学的に判断できた場合のみ、条件を変えて、もう一度確かめる
• 終了／中止する

そして、中止こそが最も立派な成果である場合も少なくありません。早い段階で「今は進めるべきでない」と分かれば、それだけで大きな損失を防げるからです。

このとき、「部分的にうまくいったから……」と、造ってしまったものに連綿と執着し、当初決めたKPIを書き換えてまで、続けるのだけは絶対に避けてください。将来回収できないサンクコストがかさむだけです。

PoCを成功させるための注意点は？

PoCは万能な魔法の杖ではありません。やり方を間違えると、時間と予算を浪費するだけのイベントになってしまいます。ここでは、PoCで陥りがちな失敗パターンと、それを回避するための注意点を解説します。

検証目的が曖昧なまま始めない

最も多い失敗原因は、目的の曖昧さです。「上司に言われたから」「他社もやっているから」といった理由で開始すると、何を検証すればよいかが定まらず、結果として何も判断できないまま終わってしまいます。

最悪のケースは、私はいくつも見てきましたが、

• PoCをやりたいからやるんだ！と、手段が目的化している
• 社内から／補助金を得て、予算が獲得できたからやる
• 「PoCやった方がいいですよ」と、PoC支援コンサル会社ににそそのかされた

という３パターンです。このケースは、まず間違いなく事業に結び付かず、コストを無駄に垂れ流すだけで終わります。

DXというバズワードが大流行した2020−2021年ごろ、私は、「DX_PoC」というキーワードでググり、外販向けのサービスのPoCの記事を、Evernote にメモしました。その数、20以上。そして2024年、それらのPoCが無事事業化できているかどうかを、一つ一つ確認しました。事業化まで曲がりなりにもこぎつけていたPoCはたったの一つであり、しかもそれは、大ヒットではなくて、某県庁で使われている、というだけのこじんまりした結果にとどまっていました。

常に「このPoCは何をアウトカム（大目的）として実施するのか？」という原点に立ち返ることが重要です。目的がブレていると感じたら、勇気を持って計画段階に戻り、再定義する必要があります。

造り込みすぎて目的がずれる

エンジニアや開発担当者が陥りやすいのが、検証用のシステムを作り込みすぎてしまうことです。PoCの目的はあくまで「ビジネスとして成り立つかどうかの諸条件の検証」であり、「完成品を造ること」ではありません。

開発者が、開発を面白がって、自分のプロダクトを完璧だと思い込むという心理を、IKEA効果と言います。だからこそ、開発スコープはギリギリまで簡単なものに、絞り込む必要があります。PoC時点では、まだ本開発をするかどうかは愚か有償PoCに進むかどうか決まっていないのだから、見事な試作品を仕上げたあまり、

と倒錯した心境になったら本末転倒です。長期間赤字を垂れ流すばかりのプロジェクトがまた一つ増えてしまうことになりかねません。

評価基準が不明確で判断できない

「なんとなく良さそう」「思ったより使えない」といった感覚的な評価では、次のステップに進むべきかの判断ができません。また、関係者によって評価が分かれ、結論が出ないままプロジェクトが宙に浮いてしまうこともあります。

これを防ぐためには、定量的（数値で測れる）な評価基準を事前に合意しておくことが不可欠です。「処理時間が◯秒短縮された」「成約率が◯%向上した」といった客観的な事実は、誰が見ても同じ判断を下せる根拠となります。

以下の表は、よくある失敗例とそれに対する対策をまとめたものです。

PoCの長期化でコストが増大する

PoCは本来、短期間で安価に行うべきものです。しかし、欲張って検証項目を増やしすぎたり、完璧を求めすぎたりすると、期間が延びてコストが膨れ上がります。

これでは「リスクを最小化する」というPoCの本来のメリットが失われてしまいます。「Time is Money」の意識を持ち、限られた期間内で最大の学びを得ることに集中しましょう。

PoCの具体的な事例を知りたい

PoCを成功させるためには、検証する範囲を絞り込み、評価指標を明確にすることが欠かせません。以下にご紹介する事例では、各社が抱える課題に対して最先端の技術をどのように適応させ、その有用性を確かめたのかが具体的に示されています。

PoCの実施事例

NTT

NTTデータでは、生成AIを活用して営業活動の生産性を高めるための実証実験を行いました。具体的には、商談の準備や提案資料の作成といった定型的な業務にAIを組み込み、その効果を細かく検証しています。この取り組みでは、単なる技術の導入だけでなく、既存の業務プロセス自体を見直す視点も重視されました。実証の結果、作業時間の短縮や品質の安定化といった具体的な成果が確認されています。これにより、営業担当者がより付加価値の高い創造的な活動に集中できる環境作りを目指しました。

KDDI

KDDIは、量子コンピューティング技術を用いて、複雑な勤務シフトを自動で作成する実証実験を実施しました。コールセンターなどの現場では、スタッフのスキルや希望を細かく考慮したシフト作成に多大な時間がかかるという課題があります。このPoCでは、膨大な組み合わせの中から最適な解を導き出す量子関連技術を活用し、作成時間の短縮と精度の向上を検証しました。実証の結果、従来の手法と比較して大幅な効率化が可能であることが示されています。先端技術を実務に応用するための非常に重要な一歩となりました。

日立製作所｜セキュリティデジタルツインの有用性をPoCで評価

日立製作所は、サイバー攻撃への対策を仮想空間上でシミュレーションする「セキュリティデジタルツイン」の有効性を実証しました。現実のシステムを模したモデルを構築し、攻撃シナリオを走らせることで、脆弱性や対策の効果を事前に評価する手法です。このPoCを通じて、システムの可用性を損なうことなく、高度なセキュリティ診断が可能であることを確認しました。理論上の設計が実際の運用環境で正しく機能するかを確かめる、非常に実践的な取り組みと言えます。これにより、企業のレジリエンス向上に向けた具体的な指針が得られました。

無償のPoCに成功し、事業化に失敗した事例

ある商社の事業

ある商社で、ビジネスコンテストが行われました。初めてのビジコンで優勝した企画が、予算を与えられ、ある、スクラムで非常に有名なスタートアップと協力してアプリを開発し、ある地域において代替的にPoCを実施しました。代替的にPRが打たれ、そのPoCはある官公庁に表彰されるような成果を出しました。その拓跋なアイデアを出した担当者は、評価のKPIを事前にきちんと設計し、ベンダーであるスタートアップに丸投げすることなく、頻度高くそのオフィスと現場に通って大変なPoCを完遂しましたから、その苦労が報われた形でした。

ところが、いざ事業化の段になって、そのプロジェクトは頓挫しました。今、その商社のグループ会社のどこを見回しても、そのサービスを見つけることができません。失敗した理由は、

からです。アプリを有料にしたら、誰も使わなかったのです。無償のPoCの欠点がモロに出た形と言っていいでしょう。

PoV・PoBより重要なのは、有償PoCへ進む条件を決めること

PoCの周辺用語として、PoV（Proof of Value）／価値の検証やPoB（Proof of Business）／事業性の検証という言葉が使われることもあります。

ただし、ここで注意したいのは、以下の2点です。

1. PoVの「価値」という言葉
   「プロダクト価値を検証する」と言えば一見もっともらしく聞こえますが、その価値が何を意味するのかを具体化しなければ、実務ではほとんど使えません。顧客が便利だと言った、現場担当者が好意的だった、機能として面白いと言われた、というだけでは、果たしてそれを価値と呼んでしかるべきかどうか判断できませんし、ましてや、事業化に進める根拠にはなりません。
   それに、私が日本に導入しようと思っている Continuous Discovery／継続的市場探索では、この段階でPoVを考えているようだと、結果として作業の優先順位を間違っていたという結論になります。
2. PoBはPoCよりはるか以前、企画段階で検証可能
   これも、Continuous Discovery／継続的市場探索では、PoCの段階までPoBをやらないで済ませるということはありえません。PoBを前提検証してからPoCに移行します。

無償のPoCまで進んでしまったら、本来PoVやPoBはすでに終わっていなければならず、「何月何日から顧客は対価を払い始めるのか？」ということだけを顧客と握るのがほぼ唯一にして最も優先順位の高い作業です。

無償PoCの中で「価値」や「事業性」を検証したつもりになっても、顧客が支払う意思を示さなければ、事業化には近づかないのだから、当たり前のことです。

【次に読む】アジャイル開発はもう古い？次世代の開発手法トレンドと今後の最適解を徹底解説（Continuous Discoveryへの導入記事です。）

まとめ

PoCは、「とりあえず試す」ためのイベントではありません。

無償PoCは、顧客に無料で尽くす場ではなく、事業として前に進めてよいかを判断するために、最も危ない前提仮説を小さく確かめる場です。

試作品が動いた。現場の反応が良かった。担当者が褒めてくれた。これだけでは、事業化の根拠にはなりません。顧客が対価を払ってでも導入したい理由があるのか。既存のやり方を変えてまで使う理由があるのか。ここを確かめないまま進めると、PoCはフォルスポジティブを生むだけです。

無償PoCは、Opportunity Solution Treeでいう前提仮説のテストを、小さく実地で行うものです。顧客が達成したいこと、困っていること、望んでいることを聞き、「この前提が崩れたら事業化できない」という一点を確かめる。ここを飛ばすと、PoCは事業化の入口ではなく、検証ごっこになります。

この考え方を詳しく知りたい方は、以下の記事をご覧ください。

【関連記事】Opportunity Solution Treeとは？基本的な考え方、描き方、事例多数を解説

富岡功

イントラプレナーとして、合計８つの新規事業開発を経験。1,300回に及ぶ顧客インタビューの実施経験を持つ。生成AIによるアイディエーションの世界初のサービスである、「AIディアソン」を、2023年の1月に上梓。それ以降も次々とAIサービスをローンチしている。
翻訳書の発行される前の版の、The Four Steps to the Epiphany （邦訳「アントラプレナーの教科書」、リーンスタートアップの下敷きになった本）を所持するほど、古くから事業開発の方法論を考究。最近はアメリカで最新とされるプロダクト開発のメソッドである、継続的発見(Continous Discovery)手法を取り入れ、エフェクチュエーションと組み合わせて事業開発に応用。