MVPとは何か — 新規事業で「最小限」をどう定義するか
MVPという言葉は、新規事業の現場で最も誤解されている概念の一つだ。
「最小限の機能で製品を作る」と理解している人が多い。だが、この理解のまま開発に入ると、「最小限」のつもりが3ヶ月かかり、結局誰にも使われない製品が出来上がる。
MVPの本来の意味は「Minimum Viable Product」。直訳すると「実用最小限の製品」。だが、エリック・リースがリーンスタートアップで提唱した本来の意図は、「仮説を検証するために必要な最小限の手段」だ。
製品ではなく、検証手段。この視点の転換が、新規事業の初期フェーズでは決定的に重要になる。
MVPの本質は「学習」にある
MVPの目的は「製品を出すこと」ではない。「学ぶこと」だ。
リーンスタートアップのBuild-Measure-Learnサイクルの中で、MVPは「Build（構築）」の部分に位置する。だが、最も重要なのは「Learn（学習）」だ。
つまり、MVPを作る前に決めるべきは「何を作るか」ではなく、「何を学びたいか」だ。
- 顧客はこの課題を本当に抱えているか？
- この解決策で課題は解決するか？
- 顧客はこの解決策にお金を払うか？
検証したい仮説によって、MVPの形は変わる。場合によっては、製品を作る必要すらない。
「最小限」を誤解する3つのパターン
パターン1: 機能を削っただけの「小さな製品」を作る
最も多い誤解。本来10個ある機能を3個に絞って、「これがMVPです」とする。
問題は、3個に絞っても開発に2-3ヶ月かかること。そして、3個の機能が「顧客が本当に欲しい3個」かどうかが検証されていないこと。
MVPは「小さな製品」ではない。「学びを得るための最小限の手段」だ。
パターン2: 完成度を下げただけの「粗い製品」を出す
「MVPだからクオリティは低くていい」という誤解。バグだらけ、UIが崩れている、動作が遅い。
これではユーザーの反応が「この製品は品質が低い」に集中してしまい、本当に検証したかった仮説（課題の存在、解決策の方向性、支払い意欲）の学びが得られない。
MVPに求められるのは「低品質」ではなく「高集中」。検証したい仮説に対して、顧客が判断できるレベルの品質が必要だ。
パターン3: MVPを一度作って「答え」を求める
「MVPを出したが、結果が微妙。この事業はダメだ」。
一発で正解を引き当てようとするのは、MVPの使い方としては間違っている。MVPは仮説検証のサイクルの一部だ。最初のMVPで学び、仮説を修正し、次のMVPを設計する。このサイクルを高速で回すことに意味がある。
MVPの種類 — 製品を作らないMVPもある
仮説の種類によって、MVPの形は異なる。製品を作ることが常に最善ではない。
1. ランディングページMVP
「この課題を解決するサービスがあったら、興味がありますか？」を検証する。
サービスの概要を説明するLPを作り、「事前登録」や「詳しく知りたい」のボタンのクリック率を計測する。製品を作る前に、需要の有無を確認できる。
検証できること: サービスへの関心の有無、メッセージの刺さり具合
検証できないこと: 実際の使用体験、支払い意欲の本気度
2. コンシェルジュMVP
システムを作らず、人力でサービスを提供する。
例えば、「AIが最適な旅行プランを提案するサービス」を検証したいなら、まずは自分が手動で旅行プランを作って顧客に提供する。顧客からの反応とフィードバックを収集し、サービスの方向性を確かめる。
検証できること: 顧客の課題の深さ、解決策の方向性、支払い意欲
検証できないこと: スケーラビリティ、技術的な実現可能性
→ コンシェルジュMVP — システムを作らず手動でサービスを検証する
3. プロトタイプMVP
実際に「触れるもの」を作って、顧客の反応を見る。
生成AIを使えば、動くプロトタイプを3-5日で作れる。ランディングページよりも具体的な反応が取れ、コンシェルジュMVPよりもスケールしやすい。
新規事業の仮説検証では、この「プロトタイプMVP」が最もバランスが良い。顧客が実際に触って反応できる具体性がありつつ、開発コストは低い。
→ MVP開発の費用感についてはMVP開発ガイドを参照
→ ノーコードで新規事業のプロトタイプを作る — ツール選定と実践
検証できること: UIの使いやすさ、機能の必要性、支払い意欲
検証できないこと: 実際のデータでの動作、長期的な利用習慣
4. オズの魔法使いMVP
フロントエンドは自動に見えるが、裏側は人力で動かす。
顧客には「AIが自動で分析しています」と見せるが、実際には担当者が手作業で分析結果を作っている。顧客体験は本物に近いが、バックエンドの開発コストがゼロ。
検証できること: 顧客体験の全体像、自動化へのニーズの強さ
検証できないこと: 自動化の技術的な実現可能性、処理速度
大企業でMVPを進める際の注意点
「MVP」という言葉を使わない
大企業の経営層にとって、「最小限の製品」は「品質が低い」と聞こえることがある。
代わりに「検証用プロトタイプ」「仮説検証スプリント」といった言葉を使う方が通りやすい。やっていることは同じだ。
判断基準を事前に設定する
MVPを出す前に、「何がわかったら次に進むか」「何がわかったらやめるか」を決めておく。
判断基準がないと、MVPの結果を都合よく解釈してしまう。「ユーザーの反応はまあまあだった」という曖昧な結論で、次のステップが決まらない。
→ PoCの成功基準の設定方法 — 曖昧な「成功」を数値で定義する
検証のスピードを優先する
大企業では、品質基準やブランドガイドラインが厳格なことが多い。MVPにもその基準を適用しようとすると、「最小限」が「3ヶ月の開発」になる。
匿名ブランドでの検証、社内限定での試行、NDAを結んだ顧客への限定公開。品質基準を下げるのではなく、検証の範囲を限定することでスピードを確保する。
MVPの前にやるべきこと
MVPを作る前に、2つのことを済ませておく必要がある。
1. 課題の存在を確認する
顧客が本当にその課題を抱えているかを、インタビューで確認する。課題が存在しなければ、どんなに優れたMVPも意味がない。
2. 仮説を構造化する
MVPで何を検証するかを明確にする。「課題の存在」「解決策の方向性」「支払い意欲」のどれを検証するかによって、MVPの形が変わる。
仮説が整理されていないまま「とりあえずMVPを作ろう」と始めると、何を学んだかわからないまま時間とコストを消費する。
まとめ
MVPは「小さな製品を作ること」ではない。「学びを得るための最小限の手段を設計すること」だ。
何を学びたいかが先。MVPの形はその後で決まる。
大企業の新規事業では、「MVP＝プロトタイプ」と限定せず、LPテスト、コンシェルジュ、オズの魔法使いなど、仮説に応じた検証手段を選ぶことが重要だ。そして、検証の結果を事業判断の材料に変えること。
作って終わりではない。学んで判断する。それがMVPの本質だ。
LITMUSは、新規事業の検証に特化したスタジオです。仮説の構造化から、プロトタイプMVPの制作、顧客検証、事業判断レポートまで、6週間で一気通貫で提供します。
50万円から始められるEntry Moduleもあります。詳しくは LITMUS をご覧ください。