PoC・プロトタイプ・MVPの違いと進め方

PoC・プロトタイプ・MVPの違いは、作るものの完成度ではなく、確かめたい問いの違いです。PoCは「技術的・運用的に実現できるか」、プロトタイプは「顧客に価値が伝わるか、使い方が成り立つか」、MVPは「実際の顧客が使い続け、対価を払うか」を確かめるために作ります。今いちばん大きな不確実性がどこにあるかで、作るものを選んでください。

3つの違いを一言でいうと

	主に確かめる問い	誰に試すか	作るものの例
PoC（概念実証）	その技術・仕組みで実現できるか	社内、協業先	限定データでの動作検証、実環境での小規模試験
プロトタイプ	顧客に価値が伝わるか、使い方が成り立つか	対象顧客の一部	画面の試作、紙や動画のモック、手作業で再現したサービス
MVP	実際の顧客が使い続け、対価を払うか	実際の顧客	最小限の機能で提供する実サービス

PoC（Proof of Concept）

PoCは、構想した仕組みが技術的・運用的に成り立つかを確かめる検証です。たとえば「このセンサーで必要な精度のデータが取れるか」「このAIモデルで業務に使える精度が出るか」「既存システムと連携できるか」といった問いに答えます。

PoCの結果が良くても、顧客がそれを求めているか、お金を払うかは分かりません。技術的な実現性に大きな不確実性がない事業では、PoCを飛ばしてよい場合もあります。

プロトタイプ

プロトタイプは、顧客に見せたり触ってもらったりして、価値の伝わり方や使い勝手を確かめるための試作品です。実際に動く必要はなく、画面のデザインだけ、説明資料や動画だけ、裏側は人が手作業で対応するといった形でも構いません。

目的は、作り込む前に「顧客がどこに反応し、どこで迷うか」を知ることです。顧客ヒアリングと組み合わせて使うと効果的です。

MVP（Minimum Viable Product）

MVPは、リーン・スタートアップの考え方で広まった用語です。エリック・リース氏の書籍「The Lean Startup」の公式サイトでは、アイデアを製品にし、顧客の反応を測り、方向転換するか継続するかを学ぶ「構築・計測・学習」のフィードバックループの最初の段階として、できるだけ早く学習を始めるためにMVPを作る、と説明されています。IPA（情報処理推進機構）のアジャイル開発版モデル契約の解説でも、MVP開発を「実用最小限の製品（Minimum Viable Product）を開発すること」と説明しています。

MVPのポイントは「実際の顧客に、実際に使ってもらう」ことです。プロトタイプへの「良さそう」という反応と、実際にお金や時間を使う行動との間には差があります。MVPはその差を確かめるためのものです。

どれから始めるかの判断

いちばん大きな不確実性から検証する

新規事業の不確実性は、大きく「顧客の課題は本当にあるか」「解決策に価値を感じるか」「技術的に作れるか」「継続的に売れ、採算が合うか」に分けられます。このうち、外れたときに事業が成り立たなくなるものから順に検証します。

技術的な実現性が最大の不安 → PoCから始める
顧客に価値が伝わるかが最大の不安 → プロトタイプから始める
課題も解決策もある程度確かめられ、実際に使われるか・買われるかを知りたい → MVPを作る

なお、課題そのものがまだ確かめられていない段階では、何かを作る前に顧客ヒアリングで課題を確かめるほうが先です。進め方は新規事業のアイデア検証でやることと進め方で解説しています。

必ずしも全部を順に通る必要はない

PoC→プロトタイプ→MVPの順に進むとは限りません。既存技術の組み合わせで作れるサービスならPoCは不要ですし、顧客との関係が深い大企業の既存顧客向けの事業なら、早い段階から限られた顧客に実サービスとして提供するMVPを試せることもあります。

それぞれの進め方

1. 検証する仮説と合格ラインを先に書く

作り始める前に、「何が確かめられたら次に進むか」を文章にしておきます。

PoC：「実環境のデータで、業務で使える水準の精度が出る」など、技術的な基準
プロトタイプ：「対象顧客のうち、何人が〇〇の機能を最も価値があると答えるか」など
MVP：「一定期間内に、何社が有料で使い始め、何割が継続するか」など

基準を後から決めると、結果を都合よく解釈しやすくなります。数値の水準は業種や事業によって異なるため、自社の事業計画と照らして決めてください。

2. 検証に必要な範囲だけ作る

検証する問いに関係のない機能や品質には時間をかけません。MVPであれば、顧客が価値を感じる中心の機能だけに絞り、管理画面や周辺機能は手作業や既存ツールで代用する方法もあります。ノーコードツールや既製のサービスを組み合わせて作れる場合もあります（ノーコードでMVPを作るときの進め方と限界を参照）。

3. 期間と予算に上限を設ける

検証は、終わりを決めないと際限なく続きます。期間と予算の上限を先に決め、その範囲で得られた結果で判断します。大企業では、この上限をステージゲートの各段階の予算として承認する形が取りやすいでしょう。

4. 結果を記録し、判断する

検証が終わったら、仮説・方法・結果・判断（進む、方向転換、中止）を記録します。記録を残しておくと、社内の意思決定者への説明や、次の検証の設計に使えます。

大企業と起業家で異なる注意点

大企業の場合

PoCが目的化しやすい：協業先や社内部署とのPoCを繰り返すうちに、「PoCをすること」自体が成果として扱われ、事業化の判断が先送りされることがあります。PoCを始める前に、結果が良ければ何をするか（次の予算、担当部署、顧客への提供）を決めておきましょう。
品質基準が既存事業並みになりやすい：社内の品質・セキュリティ基準をすべて満たそうとすると、MVPが「最小限」でなくなります。検証段階に適用する基準を、情報システム部門や法務部門とあらかじめ相談しておくと進めやすくなります。
外部との検証は契約を先に整える：協業先とのPoCでは、成果物や知的財産の扱い、費用負担を事前に取り決めておく必要があります（PoCの契約：モデル契約書で押さえる点を参照）。

起業家・スタートアップの場合

作り込みすぎに注意する：資金と時間が限られる中で、完成度を上げることに時間を使いすぎると、顧客の反応を知る前に資金が尽きるおそれがあります。
最初の顧客と一緒に作る：少数の顧客に早く使ってもらい、その反応を見ながら機能を足していくほうが、推測で機能を増やすより無駄が少なくなります。
有料で試す：可能であれば、最初から少額でも対価を受け取る形で提供すると、「使ってもよい」と「お金を払う」の違いを早く確かめられます。

よくある失敗

MVPが「小さな完成品」になる：機能を削っただけで、検証したい仮説がはっきりしていないと、使われなかった理由が分かりません。
反応の良さを需要と取り違える：プロトタイプを見せて「いいですね」と言われても、購入や継続利用の証拠にはなりません。
失敗を報告しにくい：検証で仮説が外れることは、無駄な投資を避けられたという成果です。外れた結果を報告しやすい評価の仕組みを作ることが、特に組織の中では重要です。