ウェブサービスをつくる上でよく聞くことになる用語にMVPがあります。実際の開発に入る前にMVPをつくることで、プロダクトの不確実なところがなくなり、よりユーザーに使ってもらえるプロダクトになります。この記事ではMVPとはなにか、なぜつくるのか、MVPの種類や注意点などについて書いていきます。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
MVPとは
MVPはMinimum Viable Productの略で、実用最小限のプロダクトという意味をもちます。2001年にフランク・ロビンソン氏によって提唱されました。ここでいう「実用」とは「ユーザーの抱える課題を解決できること」です。ユーザーの抱える課題を解決できる、最小限の機能をもったプロダクトがMVPです。
なぜMVPをつくるのか
MVPをつくる目的は、小さいコストで仮説を検証するプロダクトをつくり、検証による学びを最大化することです。なぜ、MVPをとおして学びを最大化する必要があるのでしょうか。
MVPが必要な理由
それはプロダクトをリリースしてユーザーに使ってもらえたとしても、ほとんどの場合は習慣的に利用してもらえないからです。つまり失敗してしまうのです。たとえプロダクトの開発に入る前にユーザーインタビューをとおして課題や解決策の検証を十分に行なっていたとしても、です。これはいったいなぜでしょうか。
この大きな要因は、プロダクトのアイデア、つまり課題をどう解決するか？──画面や機能、プロダクトのしくみ自体を検証していなかったからです。たとえば価格だったり、あるいは流通などプロダクトに関わるパートナーとの連携が問題かもしれません。いくらユーザーが課題を感じていて、その解決策に満足していたとしても、プロダクト全体として習慣的に利用したくなるようなものでないと、ユーザーは継続的に利用してくれません。
MVPの役割
このような問題を解決するのがMVPです。MVPは、ユーザーが実際にプロダクトの本質的な価値を体験できる最小限の製品です。そこには価格やパートナーとの連携もふくまれます。画面や機能、価格やパートナーといったプロダクトのすべての要素を実用最小限につくり、仮説検証を繰り返します。
このプロセスを繰り返した結果、検証すべき仮説がなくなったときがMVPの完成です。MVPが完成してはじめて実際のプロダクト開発に入ることで、失敗するプロダクトを開発する可能性を限りなく減らすことができます。
MVPの事例: Door Dash
MVPの事例として、フードデリバリーサービスのDoor Dashがあります。2018年に約570億円を調達したこのサービスも、はじめは一晩でつくったランディングページからはじまりました。この一枚のページにはひとつの店舗のメニューをPDFで置き、注文はGoogle Callで受けとりました。たったこれだけで、Door Dashとして不確実だった仮説、つまり次のことが検証できます。
- ユーザーは配送にいくら払うのか
- レストランは配送にいくら払うのか
- ドライバーの採用は可能か
Door Dashは この仮説を5ヶ月かけて検証しました。もし彼らがこの検証を行わず実際のプロダクトを開発していたらどうなっていたでしょうか。それほどMVPによる検証が重要だといえる事例です。
MVPの種類
では、MVPをどうつくればいいのでしょうか。これはプロダクトによって大きく変わってきます。ここではMVPの代表的な手法を5つあげます。この中から、あるいは別の方法で、つくろうとしているプロダクトにあった方法でMVPをつくることになります。
1. 既存のサービスを組み合わせる
まずひとつめは既存のサービスを組み合わせてMVPをつくる手法です。たとえばGlideは、データベースとしてGoogleスプレッドシートを持つことで、コードを書かずにアプリをつくることができます。MVPの要件としてデータをかんたんに入力・表示すればよい場合などに適した方法です。
2. 人力で対応する
見た目は実際のプロダクトと同じようなデザインにしつつ、ユーザーの操作に対して人力で対応するやりかたがあります。たとえばレストランの予約サービスで、ユーザーの条件を聞いた上でAIが自動で候補を提案する──ように見せて、裏では人が調べて返信する、というやりかたです。人力だと時間はかかりますが、「条件からレストランの候補を提示する」という解決策を検証することは十分可能です。
3. 機能を絞る
いくつかある重要な機能のうち、ひとつに絞って提供するやりかたもあります。たとえばブログサービスでは投稿と閲覧の機能が必要ですが、まず閲覧側の機能だけをつくり、投稿はGoogleスプレッドシートなど既存のサービスから読むようにします。閲覧側など、一方の仮説検証がより重要な場合に役に立つ方法です。
4. 予約を受けつける
これは実際に販売する商品の説明ページと購入機能を用意して、商品をつくる前に売ってしまうやりかたです。まだ完成していない商品でも、たくさんの人が実際にお金を払って予約するということはユーザーの課題と解決策、プロダクトが検証できたことを意味します。クラウドファンディングなどもこのやりかたに該当します。
5. コンテンツを公開する
ランディングページや動画などのコンテンツを公開して、反応を見ることで検証するやりかたがあります。たとえばリーン・スタートアップの実践書「RUNNING LEAN」は、目次だけが載ったページをつくり、読者の反応をみながら目次を改善し、執筆に入りました。
コードを書く必要はない
ところで、MVPといってもコードを書く必要はありません。MVPの目的はあくまで仮説を検証することです。検証できればいいので、コードを書く必要はまったくありません。Googleフォームなど、既存のサービスを組み合わせることでMVPとすることができます。むしろコードはできるだけ書くべきではありません。
できるだけ小さなコストで、不確実性の高い仮説を検証できるやりかたでMVPをつくりましょう。
いつMVPをつくるのか
MVPは課題の検証、解決策の検証が終わってからつくりはじめます。MVPははやくつくりはじめると思われがちですが、思ったより後のフェーズでつくるものです。まずアイデアを出したらリーンキャンバスでアイデアを整理し、課題を検証します。その後解決策を検証した上で、はじめてMVPの構築に取りかかります。
MVPをはやくつくりはじめると──つまり課題や解決策が十分に検証できていない状態でつくると、そもそもMVPで解決しようとしている課題をユーザーが抱えていないかもしれません。あるいは解決策が望んだ形ではないかもしれません。こうなると、MVPを構築したコストが無駄になってしまいます。
最短距離でプロダクトをつくるためにも、課題と解決策の検証にしっかり時間をかけましょう。
注意すべきこと
無料で提供しない
有料を想定しているプロダクトを、MVPの期間だけ無料で提供するケースをよくみます。ただ、MVPは有料でなければいけません。MVPの目的のひとつは、ユーザーが抱える課題の解決に対価を払うかを検証することです。ユーザーがプロダクトを使う理由には必ず料金がふくまれます。
「無料じゃないと使ってくれないから」という理由で無料にするのであれば、おそらくそのプロダクトには料金以外の重要な問題が残っています。その問題にもしっかりと目を向けて解決に取り組みましょう。
ソースコードを再利用しない
また、MVPのソースコードを実際のプロダクトに再利用すべきではありません。MVPは検証の過程でシステムがどんどん変わっていきます。つぎはぎだらけのシステムになるでしょう。ただ、MVPならそれでまったく問題ありません。なぜならMVPの目的はあくまで仮説を検証することだからです。
問題なのは、このソースコードを実際のプロダクトに利用することです。MVPのソースコードは設計がめちゃくちゃですが、実際のプロダクトでは、とくにデータベースは寿命が長く慎重に定義する必要があるからです。MVPが完成したら、その時点で最適な設計をし直すべきです。エンジニアリングに深くない創業者などは実際のプロダクトをMVPの延長としてリリース計画を立てがちですが、あくまで別モノとわりきって考えましょう。
まとめ
MVPはプロダクト全体の仮説を検証する目的でつくります。また、実用最小限の機能になるよう、可能な限りシンプルにつくります。できるだけコードは書かず、既存のサービスを組み合わせてMVPにするよう工夫します。
機能だけでなく、価格や流通などプロダクトとして必要なあらゆる要素を取り入れてユーザーに提供することで、これまでのユーザーインタビューだけでは得られなかった学びを得ることができます。MVPを完成させた上で実際のプロダクト開発に入ることで、習慣的に利用されるプロダクトにつながっていきます。
