先月から、STANDARDに参画いたしました、デザイナーの川地 真史と申します。初めてのブログ執筆ということで、まずご挨拶させていただければと思います。実は元々、学生時代にSTANDARDにてインターン生として学んでいた身でした。その縁もありこの度、再び「未来の豊かさにつながる仕組みをデザインする」ために参画することにいたしました。このブログにおいては、私からしたら”書く”という行為、皆様からしたら”読む”という行為を通して良い体験価値を届けられたらと思います。よろしくお願いいたします。

リーンスタートアップの仮説検証

新しいサービスを立ち上げる際に不確実性の高い中で答えを探し求めるとき、リーンスタートアップという概念はとても強力な助けとなります。この2,3年で広く浸透し、多くの企業が実践に取り入れていることかと思います。リーンの概念を一言で表すと、最小リソースで、最大限の顧客に対する学びを得ることです。そのためには、Build – Measure – Learnのフィードバック・ループをいかに上手く回すことで学びを得るのか、が肝になってきます。

しかし、その理論自体は理解していても、実践では上手くいかないことをよく伺います。例えば、MVPとして何をつくればいいのか、仮説を立てたがどう検証して次に活かせばいいのか、と悩んだことはないでしょうか。

私自身、過去にリーンスタートアップのループに則りながら、MVPを作って仮説検証を試みたが結局なにも学べなかった、という苦い失敗がありました。やはりいざ実践の場にたってみると、簡単には思うようにいきません。では、どのようにこのフィードバック・ループを回して適切な学びを得られる仮説検証が行えるのでしょう。

MVPキャンバスとは？

この問題を解決するために、今回の記事では、MVPキャンバスという仮説検証に役立つフレームと、その思考プロセスを紹介します。MVPキャンバスは、もともと、AppSociallyの高橋氏とRecruitのMTLが共同で開発したもので、一言で言えば「仮説を元に何を学び、そのために何を作るのか」の具体化を手助けしてくれるフレームです。

初期段階では、リーンキャンバスを利用することでビジネスの全体像が把握できるようになり、リスクの高い仮説を想定しやすくなります(こちらは是非Running Leanをご参照ください)。しかし、いざ検証すべき仮説を決定したあとにMVPを構築する際、どうすれば良いのか不明瞭な状態のままです。

このMVPキャンバスを用いて項目を埋めていけば、今何を学ぶ必要があって、そのためにどういう方法を取り、何を作ればいいのか？作ったものをどう評価すればその仮説が正しいと言えるのか？という点が整理されます。それにより、チーム全員の共通認識を形成しやすくなったり、注力する点が明確なので無駄を省き、効率的に開発を進めることが可能となります。

MVPキャンバスの書き方

では、実際にキャンバスを見ていきましょう。キャンバスは以下のように、全部で10の項目から成り立っています(オジリナルのものから少し項目をカスタマイズしたものを使用しております)。また、実際のシートと照らしあわせながら学べるよう、こちらにキャンバスのスプレッドシートを作成しましたので是非お試しください！

1. 仮説：構想中のビジネスの中で最もリスクの高い仮説を記述します。既存サービスの改善であれば、KPIに対して、検証にかかるコストと改善へのインパクトの2軸でマトリクスを作り、優先順位をつけることでどの仮説から取り組むべきか意思決定がしやすくなります。
2. 何を学ぶのか：この仮説検証をする理由であり、最終結果ともなるものです。何を学びたいのかを予めチームで明文化しておくことで、検証後に、新たな仮説が見えたり、行うべきアクションが明瞭になり前へと進めます。
3. どう検証するのか：どのように検証すれば、知りたいことが学べるのかを具体的に記述します。複数のアイデアが出た場合はアイデアごとにキャンバスを作成して比較することもあります。
4. 仮説実証に必要なデータや条件：仮説実証のためには、どのような条件や定量データが必要なのかを考えて、指標設定します。これがないと検証を行ってもその仮説を適切に評価できなくなります。
5. 何を作るのか：3、4で考えた方法から、MVPとして何を作る必要があるのかを記入します。検証方法から、作るものに落とすという流れがポイントです。
6. MVP構築に必要なコスト：どのくらいの期間やリソースを要するのかを目安で記載します。MVP案が複数ある場合は、ここに記載されているコストに対しての学びの大きさを比較して選定することもあります。
7. 実証に必要なコスト：どのくらいの期間を実証に要するのかを目安で記載します。
8. 回避できる/発生するリスクの条件：この検証方法にて回避できるリスクや、逆に発生すると想定できるリスクを記入します。複数の検証アイデアがあれば、このリスクをふまえて比較することもあります。
9. 結果：検証結果を簡潔に記入します
10. 得た学び：結果から何を学べて、それは次のステップにどう活かすことが出来るのかを記入します。

項目としては上記の10つとなりますが、ただこの項目を埋めればいいわけではなく、MVPキャンバスを利用し、学びを得るための仮説検証を設計するには何より思考のプロセスが重要となります。

というのも、実証していく際にはリーンスタートアップのBuild – Measure – Learnという流れになるのですが、検証方法を考えるにあたっては、逆算してLearn – Measure – Build の順に考えていくことになります。理由としては、先にも述べたように仮説検証をするのは、目の前の不確実なものを確かなものにしていくためであり、そのために必要なのは発見や学びだからです。

つまり、仮説から何を学びたいのか？(Learn)というのが1番の軸にあり、そのためにどのような方法で、何を測れば知ることができ(Measure)、そのためには何を作ればいいのか(Build)？という思考プロセスが必要です。リーンのサイクルでありがちな失敗が、MVPとして何を作るべきか？というBuildをスタートとしてしまうことです。ここから始めてしまうと、MVP中心の議論に陥ります。しかし、この文脈での最小限とは、何に対する最小限でしょうか？その判断基準はどこにあるのでしょうか？MVPとは何を作れば良いのかを教えてくれる、学びをもたらすものであり、作るべきプロダクトそのものではありません。ですので、MVPにおける必要最小限とは、学びを得るために必要最小限なものとなるべきです。

何を学びたいのか？から始めることで、それをゴールかつ中軸に据えることができるので、結果として何を学んだのかわからないといった仮説検証における失敗を防ぐことができます。それでは、実際の事例を交えながら思考プロセスとMVPキャンバスの使い方を説明していきます。

Dropboxの仮説検証とMVP事例

今回は、有名なDropboxのMVP事例をとって、キャンバスを埋めていきたいと思います。ご存知の通り、Dropboxはオンライン上でファイルの保存や共有、同期をとても簡単行うことができ、様々な媒体からもアクセス可能なストレージサービスです。

実は立ち上げ当時はファイル共有のストレージサービスはたくさんあったそうです。しかし、様々な端末からアクセス可能で、シームレスにファイルの共有や同期を自動で行える便利なサービスはありませんでした。市場にまだないものなので、Dropboxの初期アイデアは受け入れられるか分からない仮説にしかすぎません。
当時、CEOのDrew Houstonはストレージサービスを利用している顧客に既存の代替品についてインタビューをしていましたが、多くの人が現状に満足していませんでした。しかし、もしこのままアイデアを信じ込み、立派な完成品を作ったとしても、全く顧客に求められないということは大いにありえます。なので、「多くの競合があるなかで、本当に人々は利用してくれるのか」を知る必要がありました。

では、これを知るためにどのような方法が取れそうでしょうか？
重要な点は勿論、必要最低限のコストで効率よく学びを得ることです。

Dropboxの場合、自動同期かつ様々な端末からのアクセスが可能、という技術的な側面がソリューションの核となっているので、MVPとしてソフトウェアの形でこの機能を再現したプロトタイプを作ることは、コストが非常にかかると想定され素早い検証ができません。

では定性インタビューはどうでしょう。かかるコストとしては抑えられそうですが、このアイデアの必要性を実際に体験してもらわずにインタビューだけで検証が出来そうでしょうか？私たちは普段、自分が抱える問題に気づいてもいない場合が多々あります。潜在ニーズを導き出すためにデプスインタビューという手法を取ることもありますが、ここで学びたいのは「このサービスを本当に利用してくれるのか」です。それを踏まえるとインタビューだけでは、ソリューションが伝わりづらく体験できないという点もあり、適していないと考えられます。

そこで、Dropboxでは検証のための3分間のデモ動画をMVPとして設計しました。この動画では、Dropboxを実際に利用する流れを見せています。これにより、顧客が疑似的な体験を通してどのような価値が得られるのかを想像できるので、「本当に利用してくれるのか？」という問いに対して反応を伺うことができ、適切な判断に繋がります。そして動画と一緒に事前利用登録のためのフォームを載せた簡易的なLPを作成し、ハッカーニュースというメディアに投稿して反応を待つことにしました。

検証方法と並行して考えるべき重要な要素は、どうしたら仮説が確からしいと言えるのか？という測定指標です。これがなければ最終的に評価ができず学びにつながりません。Dropboxは、動画とともに登録フォームをLPにて用意しました。実際の評価がどのような基準で行われたのかはわかりませんが、今回の例では、「閲覧回数」と「閲覧した人数における登録者の割合」と指標を置きます。実際に動画を見ただけでは、興味の度合いは測ることができますが、利用に対する意思確認はまだ不十分です。故に、2つ置くことで興味を持った人のうち、どのくらいが実際に利用してくれそうかを正確に測定することが可能となります。

こうみると先に述べた、LPをハッカーニュースに投稿する方法は、とても有用なアプローチです。Running Leanにも述べられているように、スタートアップが初期段階にアプローチをかけるべきは、アーリーアダプターであり、ハッカーニュースという場所は情報感度の高い理想の層が集まりそうな場所です。ここに投稿することで、より多くの潜在顧客層にリーチしやすく、より素早い検証が可能になります。

ここまでの、仮説・何を学ぶのか・どう実証するのか・どういうデータで判断するのか、が特に大事な項目となります。また、その他にもこのMVP構築に掛かりそうなコストや、実証にかかる時間、回避できるリスクなどを記入しておくことで、複数のMVP案を比較して最適な案を選びやすくなります。

このような検証方法の設計を経て、実際にMVPを構築し(Build)、結果を測定しました(Measure)そして最終的に結果として、一晩で75,000人もの人が多くの要望コメントとともに登録したことで、最初に掲げた仮説の妥当性が分かり(Learn)、アイデアに確信をもって実際の開発に取り掛かっていくことができるようになります。

また、もしここで登録者リストが思うように集まらなかったなど指標を満たせなかった場合には、少なくとも現状の仮説は間違っていたことが学べます。その際の次のステップとしては仮説の調整を行います。調整においては、先の検証により得た登録者リストの傾向から何か新しい仮説が立つかもしれませんし、必要なアクションは状況にもよって変わってくるかと思います。

以上が、完全な想像にもとづいてMVPキャンバスを利用し、仮説検証の設計を行った例となります。このように、MVPキャンバスを使えば、学びある仮説検証とMVPを構築する上での整理が容易となります。また、今回はDropboxを例に、新規立ち上げの際の活用について見ていきましたが、既存のサービス改善における仮説検証でも有用性は勿論ありますので活用してみてください。

MVPキャンバスのメリット/デメリット

最後に、リーンスタートアップのプロセスにおいて、MVPキャンバスを使う際のメリットとデメリットをまとめて終わりにしたいと思います。活用する際やチームに導入する際のご参照となればと思います。

メリット

• 仮説をたて、MVPを作り、検証して評価する、という一連の流れにを上手く回すのに必要不可欠な問いかけをしてくれる
• チームの中での仮説検証に対する共通認識を形成し、円滑なコミュニケーションにつながる
• 今何に取り組むべきか、という短期的なアクションを起こしやすくなる
• 検証から学びを得て、次へのアクションへと繋げやすくなる

デメリット・注意事項

• そもそも何を学びたいのか、や仮説の優先順位はあらかじめ明確にしておく必要がある
• 細かい部分回収や、小さなUI改善には適していない。(大きな影響を及ぼすリスクの高いものや、未知な部分が多い仮説に対して検証する際に機能する)

以上、リーンスタートアップの仮説検証に役立つMVPキャンバスを紹介いたしました。STANDARDでは、仮説検証サイクルを回し、新たな発見や学びを得ることで、確度の高い新規サービスの立ち上げ・既存サービスの問題発見や改善を、様々な企業様と一緒になって取り組んでおります。ご興味ある方は、お気軽にお問い合わせください。