新規事業のMVPとは？「最小限」の誤解が有望な事業を殺す

MVP（Minimum Viable Product）は、新規事業の検証手法として広く知られるようになりました。

しかし実務の現場では、「最小限」という言葉の解釈が決定的に誤解されています。 MVPのつもりで作られた中途半端な試作品が、本当は存在していたニーズを「なかった」ことにし、有望な事業を検証の途中で葬っています。

本コラムでは、MVPの定義と設計手順を整理したうえで、この誤解の構造と避け方を解説します。 これからMVPを設計する方はもちろん、過去に「MVPを試したがニーズがなかった」という結論を出したことのある方にこそ、読み直していただきたい内容です。

MVPの定義と検証チェーンにおける位置づけ

「MVP（Minimum Viable Product）」とは、仮説の検証に必要な最小限の要素だけを備えた製品やサービスのことです。

MVPという用語自体は、2001年に米国のコンサルタントであるフランク・ロビンソンが提唱したものです。 これを世界に広めたのが起業家エリック・リースで、著書『リーンスタートアップ』の中で、MVPを「チームが顧客について検証済みの学びを、最小の労力で最大限に得られる新製品のバージョン」と定義しました。 この定義が示すとおり、MVPの目的は製品を早く市場に出すことではなく、顧客からの学びを早く得ることにあります。 何を作るかより先に、何を学ぶかが決まっていなければ、MVPは設計できません。

新規事業の検証手段には、MVPのほかにPoC（概念実証）、プロトタイプ、テストマーケティングがあります。 これらは、検証したい問いの違いで使い分ける道具です。 PoCは「技術やコンセプトは成立するか」を、プロトタイプは「どう作るか」を確かめます。 MVPが確かめるのは「顧客はお金を払うか、使い続けるか」であり、テストマーケティングは「価格や販売チャネルを含めて市場に受け入れられるか」を評価します。

とくにBtoBの新規事業では、PoCとMVPは連続した工程になりやすいという特性があります。 特定のクライアントとPoCで技術やコンセプトの成立を確かめ、その延長で同じクライアントにMVPを有償提供して事業性を確かめる、という流れです。

ただし、この連続性には注意点があります。 PoCの成立とMVPの成立は、別の問いへの答えです。 「技術的に動いた」ことと「顧客がお金を払う」ことのあいだには距離があり、PoCの成功を事業性の証明として扱うと、実施そのものが目的化するPoC死と同じ構造に陥ります。

MVPの手前に位置するPoCについては、こちらの記事で詳しく解説しています。

なぜMVPが必要か：新規事業の最大の死因

新規事業の最大の死因は、昔も今も変わっていません。 「誰も欲しがらないものを作ってしまう」ことです。

調査会社CB Insightsが、2023年以降に事業を停止したVC出資スタートアップ431社を分析した調査では、「資金の枯渇」を挙げた企業が70%と最多でした。 ただし同社は、資金の枯渇は物語の終わり方であって根本原因ではないと整理しています。 資金が尽きた理由をたどると、43%がPMF（Product Market Fit：市場にプロダクトが受け入れられた状態）の不全に行き着きます。

参照元：Why Startups Fail: Top 9 Reasons（CB Insights）

フル機能の完成品を作り込んでから市場に出す進め方は、この最大の死因に対して無防備です。 投資の大半を終えたあとに、初めて顧客の反応という一次情報が手に入るからです。

MVPは、この順序を逆転させるための手法です。 最小限のプロダクトを先に顧客へ届け、お金を払うかどうかという反応を確認してから、本格的な投資判断を下します。

検証すべき仮説の立て方と検証コストの考え方については、こちらのコラムをご覧ください。

MVPの最大の誤解：「Minimum」は何を削る言葉か

ここからが、本コラムの中心です。

MVPという手法自体は広く普及した一方で、「Minimum（最小限）」という言葉が、現場で誤読され続けています。 その誤読とは、「MVPだから、品質もコストも抑えた簡易版でよい」というものです。

MVPで削ってよいのは、プロダクトの中心にある価値の外側だけです。 中心にある価値そのものは、MVPの段階であってもユーザーを満足させる水準に達していなければなりません。 Viable（存立可能）という言葉が指しているのは、この条件です。

ケーキで考える：手を抜いた試作品は何も検証できない

新しいケーキを売る事業を構想したとしましょう。 確かめたい中心の仮説は、「このケーキを顧客は美味しいと感じ、お金を払うか」です。

このとき、MVPだからといって、本来の構想とは異なる安価な原料を使い、原価を落としたケーキを作って試食してもらったら、何が起きるでしょうか。 顧客は「美味しくない」と答えます。 しかしその「美味しくない」は、構想したケーキへの評価ではありません。 手を抜いた試作品への評価です。 実験として成立していないにもかかわらず、「ニーズがなかった」という結論だけが残ります。

世の中では、このようなMVPがあまりに多く作られています。

一方で、見た目やパッケージ、ブランドストーリーといった要素が、そのプロダクトの中心的価値でないのなら、MVPではあえて省いてかまいません。 紙皿に乗せて出しても、味の検証はできます。 省いてよいかどうかを分けるのは、要素の種類ではなく、その要素が中心的価値の一部かどうかです。

つまり、Minimumが削るのは中心的価値の外側にある要素の数であって、中心的価値の水準ではありません。
むしろ中心的価値は、しっかりと成立している必要があるという点が最もMVPで誤解されていて、見落とされている点です。

この整理は、「MVPを作り込みすぎるな」という広く知られた戒めと矛盾しません。 あの戒めが禁じているのは、「これも必要かもしれない」と機能の数を増やすことです。 中心的価値の水準を上げることと、機能の数を増やすことは、別の軸の話です。 機能は1つに絞りながら、その1つの水準を突き抜けさせる。 これがMVPの正しい姿であり、多くの現場では逆に、機能を増やしながら水準を落とすという最悪の組み合わせが起きています。

なぜ、この誤読が広がるのか

この誤読は、担当者の理解不足だけで起きているのではありません。 組織の構造が、誤読の方向へ担当者を押し出しています。

第一に、社内の予算獲得プロセスでは、「安く、早く、小さく」という側面だけが強調されやすいことです。 MVPは投資を抑える手法として説明すると承認が通りやすいため、「最小の労力で最大の学びを得る」という本来の目的が、「最小のコストで作る」という目標にすり替わります。 コストが目標になった瞬間、削る対象を選ぶ基準は消え、中心的価値まで一律に削られます。

第二に、新規事業の担当者にとって、質素なMVPは失敗したときの言い訳になりやすいことです。 「MVPですから」という言葉は、作り込みの甘さへの指摘をかわす盾として機能してしまいます。 しかし検証の観点では、この盾は逆効果です。 中心的価値が閾値を超えないMVPで得た反応は、良くも悪くも仮説について何も語りません。

第三に、「検証したという事実」自体が社内で成果として扱われることです。 検証の質を問われないまま実施件数だけが報告されると、何も学べないMVPを量産する誘因が生まれます。 これは、PoCの実施が目的化する構造と同じ根を持っています。

中心的価値は「採算度外視」で作り込む

さらに踏み込むなら、MVPにおける中心的価値は、「これでは採算が合わないのではないか」と思うぐらいの水準で実現させるべきです。 ケーキの例で言えば、原材料を惜しみなく使い、誰が食べても「これはうまい」と言うものをまず作ります。

その理由は、MVPで確かめる問いの順序にあります。 最初に確かめるべき問いは、「この価値に顧客はお金を払うか」です。 「この価値を採算の合うコストで提供できるか」は、その次の問いです。 価値への反応が確認できていない段階でコストを削ると、2つの問いを同時に、どちらも中途半端な条件で検証することになります。 コストを下げ、利益が出る構造へ組み替えるのは、価値の存在を確認したあとの工夫の工程です。

この順序は、MVPの古典的な成功例にも見て取れます。 米国の靴通販Zapposの創業者は、サイトに靴の写真だけを掲載し、注文が入るたびに自ら靴店で商品を買って発送しました。 1件ごとの採算は完全に度外視です。 しかし、顧客が受け取る中心的価値（欲しい靴が手元に届く体験）は本物でした。 在庫管理や物流網といった採算化の仕組みは、「人々はオンラインで靴を買う」という価値への反応を確認したあとに構築されています。

なお、採算を度外視するとは、事業の経済性を考えないことではありません。 「この価値が確認できたら、量産や自動化でコストはここまで下げられる」という見通しは、検証と並行して持っておくべきです。 度外視してよいのは、検証段階の1件ごとの損益だけです。

このことは、検証時の価格設定にも1つの示唆を与えます。 顧客に提示する価格は、検証段階の原価ではなく、事業として成立させたい将来の価格に置くべきだということです。 検証段階の原価で値付けをすれば高すぎて売れず、逆にコストを回収できる範囲まで価値を削れば、前述のとおり検証そのものが成立しません。 将来の価格で提示し、検証段階の原価割れは学びを得るための費用として割り切る。 この整理なら、「この価値に、この価格で、顧客はお金を払うか」という本来の仮説を、まっすぐ検証できます。

採算からの逆算で作られたMVPの末路

逆に、「おそらくこの値段でなければ売れない」という想定から逆算して、最初から採算の合うMVPを作りにいったとします。 先ほどのケーキの例で言えば、想定した売価から逆算した原価の範囲で、材料も、見た目も、作り方も決めていくやり方です。 できあがったケーキがユーザーの満足する閾値を超えなかったら、どうなるでしょうか。

味も、見た目も、それ以外も、すべてが中途半端です。 中途半端どころか、市場にすでにある一般の製品より劣ったもので、実験をすることになります。 そのようなものに返ってくる反応は、当然ネガティブです。

深刻なのは、仮説そのものは正しく、ニーズも実在していた場合です。 MVPの作り方を間違えただけで、正しかった仮説に「検証の結果、ニーズなし」という記録が残り、事業ごと葬られます。 本来つかめたはずのビジネスチャンスをみすみす逃すこの構造は、おそらく世の中で多発しています。

新規事業におけるMVPの設計手順（5ステップ）

以上を踏まえると、MVPの設計は次の5つの手順になります。

１．中心的価値を1つに特定する

このプロダクトが顧客に選ばれるとしたら、その理由は何か。 この問いへの答えを1つに絞ります。

特定の手がかりは、顧客の課題の側にあります。 「顧客は今、この課題を何で解決していて、その解決の何に不満を持っているか」を言語化できれば、その不満を解消するものが中心的価値の候補です。 プロダクトの機能一覧から「一番の売り」を選ぶ発想では、作り手の思い入れが混ざり、顧客の選ぶ理由と一致しません。

中心的価値が特定できていない状態で作り始めると、削ってよい要素とそうでない要素の区別がつきません。 その結果、すべての要素を均等に「そこそこ」の水準で作ることになり、前節で述べた末路へまっすぐ向かいます。 候補が複数あって絞れない場合は、まだMVPを作る段階ではなく、顧客の課題を特定し直す段階です。

２．最もリスクの大きい仮説を選ぶ

事業アイデアは、顧客、課題、解決策、価格といった仮説の束です。 その中で、外れたときに事業が根本から成立しなくなる仮説から検証します。 多くの場合、それは「この中心的価値に、顧客はお金を払うか」です。

技術的に作れるかどうかが最大の不確実性であれば、MVPの前にPoCで技術の成立を確かめるほうが安く済みます。 検証手段の使い分けは、冒頭の検証チェーンの図に立ち返って判断してください。

３．中心的価値を本番同様に体験できる最小の形を選ぶ

中心的価値を、顧客が本番と同じ質で体験し、評価できる最小の形を選びます。 中心的価値の外側は、検証の成立を妨げない範囲で、どれだけ省いてもかまいません。

なお、大企業の新規事業では「未完成なものを出すとブランドを傷つける」という懸念がよく挙がります。 この懸念への答えも、同じ原則から導けます。 中心的価値は満点を目指し、周辺は省略し、安全性や法令遵守など絶対に外せない品質ラインは守る。 この切り分けができていれば、MVPがブランドを傷つけることはありません。 ブランドを傷つけるのは、中心的価値まで削られた「一般の製品より劣ったもの」のほうです。

４．課金を含めて検証する

「良いですね」という言葉と、お金を払う行動のあいだには、大きな距離があります。 可能な限り、実際の課金、あるいは発注書や有料トライアル契約といったコミットメントを伴う形で反応を確かめます。

このとき、価格を安易に下げないことも大切です。 検証したいのは「この価値に、想定した水準のお金を払うか」であり、値引きした価格での購入は、その仮説の検証になりません。

５．学びを次のサイクルへつなぐ

検証結果から、仮説を維持するか、修正するか、方向転換（ピボット）するかを判断し、次のMVPへ反映します。 リーンスタートアップの言う構築、計測、学習の反復です。

このとき、登録数や継続率といった定量データと、顧客の生の言葉である定性情報の両方を突き合わせます。 定量データは「何が起きたか」を示しますが、「なぜ起きたか」は定性情報からしか読み取れません。 MVPを出したこと自体に満足して、フィードバックの収集と分析を省くと、投じたコストに対する学びはゼロになります。

このとき、ネガティブな結果が出ても、即座に「ニーズなし」と結論づけないでください。 後述するとおり、その結果はMVPの作り方や見せ方が生んだ偽物である場合があります。

MVPの型と、その型で検証できる仮説

MVPには定番の型があります。 ただし、どの型を選ぶかは好みの問題ではなく、「その型で中心的価値を本番同様に体験させられるか」で決まります。

• 「ランディングページ型」：サービスの概要と申込導線だけのWebページを作り、登録や問い合わせの数で関心を測ります。検証できるのは「価値の言語表現に人が反応するか」であり、体験したあとの満足は検証できません。
• 「Explainerビデオ型」：実物を作らず、サービスの動きを動画で見せて反応を測ります。Dropboxは開発前に紹介動画を公開し、大量の登録希望を獲得しました。概念が伝わるか、欲しいと思われるかを検証できます。
• 「コンシェルジュ型／ウィザード・オブ・オズ型」：裏側を人力で運用し、顧客には完成されたサービスとして中心的価値を提供します。Zapposの例のとおり、中心的価値を本物の品質で届けながら、システム投資を後回しにできる型です。
• 「限定機能型」：中核となる1機能だけを実装して提供します。初期のTwitterが短文共有だけに絞ったように、中核機能そのものの価値を検証できます。
• 「プロトタイプ型」：動く試作品や画面モックで、使い勝手や体験への反応を検証します。

型の選択は、中心的価値の性質に従属します。 「味」が中心的価値のケーキをランディングページ型で検証しても、得られるのはコンセプトへの関心だけで、美味しいかどうかは永久にわかりません。 逆に、届け方の効率が中心的価値でないなら、コンシェルジュ型のように人力で豪華に届けてかまわないのです。

また、型は1つに絞る必要はなく、検証したい仮説の変化に合わせて乗り換えていくものです。 たとえば、まずランディングページ型で「この価値の言語表現に反応する人がいるか」を確かめ、反応した相手にコンシェルジュ型で本物の価値を人力提供し、需要が確認できたら限定機能型で仕組み化する、という段階的な進め方が組めます。 各段階で確かめる仮説が明確なら、型の乗り換えはそのまま検証の前進になります。

プロトタイプの作り方と検証の進め方については、こちらのコラムで詳しく解説しています。

MVPにかかる費用と期間の目安

MVPの費用と期間は、どの型を選ぶかでほぼ決まります。 以下は、外部の制作会社や開発会社に依頼した場合の一般的な相場観です。 自社に作れる人材がいるか、次章で述べる生成AIをどこまで活用するかで大きく変わるため、初期の予算感をつかむための目安としてご覧ください。

• 「ランディングページ型」：10万〜50万円程度、1〜2週間。ノーコードツールを使えば、数万円と数日の規模まで圧縮できます。
• 「Explainerビデオ型」：30万〜150万円程度、2週間〜1カ月。アニメーション動画の制作費が中心です。
• 「コンシェルジュ型／ウィザード・オブ・オズ型」：制作費はほとんどかからず、主なコストは運用にあたる人の人件費です。検証期間は1〜2カ月が目安です。
• 「限定機能型」：100万〜500万円程度、1〜3カ月。機能を1つに絞ったソフトウェア開発が典型です。
• 「プロトタイプ型」：10万〜100万円程度、2週間〜1カ月。デザインツールで作る画面モックなら安く、動く試作品を作るなら高くなります。

費用を考えるときの判断基準は、金額の安さではありません。 「その支出で、中心的価値が満足の閾値を超えるか」です。 閾値を超えないMVPに払う費用は、金額の大小にかかわらず、学びを生まないまま消えます。 ケーキの例で言えば、パッケージの印刷費は削ってよくても、原材料費を削ってはいけないということです。

期間についても、制作にかかる日数だけでなく、設計、制作、顧客への提示、判断までの検証サイクル全体で考えます。 1サイクルを3カ月以内で回すことが1つの目安であり、制作だけで3カ月を超えるようなら、MVPではなく完成品を作り始めているサインと疑うべきです。

生成AIは、MVPの何を変えたか

近年の生成AIの普及は、MVPの作り方を大きく変えました。 ランディングページの文面や画像、紹介動画、画面モック、簡単なアプリケーションのコードまで、かつては外注していた制作物の多くを、数日と数万円の規模で用意できるようになっています。 前章で挙げた費用と期間の目安は、生成AIの活用度に応じて下振れしていくと考えてよいでしょう。

ただし、安くなったのは「作る」工程だけです。 生成AIが下げたのは中心的価値の外側を整えるコストであり、中心的価値そのものを閾値超えまで作り込む仕事と、検証を設計する仕事（誰に見せ、誰が会い、何で測るか）のコストは下がっていません。 ケーキの例で言えば、AIが安くしてくれたのはパッケージやメニュー表の制作であって、味を作る仕事ではありません。

むしろ、作ることが簡単になったぶん、閾値を超えない試作品を量産する誘惑は強まっています。 かつては制作コストの高さが「本当にこれを作って検証すべきか」を立ち止まって考える関門として機能していましたが、その関門は消えました。 偽の失敗は、以前より速く、大量に生産され得る環境になっています。 道具が進歩するほど、成否を分ける変数は検証の設計に集中していくと考えるべきです。

一方で、生成AIは検証の質を上げる方向にも使えます。 ヒアリング記録の分析、想定顧客ごとの訴求案の作り分け、インタビュー前の質問設計の壁打ちは、生成AIの得意分野です。 外側を整えるコストが下がったぶんの資源を、中心的価値の作り込みと、顧客に会う時間へ振り向ける。 これが、生成AI時代のMVPの使い方です。

BtoBの新規事業でMVPの成否を分ける3つの論点

MVPの解説の多くは、不特定多数のユーザーに届けるB2Cサービスを念頭に置いています。 しかし、日本企業の新規事業の多くはBtoBであり、BtoBのMVPには固有の論点があります。

１．誰に見せるか：Right Personの見極め

BtoBでは、MVPを見せる企業が正しくても、その中で見せる人を間違えるケースが頻発します。

たとえば会計系のプロダクトなら、経理部門、IT部門、数字をモニタリングする経営層、営業部門のどこに見せるかで、返ってくる反応はまったく異なります。 決裁に関与しない相手や、そのプロダクトの便益を受けない相手からの「間に合っている」は、ニーズの不在を意味しません。 検証相手が「Right Person」（そのプロダクトの便益と決裁に関わる、正しい相手）かどうかの見極めは、MVPの中身と同じだけ検証の質を左右します。

２．誰が見せるか：プロデューサー自身が顧客に会う

顧客ヒアリングを兼業的な営業担当に任せると、又聞きによって最重要の情報が薄まります。 顧客のわずかな言い回しの違いや、表情に表れる温度感は、報告書には残りません。

プロダクトを作っている当事者が顧客に会い続けることで、反応の差に気づき、見せ方や説明へ素早く反映できます。 BtoBのMVP検証は、作る工程と売る工程を分業した瞬間に精度が落ちると考えておくべきです。

３．何で確かめるか：BtoBは課金検証がやりやすい

BtoBには、B2Cにない利点もあります。 発注書、有償トライアル契約、導入意向書といった、課金やコミットメントを伴う検証手段が最初から使えることです。

相手が特定の企業だからこそ、「本契約と同じ稟議を通してもらえるか」という、行動ベースの強い検証を早期に設計できます。 アンケートの好意的な回答を積み上げるより、1社の発注書のほうが、はるかに多くを語ります。 BtoBでは検証対象の数が少なくなりがちですが、その分、1件ごとの検証の質を高められるのがこの領域の特性です。

判断を誤らせるMVP検証の2つの罠：偽の成功と偽の失敗

MVPの検証結果は、そのまま信じられるとは限りません。 判断を誤らせる罠は、2つの方向にあります。

「偽の成功」とは、実際にはニーズがないのに、あるように見えてしまう検証結果です。 課金を伴わない好意的な感想、関係者への忖度を含む社内評価、決裁に関与しない人からの「いいね」が典型です。

「偽の失敗」とは、実際にはニーズがあるのに、ないように見えてしまう検証結果です。 中心的価値が満足の閾値を超えないMVPで得たネガティブな反応や、決裁や利害に関わらない相手（Right Personでない相手）からの「間に合っている」という回答が典型です。

整理すると、検証結果の解釈には4つの象限があります。 ニーズが実在し、検証結果もポジティブなら、次の投資に進む本物の成功です。 ニーズが実在せず、検証結果もネガティブなら、早期に撤退できた本物の失敗であり、これはMVPが機能した証拠です。 問題は残りの2つ、すなわち偽の成功と偽の失敗であり、どちらも検証の設計（何を見せたか、誰に見せたか、何で測ったか）に原因があります。

本コラムで論じてきた「最小限」の誤読は、この偽の失敗を量産する構造です。 手を抜いた試作品は、実在するニーズを検出できないまま、「検証した」という事実だけを組織に残します。

罠を避けるには、検証結果を受け取ったときに、結果そのものより先に検証の設計を疑う習慣が有効です。 ポジティブな結果には「課金を伴っていたか」「相手はRight Personか」を、ネガティブな結果には「中心的価値は閾値を超えていたか」「見せ方は本番同様だったか」を問い直します。 この問いを通過した結果だけが、Go、ピボット、撤退の判断材料になります。

この2つの罠への対処と、検証後のGo、ピボット、撤退の意思決定については、以下記事で詳しく扱っています。

内部リンク┃ リンク先：新規事業PoCピラー記事（URLは公開後に差し替え）

事例：プロダクトを変えずにPMFへ至った検証

罠を避けてMVPを運用すると、何が起きるのでしょうか。 当社unlockが支援し、PMFの達成に至った事例を紹介します。

なお、この事業は同業からの参入障壁が低い性質のため、企業名や業種を特定しない形での紹介になります。 詳細な経緯は、代表津島のnoteで公開しています。

主体は伝統的な大企業で、本業の副産物として手に入る素材を活用した、ニッチな新規プロダクトを構想していました。 初期のヒアリングでは、有望と見ていたターゲットの大半から「自社で賄えており、お金を払うほどではない」という反応が返り、プロジェクトには暗雲が立ち込めました。

転機は2つありました。

1つ目は、プロトタイプの見栄えを完成品に近づけたことです。 実質的に同じプロダクトでも、実物に近い見た目で提示した途端、顧客から本番に近い反応を得られるようになりました。

2つ目は、同じ企業や部署の中でも会う人を変え、プロデューサー自身がヒアリングを重ねたことです。 ヒアリングで得た気づきを、客観的な数字を用いた提案に反映した結果、それまでとは異なる好意的なフィードバックを複数得られるようになりました。

最終的に、当初の想定より強気の価格でテスト販売に踏み切ったところ、想定を上回る数の企業から発注を獲得し、PMFの達成を確認するに至りました。

この経緯をMVPの観点から読み直すと、2つのことがわかります。

第一に、プロダクトの中身、すなわち中心的価値は、初期からほぼ完成していました。 初期の「お金を払うほどではない」という反応は、中心的価値の否定ではなく、見せ方と聞く相手を誤った検証が生んだ偽の失敗だったのです。 この段階の反応を真に受けて撤退していれば、実在したニーズごと事業が消えていました。

第二に、「見た目は中心的価値でなければ省いてよい」という原則を、機械的に適用してはいけないことです。 この事業では、実物に近い見た目がなければ、顧客は「実際に買うつもりで評価する」姿勢に入りませんでした。 つまり見た目の完成度は、この事業においては顧客が中心的価値を本気で評価するための前提条件であり、削ってよい外側ではなかったのです。 省く判断の基準は、あくまで「それを省いても、中心的価値が本番同様に評価されるか」に置く必要があります。

また、当初の想定より強気の価格でのテスト販売は、採算の設計を後工程に回しながら、課金という最も信頼できる反応で価値を検証した実例でもあります。

なお、この事例の2つの転機は、前章で述べたBtoBの論点そのものでもあります。 会う人を変えたのはRight Personの見極めであり、プロデューサー自身がヒアリングを重ねたのは、作る工程と売る工程を分業しなかったことの効果です。

また、この経緯をきれいな成功法則として読むことには注意が必要です。 実際には、ニーズが見えない状況でも撤退せず続けたことなど、合理的な設計とは言えない要素が結果に寄与した部分も含まれています。 成功事例は参考にしつつ、盲信しないことが、事例に向き合う際の前提です。

検証の終わり：PMFをどう確認するか

MVPの検証サイクルは、どこまで回せば終わりなのでしょうか。 一般的な答えは、PMFの確認です。

PMFに万国共通の判定基準はありませんが、実務では次のようなシグナルの組み合わせで判断します。

• 「値引きなしの受注」：想定した水準の価格で、顧客がお金を払うこと。前述の事例では、強気の価格でのテスト販売への発注がこれにあたります。
• 「継続と拡大」：一度きりの購入で終わらず、継続利用や追加発注が発生すること。
• 「顧客起点の広がり」：こちらから売り込んでいない相手から、紹介や問い合わせが発生すること。

逆に、値引きしなければ売れない、初回で解約される、紹介が生まれないという状態は、まだ検証の途中です。 このときに問い直すべきは、プロダクトの機能一覧ではなく、中心的価値がユーザーの満足する閾値を超えているかどうかです。

PMFが確認できたら、検証の主題は「売れるか」から「どう広げるか」へ移り、価格や販売チャネルを含めたテストマーケティングの段階に入ります。

まとめ：小さく作る。ただし価値は本物で

MVPは、最小限のプロダクトで顧客からの学びを最速で得るための手法です。

ただし、Minimumが削ってよいのは中心的価値の外側だけです。 中心にある価値は、MVPの段階でもユーザーを満足させる閾値を超えていなければならず、そこは採算を度外視してでも作り込む対象です。 コストを下げて利益の出る構造にするのは、価値への反応を確認したあとの工程です。

この順序を誤ると、正しい仮説と実在するニーズが、「検証の結果、ニーズなし」という偽の失敗の記録とともに失われます。 小さく作ること自体は、目的ではありません。 本物の価値を、最小の形で顧客に届け、お金を払うかどうかの反応から学ぶこと。 それがMVPです。

株式会社unlockは、MVPの設計から検証、事業化までの実行を支援しています。 自社のMVP検証の設計にお悩みの方は、unlockの伴走支援をご覧いただくか、お気軽にお問い合わせください。