CREATIVE

リーンスタートアップにおけるMVP制作のポイント by Youki Takai

main.jpg

「良い事業アイデアを思い付いたんだけど、実際に立ち上げるためには、まず何をすればいいんだろう…?」

ハッカソンやアイデアソンといった言葉も当たり前になり、一昔前から見れば新規事業アイデア創出の需要も機会も増えているけれど、それと同時に、事業アイデアを思い付いてもどう形にしていけばいいのかが分からずに頓挫してしまったり、逆に突っ走って失敗してしまう、という声もよく耳にする。

アイデア創出の「次」に何をすればいいのか、日経新聞社主催『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:プロトタイプ(β版)

07.jpg

いわゆる試験やデモ用に作られる実験機。完成版ではないものの、実際に動作する製品を作り、クローズドβ版などテストユーザに使用してもらいフィードバックを得る。
洗練はされていなくとも実際に動作する製品なので、その分つくるにも比較的大きなリソースが必要になる。開発の段階としてはローンチに近く、市場投入前の段階で使用するMVP。

CASE 2:オズの魔法使い

08.png

システム化されているように見えるが、実際は生身の人間が手動で実行することで、大掛かりなシステム開発の前にユーザニーズを確かめる手法。
靴通販の「Zappos」も、当初は注文が来たときには創業者が自ら商品を買いに行って発送を行い、サービスの需要を確かめた後に本格的なシステムを構築した。
裏側のシステムはできていなくとも、表向きは完成版のように見えるものなので、これも比較的制作にリソースが求められる。

CASE 3:プレオーダー

09.png

ローンチ前に事前に登録や購入を募る手法で、そのサービス・プロダクトのベネフィットが顧客に響くかや、十分な数の顧客が得られそうかを探ることができる。例えばクラウドファンディングもプレオーダーの有効な手段のひとつ。
これは実際にプロダクトができる前に実行できるため、上の2つに比べるとつくりやすいMVPだと言える。

CASE 4:デモムービー

10.png

ローンチ前に出すサービス紹介ビデオのこと。Dropboxは3分間のデモムービーを作り、Dropboxを実際に利用する流れを見せることで、顧客にどのような価値が得られるのかを想像させて事前登録を募り、ユーザー数を5,000人から75,000人へと大幅に増加させた。
これもサービスアイデアが固まった比較的初期の段階で実行できるMVPのひとつ。

CASE 5:コンシェルジュ

11.png

「オズの魔法使い」が裏側のシステム部分だけ人力で行う手法だとしたら、こちらは製品を開発する前に、全てを人力のマニュアルで実行し、需要があるかを検証する方法。
近所のセール情報と食の好みから献立を考えてくれるサービス「Foodonthetable.com」は、Webサイトを立ち上げる前に、自分で直接スーパーで主婦に声をかけ、サービス内容を訪問して提供して直接フィードバックをもらって成功につなげた。

CASE 6:ペーパープロトタイプ

12.jpg

紙で実際にアプリやサイトを制作する手法。リソースを費やして実際に実装する前に、紙とペンでモックアップを作成することで、事前にフローや仕様の齟齬を確認することができる。
手軽につくれるMVPだが、デザインなどUIの仮説検証に向くため、開発のフェーズとしては比較的後期のプロダクトの作り込みのフェーズで使用することが多い。

適切な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をつくってスタートアップを立ち上げようとしているということは、それだけ良い事業アイデアだと心から思っているからこそ。ただ、その思い入れが強ければ強いほど、無意識のうちに否定される恐れのある検証を避け、「幻のニーズ」を誘導して自分のアイデアに「幻の裏打ち」を与えてしまうリスクをはらむことになる。

リーンスタートアップは、「早く成功するために、早く失敗して、早く学びを得る」考え方。逆に言えば、最初のアイデアは「失敗する前提」。あまり最初のアイデアに固執しすぎずに、アウトプットの質は「何回修正できたか」が規定すると考え、早くたくさん失敗して、たくさん学びを得たほうが良い。
アイデアに「これはいける!」という手応えがあればあるほど、自分に都合のいい検証結果を導いてしまわないように、自分自身がドライに「このアイデアは自分だけの思い込みじゃないか?」と疑って顧客の心の声に真摯に耳を傾けることが大切になる。

もちろん、顧客からのフィードバックを学びとして反映していくにつれて、最初の事業アイデアとは違うソリューションやビジネスモデルに変わっていくことになるが、それはその分だけ正しい方向に進めているということ。もし、ピボットしたアイデアの形に「これは自分が作りたいものじゃない」と感じてしまったら、それは厳しいけれど「ただ自分が作りたいものを作りたいだけ」だったのかもしれない。
アイデアの形は最初に思い描いたものと違ったとしても、それが解決したい課題や実現したい世界、自分のビジョンに合っているものであったら、きっと最初のアイデアと同じように情熱を傾けられるはず。
自分が心から情熱を燃やせるビジョンを大切に、一歩ずつでも確かに「正しい」方向へ進んでいくこと。それが何よりの成功の近道なんだと思う。


未知の領域に挑み続けるクリエイティブディレクター:高井 勇輝 ロフトワークディレクター分解シリーズ Vol.5 by Youki Takai

main.jpg

ロフトワークのディレクターを一人ひとり紹介するコーナー、ディレクター分解シリーズ。

今回は入社して間もなく大プロジェクトに抜擢され、全く未体験の領域にも関わらず見事やり遂げた高井が登場。若手ながらバランスが良く安定感があり、周囲からの信頼も厚い今後の進化が楽しみなディレクターです。
(聞き手:PR石川)

ー前職は何をされていましたか?

インターネット広告会社に新卒で入社し、アカウントプランナーとして、不動産や化粧品、健康食品、ゲームコンテンツ等、幅広い業種のクライアントを相手に提案からディレクション、そして運用まで一連して担当していました。スピード感あるベンチャー気質の会社で、プッシュ営業もやりましたし、代理店、メディア、クライアントと、様々なステークホルダーに囲まれて仕事をしてたので鍛えられましたね。
クライアントとメディアの間に立って調整しながらプロモーションプランを実施していくのは、今のロフトワークでやっているディレクションに共通するものがあると思っています。

ーどういう案件が得意ですか?今までどのような案件に関わってきましたか?

2012年11月に入社したので、ロフトワークに来てちょうど1年半(インタビュー時)、Webサイトリニューアルやコンテンツ案件も担当してきましたが、他にも新規自社サービスの立ち上げとか、空間ディレクションや、新しいCMS導入など、ロフトワークのディレクターの中でもかなり幅広く関わっている方だと思います。結果的にまだ誰もやったことないような新しいタイプのプロジェクトが多いかもしれません。
ちなみに、ロフトワークに入社するまでWebのディレクションはほとんど経験がありませんでした。HTMLは知っているけど書いたことはない、Photoshopなどのデザインツールは多少触ったことがある程度で、制作系の知識は充分とは言えませんでした。

ー柏の葉のオープンイノベーションラボ「KOIL」が4月にオープンしました。高井さんはこのプロジェクトにずっと関わっていたそうですね?

01.jpg

三井不動産のイノベーションセンター「KOIL(Kashiwa-no-ha Open Innovation Lab.)」プロジェクトにおいて、ロフトワークはコンセプトの提案から空間デザイン、会員システム、Webサイトまで幅広くクリエイティブ全般をサポートしてきました。

KOILは、電磁石の「コイル」をイメージしていて、「磁場」となっていろんな人が集まり、場所や僕らが触媒となって、いろんな人が交わって刺激しあって、イノベーションが起こるエネルギーが生まれる場所にしたいという思いから名付けられています。

僕は入社1ヶ月後にこの大きなプロジェクトに携わることになったのですが、担当したのは結果的に非常に多岐に渡っていて、空間ディレクションから、会員管理システム構築、映像音響設備プランニング、プロトタイピング機器プランニング、インターネット環境プランニングから、気付けば最終的には運営計画の部分含めて全体に関わっていました。

成瀬猪熊建築設計事務所が空間設計を担当し、バッタネイションの岩沢兄弟とも一緒に家具の設計をしたのですが、自分で空間のコンセプトを決めてぐいぐい推し進めるというよりは、僕は運営側からの必要な視点でのフィードバック、逆に建築現場からの意見を運営側にフィードバックしたり、全体を俯瞰して、要望をそれぞれのプロフェッショナルに上手に伝えて間をつなぎ、彼らに十分に力を発揮してもらえるようにすることを心がけました。

インターネット環境プランニングでは、どのWiFiルーターをいくつ・どの構成で置くか検討したり、また「KOIL FACTORY」に設置する、レーザーカッター、3Dプリンター、3Dスキャナー、3Dモデラー、その他工具一式といったデジタルファブリケーション機器や、KOIL全体の映像・音響機器のディレクションと調達も行いました。
もちろん、僕はこれらの分野のプロフェッショナルでは全然なかったので、それぞれの専門家とコラボレーションしながら、手探りながらもプロジェクトを進めてきました。

また会員管理システムの構築に関してはメインでディレクションとプロジェクトマネジメントを行っています。 会員情報のDB、申し込み機能から課金システム、予約システムなどと連携が可能なパッケージを検討し、Bplatsを導入しています。施設予約システムに関してはリザーブリンクを採用しました。

ー同じプロジェクトでも本当に多岐に渡る案件に携わってたんですね…。なんというか、全体俯瞰できて、フットワーク軽くて、気が回る高井君だからこそ、役割を果たせたんじゃないかと思えてきました

はい、どこからどうボールが転がってくるか分からないから、とにかくレシーブしまくった感じです。
大小含め、タスク量はすごく多かったですね。
プロジェクトマネジメントともディレクションとも違う、例えて言うならサッカーの「ボランチ」みたいなイメージで、フットワーク軽くセカンドボールを拾って、適切な相手に展開してプロジェクトがスタックしてしまわないように前進させることを意識しました。
例えばなかなか捕まらない代表の諏訪と林を捕まえて意思決定の場を整えるとか。
とにかく、来たボールをしっかり展開して、彼ら(設計する人間やコンセプトを決める人間)のアシストをすることに集中しました。

ー言い方は良くないですが、「最強の雑用係」だったんですね!

02.jpg

はい、まさにそんな感じです(笑)

ーでもフォロー力と処理能力が高くないと務まりませんからね。スーパーマルチプレイヤーということにしておきましょう!
…苦労話とかありますか?

この規模の「イノベーションセンター」をつくったのは日本初で、誰も見たことのない正解を知らないものを創らなきゃいけない中、建築とか空間とかシステムとか、全部ほぼ未経験の中、初めてのことだらけで全部手探りの大変さは当然ありました。 担当クリエイティブディレクターとしてこの大きなプロジェクトに関わっているというプレッシャーは常にありました。
これだけの規模のプロジェクトとなると、ステークホルダーも多く、皆頭のなかに描いている画が微妙に違うのは仕方がありません。
その中でひとつずつ合意形成していくのも大変でした。でもだからこそ、相対するのではなく、みんなで同じ目標や課題を見据えて進めることができたという面もあって、クライアントと同じ方向をみて進められたところは良かったと思います。
あとは発注が来なくて動けないとか…そういった苦労は、往々にしてありましたね(笑)。

ー話変わって、これから伸ばしていきたいスキルはなんですか?

新しいサービスをつくってみたいと前からずっと思っています。
KOILではプロジェクトを描くというよりは推進していくという役割だった反面、今後はもっとコンセプトメイキングなどができるようになりたいです。価値ある「0→1」を描き「1→10」を着実に積めるのが本当のクリエイティブディレクターだと考えていて、リーン・スタートアップやグロースハックのスキルもそのために要るものだと思っています。

なので、クリエイティブディレクターという肩書きは重いですが誇りでもあるので、本当の意味での「クリエイティブディレクター」になるべくこれからも頑張ります!

あなたのリーンスタートアップがうまくいかない4つの理由と覚えておくべき3つの心得 by Youki Takai

main_img.jpg

「リーン」って具体的にどうやるの?

耳にすることも多くなり、すっかり定着した感もある「リーンスタートアップ」という言葉。関連記事を読んだり話を聞いたりすれば「おっしゃるとおり!」と納得するけれど、いざ自分でやってみようと思うと、何から始めてどうすれば「リーン」になるのかよく分からない。そこで、リーンスタートアップの手法のひとつ、『Validation Board(バリデーションボード)』を使って実際にやってみました。

02.png

まさに、百聞百見は一験にしかず。実際にやってみて分かったつまずきやすいポイントや、得られた教訓を、気をつけたいポイント4つと、覚えておくべき3つの心得にまとめてみました。

ポイントその1: 実験仮説の立て方

バリデーションボード」とは、仮説→実験→検証のフィードバックサイクルを繰り返しながら製品の精度を高めていく手法です。最初のステップである実験仮説(Assumption)を適切に立てるところで早速難しいと感じるかもしれません。というのも、「こういうことを課題に感じたことありませんか?」と課題仮説をそのまま投げかけてしまったら、「言われてみればそういうこともまああるかな…」と、幻のニーズに誘導してしまうことになるからです。

それでは「本当に解決すべきニーズなのか」を検証できません。課題仮説そのままを実験仮説にするのではなく、「こういう体験があるなら、課題仮説が正しいと言える」ということを実験仮説にすることが大切です。

03.png

ポイントその2: ユーザインタビューの実践

ターゲットとその課題が本当に存在するのか、それを検証する方法のひとつがユーザインタビューです。無意識に答えを誘導してしまわないよう、そしてしっかりユーザの声を引き出すために、ちょっとしたインタビュースキルが必要になります。
まずは、軸となる質問を聞きもらさないためにも、インタビューシートを持参すること。次に、インタビューが終わったらすぐに振り返ってチームで共有できるように、気になったキーワードやコメントなどは随時メモしながら進めることです。
また、あらかじめ用意していた質問項目以外から、いかにユーザの本音や新しい気付きが得られるかも、とても重要なポイントです。思いもよらない言葉から真の課題が見つかることも多いので、なるべく一問一答のぶつ切りのやりとりにならないように、対話形式でキャッチボールしながら、興味深い話をどんどん掘り下げていきます。
そして、1人のインタビューが終わるごとに、都度インタビューのメモをチームで共有して、「ここが気になる」とか「ここはこういう聞き方をした方が引き出せそう」とか、小さなことでもフィードバックして改善していくと、わずかな人数にインタビューする間でもどんどんいいインタビューができるようになっていきます。バッチサイズを小さくして、フィードバックサイクルを早く回すことがリーンスタートアップの肝です。

04.png

インタビュー結果の何をもってして「検証」するかは、「直感」でOKです。もちろん、判断基準としてのKPIを定めておくのも大切ですが、それはあくまで判断材料のひとつ。

ユーザインタビューでは定量的な調査は難しいので、「アリ」か「ナシ」かの判断さえつけば良いのです。ある程度判断ができたなら、だらだらインタビューを続けるより、さっさと次のステップに移りましょう。「そんなこと言ってもそんな簡単に判断できるもの?」と思うかもしれないけど、意外に大丈夫です。実際にユーザに対峙して直接声を聞くことは、想像している以上に雄弁に物事を語ります。

05.png

ポイントその3: MVPの作り方

MVPとは、「Minimum Viable Product」の略で、「検証に必要な最低限の機能を持った製品」という意味です。つまり、「完璧な企画書を作りこむより、とりあえずでもモノという形にしてみよう」ということ。モノを作り始めるとどうしても「いいモノ」にしたくなってしまう気持ちは分かりますが、大切なのは、「1機能・1プロトタイプ・1検証」に絞り込むこと。欲張らずに、重要な仮説から一つずつ着実に検証していくのがポイントです。
MVPの例としては、Webサービスとして作る前に、単機能のサービスを手動(アナログ)で提供してみてユーザのニーズを確かめるやり方(コンシェルジュ型)もあれば、端的にサービスの特長とビジュアルをまとめてティザーサイトを作り、そこへの反応で検証するやり方もあります。他にも、世界観を表したムービーや、プレスリリース、今ならクラウドファンディングのプロジェクトを立ち上げるのもMVPになり得るかもしれません。
リーンスタートアップの基本は、「ユーザから学びを得て修正する」というサイクルです。ブラッシュアップするためには、一度対象から離れて客観視することが必要なので、そのためにも、プロトタイプという形でアウトプットを一度出して客観視することがとても大切なプロセスなのです。

06.png

ポイントその4: 検証実験の設計

MVP(Minimum Viable Product)という形ができると、「さあ、あとはこれを世の中に投げて問うだけだ!」と急ぎたくなる気持ちもやまやまですが、ここでいったんその問い方を考えましょう。

大切なのは、ちゃんと「学びを得られる構造が設計されている」かどうかです。十分な数のデータが集められるのか、集まるデータは検証したいことに合致しているか、次のアクションに移るトリガーは何なのか…。MVPがランディングページやティザーサイトであれば、サイトのアクセス解析から色々なデータを取得することができますが、「データは取ったものの、結局この結果って良いの?悪いの?」とならないように、あらかじめ検証方法を考えておかなくてはいけません。

07.png

適切な比較材料や基準となるKPIがなく、判断のつかないような定量データを取るくらいなら、ユーザの声などの定性データから学びや良し悪しの直感を得られるようにした方がいいこともあります。

08.png

そして、検証できたら早く次のサイクルに移れるように、その後のアクションへのフローまでセットで考えておくことも忘れずに。

09.png

「リーンスタートアップ」は「急がば回れメソッド」

やってみて思ったのは、リーンスタートアップとは「成功」にジャンプできる魔法のショートカットではないということです。最初に僕が漠然と思い描いていたのは、「とにかくさっさと作って、駄目ならさっさとピボットすればいいんでしょ?」というイメージでした。一見近いようにも思えますが、でも正しくは「外せないポイントをちゃんと仮説を立てて考えて、それを検証できるMVPをさっさと作り、駄目なポイントがはっきりしたなら、その学びをもとにさっさとピボットする」ということ。このサイクルを早く回すために、バッチサイズは最小限まで小さくするのです。まどろっこしいからと欲張って一度に複数のことを検証しようとしたり、とりあえず製品を作ってしまおうとすると失敗しがちです。「魔法のショートカット」というより、むしろ、愚直に確かめながら進めるという当たり前のことを一歩ずつ、それをものすごいスピードでやるから早く成功できる、ということなのです。自分の思いつきを過信せずに、確実な一歩を早く積み重ねるというド正攻法を貫くこと、それがリーンスタートアップの本質なのではないでしょうか。
今回の取り組みは実質15回、週一回のペースで3ヶ月間やってみました。ぎゅっと集中して取り組めば、2週間もかけずにここまでのことは充分できます。実際には技術的・権利的なハードルをいくつも超える必要がありますが、少なくともスタートアップを進めるときにはどうすればいいのかが具体的にイメージできたことはとても大な成果でした。

リーンスタートアップ「3つの心得」

これらの体験をもとに、リーンスタートアップを実践するにあたって大切なエッセンスを凝縮して「3つの心得」にまとめてみました。

1.自分の感覚を疑い、ユーザの心の声に従え
2.否定を恐れず、修正回数を誇れ
3.サービスにこだわらず、ビジョンにこだわれ

リーンスタートアップは、「早く成功するために、早く失敗して、早く学びを得る」考え方。早くたくさん失敗して、たくさん学びを得たほうが良い、ということです。つまり、アウトプットの質は「何回修正できたか」が規定するとも考えられます。逆に言えば、最初のアイデアは「失敗する前提」。けれども、実現させようと思ったということは、最初のアイデアにそれなりに「いける!」という手応えを感じているはずです。その思い入れが強ければ強いほど、無意識のうちに否定される恐れのある検証を避け、「幻のニーズ」を誘導して自分のアイデアに「幻の裏打ち」を与えてしまっているかもしれません。誰だって自分の素晴らしいアイデアを否定されるのは怖いと思います。でも、だからこそ、まずは自分自身がドライに「このアイデアは自分だけの思い込みじゃないか?」と疑い、思い込みに隠された本当のニーズを暴こうとする作業が大切なのです。
その結果導き出されたソリューションやビジネスモデルに「これは自分が作りたいものじゃない」と感じてしまったら、それはきっと残念ながら「作りたいものを作りたいだけ」だったのかもしれません。ソリューションの形は最初に思い描いたものと違っても、それが解決したい課題、つまり自分のビジョンに合っているものであったら、きっと最初のアイデアと同じように情熱を傾けられるはずです。
「リーンスタートアップ」とは、それに則れば成功が約束されたマニュアルではなくて、文化やマインドに近いものなんだと思います。逆に言えば、この「心得」さえ忘れずにいれば、きっと、たとえ多少進め方が違ってたとしても、ちゃんと「リーンスタートアップ」ができるはずです。

10.png
 

※今回の実践の全スライドはこちらからご覧いただけます。