PoCとMVPの違いとは？新規事業における役割と移行手順

新規事業開発で重要となるPoCとMVPとは

PoC（概念実証）は、特定の実現可能性を確かめる

PoCは「Proof of Concept」の略で、日本語では概念実証と呼ばれます。新しいアイデアや技術について、想定した方法で実現できるかを確かめる活動です。

製品開発なら「この測定方式で必要な精度を出せるか」「想定する設置場所で通信できるか」など、判断したい問いを絞ります。製品全体を完成させることが目的ではなく、検証した構成・条件と結果を残すことが重要です。

MVPは、顧客に関する仮説を最小限の提供で確かめる

MVPは「Minimum Viable Product」の略で、実用最小限の製品と訳されます。必要な範囲に絞った製品・サービスを通じて、顧客の課題や提供する価値について学ぶための手段です。

何を最小限にするかは、確かめる仮説によって変わります。利用されるかを調べるMVPと、提示した価格で購入されるかを調べるMVPでは、提供条件も集めるデータも異なります。一度の検証で事業全体の成立を証明するものではありません。

プロトタイプは、PoCにもMVPにも使える

プロトタイプは、動作や構造、操作性などを確かめる試作品です。PoCは検証活動、MVPは顧客から学ぶための最小限の製品・サービスを指します。プロトタイプには検証目的が一つに決まっているわけではなく、PoCにもMVPにも利用できます。

たとえば、試作端末で通信方式を確かめればPoCに使う成果物になります。その端末を使ったサービスで、顧客が業務上の価値を得られるかを確かめるなら、MVPの一部にもなり得ます。名称を付ける前に、何を判断するための試作なのかを共有しましょう。

PoCとMVPの明確な3つの違い

1. 目的の違い：何を確認できたら判断が変わるか

PoCとMVPの中心的な違いは、検証で答えようとする問いです。同じ機器を使っていても、測定方式を確かめるのか、顧客の業務に役立つかを確かめるのかで、必要な証拠は変わります。

特にハードウェアでは、試験室で動いた結果を、現場でも同じように動く証拠として扱わないこと。設置場所や通信条件、周辺機器が変わるなら、その条件で確認する必要があります。NASAの技術成熟度の考え方でも、概念実証と実際に近い環境での試験は区別されています。

2. 対象者の違い：参加者より、誰の行動を確認するか

PoCを社内だけ、MVPを社外だけで行うと決める必要はありません。顧客の設備を使って技術を確かめるPoCも考えられます。参加者の所属だけでは、検証の性質を区別できません。

MVPでは、実際に想定する顧客の反応を確認します。BtoBなら、利用者と、購入や導入を判断する人の条件を分けてください。現場担当者が便利だと評価しても、予算や導入手順が未確認なら、購買の仮説はまだ残っています。

3. 実施時期の違い：不確実性に合わせて順番を選ぶ

PoCを経てMVPへ進む流れは選択肢の一つです。ただし、独自技術を完成させる前でも、既存機器や手作業で顧客価値を確かめられる場合があります。PoC・プロトタイプ・MVPを、必ず通過する一列の工程として扱うと、検証に必要のない開発まで先行しかねません。

技術が成立するか不明

成立しなければ顧客への提供ができない部分を、PoCで先に確かめる。

使われるかが不明

既存技術で提供できる範囲のMVPを検討し、顧客の利用を確かめる。

使い方が定まらない

プロトタイプで操作や設置方法を評価し、技術・顧客双方の検証条件を具体化する。

どちらも不明なら、技術の検証と、既存手段を使った顧客検証を並行する案もあります。その場合、代替手段で得た結果が、どの仮説の判断に使えるかを区別しておきます。

開発プロセスにおけるPoCからMVPへの移行ステップ

移行時に必要なのは、PoCの成果物を大きくすることより、次に確かめる問いを決めることです。技術検証で得た結果と、顧客へ提供するために残った条件を分けて整理します。

ステップ1：次の投資を止めている仮説を選ぶ

作れないことが懸念なのか、使われないことが懸念なのか。判断を変える仮説を選び、その仮説に答えるための最小限の構成を決めます。

最後の案なら、独自機器や自動レポート機能を完成させる前に、報告内容への反応を確認できます。ただし、独自機器の性能や、自動化後の原価を確かめたことにはなりません。手作業の工数も記録し、どの業務を自動化する必要があるかを次の検討に残します。

ステップ2：検証条件・評価指標・終了時の判断を決める

「反応が良ければ進める」では、終了時に解釈が分かれます。仮説、確かめ方、判断に使う証拠を、実施前に書き出しましょう。

仮説

誰のどの課題について、何が成立すると考えているか。

対象・提供条件

どの利用者・購入判断者に、何を、どの価格や支援条件で提供するか。

確認する証拠

技術なら測定結果と試験条件。顧客価値なら実際の利用、継続の理由、購入判断への反応など。

期間・判定方法

いつまで確認し、何を満たせば仮説を支持するか。データが足りない場合の扱いも決める。

判断する人

結果を受けて、追加検証・条件変更・次の開発への投資を誰が決めるか。

好意的な感想、継続利用、支払意向、実際の支払は、確認している内容が異なります。無料で使われた結果から、提案価格で購入されると結論づけないよう、証拠と仮説を対応させてください。

ステップ3：検証結果を、次に進める範囲へ結びつける

終了時には、結果を「成功・失敗」の二択だけにしないほうが、次の行動を決めやすくなります。本記事では、次のように整理します。

• 仮説を支持する結果が得られた：確認できた範囲を明記し、残った条件を踏まえて次の投資を検討する。
• 仮説を支持する結果が得られなかった：技術、対象顧客、提供内容など、見直す前提を決める。中止も選択肢に含める。
• 判断に必要なデータが得られなかった：未判断として残し、追加で何を確認すれば決められるかを整理する。

PoCの検証結果を受け取る担当者だけでなく、顧客への提供と次の開発費を決める担当者も、検証前から関与しておくと判断の前提を共有できます。

PoCからMVPへの移行で陥りやすい失敗と対策

「PoC死」を避けるには、再検証で増える証拠を明確にする

実証実験を繰り返しても次の判断へ進めない状態は、「PoC死」と呼ばれます。繰り返し自体が問題なのではなく、追加の検証で何が分かり、どの判断が変わるかが見えないことが問題です。

再実施するなら、未達の技術条件を変えるのか、試験環境を現場に近づけるのか、対象顧客を変えるのかを明記します。次の検証でも判断できないなら、必要な情報・予算・担当者が不足していないかを確認してください。同じ動作を再び見せるだけでは、需要や量産の問いには答えられません。

PoCの成果物は、流用できる部分を評価して引き継ぐ

PoCで動いたコードや回路が、そのまま顧客への提供条件を満たすかは別の評価です。試験条件、構成、確認済みの項目、未確認の項目を、成果物と一緒に引き継ぎます。

ソフトウェアについては、英国政府のGOV.UKも、プロトタイプのコードを本番へそのままコピーしないよう注意しています。検証用の実装と、実際の提供に必要な品質・運用条件を区別するためです。

コード・データ

アクセス制御、エラー時の処理、データの保管・復旧、利用者が増えた際の動作などを確認する。

回路・筐体

電源や接続の条件、設置・使用環境、使い続ける場合の構造を確認する。

製造・運用

部品の入手性、組立・検査方法、故障時の交換や保守、提供に必要な作業を整理する。

上のハードウェア項目は、引き継ぎ時に確認する観点の例です。すべてを作り直すか、そのまま使うかの二択にせず、どの部分をどの条件で利用できるかを開発会社・製造先と判断しましょう。

作り手目線のMVPを避け、利用と購入の条件を分ける

機能を減らすだけでは、MVPの検証目的は定まりません。顧客が解決したい仕事を一つ選び、その仕事を行うのに必要な範囲を残します。利用者には、機能の感想に加えて、従来の手順の何を置き換えたか、使わなかった理由も確認してください。

BtoBでは、購入や導入を判断する側にも確認が必要です。提示した価格、導入に必要な手順、予算を決める時期などを整理し、便利という評価を購買判断と混同しないようにします。

また、開発側が設置・説明・報告を手厚く代行した場合は、その支援内容と工数を残しましょう。支援を含めて使われた結果から、顧客が単独で運用できると判断することはできません。製品に残す機能と、提供し続けるサービスを分けて検討します。

まとめ

PoCとMVPの違いは、実現可能性を確かめるのか、顧客に関する仮説を確かめるのかという検証の焦点にあります。プロトタイプは、どちらにも使える試作品です。

開発の順番を決める前に、今の結果ではまだ判断できないことを整理してください。技術、利用、購入、量産の問いを分けると、次に必要な検証と投資範囲が具体化します。

• 今回の検証で答える問いと、対象外の問いが決まっているか。
• 試験・提供条件と、判断に使う証拠を事前に共有しているか。
• 結果を受けて、誰がどの範囲の開発・提供を承認するか決まっているか。

ハードウェアでは、顧客検証に使う試作と、量産へ引き継ぐ設計・工程を分けて相談すると、依頼する範囲を整理できます。技術検証だけでよいのか、顧客への提供や量産準備まで必要なのかを示したうえで、専門家と進め方を詰めましょう。