リーン・スタートアップの解説をしてみます。
彡(ﾟ)(ﾟ)で学ぶリーン・スタートアップ誕生ストーリーでリーンスタートアップに至る経緯を会話形式のストーリー仕立てで解説します
リーン・スタートアップ解説編で彡(ﾟ)(ﾟ)抜きで普通に解説します
彡(ﾟ)(ﾟ)で学ぶリーン・スタートアップ誕生ストーリー
脚色や私の想像による補完が混ざることはご了承ください。
正確な情報は参考の書籍を読んでください。
顧客開発モデルとの出会い編
2004年
彡(ﾟ)(ﾟ) 「なー、ええやん、投資してぇやー」
彡(ﾟ)(ﾟ) 「次こそ絶対うまくいくから～」
彡(ﾟ)(ﾟ): エリック・リース。後にリーン・スタートアップを提唱する男。
(´・ω・｀) 「えー。君、起業に失敗したところじゃん。」
(´・ω・｀) 「3年も開発してたのにリリースしたら全然売れなかったって。。。」
(´・ω・｀): スティーブ・ブランク。投資家
彡(ﾟ)(ﾟ) 「次のサービスはすごいで! IMVUって言って、3Dアバターを作って仮想世界でみんなで遊ぶんや！」
(´・ω・｀) 「うーん....分かった。投資しよう。」
(´・ω・｀) 「その代わり、条件がある。」
(´・ω・｀) 「やりかたを変えるんだ。僕が提唱している顧客開発モデルを実践するんだ。」
(´・ω・｀) 「大学で講義してるから受講するように。」
彡(-)(-) 「ありがとうございます」(講義？だるいけど金のためや。しゃぁないなぁ)
(´・ω・｀) （むっちゃ嫌そうやなこいつ）
顧客開発モデルは後のリーン・スタートアップのコア理論の1つとなる
カリフォルニア大学にて
(´・ω・｀) 「アメリカの.comバブル1崩壊の原因」
(´・ω・｀) 「それは大してあてにならない市場予測に基づいて投資・拡大を進めたことだ」
(´・ω・｀) 「その結果、誰も欲しがらない製品の開発に膨大な投資をしてしまうことになった。」
(´・ω・｀) 「そもそも新規事業は不確実で正確な予測なんか出来はしない」
(´・ω・｀) 「確実な予測が立つというならそれは新規性がないだけだろう」
(´・ω・｀) 「だからプロトタイプ製品等を通じ、顧客のニーズを予測ではなく発見・実証していくことが重要なんだ」
...
彡(●)(●) 「なんてことや。。スティーブ、なんちゅう理論を編み出したんや！」
彡(●)(●) 「ワイが興味を持っとったアジャイル開発とも相性がよさそうや」
彡(^)(^) 「早速取り入れたろ！」
再びの失敗編
インスタントメッセンジャー連携
彡(ﾟ)(ﾟ) 「インスタントメッセンジャー2めっちゃはやっとるな」
彡(^)(^) 「せや！IMVUにメッセンジャーとの連携機能付けたろ!」
彡(^)(^) 「使い慣れた既存メッセンジャーで遊べるうえ、メッセンジャーで友達を巻き込んでくれるやろう」
彡(^)(^) 「他にもメリット山盛りや。我ながらいいこと思いついたなぁ」
彡(^)(^) 「顧客開発モデルに従って早速開発や！アジャイルで開発進めるでー」
彡(^)(^) 「180日で製品作って金を実際に払う顧客を見つけるのが目標や！」
(＊^◯^) 「殺人的スケジュールなんだ！」
(*^◯^): IMVUのエンジニア。モブキャラ。
180日後
(＊^◯^) 「バグや仕様漏れだらけなんだ！」
彡(-)(-) 「さすがにキツイな。。」
(＊^◯^) 「これを世に出すのは恥なんだ！IMVUの名に傷がつくんだ！リリース延期したほうがいいんだ！」
彡(ﾟ)(ﾟ) 「いや、リリースするんや。」
彡(ﾟ)(ﾟ) 「**悲惨な製品リリースよりもっと悲惨な失敗――それは”誰も欲しがらない製品を作ること”**や。」
彡(-)(-) 「たとえ非難を受けてもフィードバックが早く得られることのほうが大事や」
(＊^◯^) 「謝罪文用意しとくんだ」
リリース後
(＊^◯^) 「そもそも誰もダウンロードしてくれないんだ。。。」
彡(ﾟ)(ﾟ) 「謝罪文の出番はなくてよかったが、何とか製品改良して顧客を増やさんと。。。」
彡(ﾟ)(ﾟ) 「対応するメッセンジャーの数が足らんのかな。増やすか。」
彡(ﾟ)(ﾟ) 「バグも多いから直さんとな」
毎日のように試行錯誤するもほとんど顧客はつかず
彡(ﾟ)(ﾟ) 「あかん。。。目標の売り上げにも全然届かん」
(＊^◯^) 「このままじゃまずいんだ。見込み客にお願いして使ってもらってみて、感想を聞いてみるんだ」
彡(ﾟ)(ﾟ) 「定性分析か。せやな」
見込み客に使わせてみる
(＊^◯^) 「この製品使ってみてください！」
(*ﾟーﾟ) 「あら、おもしろそうですね」
(*ﾟーﾟ) （アバターをカスタマイズして遊ぶ）
(＊^◯^) 「いいアバターですね。じゃあメッセンジャーのアドオンを入れて、友達を招待してみてください」
(*ﾟーﾟ) 「え。。。友達を招待？？」
(*ﾟーﾟ) 「絶対イヤ！」
(;^◯^) 「ど、どうしてですか？」
(*ﾟーﾟ) 「これがクールかまだよくわかんないし。。」
(*ﾟーﾟ) 「これが変だったら、友達に見せた私まで変に思われちゃう。そんなの無理！」
彡;(ﾟ)(ﾟ) 「こ、この人はたまたまやろ。きっと次はうまくいく」
しかし、何度やっても、他の人も同じ結果でした。
彡;(ﾟ)(ﾟ) 「シングルプレイヤーモードで遊び倒させたら、クールと分かって友達呼んでくれるんちゃうかな」
(＊^◯^) 「シングルプレイヤーモードなんて機能ないんだ」
彡(^)(^) 「作るんやで、これから。」
しかし、見込み客の反応は変わりませんでした。
彡(●)(●) 「やけくそや！IMVU内ユーザーとランダムに知り合う機能作って、その知り合い管理にメッセンジャー使わせたれ」
彡(●)(●) 「メッセンジャー使いだしたらそのうち友達呼び込むやろう」
やっと、見込み顧客の反応が変わりだしました。
ξﾟ⊿ﾟ)ξ 「このランダムにユーザーと知り合える機能面白いわね」
(＊^◯^) 「よかった！」
ξﾟ⊿ﾟ)ξ 「あ、今知り合った人よかったな。メンバーリストを作って登録しといたりできます？」
彡(^)(^) 「すでにお持ちのインスタントメッセンジャーに登録できます」
ξﾟ⊿ﾟ)ξ 「え？冗談でしょう。。。？知らない人を今持ってるメッセンジャーに登録しろですって？」
彡;(^)(^) 「ええ。でもそうしないと新しいメッセンジャーにアカウントを登録して。。。という面倒な作業が必要ですよ？」
ξﾟ⊿ﾟ)ξ 「あなたたち、私がいくつインスタントメッセンジャー使ってると思ってるの？」
ξﾟ⊿ﾟ)ξ 「８つよ。別にインスタントメッセンジャーが増えたところで気にしないわ」
彡(●)(●) 「」
(＊^◯^) 「」
振り返り編
彡(●)(●) 「なんてことや。最初に思いついた「使い慣れたメッセンジャーで遊べる」「既存メッセンジャーの友達を巻き込んでくれる」、そんなん完全に的外れやった」
彡(●)(●) 「見込み客は「新しいメッセンジャーなんて気にしない」「既存の友達より新しい友達をIMVU上に求める」」
彡(●)(●) 「最初に思いついたのは完全に間違った先入観やったんや」
彡(；)(；) 「数カ月かけたコードがパーや」
彡(；)(；) 「アジャイルでいくら効率的に作っても、そもそも要らんもん作ってたらそれ以上の無駄はないわ」
(＊^◯^) 「で、でもこの機能を作ったおかげで顧客が本当に求めてたものに出会えたんだ。」
(＊^◯^) 「おかげでIMVUは大成功なんだ！」
彡(；)(；) 「それもそやけど。。」
...
彡(-)(-) （そもそも目的が「顧客を知ること」やったとしたら、こんなに作る必要があったんやろうか？）
彡(-)(-) （顧客について学ぶためだけの、最低限の実装のみ作ったらよかったんちゃうか）
彡(-)(-) （対応メッセンジャー増やすとかは、この考えに基づけばなくせたな。顧客の反応見るには1つあれば十分やった）
彡(-)(-) （機能を作る前に機能の提案だけやって反応を見る、とかすれば実装さえ要らんかったかもな）
彡(-)(-) （勝手な思い込みをしてることに気づけんかったのもあかんかった。）
彡(-)(-) （新規事業で何もわかってない状態なんやから、自分の考えは仮説でしかないと思うべきやったんや）
彡(ﾟ)(ﾟ) (きっと、もっと無駄をなくして新規事業を成功に導く方法があるはずや）
そしてリーン・スタートアップが生まれるのであった
リーン・スタートアップ解説編
もう彡(ﾟ)(ﾟ)は出てきません
リーン・スタートアップが必要となる背景
- 新規事業では「求められる製品」を作ることが非常に難しいです
- 作ったのに誰も欲しがらないという事態がかなり多いです
- ベンチャー失敗理由の上位です
- 作ったのに誰も欲しがらないという事態がかなり多いです
- 新規事業は不確実性が高く、求められる製品を予測することは困難です
- 特に新規事業では、顧客自身も本当に何が欲しいか分かっていないものです
- 「もし顧客に望むものを聞いていたら、『もっと速い馬が欲しい』と答えていただろう。」 by ヘンリー・フォード
- 「人は形にして見せて貰うまで自分は何が欲しいのかわからないものだ。」 by スティーブ・ジョブズ
- 顧客に対して何が欲しいかを、聞くのではなく提示して探る必要があります
- 特に新規事業では、顧客自身も本当に何が欲しいか分かっていないものです
- そのため、試行錯誤しながら何が求められるものなのかを見つけ出す必要があります
- 顧客に対する仮説を立てて、それを検証することになります。
- 一方で、試行錯誤には時間と労力が必要になります
- より多くの試行錯誤を行うには、1つの1つの試行錯誤について、時間と労力を最小化することが必要です
- 「小さな失敗」を大量に繰り返す中で、成功にぶち当たるのです。必ずとは言えませんが、確率は上がります
リーン・スタートアップの概要
-
次のプロセスを高速で繰り返すことで顧客ニーズの発見と製品開発を進めるマネジメントの手法です
0. 仮説立案- 顧客に対する仮説を立てます
- 特に事業の確立に必要な仮説をリーンキャンバス等を用いて立てます
- 構築
- 仮説検証に必要な最小の機能を実装します
- この最小の機能を実装したものをMVP(Minimum viable product)と呼びます
- 仮説検証できればよいので、必ずしも製品開発するとは限りません
- 計測
- アーリーアダプターに製品を提供し、反応を見ます
- 学習
- 計測結果をもとに、仮説の正しさを判断します
-
実施は1→2→3→4と進みますが、計画段階では1→4→3→2の順で検討する必要があります
-
- 仮説立案
-
- 学習の検討
- 何をもって仮説を判断するのか？
-
- 計測の検討
- 4.の判断材料はどのように集められるか
-
- 構築の検討
- 3.の計測は何を構築すれば実現できるか
-
-
実施の速さと労力の小ささが重要です
- 速く・多く仮説検証をするためです
ありがちな勘違い
- リーンスタートアップは起業家のための理論
- 「とりあえずやってみる」
- リーンスタートアップでは否定されているやり方です。
- 仮説が何で、何を計測する必要があって・・・という考慮がないと構築で無駄なものを作ってしまいます
- なんとなく作ったものは何となくの学びしか生みません。それが役立つ学びかどうかも分かりません
- 多くの場合、失敗に対する言い訳にしかなりません
- MVPはバグだらけでいい
- それはケースバイケースです
- 仮説検証ができるのであれば、バグだらけでもいいでしょう
リーンスタートアップに対する批判
-
0to1におけるピーターティールの批判
- 読みましたが、そもそも肯定も否定もしているようには私には見えませんでした
- Quoraに記事があります
-
SNSで悪評が一瞬で広まる今ではもう無理では
- これは一理ある批判だと思います
- しかし、仮説検証は別に製品リリースせずにもできます
- 大事なのは仮説検証することです。不完全な製品をリリースすることではありません
-
検証のための製品を作るコストが無駄なのでは
- トータルで見ると巨大な失敗を減らせる分プラスになるというスタンスです
- とはいえ、コストがかかるのもまた事実です
- 出来るだけ作らないで検証する発想は必要だと思います
エンジニアから見たリーン・スタートアップ
- 製品を作りたい！をぐっとこらえる必要が出てきます
- でも半年かけて作ったコードが全く使われずにゴミ箱に行くよりはましでしょう？
ここまで解説しといてなんですが
私自身はリーンスタートアップの実践に失敗したことしかありません。
いつかちゃんと実践したいなぁ
補足：顧客開発モデルとリーンスタートアップについて
さもMVPや仮説検証のアイディアがエリック・リースの発案のように書きましたが、実際には顧客開発モデルにも含まれていた概念です。
にもかかわらずIMVUの失敗が起きたのは、おそらく理屈で分かっていても実践は難しかった、ということなんだと思います。
顧客開発モデルとリーンスタートアップの違いはかなり難しいもので、私も理解しきれていません。
よく目にするのは、リーンスタートアップ = 顧客開発モデル + アジャイル というものです。
リーン・スタートアップで触れられているが割愛した内容
- 参考を読んでください
- KPIをどのように設定して事業の成長を測るか
- 事業の方向転換（ピボット）の判断
- MVPにどのような種類があるか
- バッチサイズを小さくする必要性
- 成長のエンジン
...等