MVPの90%は偽物、本当のMVPの定義

M(Minimum)ではなくV(Viable)が、MVPの運命を決める。

6か月かけてリリースしたのに失敗した配達アプリ

ある配達プラットフォームのスタートアップの話です。創業チームは自信をもって「MVPを作ろう」と宣言し、その後6か月働きました。決済システム、レビューシステム、クーポンシステム、レコメンドアルゴリズムまで、すべてを揃えてからローンチしました。「完璧なMVPだ」と思っていました。

ところが市場に出してみると、問題が爆発します。飲食店オーナーと顧客をつなぐという、いちばん基本の価値さえ検証せずに進めてしまっていたのです。気づいたときには、すでに遅すぎました。

この記事を読み終えた頃には、あなたが今作ろうとしているものが「本当のMVP」なのか、それとも「MVPのふりをした完成品」なのか、はっきり診断できるようになっています。

「最小」の罠、機能ではなく検証だ

初めてMVPを作るとき、人はほとんどいつも同じ失敗をします。「M(Minimum)」にだけ集中することです。「いちばん少ない機能で」「いちばん速く」「いちばん安く」という目標が先に立ちます。それでスプレッドシートを開いて、「ユーザーが本当に必要な機能は?」ではなく、「5機能で足りるか、10機能までいけるか」を考えてしまいます。

エリック・リースはThe Lean StartupでMVPをこう定義しました。

「最小限の努力で、検証済みの学びを最大限得られる、新しい製品のバージョン。」

大事なのは「機能の数」ではなく「学び」です。本当に確かめたいのは「人はこれを使うか?」ということ。機能が5つでも20でも関係ありません。その機能が、確かめるべき仮説をきちんと検証できるか、ここが重要です。

機能が少なすぎると、MVPではなく「未完成の製品」になります。機能が多くてもコアの価値を検証できなければ、それは「完成度の高い無駄」でしかありません。

MVP vs ベータ vs プロトタイプ — 境界をはっきり

この三つはよく混ぜて使われますが、目的も対象も時期も違います。

ダンクン(Daangn)の初期MVPを見てください。「リクエストする」「もらった提案を確認する」、この2つの機能だけで始めました。残りは本当に手作業でした。仲介事務所に電話を回したのです。マッチングロジック? なし。人がやっていました。きれいなUI? なし。カカオトーク経由で問い合わせを受けて処理していました。

でもこれが本当のMVPだった理由は、「人が自分の意図(物件のリクエスト)を登録し、物件を受け取る」というコアの価値を検証できたからです。

良いMVPの4つの条件

1. コア仮説がはっきりしている

「人は私たちのサービスを使うだろうか?」では大きすぎます。「ソウルの25〜35歳の会社員は、ランチタイムに5分以内に注文できる手軽な食事を、毎週2回以上買うだろうか?」のように、具体的にする必要があります。

トス(Toss)の初期仮説は「既存の銀行アプリより10倍速く送金できれば、人は使うだろうか?」でした。だから送金機能だけを完璧に作りました。あとはボタンすらありませんでした。

2. ユーザーが実際に問題を解決される

「自分のアイデアが答えなんだ」と感じてもらう必要があります。無料でも有料でも、完璧でも70%の完成度でも構いません。ダンクンのユーザーは「このアプリで本当に物件が見つかる」と感じました。それがMVP成功のシグナルでした。

3. 測定可能である

ユーザーが本当に問題を感じたか、どうやって分かるでしょうか。数字で。会員数、アクティブユーザー、購入回数、再訪率といったものです。「いいフィードバックをもらいました」は測定ではありません。口は嘘をつくけれど、指は嘘をつきません。アプリをもう一度開いたか、買ったか、友だちにすすめたか、これが証拠です。

4. 仮説が外れたとき、すぐ方向を変えられる

6か月かけて作ったとしたら? 投資が大きすぎると「これ、間違ってる?」という疑問が浮かんでも、方向を変えられません。心理的にも金銭的にも。逆に2週間で作ったなら、「あ、これは違うな」と次のアイデアに移れます。最初のMVPが成功する確率はとても低いのです。

避けるべき間違ったMVPパターン3つ

パターン1:MVPのふりをした完成品

冒頭の配達プラットフォームのように。「本音では完成品を作りたいけど、MVPと呼んでおこう」という心理です。たいてい「これは実際のユーザーが触る製品だから、完璧でなければ」と正当化します。

処方:今作っているものから「絶対に必要ない機能3つ」を消してみてください。カカオトークで顧客対応してもOKか? 自動化アルゴリズムなしで手作業でも始められるか?

パターン2:小さすぎるMVP

反対の極端もあります。プロトタイプ程度を作って「これがMVPです」と言うケース。ユーザーが本当に自分の問題を解決できないレベルです。フィードバックがないか、「もっと作ってください」というリクエストばかり。それは市場のシグナルではありません。

処方:「ユーザーはこれで本当に私の問題を解決できるか?」 ダメなら、何が足りないかを書き出すこと。

パターン3:測定をしないMVP

もっとも多いパターン。MVPを作ってリリースしたのに、データを見ない。2〜3人のユーザーフィードバックを元に、次の方向を決める。

処方:MVPリリース前に「どの指標を見るか?」を先に決めます。Google Analyticsの設定、登録データ、アクティブユーザー追跡、再購入率といったところ。

チェックリスト、私のアイデアは本当にMVPか?

次の10問に答えてみてください。「はい」が7つ以上あれば、本当のMVPです。

1. コア仮説が1文で定義されていますか?
2. その仮説を検証するために必要な機能が明確ですか?
3. その機能だけでユーザーは実際に問題を解決できますか?
4. 開発の見込みは8週間以内ですか?(理想は2〜4週間)
5. 最初の5分でユーザーは「これは私の問題を解いてくれる」と感じられますか?
6. 手作業やカカオトーク経由のサポートで運用してもOKですか?
7. 仮説が外れたとき、すぐ次のMVPに移る心の準備はできていますか?
8. リリース後に見るコア指標を3つ決めましたか?
9. 外部の人(顧客)に使ってもらい、フィードバックをもらいましたか?
10. 先週、「絶対に必要ない機能」を3つ以上消しましたか?

まとめ

M(Minimum)が罠で、V(Viable)がコアだと分かりました。すると次の問いが立ちます。「で、何を作る?」 アイデアはたくさんあるのに、何を選びますか? 次の記事では、あなたのアイデアを診断する5つの質問フレームワークを紹介します。「作れるか?」ではなく「1年間しがみつけるか?」を問うフレームです。MVPの成功は製品ではなく、あなたの粘りから生まれるのです。

前の記事:なぜ今、あなたがMVPを作るべきか(14日メイカーの時代)
次の記事:何を作るか決める5つの質問(持続可能性チェック)

キム・ミンチュル、Freeive CEO、フェイルスクール