リーンスタートアップ is なに
- この本を書いた著者「エリック リース」さんが提唱したスタートアップにおける方法論だよ。
- 書籍の原本が出版されたのは2011年。「検証による学び」を中核とした、当時としては画期的なスタートアップの方法論であり、今も後続のいろんなスタートアップ方法論のベースになったり、比較対象として語られることがあるよ。
- 「スタートアップの方法論」とはいえ、それは立ち上げたばかりの新興企業にだけ効果を絞ったものではないよ。ビジネスの速度が上がった現在では、いまや大企業すら、スタートアップの方法論を活用しているよ。
どんな人が読むべき？
みんな読むといいよ！
というのも、前述の通りいまどきのビジネスはどこもかしこも速度が超はやいから、まともに競合企業とやり合おうとすると、どうしてもスタートアップ的な動きで迅速に価値を提供し続ける必要があるからだよ。
「わたしは純粋なIT技術者だからそういう話はパスで」という人も、読むといいと思うよ。組織文化というのは得てして、全員の理解がないとなかなか前に進まないものだから、組織にいる人みんなが読んで、或る種の共通理解を築き上げるととってもいいと思うよ。
あと、PMPとかPMBOKの勉強をしている人にもおすすめだよ。わたしはこの書籍を読む前にPMPを取得していたけど、「勉強の合間にリーンスタートアップ読んでたらより深い学習ができたな」と思っているよ。『実用最小限の構成 (MVP: Minimum Viable Product) 』の話とか、PMPの試験でも普通に出て来た覚えあるよ。
リーンスタートアップの全体像
リーンスタートアップは、「とにかくやってみよう！」で爆死するたくさんの人たちを救うための方法論だよ。勢いは大切だけど、スタートアップが直面するたくさんの混乱や不確実性と対峙するには、もっと科学的にスタートアップの「やり方」を分析し、いい感じの方法論を創出できるんじゃないかって、著者のエリック氏は思ったみたいだね。
中核にあるのは「検証による学び」
これまでたくさんのスタートアップが、「プロダクトの進捗は途中までいい感じだったはずなのに、なぜか爆死した」という謎事件を起こしてきたよ。
エリック氏はこれについて「そもそものところ、スタートアップにおける進捗のはかりかたが間違ってたんじゃないか」と考えたみたいだよ。
色々考えた結果エリック氏は、「検証による学び」をスタートアップにおける進捗の基準とすべきと考えたよ。
なぜってスタートアップがつくるものは「未知」であり、
- 「誰が顧客かも分からない」
- 「どんな価値があるかも分からない」
という厄介窮まる性質を持っているからだよ！
こういう、なにが価値になるか分からないものをつくるときには、まずは「へー、こんなことが価値になるんだ」という学びを行う必要があるよね。でないと、誤って「誰も望んでいないもの」を作ってしまいかねないからね。
この「へー、こんなことが価値になるんだ」の学びを、スタートアップにおける進捗として捉えているよ。
「検証による学び」の構成要素は3つ
構築、検証、学習。
検証による学びは、この3つのプロセスを何度も反復しながら進めていくよ。
構築はアイデアをもとに製品を生む、
検証は製品をもとにデータを生む、
学習はデータをもとに新たなアイデアを生む。
と、まあこんな風に「検証による学び」がループしていくわけだね。
リーンスタートアップでは、このループ1周にかかる時間を短くしていくことがとっても大切だよ！
ちなみにさっきから学び学びって言ってばかりで具体的なイメージがわかない人もいるかもしれないから例を出すと、学びっていうのは例えば
「自分の代わりに確定申告を済ませてくれるサービスがあったら喜ばれるかな」
「仮想空間でお店を開けるプラットフォームがあれば、使う人はいるのかな」
「使う人がいたとして、何人くらいが有料会員になってくれるかな」
「有料会員になってくれた人は、このサービスのどんなところに価値を感じているのかな」
とかいった感じの "仮説" を、検証の結果
「本当にお客さんはこんなことを望んでいたんだ！」とか
「こんなこと望んでいなくて、本当はこんなところに価値を感じていたんだ」
とかいった "事実" へと変えていくプロセスのことだよ！
まあそんなわけで前提は話せたから、以降さっそくこの「検証による学び」を構成する3要素について、ひとつずつ解説していくよ！
1. 構築
プロダクトをつくるプロセスが「構築」だよ！
とはいえ、ただなにも考えずつくればいいってものじゃないよ。
あくまで目的は "学び" にある。
学びのために必要な「実用最小限の構成」、すなわち MVP (Minimum Viable Product) をつくることが肝要だよ！
なぜって、繰り返しになるけど、スタートアップがつくるものは「未知」であり、どんな顧客がいるのかも、どんな価値があるのかも分からないんだ。
そんな中でたとえば、全力でつくった莫大なコード量のプロダクトの大半が検証の結果「これやっぱりいらない」ってなったら目も当てられないよね？
もっと分かりやすく話そう。スタートアップはよく滑走路に例えられるんだ。滑走路の終わりまでに飛び立てないと、失墜しちゃう。1を学ぶのに、100も200も費やしてはいられないんだ。
そういうわけだから、あんまり大きなものは作るべきじゃないんだ。プロダクトの規模は実用最低限でいいから、ともかくさっさとつくって、お客さんから迅速にフィードバックを獲得したい！ そして必要な学びを得た上で、思い切りスピードをつけて滑走路から離陸したい！
というわけで、構築は「実用最小限の構成（MVP）」であるべきなんだ。
それじゃあ次は、構築の次に行うべき「検証」のプロセスにいくよ。
2. 検証
つくったものをお客さんに見せて、得られた反応について分析するのが「検証」だよ。
こう書くと簡単そうに見えるけど、ここで誤った分析をしてしまうと、とってもひどいことになるよ！ 下手したら失墜一直線だよ！
たとえばだけど、次のうちどっちのプロダクトが将来性あると思う？
- 総ユーザ数1万人のSNS
- 総ユーザ数1,000人のSNS
これだけの情報なら、前者が将来性あるプロダクトだと思うよね。
じゃあこんな情報を付け足したら、どうだろう
- 総ユーザ数1万人であり、直近1ヵ月は毎週50人ずつユーザが増えてるSNS
- 総ユーザ数1,000人であり、直近1ヵ月は毎週200人ずつユーザが増えてるSNS
これなら前者より、後者の方が将来性がありそうって思うよね？ 今はまだ前者に総ユーザ数で負けてるけれど、将来的には前者を追い抜く可能性がある。
この例は直観的に分かり易い話だから、判断を誤ることも少なそうだよね。でも実際に直面するデータや、組織における人の動きはもっと複雑で、この「現時点の総計」と「直近の動き」を見誤ってしまうことがあるの。
たとえば、上記の例にさらに条件を加えてみるね。
- 総ユーザ数1万人であり、直近1ヵ月は毎週50人ずつユーザが増えていて、なおかつ新規ユーザの9割が週に5日以上ログインしているSNS
- 総ユーザ数1,000人であり、直近1ヵ月は毎週200人ずつユーザが増えていて、なおかつ新規ユーザの1割が週に5日以上ログインしているSNS
こうなってくると、次第に判断が難しくなってるよね。正確な判断にはもっとたくさんの情報が必要だけど、ひとまずこれだけの情報で判断するなら、後者はちょっと怪しいかなって思わない？
総ユーザ数もいる。毎週のユーザ増加数もいい感じ。でも週5日ログインする新規ユーザが1割しかいないってことは、新しく入ってくるユーザの大半が「登録したけどあまり使っていない」って状態だって考えられないかな。さらにいえばひょっとして「評判に釣られて登録したけど、思ったより楽しくないな」って思われちゃってたりしないかな？
こんな風に、単なる総数ではいっけん良さそうに見えるプロダクトも、観点を変えれば意外とダメだったりすることがあるんだ。こういうときにちゃんと「ここがやばい」「ここは良い感じ」と適切な分析ができないと、本当は解決すべき課題を見逃したまま突き進んで、あとになって大問題になってしまったりするんだ。
検証を間違えれば、その後の学びも「誤った学び」をしてしまうからね。美味しくないご飯をつくったのに、ご飯を食べた量だけ見て「このレシピめっちゃ美味しかったっぽい！ このレシピもっと極めていこう！」と突き進んだら、そのご飯が余計に不味くなっていく一方だよね。
だから検証は適切に！ **単なる総計じゃなくて、「新規顧客の振る舞い」をしっかり検証することが大切だよ。**古い顧客は必ずしも最新のプロダクトを評価しているとは限らないし、「振る舞い」を計測しないと、見えてこないものがあるからね。
ちなみにこういう**「製品と新しく接する顧客グループの行動」を中核に行う分析手法で「コホート分析」**っていうのがあって、リーンスタートアップではこれを重要視しているよ！ コホート分析の詳しいやり方は、書籍を読んだりぐぐったりして調べてね！ たぶんここでわたしが解説したことは、コホート分析のざっくりした「つかみ」にはなったと思うよ！
これで「検証による学び」を司る二つ目のプロセス「検証」については（まだまだ話せていないことがたくさんあるけれど）ひとまず触りの部分はざっくり話せたね。
次は三つめのプロセス「学習」について話すよ！
※ちなみにここでは書ききれないけど、検証っていうのは本当に難しいプロセスだよ！ なぜってここで話した単なる分析の難しさだけでなくて、人は得てして自分にとって合理的に動くものだからね！
合理的に動くってことはたとえば、「組織の中で自分にとって有利な状況」を生み出すために、あえて誤った検証を行ったり、正確な検証を妨害したりすることだってある、ってことだからね！ スタートアップも組織たるもの常にこういった問題との対峙が必要になるよ！
対峙は大変だけど、これは実は組織の仕組み上の問題だよ！ リーダーやマネージャにとっては頭の痛い話だろうけど、自分の組織を強くしたいならなんとかしないとだよね！
3. 学習
検証結果をもとに、
我々の努力のうち価値を生み出しているのはどの部分で無駄なのはどの部分か
を明らかにするのが「学習」のプロセスだよ！
構築プロセスを開始時点では「こんな価値があるはず」と仮説を立ててMVPを作ったと思うけど、その "仮説" を "事実" にするプロセスだということも出来るかな。
冒頭で**「学習はデータをもとに新たなアイデアを生む」**と話したけどこのアイデアは単に「新しい機能」とは限らないよ！ スタートアップがつくるプロダクトには何度も方向転換が必要になる。当初の想定と異なる顧客をターゲットにしたり、これまでつくっていた製品の一部機能を独立したプロダクトとして拡張したりすることだって、いわゆる「アイデア」のひとつだね。
この「方向転換」って言葉はリーンスタートアップにおいてとても重要な言葉のひとつだよ！ 正確には、リーンスタートアップの書籍の中ではこれを「ピポット」という言葉で表現しているね。純粋に「これまであったものをやめて、違うものをつくる」というわけではなく、ターゲットを一部機能に絞り込んだり、逆に拡張したり、その使い途を応用したりと、純粋な「方向転換」という言葉の意味とは少し異なるニュアンスも含んでいるから、あえて「ピポット」と読んでいるみたいだね！
方向転換はスタートアップでは常に必要な概念だよ！ 成長すれば必要ない、なんてことはない。プロダクトがそれなりに成功して、組織の規模が大きくなったとしてもそれは同じことだね。なぜって自分たちを取り巻くこの世界は、とってもすごい速度で変化していくからね！ 競合は現れるし、顧客はすぐに飽きるし、下手したらすべてを土台から覆すような新たな概念が立ち上がったりするからね！ 常に検証による学びを通して、必要とあらばプロダクトを方向転換していくことが継続的な事業には必要だよ。
とりあえず学習についてはこんなところかな。学習の精度を高めるには、どれだけしっかりと検証できているかがとってもとっても大切だから、検証を疎かにしないようにね！ 繰り返しになるけど、誤った検証による誤った学習は、「誰にも求められていないもの」をつくる原因になってしまうよ！
余談だけど、学習をすっぽかしたまま次の新機能の開発に移るなんてことはもってのほかだよ！ スタートアップにおける進捗は学びであり、学びを得ていないままの開発なんて、自分で掘った穴を自分で埋める仕事みたいなものだよ！ そんなことして後で虚無になったって、誰にも文句なんて言えないからね！
そんなことしないよって笑うかもしれないけれど、実は世の中のたくさんのプロジェクトが「学び」を得るプロセスを無視しているってことが知られているよ！ リーンスタートアップの話から逸れるけど、プロジェクト管理について体系的に知識をまとめた "PMBOK" ってやつの話を少しするね。
PMBOKではプロジェクトの最後行うプロセスを「終結プロセス」と名前をつけて色々やるべきことを定義しているのだけど、その終結プロセスの中のひとつに「教訓登録簿の最終更新」があるよ！ 教訓登録簿とはその名の通りプロジェクトにおける教訓、つまり学びをまとめたものなのだけど、たくさんの人がこの「学びをまとめる」プロセスを無視して次のプロジェクトを始めてしまうよ！
学びは蓄積するもの。とくに組織においては、意図的に学びをまとめて蓄積させようとしないと、あっという間に戦力不足になるよ。個人に依存した学びは、どうしてもスケールアップの枷になってしまうからね。学びは意図的に！
え、解説これだけですか？
そろそろ書くの疲れてきたからね！
でも書籍にはもっともっと正確かつ多角的かつ重厚な情報がたくさん書かれているから、リーンスタートアップについてちゃんと知りたい人は、書籍買おうね！ レイアウト最適化済みのKindle版もあるから、ベッドで横になりながらスマホで読むことだってできるよ！ こういう読み方は片眼視が進むこともあるからあんまり良くないのだけど、楽だし快適だしあったかいよ！
わたしも読んだことしっかり頭に焼き付けたいから、ときどき記事更新すると思うよ！ そのときはTwitterとかで報告するからね！
ちなみにこの記事で書いた「検証による学び」の構成要素「構築」「検証」「学習」の話は、実はリーンスタートアップの基礎のさわりでしかないよ！ 本当に大切なのは、それらの基礎を抑えた上でスピードアップして、組織とプロダクトを成長させていくことだからね！ 大変だけどがんばろうね！
この記事読みたい人っているの？
それはこれから検証するよ！ 検証は早めに行わないと、まさに「誰も望んでいないもの」を計画通りきっちり作り上げて爆死するスタートアップの話と同じになるかもしれないからね。
ところで記事を書くときにはいくつかの価値が想定されていて、
- 書くことで心的イメージを構築して、この記事で書いたことをより深く自分のものにできる
- 第三者が読んでくれることで自分が嬉しい気持ちになる
- リーンスタートアップについて知っている人が増えることで、社会全体の知識の総量がほんのちょっぴり増える
こんな価値があるんじゃないかなーと思っているよ。
これはいわゆる「事実に基づいていない仮説」ってやつだから、これらの価値が真に正しいものと判断して計画を遂行すると、どの価値も満たされずに終わる爆死ルートが有り得るよ。
でも今のところ、唯一「1」だけはちゃんと事実っぽい気がするよ。アウトプットは銀の弾丸じゃないと思ってるから、昨今のとにかくなんでもアウトプットが大切という雰囲気にはちょっと相反する考え方を持っていたりもするのだけど、でもやっぱりある程度の学習効果が記事執筆にはあるという気がしているよ。
とりあえず大切なのは、検証を続けて、得られた学びの上で適宜スポットを行うことだね。この記事も、様子を身ながら方向転換を行っていくはずだよ。