起業の流れを検証の順番で読み解く — 市場調査・モック・PoC・MVP の違い

市場調査、モック、PoC、MVP。起業の準備を調べると、こうした言葉が順番もはっきりしないまま並んでいて、何から手をつければいいのか分かりにくくなります。本記事の結論を先に置くと、この 4 つはバラバラの作業ではなく、すべて「どのリスクを先に潰すか」という一つの問いに還元できます。順番は固定ではなく、自分の事業で一番不確実な部分から確かめるのが筋になります。以下では、4 つの言葉の違いと役割、進める順番のトレードオフを整理します。

なぜ言葉が混乱して見えるのか

これらの用語は、出どころの違う世界からそれぞれ持ち込まれています。市場調査はマーケティングや経営の文脈、モック(プロトタイプ)はデザインや製品開発、PoC は技術・SI の現場、MVP はリーンスタートアップの文脈です。それぞれが「作って試す」点で重なるため、初めて見ると区別がつきにくくなります。

区別をつけるコツは、「何を作るか」ではなく「何を確かめたいか」で並べ直すことです。同じ試作物でも、確かめたい問いが違えば呼び名が変わる、と考えると整理しやすくなります。

4 つを「確かめる問い」で並べる

表のとおり、市場調査とモックは「ニーズ側」、PoC は「実現側」、MVP はその両方をまとめて市場で確かめる段という分担になっています。下に行くほど作る量とコストが増えるので、安く確かめられる問いから先に潰すのが基本の発想です。

根っこにあるのは「リスクの順番」

起業の失敗要因を調べた調査では、CB Insights が「市場にニーズがなかった」をスタートアップの失敗理由の上位に挙げています。技術的に作れなかったから、ではなく、作ったものを欲しがる人がいなかった、という失敗が目立つということです。

ここから導かれるのが、リーンスタートアップ(Eric Ries)や顧客開発(Steve Blank)が共通して説く順番です。事業の不確実性は、おおよそ次の 4 つのリスクに分解できます。

• 課題リスク：そもそも困っている人がいるのか
• 解決リスク：困りごとはあるが、自分の解き方がずれていないか
• 実現リスク：その解き方を技術的・運用的に作れるか、回せるか
• 需要リスク：作れたとして、お金を払う人がいるか

市場調査は課題リスク、モックは解決リスク、PoC は実現リスク、MVP は需要リスクに対応します。4 つのステップは、4 つのリスクを潰す道具立てだと捉えると、なぜこの順で語られることが多いのかが見えてきます。一番外れたら痛い前提(多くの場合は課題と需要)から確かめる、というのが共通の発想です。

各ステップを少し掘る

市場調査 ─ 課題が実在するかを確かめる

市場調査というと大規模なアンケートを思い浮かべがちですが、起業初期に効くのはデスクリサーチと顧客インタビューの組み合わせです。デスクリサーチでは公的統計や業界レポートで市場の規模と方向を押さえ、インタビューでは想定顧客が「過去に実際どう困り、どう対処してきたか」を具体的に聞きます。

注意したいのは、聞き方で答えが簡単に歪むことです。『The Mom Test』(Rob Fitzpatrick)は、「こういうサービスがあったら使いますか」と未来の意向を聞くと、人は気を遣って「使う」と答えてしまうと指摘します。代わりに、過去の具体的な行動(いつ、何に、いくら払って解決しようとしたか)を聞くほうが、課題の実在性を見誤りにくくなります。

モック / プロトタイプ ─ 解き方が刺さるかを確かめる

課題が確かめられたら、次は解決案を相手に見せて反応を見ます。ここで作るのは完成品ではなく、画面イメージや紙芝居のような「捨てる前提の試作」で十分です。作り込んでから見せると、引けなくなって判断が鈍ります。先に見せて、どこで手が伸びるか・どこで止まるかを観察するほうが学びは多くなります。

PoC ─ 実現できるかを確かめる

PoC(Proof of Concept、概念実証)は、アイデアが技術的・運用的に成立するかを確かめる段です。重要なのは、プロダクト全体を作るのではなく、一番不確実な部分だけを小さく試すことです。新しい技術、外部サービスとの連携、人手のオペレーションなど、「ここが成立しなければ全部崩れる」という箇所に絞ります。完成度ではなく「成立するか/しないか」を見るのが目的なので、PoC のコードや仕組みは本番に持ち込まず捨てることも珍しくありません。

技術職以外の事業でも PoC の発想は使えます。たとえば飲食やサービス業なら、小さく試験提供して原価とオペレーションが回るかを確かめるのが PoC にあたります。

MVP ─ お金を払う人がいるかを確かめる

MVP(Minimum Viable Product、実用最小限の製品)は、価値の核が伝わる最小構成を実際に市場に出し、需要と採算を確かめる段です。モックやデモと混同されがちですが、決定的な違いは「実際にお金や継続利用が発生するか」を測る点にあります。無料の「いいね」ではなく、支払い・申し込み・継続といったコストを伴う行動が出るかどうかを見ます。

MVP で何を測るかを決めるとき、指標が虚栄の数字に寄らないよう注意が要ります。登録数や閲覧数だけを追うと需要があるように錯覚しやすいので、事業ゴールに紐づく指標を選ぶ必要があります。指標の階層づくりは KGI と KPI を正しく設計する の考え方がそのまま応用できます。

順番は固定ではない ─ どのリスクが一番怖いか

「市場調査 → モック → PoC → MVP」と直線で語られがちですが、実際には事業によって一番不確実なリスクが違うため、順番もトレードオフになります。

順番を考えるときの原則は一つです。外れたときに最も痛い前提を、最も安い方法で先に確かめる。これさえ守れば、4 つを必ずしも教科書どおりの順で踏む必要はありません。

よくあるつまずき

課題を確かめる前に作り込む

一番多いのが、課題リスクを飛ばしていきなり MVP や本番開発に入るパターンです。手応えのある「作る」作業に時間を使ってしまい、誰も欲しがらないものが完成する、という結果になりがちです。安い検証(インタビュー、モック)を飛ばした分の手戻りは、後工程ほど高くつきます。

PoC が目的化する

技術検証そのものが楽しく、PoC を作り込みすぎて需要の確認に進まないことがあります。PoC は「成立するか」を見たら役目を終える段で、完成度を上げる場ではありません。

調査だけで動けなくなる

逆に、市場調査やデスクリサーチを延々と続けて、作る・出すに踏み出せないこともあります。机上の調査でわかるのは課題の輪郭までで、解決案が刺さるか・お金が動くかは、見せて出してみないと確かめられません。調査は「次の一手を決められる程度」で切り上げ、安い試作に進むほうが学びの速度は上がります。

次にやるべき検証ステップを確かめる

自分がいまどのリスクを残しているかを、下の診断で確認できます。すでに確かめられた段にチェックを入れると、最初に未確認になっている段が「いま手をつける価値の高い検証」として表示されます。

検証の前に決めておくこと

検証を始める前後で、事業の入れ物をどうするかという論点も出てきます。会社を作るのか、個人事業のまま小さく始めるのかは、税・社会保険・信用・コストのトレードオフで変わります。検証段階では身軽な個人事業で始め、需要が見えてから法人化を検討する、という順序も選択肢になります。判断材料は 会社員と個人事業主 ─ 制度・手取り・自由度のトレードオフ で整理しています。

また、MVP で需要が確かめられた後は、どう知ってもらい、どう最初の顧客をつかむかという問題に移ります。認知を作る設計は 自分のサービスをどう知ってもらうか 、最初の受注経路の選び方は 業務委託で受けるか、自分で開拓するか が地続きの話になります。検証と販売は別物に見えて、同じ「相手の行動で確かめる」という発想でつながっています。

まとめ

• 市場調査・モック・PoC・MVP は別作業ではなく、すべて「どのリスクを先に潰すか」に還元できる
• 市場調査＝課題リスク、モック＝解決リスク、PoC＝実現リスク、MVP＝需要リスクに対応する
• 下に行くほど作る量とコストが増えるので、安く確かめられる問いから先に潰すのが基本
• 順番は固定ではない。外れたとき最も痛い前提を、最も安い方法で先に確かめる
• 課題を確かめる前の作り込み、PoC の目的化、調査で止まる、の 3 つがよくあるつまずき
• 需要を測る指標は虚栄の数字を避け、支払い・継続などコストを伴う行動で見る