PoCとMVPの順番は、技術的不確実性が高ければPoCを先に、技術が既知で市場価値が不明ならMVPを先にします。両方が高い場合は、致命的な技術リスクだけをPoCで確認してMVPへ進むのが基本です。常にPoCから始める必要はありません。
この記事のポイント
- PoC→MVPは原則ではあるが、技術が既知ならPoCを省略できる
- 技術と市場のどちらの不確実性が高いかで最初の検証を選ぶ
- PoCは成功条件・終了条件・次の判断を開始前に決める
- 並行化は、失敗時に捨てる量と利用者への危険で判断する
- PoCでは実現性、MVPでは実利用の価値を測り、同じ評価を繰り返さない
判断基準 — 二つの不確実性で決める
PoCは「技術的に成立するか」、MVPは「実ユーザーに価値があるか」を確かめます。したがって、順番ではなく最初に潰すべきリスクを選びます。
| 技術的不確実性 | 市場的不確実性 | 最初にすること | 理由 |
|---|---|---|---|
| 低い | 低い | 通常開発または小規模リリース | 主要な前提が既に確認されている |
| 低い | 高い | MVP | 作れるため、実利用で需要を確かめる |
| 高い | 低い | PoC | 需要より先に実現性を確認する |
| 高い | 高い | 小さなPoC→MVP | 作れないリスクを限定確認してから市場へ出す |
「高い・低い」は感覚で決めません。技術側は必要な精度・性能・連携・安全性を満たす証拠があるか、市場側は対象ユーザーが課題解決のために時間・予算・行動を既に投じているかで評価します。
PoCを省略してMVPへ進めるケース
- 一般的なWeb技術と既存APIの組み合わせで実現できる
- 技術方式に前例があり、必要な性能も予測できる
- 最大の不確実性が「顧客が使うか、払うか」にある
- 限定公開なら、安全性と運用リスクを管理できる
この場合、「念のためPoC」を挟んでも、市場についての証拠は増えません。MVPの中で通常の技術検証と品質確認を行う方が、意思決定までの距離を短くできます。
PoCを先に行うケース
- 未知のモデル・アルゴリズムで必要精度を出せるか分からない
- 外部システム、機器、特殊データとの接続可否が不明
- 処理時間や単価が事業成立条件を超える可能性がある
- 法令、セキュリティ、安全性の成立条件が分からない
PoCの範囲は、MVPを止め得る技術リスクに限定します。全機能の技術デモを作るのではなく、「この条件を満たさなければ事業案を変更する」という項目だけを検証します。
PoCの終了条件
PoCは、動くデモができた時点ではなく、次の判断に必要な情報がそろった時点で終えます。
| 終了時に必要なもの | 確認内容 |
|---|---|
| 判定結果 | 事前に決めた精度・速度・費用・安全条件を満たしたか |
| 成立範囲 | どのデータ、利用条件、例外まで成立するか |
| 残存リスク | 未確認事項と、本番化前に追加検証する事項は何か |
| コードの扱い | 捨てる、部分再利用する、製品設計から作り直すのどれか |
| 次の判断 | MVPへ進む、方式を変える、中止するのどれか |
評価基準を結果の後に変更すると、PoCは終わりません。開始時に責任者と判定日まで決めます。
PoCからMVPへ進む条件
- 致命的な技術リスクが解消され、残る制約を説明できる
- 対象ユーザーと解決する課題が一文で定義されている
- MVPで検証する市場仮説が一つに絞られている
- 実ユーザーが完了できる体験と、対象外の範囲が決まっている
- 利用、継続、支払いなどの判断材料を取得できる
- PoCコードを本番利用する場合、認証・監視・障害対応・データ保護を再評価している
PoCの成功だけではMVPへ進む理由になりません。「作れる」と分かった技術で、誰の何を解決するかが決まって初めて次へ進めます。
並行してよいケース
技術検証に時間がかかる間、顧客課題のインタビュー、業務観察、価格仮説の確認、利用者募集を並行できます。また、技術的に成立する部分だけで安全な限定体験を提供できるなら、PoCとMVPの境界を近づけることもできます。
一方、PoCの失敗でMVP全体が無価値になる場合や、安全性が確認されるまで実ユーザーへ触れさせられない場合は、構築を並行すると手戻りが増えます。並行化は速さではなく、結果が外れたときに捨てる量と利用者への危険で判断します。
例 — 生成AIの問い合わせ分類
問い合わせ分類サービスで、過去データに対する分類精度、機密情報の取り扱い、処理費用が未知なら、最初に小さなPoCを行います。通過条件は、業務で許容できる誤分類、応答時間、費用、安全要件から逆算します。
PoCと並行して、担当者への業務観察で「振り分け作業が本当に優先課題か」「どの例外処理が負担か」を確認できます。
技術条件を満たした後は、一つの共有メールボックスだけを対象にMVPを出します。そこで見るのは、担当者が継続利用するか、確認・修正まで含めて価値があるかです。PoCとMVPで同じ「精度」だけを測ると、市場検証へ進んだことになりません。
よくある失敗
PoCを儀式として挟む
既知の技術なのにPoCを行うと、「技術検証中」を理由に顧客へ届ける判断が遅れます。証拠が不足している技術項目を具体的に言えなければ、MVPを検討します。
PoCを何度も延長する
追加で何を測れば次の判断が変わるかを確認します。変わらないなら検証を終了し、方式変更・MVP・撤退のいずれかを選びます。
PoCのコードを完成品の土台と決めつける
検証用コードは、速度を優先して品質要件を省略している場合があります。再利用は目的ではなく、製品要件に適合するかで判断します。
よくある質問
MVPをPoCより先に行うことはありますか
あります。既知の技術で安全に限定公開でき、最大の不確実性が需要ならMVPを先にします。「PoCが先」という工程表より、最初に減らすべきリスクを優先します。
PoCに成功したら必ずMVPへ進みますか
いいえ。技術が成立しても、対象課題や顧客が明確でなければ進む根拠はありません。顧客調査を続ける、別の用途へ変える、中止する判断も含まれます。
