リーンスタートアップの最大の欠点は、リーンスタートアップを知り、書籍を読んでも、実際に何をやればいいのか分からないことです（笑）

リーンスタートアップは「戦略論」なので、「100万ユーザを獲得するまではユーザに課金すべきではない」などといった「戦術」の記載も、顧客開発モデルのようなプロセスもなにもないからです。

 

そこで、どのような立場のアントレプレナーにとっても一発で「何をすべきか？」が理解できる説明を考えていたのですが、もしかしたらというアイディアを思いつきましたのでご紹介します。

 

それは

『仮説ドリブン・スタートアップ』Hypothesis-Driven Startup

『実験ドリブン・スタートアップ』Experiment-Driven Startup

『結果ドリブン・スタートアップ』Result-Driven Startup

という言葉です。

 

ぜひともみなさんには

「リーンスタートアップを実践しようぜ」ではなく

「仮説ドリブンでスタートアップをしようぜ。リーンスタートアップの精神で」

と意思統一して欲しいと思うのです。

 

 

この言葉の意味することは、すべてのスタートアップは「このアイディアは事業化可能か？」という大きな仮説に対して、検証作業を繰り返すことでしか事業を生み出すことができず、決して製品・サービスを作ることが事業開発なのではない、ということをチーム全体に一瞬で知らしめるのです。スタートアップが日々やるべきことは、「証明すべき数々の仮説」に導かれて「実験をタスク化」することなのです。

 

「このアイディアは事業化可能か？」という大きな仮説は、

「そのアイディアによってターゲットするユーザは誰か？」

「そのユーザの課題は何か？」

「その課題に対する現在の代替手段はなにか？」

「現在我々が考えているソリューションは、その代替手段に取って代わるものになるのか？」

「なるとしたらどこからマネタイズすべきか？」

「そのマネタイズ方法はどのような状態になれば成立するのか？」

「マネタイズ可能な状態になった時、ユーザはどのような行動を我々のサービス上でするのか？」

「我々の提供するイノベーションを最も適切に表現できるポジショニングはなにか？」

「提供するソリューションが代替手段に取って代わるものであっても購入をためらう可能性はあるか？」

などと言った「細分化された仮説」の積み重ねでしか証明できません。

 

こうした仮説はすべてのコンタクトポイントで「機能」「デザイン」「ユーザビリティ」に対して「バリューとコストの交換」が成立するかの観点で仮説検証されるため、たとえ小さなサービスでも検証項目は数百項目に上ります。のんびりゆっくりと製品開発をしているヒマなんかまったくないのです。

 

こうした仮説は「アイディア」を絞り出して証明していくのではなく、素早く「実験」する手段をひねり出していくのが、リーンスタートアップを実践しているというスタートアップの毎日の行動です。

 

「リーンスタートアップでやろうぜ！」とチーム内で宣言しても、何をすればいいのかまったく分からないですが、「仮説ドリブンで進めていこうぜ！」と宣言すれば、仮説によって活動が決定され、仮説の証明によってマイルストーンが計測できることが一気にチーム内に浸透します。

 

仮説ドリブンになれば、仮説が1日でも、いや1時間でも早く検証できることが自分たちに必要であることはあっという間に共有できます。

そして、仮説こそが自分たちの行動をすべて決めるのだから、その精度を上げなければ行動の精度がそのまま下がることも分かります。

仮説に対するKPIの設定が曖昧なら、フィードバックループから得られる「学び」の質が低下することももちろん理解できます。

さらに、仮説は細分化して検証したほうがスピードは上がるため、「じゃ１か月後にリリースして見てみましょう」などといった計画の立て方がいかに時間と資源をムダにしているのかが理解できるようになります。

 

“Build-Measure-Learn”のフィードバックループは、

「作ってみた。測定してみた。学んでみた」の順序ではなく、

「いまどの仮説を証明すべきか共有した。その手段はどうするか考えた。どのような結果が出れば証明されたと言うか決定した。さぁ即実行！即測定！即判断！」という順序で、しかも最速、最軽量の手段を繰り返し続けるのです。

 

さて、打合せをしている時間がいかにムダなのか想像できましたでしょうか？

 

チームの方向性をもっと統一したい場合には、ローンチするまでは、製品名・サービス名・プロジェクト名も抽象的なものを止めて、検証すべきビジョンや戦略にするのがオススメです。オシャレなサービス名やプロジェクト名では、チーム内で「いま何を実施すべきなのか」にブレを生じさせます。思い切ってプロジェクト名を「ｘｘ課題を持ったｘｘユーザがｘｘというソリューションを利用することで我々は事業を成立させることができるか？の検証プロジェクト」にしてしまった方が、チーム内で間違えた方向性を向いている人がいなくなります。

 

さすがに長くて呼びにくくなった場合は、正式プロジェクト名を頻繁に確認することを前提に、省略名を決めましょう。

でも他の人にプロジェクト名の由来などを紹介する機会が増えれば増えるほど、チーム内の行動は同じ方向を向いていきますっ！

 

Facebookページにもぜひいらしてください

https://www.facebook.com/LeanStartupJapan