「最小限の機能しか持たない製品」ではない
MVP（Minimum Viable Product）は、「検証したい仮説を最も効率的に検証できる最小限の実験物」を意味する。Eric Riesがリーンスタートアップの文脈で普及させた概念だが、実際の使われ方を見ると「コスト削減のための粗削りな初期製品」として誤解されているケースが多い。
「最小限（Minimum）」と「実用的（Viable）」という2つの形容詞の定義が重要だ。「最小限」は機能数や開発工数の少なさではなく「この仮説を検証するのに必要十分な実験物」を意味し、「実用的」はユーザーが実際に使えること（品質の最低ライン）を指す。この定義を取り違えると、MVPは「中途半端なもの」を出す言い訳に変質する。
Riesの原典では、MVPは「検証と学習のための最小投資で最大の学びを得るもの」として定義されている。
「何が最小か」は仮説によって決まる
MVPの設計における最も重要な問いは「今最も重要な仮説は何か」である。この仮説が明確でなければ、何を最小化すれば良いかも決まらない。
仮説には複数の種類がある。「この課題は実在するか（Problem仮説）」「この解決策が有効か（Solution仮説）」「この顧客セグメントが価値を感じるか（Customer仮説）」「この収益モデルが機能するか（Revenue仮説）」——それぞれに対応するMVPの形態は異なる。
Problem仮説を検証したいなら、製品を作る前に顧客インタビューとランディングページで反応を見ることがMVPになる。Solution仮説なら、手動で機能を模倣した「コンシェルジュMVP」が適している。Revenue仮説なら、実際に料金を提示してクレジットカード情報を入力させることで支払い意向を直接検証できる。MVPの形態は、検証したい仮説によって根本的に変わる。
MVPの代表的な類型
ランディングページMVP
製品が存在しない段階で、価値提案を説明するランディングページを作り、ユーザーの行動（メール登録・事前申し込み・クリック率）で需要を測る方法だ。Dropboxの事例が有名で、実際のサービスを作る前に機能を説明する動画だけを公開し、数日で数万件のウェイトリスト登録を獲得した。
開発コストがほぼかからないため、Problem仮説とCustomer仮説の検証に適している。ただし「興味がある」と「実際に使う」「実際にお金を払う」の間には大きなギャップがあるため、行動の解釈には注意が必要だ。
コンシェルジュMVP
人手で機能を模倣し、システムが完成しているように見せながらサービスを提供する形態だ。Zapposの創業初期（靴屋で写真を撮り、注文が来たら実際に買って発送）がこの類型の典型例だ。
自動化せずに手動で対応するため、スケールしない。しかしそのスケールしない部分こそが「ユーザーが本当に何を求めているか」の学びを直接的に得る機会になる。ポール・グレアムの「スケールしないことをやれ（Do Things That Don’t Scale）」という言葉はこの考え方に通じる。
ウィザード・オブ・オズMVP
コンシェルジュMVPと似ているが、ユーザーから見ると自動化されているように見えるが、裏側では人が手動で対応している形態だ。AIチャットボットのように見えながら、実際は人がメッセージを返しているといった形が典型例。自動化の前にユーザーの行動パターンとニーズを深く理解するために有効だ。
プロトタイプMVP
デザインスプリントでも使われる形態で、実際には動作しないが、ユーザーが操作した際の反応を観察できる程度の視覚的な実験物を指す。Figmaやスライドで作ったモックアップにユーザーを通し、どこで迷うか・どこに期待するかを観察する。UI/UXの仮説検証に適している。
「最小限」と「品質」のトレードオフ
MVPをめぐる実務的な議論として、「どこまで品質を下げても良いか」という問いがある。リリースして恥ずかしくないなら、まだリリースが遅い（If you’re not embarrassed by the first version of your product, you’ve launched too late）というReid Hoffmanの言葉はよく引用されるが、これが「品質を気にしなくて良い」と解釈されることがある。
実際には、MVPの品質は「検証の有効性を保証できる最低ライン」が基準だ。品質が低すぎてユーザーが使えない場合、得られるのは「品質が低かったから使わなかった」というデータだけだ——本来検証したかった仮説のデータではない。品質の低さが仮説検証の結果を汚染する場合、それは「最小限」ではなく「不十分」だ。
B2BとB2CではMVPの設計が異なる
MVP設計の文脈でしばしば見落とされるのが、B2BとB2CではMVPの条件が根本的に異なるという点だ。
B2Cでは、数百人〜数千人のユーザーが短期間で試用し、行動データが素早く蓄積される。ランディングページMVPや無料試用型のMVPが機能しやすい。一方、B2BではPoCや試験導入のプロセスが長く、意思決定者が複数存在し、「使ってみる」ハードルが高い。B2Bのコンテキストでは、ランディングページへの反応よりも、実際に使ってもらうためのコンシェルジュMVP的なアプローチが有効なことが多い。
大企業向けB2B SaaSのMVPを「一般消費者向けアプリ」と同じ設計思想で作ろうとすると、検証が機能しない。
顧客インタビューとの組み合わせについては顧客インタビューという幻想で詳しく論じている。MVPからスケールへの移行についてはスケールアップの死の谷も参照してほしい。
参考文献
- Ries, E. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Crown Business (2011)（邦訳：『リーン・スタートアップ』日経BP）
- Cagan, M. Inspired: How to Create Tech Products Customers Love, Wiley (2018)（邦訳：『INSPIRED: 熱狂させる製品を生み出すプロダクトマネジメント』日本能率協会マネジメントセンター）
- Graham, P. “Do Things That Don’t Scale,” paulgraham.com (2013)
- Olsen, D. The Lean Product Playbook, Wiley (2015)
- Gothelf, J. & Seiden, J. Sense & Respond: How Successful Organizations Listen to Customers and Create New Products Continuously, Harvard Business Review Press (2017)