※2021/6/21 追記更新
「良い事業アイデアを思い付いたんだけど、実際に立ち上げるためには、まず何をすればいいんだろう…？」
ハッカソンやアイデアソンといった言葉も当たり前になり、一昔前から見れば新規事業アイデア創出の需要も機会も増えているけれど、それと同時に、事業アイデアを思い付いてもどう形にしていけばいいのかが分からずに頓挫してしまったり、逆に突っ走って失敗してしまう、という声もよく耳にする。
アイデア創出の「次」に何をすればいいのか、日経新聞社主催『AG/SUM HARVEST』のアクセラレーター・プログラムで講演した内容をもとに、MVP制作のポイントについてまとめてみた。
リーンスタートアップのプロセス
リーンスタートアップとは、まずはアイデアから最低限実用に足る製品（Minimum Viable Product）を作り、顧客の反応を検証しながら改良・軌道修正を行うという、構築（BUILD） - 計測（MEASURE） - 学習（LEARN）の学習サイクルを迅速に繰り返すことによって、無駄を最小限に抑えて成功に近づくというスタートアップ手法。つまり、いかに短期間でたくさん学びを得られるかが勝負になる。
とはいえ、厳密に言えば本当にアイデア出しの「次」にやることは、MVP制作ではない。
多くのスタートアップが、「その課題が本当に存在するのか」や「そのソリューションは本当に課題を解決できるのか」の検証をすっ飛ばしてMVPを作ってしまうが、実はこれがスタートアップが死ぬ原因のひとつ。MVPとはいえ、モノをつくるには当然リソースが必要なのだが、検証をせずに誰も欲しがらないものを作ってしまうのは「最大の無駄」。そして限られたリソースの中で成功のサイクルに乗ることが至上命題のスタートアップにとっては、この「無駄」が致命傷になる。
リーンスタートアップは「成功へのショートカット」ではなく「急がば回れメソッド」であることを肝に銘じ、MVPを作る前に最もリスクの高い要素から順に検証していくことが、本当に無駄のない「LEAN」を実現するポイント。
仮説「検証」のプロセス
では、その仮説検証はどのように進めていくのか。検証する順番は「リスクの大きい順」。
間違っているソリューションの市場を検証しても無意味だし、問題が存在しなかったらそのソリューションも存在しない、という風に逆算していくと、最も大きなリスクとなるのは「顧客と課題」だと分かる。
つまり、「顧客と課題」＞「解決策とサービス・プロダクト」＞「サービス・プロダクトと市場」の順番にひとつずつ検証していく。
仮説「立案」のプロセス
さらにもう一段掘り下げて、検証するべき「仮説」とは何か、その仮説はどうやって立てるのかについて、順を追って考えていく。
STEP 1：顧客と、その顧客の最も重要な課題を選ぶ
上記の通り、まずは最もリスクの大きい「顧客と課題」、本当にその顧客と課題が存在するのか（解決すべき課題なのか）から検証していくので、その事業アイデアの対象として想定している「顧客」と、その顧客が抱えていると想定している課題の中で最も重要だと思う「課題」をひとつ選んで書き出す。
STEP 2：課題の前提条件を洗い出す
次に、その課題の「前提条件」を書き出す。
ここでのポイントは、「課題」と「仮説」は違うものであることを認識すること。なぜなら、「こういうことを課題に感じたことがあるか」と課題をそのまま検証しようとしてしまうと、確かにそれ自体は課題でも、実はそんなことが問題になるシーンはほとんどなかった、ということが起こってしまい、本当の意味で解決すべき課題なのかの検証にならないから。課題をそのまま検証しようとするのではなく、「この前提条件が正しければ、課題は正しい」と言えることを仮説にする。
ここではひとまず粒度は気にせず、思いつく限り、顧客の状況や行動など課題にひもづく前提条件を書き出す。
STEP 3：最も検証が必要な前提条件を洗い出す
前提条件を書き出したら、それらを「インパクトの大／小」「確度の自明／不明」の2軸でマッピングする。
その前提が合っていようが間違っていようが大した影響がないものならば検証する意味はないし、わざわざ検証しなくても分かりきったことならば検証に時間を割く必要はない。つまり、最もインパクトが大きく不明な前提条件＝最もクリティカルな前提条件こそが最も検証すべきもの。
また、こうしてマッピングすると検証しなければならない前提条件は山ほどあることに気付くが、欲張って2つも3つも一気に検証しようとしてはいけない。複数の前提条件を同じ検証の俎上に上げてしまうと、どの前提条件がどう課題にひも付いているのかが分からなくなり、有効な検証ができなくなってしまう。ここでも「急がば回れ」を思い出して、最もクリティカルな前提条件からひとつずつ検証を進めていくことが大切。
STEP 4：検証方法と判断基準を決める
検証方法とはつまり、MVPとして何をつくるのか。MVPの選び方は後述するとして、ここでのポイントは判断基準＝KPIを定めるということ。
ただ、検証で100％の白黒がつくことはないので、「◯◯人以上」「◯◯％以上」といった数値の設定に絶対の正解はない。KPIはあくまで判断材料のひとつなので、何をもってして「検証できた」とするかは「直感」でOK。
これもよくあるスタートアップが陥りやすい罠で、慎重になるあまりユーザテストから抜け出せずに、いつまでたってもきちんとしたプロダクト・サービス開発に入れないままリソースが尽きてしまうことがある。そうなっては元も子もないので、ある程度「アリ」か「ナシ」かの判断ができたなら、だらだら検証を続けるよりさっさと次のステップに移り、サイクルを早く回していくことが大事になる。
こうして検証を繰り返し、その度にアイデアと仮説を修正しながら、「顧客と課題」＞「解決策とサービス・プロダクト」＞「サービス・プロダクトと市場」と検証のフェーズを進めていく。
MVPの例
改めて「MVP」とは何か。MVPとは Minimum Viable Product の略で、「最低限実用に足る製品」などと訳される。
ここでいう「実用に足る」というのは、「仮説検証から学びを得るために過不足がない」という意味。MVPは単なる初期のプロトタイプではなく、最も効率的に学びを得られるプロダクトであること、つまり「検証できること」と「それをつくるのにかかるリソース」のバランスが取れていることが大切。
参考までに、以下にいくつかMPVの例を紹介する。
CASE 1：プロトタイプ（β版）
いわゆる試験やデモ用に作られる実験機。完成版ではないものの、
実際に動作する製品を作り、クローズドβ版などテストユーザに使用してもらいフィードバックを得る。
洗練はされていなくとも実際に動作する製品なので、その分つくるにも比較的大きなリソースが必要になる。
開発の段階としてはローンチに近く、市場投入前の段階で使用するMVP。
主に検証できること
・機能は十分か
・操作性は問題ないか etc.
CASE 2：ペーパープロトタイプ
紙でアプリやサイトを制作する手法。リソースを費やして実際に実装する前に、紙とペンでモックアップを作成することで、事前にフローや仕様の齟齬を確認することができる。
手軽に作れるMVPだが、デザインなどUIの仮説検証に向くため、開発のフェーズとしては比較的後期のプロダクトの作り込みのフェーズで使用することが多い。
主に検証できること
・要素に過不足はないか
・フローや仕様は適切か etc.
CASE 3：プレオーダー
ローンチ前に事前に登録や購入を募る手法で、そのサービス・プロダクトのベネフィットが顧客に響くかや、十分な数の顧客が得られそうかを探ることができる。
ランディングページやメルマガ購読、クラウドファンディングもプレオーダーの有効な手段のひとつ。これは実際にプロダクトができる前に実行できるため、比較的作りやすいMVPだと言える。
主に検証できること
・十分な顧客がプロダクトに興味を示すか
・顧客のプロフィール
・サービスに顧客がお金を払ってくれるか etc.
CASE 4：デモムービー
ローンチ前に出すサービス紹介ビデオのこと。Dropboxは3分間のデモムービーを作り、Dropboxを実際に利用する流れを見せることで、顧客にどのような価値が得られるのかを想像させて事前登録を募り、ユーザー数を5,000人から75,000人へと大幅に増加させた。
これもサービスアイデアが固まった比較的初期の段階で実行できるMVPのひとつ。プレオーダーと併用も。
主に検証できること
・十分な顧客がプロダクトに興味を示すか etc.
CASE 5：オズの魔法使い型
システム化されているように見えるが、実際は人間が手動で実行することで、大掛かりなシステム開発の前にニーズを確かめる手法。
靴通販の「Zappos」も、当初は注文が来たときに創業者が自ら商品を買いに行って発送を行い、需要を確かめた後に本格的なシステムを構築した。
裏側のシステムはできていなくとも、表向きは完成版のように見えるものなので、これも比較的制作にリソースが求められる。
主に検証できること
・ソリューションは課題を解決できるか
・サービスに顧客がお金を払ってくれるか etc.
CASE 6：コンシェルジュ型
「オズの魔法使い」が裏側のシステム部分だけ人力で行う手法だとしたら、こちらは製品を開発する前に、全てを人力のマニュアルで実行し、需要があるかを検証する方法。
近所のセール情報と食の好みから献立を考えてくれるサービス「Foodonthetable.com」は、Webサイトを立ち上げる前に、自分で直接スーパーで主婦に声をかけ、サービス内容を訪問して提供して直接フィードバックをもらって成功につなげた。
ほとんどリソースをかけることなく、サービス価値を検証できるので、価値検証がしたいなら、まずはコンシェルジュ型の採用を検討してみるのがおすすめ。
主に検証できること
・ソリューションは課題を解決できるか
・サービスに顧客がお金を払ってくれるか etc.
（番外編）SFプロトタイピング
SFプロトタイピングとは、SFの力で未来を想像し、そこからバックキャスティングして今なにをすべきかを考えるための手法。
具体的なシーンをストーリーで描くという点では、ストーリーボードに近いところもあるが、バックキャスティングすることで現状の延長に囚われない発想ができる点、物語の中に没入することで解像度高くその未来を想像できる点が特長だと感じる。
SFを描くということは、ひとつの世界とルールを構築する作業であり、SFの中にアイデアを配置する際には、必然的にその世界のルールとの整合性を取ることになる。その思考プロセスによって、現実世界に置き換えた際にも通じるある種の実装シミュレーションができる可能性がある。
「プロトタイピング」という名前は付いているが、どちらかというとMVPではなくアイディエーションのフェーズで有効な手法。
適切なMVPを設計するには
きちんと学びを得られるMVPをつくるには、今一度リーンスタートアップのプロセスを理解する必要がある。
当然、実証していく際にはBuild → Measure → Learnという流れになるが、検証方法を考える際は、逆算してLearn → Measure → Build の順に考えていく。
つまり、仮説から何を学びたいのか（Learn）を起点として、そのためにはどんな方法で何を測ればいいのか（Measure）、そしてそのためには何を作ればいいのか（Build）、というプロセスで考える。
表層的にリーンスタートアップの実証サイクルだけを見てしまうと、Ideasの次、つまりMVPとして何を作るべきか（Build）からいきなりスタートしてしまいがちだが、「MVPは単なる初期のプロトタイプ」ではなく「最も効率的に学びを得られるプロダクト」なので、後ろから逆算して「何を学びたいのか」から始める必要がある。そうすることで「MVPをつくってみたが良かったのか悪かったのかよく分からない」といった失敗を防ぐことができる。
いきなりMVPをつくろうとせず、適切なMVPの形は「学び」からの逆算で決まることを意識するのが大切。
MVPキャンバス
「MVPキャンバス」とは、AppSociallyの高橋氏とRecruit MTLが共同で開発したもので、最適なMVPを設計するために、リーンスタートアップの思考プロセスを一枚のキャンバスにまとめたもの。
思考の順に項目を埋めていくことで、どこにフォーカスすべきなのかそれぞれのポイントが整理され、効率的にMVPの制作と学びのサイクルを回すことができる。
ここではより最低限の項目に絞って簡易化したものを紹介する。
1：検証したい仮説は何か
そのサービス・プロダクトの中で最もクリティカルな仮説（前提条件）を記入する。
2：何を学ぶのか
この仮説検証をする理由、知りたい結果を記入する。
あらかじめ明文化しておくことで、仮説のピボットなど次のアクションが考えやすくなる。
3：仮説をどうやって検証するのか
どのように検証すれば、知りたいことが学べるのかを具体的に記入する。
複数検証方法がある場合は、それぞれでキャンバスを作成する。
4：実証に必要なデータ・条件は何か
仮説実証のためにどのような条件や定量データが必要なのか（KPI）を記入する。
実証結果がOKなのかNGなのかの判断基準。
5：MVPとして何をつくるのか
3・4を踏まえ、MVPとして何をつくる必要があるのかを記入する。
その際、MVPをつくるのにかかるリソースも考え、MVPを選ぶ材料にする。
6：検証結果
KPIに照らし合わせてどうだったのか、実証できたのかできなかったのか、得られた検証結果を記入する。
7：得た学び
結果から何を学べて、次のステップにどう活かすことができるのか、次のアクションを記入する。
まとめ
ここまでを振り返って、大事なポイントをまとめてみる。
リーンスタートアップは「急がば回れ」メソッド。検証すべき仮説を順番につぶしていくのが大切。
仮説を検証する順番は「リスクの大きい順」、「顧客と課題」から始める。
「課題」と「仮説」は違う。「この前提条件が正しければ、課題は正しい」と言えることを仮説にする。
課題検証はひとつずつ。最もインパクトが大きく不明な前提条件＝最もクリティカルな前提条件を選ぶ。
KPIはあくまで判断材料。直感で「OK / NG」の確信が得られれば十分。
MVPは単なる初期のプロトタイプではない。仮説検証のためのプロダクト。
MVPは「検証できること」と「それをつくるのにかかるリソース」のバランスが取れていることが大切。
いきなりMVPはつくらない。適切なMVPの形は「学び」からの逆算で決まる。
ここまで、フレームワークや事例を交えてMVP制作のポイントを紹介してきたが、実はその実行を妨げる一番の要因は自分の「無意識」や「気持ち」だったりする。
MVPをつくってスタートアップを立ち上げようとしているということは、それだけ良い事業アイデアだと心から思っているからこそ。ただ、その思い入れが強ければ強いほど、無意識のうちに否定される恐れのある検証を避け、「幻のニーズ」を誘導して自分のアイデアに「幻の裏打ち」を与えてしまうリスクをはらむことになる。
リーンスタートアップは、「早く成功するために、早く失敗して、早く学びを得る」考え方。逆に言えば、最初のアイデアは「失敗する前提」。あまり最初のアイデアに固執しすぎずに、アウトプットの質は「何回修正できたか」が規定すると考え、早くたくさん失敗して、たくさん学びを得たほうが良い。
アイデアに「これはいける！」という手応えがあればあるほど、自分に都合のいい検証結果を導いてしまわないように、自分自身がドライに「このアイデアは自分だけの思い込みじゃないか？」と疑って顧客の心の声に真摯に耳を傾けることが大切になる。
もちろん、顧客からのフィードバックを学びとして反映していくにつれて、最初の事業アイデアとは違うソリューションやビジネスモデルに変わっていくことになるが、それはその分だけ正しい方向に進めているということ。もし、ピボットしたアイデアの形に「これは自分が作りたいものじゃない」と感じてしまったら、それは厳しいけれど「ただ自分が作りたいものを作りたいだけ」だったのかもしれない。
アイデアの形は最初に思い描いたものと違ったとしても、それが解決したい課題や実現したい世界、自分のビジョンに合っているものであったら、きっと最初のアイデアと同じように情熱を傾けられるはず。
自分が心から情熱を燃やせるビジョンを大切に、一歩ずつでも確かに「正しい」方向へ進んでいくこと。それが何よりの成功の近道なんだと思う。