「ぼくはね、完璧でないものは、出したくないんですよ！」
「クラウドですから、お客様に使っていただきながら、だんだんパワーアップしていってもよいと思いますよ。」
「いや、完璧でないと、ダメなんですよ！」
完璧なものを出したいのは誰しも同じ気持ちです。完璧主義にしたいものです。
でも、おカネと時間が限られているこの世界では、何かを選んで何かを捨てなければなりません。しかも、その「完璧なもの」がお客様に受け入れられてどんどん売れていくかどうかは、売る前にはなかなかわかりません。むしろ、実際に売ってみなければ確認できない、という考え方がいまのトレンドです。
このジレンマを解決するコンセプトとして「MVP（Minimum Viable Product）」を取り上げます。
MVPとは
「MVP（Minimum Viable Product）」は、「リーンスタートアップ」という手法のなかに位置づけられるコンセプトです。
リーンスタートアップは、「構築→計測→学習」のフィードバックループを高速に回す、という考え方が主軸です。
「MVP」は、このループの中の「構築」プロセスで使います。全体を高速に回すのですから、「構築」をいかに早く短い時間で行うかが、勝負の分かれ目になります。「構築」スピードを上げるには、構想をすべて完璧に表現した製品を作るというよりは、「必要最小限の「構築」をするには？」という真逆の発想になります。
その必要条件は、次の「計測」と「学習」のプロセスが回ることです。「学習」ができれば、その内容を反映した次の「構築」を始めることで、「構築→計測→学習」のフィードバックループが高速に回ることになります。
よって、「計測」と「学習」ができる必要最低限のプロダクトを考えなければなりません。
実用の最小限、一番小さなプロダクトの事例
「MVP（Minimum Viable Product）」とは、直訳すると「実用最小限の製品」となりますが、仮説を検証するための一番小さな製品、と考えることもできます。
「構築」すると言いながらも、「MVP」というコンセプトは「いかにつくらないで仮説を試すか」ということを考えさせます。すべてはスピードアップのためです。
ここでは、「MVP」の有名な事例を２つ紹介します。
１）Dropbox
「Dropbox」はクラウドに自分のファイルを自動的に保存できるサービスとして、全世界に広まりました。創業者がUSBメモリを持ち歩く不便さを解消するために考えた、という話しは有名ですが、これが本当に受け入れられるのか誰にもわかりませんでした。そこでDropbox社がつくった「MVP」は、「いかにもそれっぽく動く動画」でした。
実際の動画がこちらです：
「Dropbox」のサービスを作る前に、「こんな風に動くんだけどほしいかい？」と聞くためのいわば偽の動画を作って公開したのです。これによって、サービスを出す前に、７万ものメールアドレスをゲットしてユーザー数を確保した状態で、サービスが世にでることとなりました。
この考え方は、「クラウドファンディング」に受け継がれているとも言えます。
２）ザッポス
「ザッポス」は日本ではなじみがないかもしれませんが、靴のネット販売で大きくなったサービスです。
「靴ははいてみないと、サイズが合うかどうかわからないので、ネットで買いにくい」という課題を解決しました。つまり、返品を無料にしたのです。たとえば、自分のサイズの前後で３つぐらい送ってもらってはいてみて、合わない２つを送り返します。
これを始めるとき、創業者は、まず、いかにも在庫豊富な靴屋にみえるようなECサイトを作りました。
ネットで注文できる状態を作りましたが、在庫や販売体制はまったく作りませんでした。注文が入ったら、近所の靴屋に自ら買いに行ったのです。いかにもそれっぽいECサイトが、「MVP」だったわけです。
このようにお客様とのコミュニケーションを重ねることで、ニーズが本当にあるのか、これをやったとしたらどういうことが求められるのか、を実地に確認していきました。
「ペーパープロトタイピング」は、紙芝居でMVPを実現
ペーパープロトタイピング動画を作ったり、実際のECサイトを作ったりすることよりも、もっとお手軽な方法も広がっています。その一つが「ペーパープロトタイピング」です。要するに、紙芝居を作ります。
ホームページ・Webサイトをつくるときによく使われる「ワイヤーフレーム」と似ています。
ワイヤーフレーム」は一つ一つの画面設計に対して、合意をとったり承認をとったりするときに使われます。つまり、「ワイヤーフレーム」は設計書と位置づけることが多く、その場合ユーザーには見せません。
これに対して「ペーパープロトタイピング」と言った場合は、実際にユーザーに見せるために作ることが多いです。実際にサービスをつくったときの状態を、手書きの紙芝居で表現して、ユーザーに聞いてみるのです。
この場合、「構築→計測→学習」のフィードバックループは、
- 構築＝紙芝居を作成
- 計測＝ユーザーへのヒアリング、インタビュー
- 学習＝インタビューの結果をどう製品に反映するかを考える
ということになり、実際にプログラムを作る場合に比べると、おそろしく早くフィードバックループが回転します。
こうすることによって、ユーザーの求めていないものを作ってしまうリスクをできる限り避けようとするわけです。
まとめ
「リーン・スタートアップ」の核になるコンセプトとして、「MVP（Minimum Viable Product）」 を紹介し、その事例や実現方法についてコメントしました。
お役に立てば幸いです。
コメント