プロダクト開発におけるMVPをちゃんと考える

はじめに

MVPって知ってますか？バスケや野球で選手が表彰される方じゃなくて、スタートアップやプロダクト開発の場面でよく言われる方です。MVPは、Most Viable Productの略で、実用最低限に実装されたプロダクトのことを言います。2010年あたりに、エリックリースが「リーンスタートアップ！」という本の中で、まずプロダクトの工数を見積もって開発を進める前に、このプロダクト本当にいけるんか？！っていうところをちゃんと検証してから、プロダクト開発に着手しようという理論です。

分かりやすく言えば、プロダクトがいけるかどうかを確かめるために、コードなんて書く必要がないってことです。いけるならやればいいし、いけそうにないなら止める。普通、アプリ作ろうと思ったら、何ヶ月もかかるし、お金も時間も奪われますよね。それでダメだって分かったら、これまでのコスト（涙）ってなる。だから、これを最低限に抑えようぜっていうのが、MVP。スタートアップや個人開発のように、リソースが限られている僕らには知って損はないやり方なのかなって思います。

どんなのがMVPっていうのか？

主に海外の事例になりますが、「これぞ！MVP」というものを幾つか紹介していきますね。

Dropbox

MVPの事例を探したとき、一番初めにヒットするのがDropboxですね。Dropboxはプロダクト開発をしている最中に、デモンストレーションのビデオを作り、HackerNewsに投稿したことで75,000の事前登録者を獲得することに成功します。サービスを出す前にこれだけ登録者を得られるってすごいですよね。やる気上がりそう。

ProductHunt

今や開発者コミュニティの代表的サイトとなった、ProductHunt。実は創業者のRyanは開発者でもなければ、共同創業者も持たないというバックグラウンド。彼が最初に始めたのはニュースレターでした。投資家や創業者に対して、自分が探したプロダクトの最新情報をメールで送っていたのですね。

Buffer

Bufferは、SNS予約投稿ツールとして不動の地位を築いています。彼らはリリース前に、こういうサービスを作ろうと思っているよ！というランディングページを用意し、事前登録者を誘いました。登録者が増えるたびに、幾らだったら払うかみたいな検証も少しずつ加えていって、プロダクトの検証を進めました。（LPは会議のアイデア機能でも作れるのでぜひ！）

Zappos

カスタマーサポートの神として崇められているオンライン靴ECのZapposも、最初はコストを欠けずに経営していました。彼らは、簡単なホームページを作成し、靴の写真を並べて、在庫は持ちませんでした。ページ上で靴が売れたら、経営者本人が靴を買いにいって配送するという仕組み。

Uber

最近上場した白タクサービスのUberも、リリース時はあんなに立派な位置情報は用いておらず、SMSで近くの車を呼ぶ仕組みでサービスを成立させていました。また、最初は創業者たち自らが車を控えていて、運転手をやっていたそうです。

MVPは、有名サイトのURLをアーカイブで検索して、リリース頃まで巻き戻れば見れるので結構勉強になりますよ〜。

ちゃんと考える

Facebookのマークザッカーバーグも「完璧よりも、まず終わらせろ！」って言ってるし、Linkedinのリードホフマンも「v1.0は恥ずかしいくらいで良い」って言ってます。もうまさに世の中MVP万歳！みたいな空気になってるけど、果たしてそうなんでしょうか。

これだけMVPの良さや事例を書いてきたのですが、僕個人としてはMVPの考えに対して半分賛成、半分懐疑的に受け止めています。どうしてかという理由は2つあって、1つはMVPでダメだったからといって諦めるべきなのかと、MVPでうまくいったら本当にうまくいくかどうか、です。

MVPでダメだったからといって諦める理由になり得ないという点から話していきましょう。ランディングページを出した時点では、そんなに人を集められることができなくても、実際にアプリを出してみたら、バズって多くの人に使ってもらえることになったというのもなくはないのではないでしょうか。

例えば、フリマもTwitterで事前登録を募集した際にはそんなに良き反応なかったんですけど、えいやで作ってみたら、出して初週から成約したり、多くの開発者の方々に出品をしていただけることになった。もちろん、まだまだ成功といえるには程遠いんですが、事前登録を出した時とは思いもよらぬ結果になったのは事実です。

Bufferや、Dropboxの例は興味深いんですけど、LPのようなものを出す場合にはMVPよりもマーケティング的な要素が強いんじゃないかなとも思っています。ただ、そこから事前登録したユーザーの声とか聞いていくと、だんだん検証が取れていくのかもしれませんが。

もう一つの点が、MVPでうまくいったら本当にうまくいくかどうかという点です。いいね！と、本当にお金払うは全然気持ちが違います。無料だったら使う人や、事前登録だったら登録する人はいても、実際にお金を払ってまで使うという人の属性とは違うと思うのです。1000いいね！をもらって誰もお金を払わないプロダクトよりも、0いいね！で10人の顧客がいる方がうまくいっているように思いませんか？

つまり、この2点に対しての僕なりの答えは、MVPは完成品の延長線上にあるべきということです。もし、ECだったらMVPの段階からモノを売るべきだし、SaaSだったら最初からお金を払って使ってもらうべきだと思います。フリーミアムって考え方はあんまり好きじゃないんですよね。MVPのVは、顧客から実用（Viable）ですが、開発者からすると検証可能（Validatable）っていうことです。

もっとちゃんと考える

ここまでは理論の話でした。コストを最低限に抑えて、いけるかどうかの検証ができるのがMVPです。ですが、顧客からしたら「知らねーよ」って話ってわけです。自分が顧客だったら、不完全なものよりも完全なものを使いたがるだろうし、開発者側のテストに付き合うつもりは毛頭ないのです。だから、MVPの段階からちゃんと顧客の欲しいものを作る必要があります。

ここでいうスケートボードを目指したいですよね。スケートボードを使えば、歩くよりも早く移動できるし、車よりも使い方もシンプルで分かりやすい。もちろん、作るにあたっても車よりずっとコストは削減できる。
MVPは、ちゃんと顧客が使う一番の理由を抑えつつ、それをいかに最低コストで開発できるかを考えて開発することなんですね、多分。

少し自分のことを補足すると、冒頭でコードを書かないってことを書いたのですが、そこは本質ではないので無視しても良いと思ってます。僕も開発者なので、むしろコードを書いた方が早い時の方がMVPを素早く作れたりすることの方が多いですし。だいたい、一週間で作れるかどうかをMVPになり得るかどうかで判断していますね。

おわりに

ちょっと最後無理やりまとめた感もありますが、結構海外には成功したスタートアップの創業者たちが、唸るレベルの記事をたくさん残してくれていて参考になるし、勇気が湧いてきます。そういう記事をたくさんシェアしていこうと思っているのが、世界中のユーザーに愛されるプロダクトを作るオンラインサロン「East Hackers」です。6/24にスタートするので、ぜひ事前登録お待ちしてます！（これはMVP！そして宣伝！！）