MVP、プロトタイプ、PoCの違い：最初に作るべきものはどれか

三つはそれぞれ別のリスクを検証します。次の表で並べて比べます。

PoC（概念実証）は、あることが技術的に可能かどうかを確かめるものです。通常は一つの難しい課題だけを解く小さなコードで、それ以外はすべて省きます。デザインもアカウントも仕上げもありません。

たとえば、手書きのレシートの写真から合計金額を読み取りたいスタートアップなら、まずAIモデルが十分な精度で読み取れるかを試すべきです。読み取れなければ、どんなデザインもそのプロダクトを救えません。

ほとんどのプロダクトにPoCは必要ありません。アカウント、決済、フォーム、ダッシュボードのような実績のある要素でできたアイデアなら、技術的なリスクは低く、PoCは本当の問いを先送りするだけです。

PoCのコードは、通常捨てられます。一つの問いに素早く答えるために書かれたもので、プロダクトを支えるためのものではないからです。

プロトタイプは、本番用のコードを書く前に、プロダクトがどう動くかを示すものです。スケッチの集まりのこともあれば、本物とほぼ同じように動く、クリックできるリアルな画面のこともあります。

Nielsen Norman Groupのローファイとハイファイのプロトタイプについての解説は、この選択をよく説明しています。簡単なスケッチは早く作れて率直な意見を引き出しやすく、作り込んだプロトタイプはリアルな動きを見せられるため、特定のフローをテストするときに役立ちます。

プロトタイプは、関係者の認識をそろえるための最良の道具でもあります。ドイツの中古車市場向けB2BツールAutoIntelは、サンプルの車両情報を使ったインタラクティブなプロトタイプから始まりました。クライアントはチームと一緒にそれを操作し、データ処理の見積もりの前に、どの項目と絞り込み条件が重要かを決めました。

MVP（実用最小限の製品）は、実際のユーザーが本当に使える、最小限のバージョンのプロダクトです。アカウントが機能し、実データがあり、必要な場合には実際の決済もできます。

目的は学ぶことであり、公開そのものではありません。Lean Startupの言葉を借りれば、MVPを作るのは「できるだけ早く学習のプロセスを始める」ためです。

MVPは、プロトタイプでは測れないものを測れます。ユーザーが戻ってくるか、お金を払うかです。車の掲載写真のためのAIフォトスタジオCarPixlyでは、誰でも登録して無料でスタジオを試せ、支払いは価値が生まれる瞬間、つまりレンダリングの時点で始まります。このようなモデルなら、訪問者のうち何人が有料ユーザーになるかがはっきり分かります。

多くのMVPは、複雑さに応じて6〜14週間で開発できます。MVPの開発期間とSaaSのMVPの開発費用についての記事で、段階ごとの目安を紹介しています。

最もリスクの高い不確実性から始めます。次の問いを順番に確認しましょう。

• 本当に作れない可能性があるか？たとえば、まだ試していないAIモデル、ハードウェアのセンサー、APIに依存している場合です。それならPoCを作ります。
• ユーザーが解決策を理解し、求めているかが分からないか？それならプロトタイプを作り、ユーザーでテストします。
• 理解され、求められていることは分かっていて、残る問いは使われるか、お金を払ってもらえるかか？それならMVPを作ります。

ほとんどのスタートアップは、二つ目の問いに当てはまります。技術はたいてい実績があり、証明されていないのは、そのプロダクトが対象とする人々にとって意味があるかどうかです。

自分のアイデアで最大のリスクがどこにあるか分からない場合は、短いブリーフをお送りください。私たちならどの一歩から始めるか、その理由とともにお伝えします。

プロトタイプは、実際の人が試して初めて役に立ちます。うれしいことに、必要なテスト参加者は多くの創業者が思うより少なくて済みます。

Jakob Nielsenの研究によると、5人のユーザーでのテストで、デザインの使いやすさの問題の大半が見つかります。大規模な調査を一度行うより、小さなテストを何度か繰り返すことが勧められています。

シンプルなテストは次のように進めます。

• 一人ひとりに「来週の火曜日にサービスを予約してください」のような現実的なタスクを渡します。
• 手助けや説明をせずに、その人の操作を観察します。
• 迷った箇所、読み違えた箇所、あきらめた箇所を記録します。
• 最も深刻な問題を直し、次のバージョンを新しい人でテストします。

今のやり方についても聞きましょう。その課題を今どう解決していて、どれくらいの手間や費用がかかっているかです。「このプロダクトを使いますか」と聞くより、需要についてずっと多くのことが分かります。

スケッチで作ったプロトタイプは学びのための道具で、後で描き直されます。実際のコンポーネントで作り込んだプロトタイプは違います。そのフロー、画面、デザインシステムが、そのままMVPの出発点になります。

そのため私たちは、最初の画面から再利用できるコンポーネントで設計しています。プロトタイプがテストされて承認されれば、絵を解釈し直すのではなく、同じコンポーネントの上で開発を始められます。

PoCの場合は逆です。そのコードは一つの問いに答えるためのもので、実際のユーザーを支える前提ではないため、通常はMVPの中できちんと書き直されます。

各段階は、感覚ではなく明確な答えで終えるべきです。始める前に「成功」の定義を書き出しておけば、後から結果を期待どおりに解釈し直すことができなくなります。

• PoCの成功とは、難しい部分が実際に近いデータで、プロダクトに必要な精度や速度で動くことです。ユーザーが何千ものファイルを送るなら、「三つのテストファイルで動いた」では足りません。
• プロトタイプの成功とは、テストユーザーの大半が手助けなしに主要なタスクを終え、それが解決する課題を自分の言葉で説明できることです。
• MVPの成功とは、実際のユーザーが促されなくても戻ってくる、またはお金を払う割合が、次の投資に見合う水準に達することです。

ある段階がうまくいかなくても、それにも価値があります。失敗したPoCは、高額な開発を避けさせてくれます。分かりにくいプロトタイプは、変更がまだ安いうちにフローを見直すべきだと教えてくれます。

各段階には期限も設けましょう。何か月も磨き続けているプロトタイプは、もはやテストではなく、まだ誰も使えないプロダクトになっています。

場合によってはよいです。たとえばサービスを手作業で提供するなどして、すでにアイデアを検証しているなら、MVPに直接進めるだけの知識があるかもしれません。

たとえば、何か月も表計算ソフトとメッセージを使って、手作業で顧客と家庭教師を引き合わせてきた創業者なら、フローも利用者がよくする質問もすでに分かっています。プロトタイプを作っても、多くはすでに知っていることの確認になるでしょう。

プロトタイプを省いてよいのは、次の三つがそろうときです。技術に実績があること、実際の人がそのプロセスを進める様子を見てきたこと、プロセスのどの部分を最初にソフトウェアに任せるかが分かっていることです。一つでも欠けているなら、プロトタイプのほうがそれを確かめる安い方法です。

同じ失敗が何度も繰り返されます。

• プロトタイプをMVPと呼ぶ。プロトタイプ上のクリックは理解を示すだけで、利用や支払いを示すものではありません。両者を取り違えないようにしましょう。
• PoCを磨いてプロダクトにする。一つの問いに答えるために書かれたコードは、その上に作るすべてにとってもろい土台になります。
• プロトタイプを飛ばす。フローを検証する前にMVPを作ると、デザインの問題を見つけるために開発者に費用を払うことになります。
• MVPに機能を詰め込みすぎる。機能が一つ増えるたびに、核となる部分が機能するかを知るタイミングが遅れます。
• 友人でテストする。好意を持ってくれている人は、アイデアを褒めてくれます。その課題を実際に抱えていて、気を遣う理由のない人でテストしましょう。

最初の一歩を選ぶ準備はできましたか。アイデアについてお聞かせください。PoC、プロトタイプ、MVPのどれが合うか、一緒に判断します。