時間をかけて丁寧に作ったプロダクトが、いざユーザーに使われると「いらない」と言われる。そんな経験はないだろうか？ これは決して珍しいことではない。なぜなら、ユーザー自身も実際に使うまで、本当に価値があるか分からないからだ。
最小限の機能を備えたプロダクトを作り、ユーザーに試してもらうことで、本当に価値のある機能を見極める考え方がMVP（Minimum Viable Product） である。このアプローチにより、無駄な開発を減らし、最短で最良のプロダクトを作ることができる。
MVPの概念は、経営コンサルティング会社 SyncDevのCEOであるFrank Robinson氏が、2001年にMVPを提唱した。2005年に、起業家であり学者のSteve Blankスティーブ・ブランク氏がコンセプトを説明し、2010年には Eric Ries氏の書籍「Lean Startup」で広く知られるようになった。
ユーザーの要望通りに作っても失敗する理由
「こんな機能があれば便利そう」――ユーザーの声を反映して作ったのに、いざリリースすると「使わない」と言われる。これはなぜなのか？
ユーザーは、必ずしも自分が求める機能を具体的にイメージできているわけではない。例えば、タスク管理アプリを作るとしよう。
- タスクの登録
- カテゴリ分け
- 優先度付け
- 期限設定
- 他者との共有
一見すると、機能が豊富なほど便利に思える。しかし、多機能すぎると、逆に「使いにくい」となり、シンプルな使い勝手が求められることも多い。
MVPのアプローチでは、まず最小限の機能を実装し、実際にユーザーに使ってもらう。その反応を見て、本当に価値がある機能かを見極める。机上の理論ではなく、実際の利用状況からプロダクトを成長させられる。
必要最低限とは何か：スケートボードで考える
価値のないプロダクトに時間をかけるほど、コストの無駄は大きくなる。だからこそ、機能を必要最小限に抑え、できるだけ早い段階でユーザーに使ってもらう ことが重要だ。こうすれば、もし価値がなければ早期に軌道修正でき、制作時間を無駄にするリスクを最小限にできる。では、必要最小限とはどのようなものだろうか。
この考え方を理解するために、ヘンリック・ニバーグ（Henrik Kniberg）氏のアジャイル開発とウォータフォールの対比図を見てみよう。
ウォーターフォール開発の問題点
ウォーターフォール開発では、完成形を目指して段階的に作る。例えば、車を開発するとしたら、
- まずタイヤを作る
- 次にシャーシを組み立てる
- 最後にエンジンやボディを追加する
しかし、ユーザーは車が完成するまで「移動する」という価値を体験できない。図で言えば、最初に作られるのは「タイヤだけ」だが、これでは当然 移動することはできない。
タイヤでは、移動する価値を体験できない
アジャイル開発のアプローチ
アジャイル開発では、最初からユーザーに価値を提供する ことを重視する。
- スケートボードを作る（最低限の移動手段）
- 次にスクーターに進化させる
- さらに自転車へとアップグレード
- 最終的にバイクや車へと発展
スケートボードなら、シンプルな構造でありながら、車輪を活用した移動手段として機能する。これにより、ユーザーは実際に移動する体験をしながら、「もっと安定したい」「スピードを上げたい」といったフィードバックを提供できる。
このアプローチの利点は、ユーザーの反応をもとに素早く改善できることだ。スケートボードからスクーター、そして自転車へと段階的に進化させることで、本当に求められている機能を見極めながら開発を進められる。
スケートボードであれば、早い段階で移動する価値を体験できる
つまり、「必要最小限」とは、単に開発時間を短くすることではなく、ユーザーがすぐに価値を実感できる形でプロダクトを提供することになる。
MVPの誤解：「最低限作ればいい」は間違い
アジャイル開発とウォータフォールの対比図が広く知られるようになると、一部の企業は 「とにかく最低限動くものを提供し、ユーザーにテストさせればよい」 と誤解するようになったが、これは間違いである。
例えば、「目覚まし時計」のMVPを考えてみよう。
不満や怒りを募らせるのは誤ったMVP
例えば、「決まった時間に起きられない」という課題を解決するために「目覚まし時計」を作るとする。もし 「最低限の機能」 という考えだけで開発すると、セットした時刻に大音量で鳴るだけのシンプルな目覚まし時計 になるかもしれない。
しかし、これが 驚くほど大きな音で不快なもの だったらどうだろう？ ユーザーは価値を感じる前に、「うるさい」「使いたくない」という不満や怒りが先に来てしまい、結局使われなくなる。
使いたいと思えるものにするのがMVP
「時刻になったら音が鳴る」という仕組みに本当に価値があるのかを確かめる前に、周辺機能をいくら追加しても意味がない。価値を確かめるには、ユーザーが実際に満足して使えるものを提供する必要がある。
例えば、目覚まし時計を考えてみよう。ただ大音量で鳴るだけでは、「うるさい」「不快」と感じ、すぐに使われなくなる可能性が高い。一方で、心地よく目覚められる音で、決まった時間に快適に起きられるなら、ユーザーは翌日も使おうと思う。
このように、ユーザーが継続して使いたくなる体験を提供できれば、プロダクトの価値を確認できる。そして、使い続けてもらう中で、より良い改善点のフィードバックを得られるようになる。
Minecraftに学ぶMVPの成功例
ゲーム業界でのMVP成功例として、Minecraft がある。
Minecraftの初期バージョンは、わずか6日間で開発された。最初の機能はシンプルで、
- ブロックを配置・破壊できる
これだけだった。しかし、プレイヤーはこれを使って自分なりの遊び方を見つけ、フィードバックを提供した。その結果、Minecraftは進化し、世界的なヒット作になった。
開発初期のminecraft
引用元：making-sense-of-mvp
当時のゲーム市場では、現実世界に近い高精細なグラフィック が主流だった。しかし、リアルなグラフィックを実現するには膨大な開発時間が必要であり、リリースまでに長い期間を要する。
もしMinecraftが、最初からグラフィックにこだわり、精巧なキャラクターや建物を作ることに時間を費やしていたらどうなっていただろうか？ 「構造物を作る楽しさ」という価値をすぐに確かめることができず、売れるかどうかわからないまま膨大な開発コストを投じ、大きなリスクを抱えることになっていただろう。
しかし、Minecraftはグラフィックではなく、「構造物を作る楽しさ」という価値にフォーカス した。これにより、早い段階でユーザーの反応を確かめながら、改良を重ねることができた。その結果、Minecraftは大ヒットし、月間アクティブユーザー（MAU）1.4億人 という驚異的な成長を遂げた。
当時販売された現実世界に近いグラフィック
引用元：https://anastasm.hatenadiary.org/entry/20100308/1267980936
MVPからMLPへ：愛されるプロダクトを作る
最近では、MVPの発展形として MLP（Minimum Lovable Product） という考え方も注目されている。
MVPは 「最小限の機能で価値を検証する」 ことが目的だった。しかし、多くの企業が「とにかく動くものを出せばいい」と誤解したため、
- 「動くけど使いたくない」
- 「機能はあるけど使わない」
といったプロダクトが生まれがちだった。
MLPは、利便性が高く、楽しくてワクワクするような体験 を提供することを目指す。重要な問題を解決しつつ、信頼性・使いやすさ・感動 を兼ね備えたプロダクトを生み出す。
MLPの特徴
- 便利であるだけでなく、楽しくワクワクする体験 を提供する
- ユーザーの課題を解決しつつ、信頼性・使いやすさ・感動 を重視する
- 初期段階から「使いたい！」と思わせる工夫がある
MVPは重要な概念だが、それを一歩進めて、「ユーザーに愛される最小限のプロダクト」を目指すことが、成功への近道となる。
デザインの欲求階層とMLPのイメージ
まとめ
- MVPは「最小限の機能で価値を確かめる」ための考え方である
- 「ユーザーの要望通りに作る」のではなく、「本当に必要なものを見極める」ことが重要
- アジャイル開発の考え方を取り入れ、段階的に価値を提供する
- MLP（Minimum Lovable Product） の視点を持つことで、ユーザーに使ってもらえるプロダクトとなる
