リーンスタートアップにおける良い仮説、悪い仮説

1. リーンスタートアップにおける良い仮説、悪い仮説 Good Hypothesis, Bad Hypothesis Takaaki Umada / https://medium.com/@tumada/ September 1st, 2015 @ 某社向けクローズド勉強会資料 1

2. このスライドでは、これまでスタートアップの皆さんからの相談を受けてきた経験やプロダクトマネージャー時代の経験から、リーンスタートアップの方法論で用いられる良い仮説と悪い仮説について解説します。クローズドでの社内勉強会のベースの資料のため、一部口頭での補足がないと分かり難い部分があるかもしれません。ご了承ください。左記は今回特に参考にした文献です。 • リーンスタートアップ • Running Lean 実践リーンスタートアップ • カンバンソフトウェア開発の変革タイトルは Ben Horowitz Good Product Manager/Bad Product Manager から。 2 スタートアップの良い仮説検証を実現するために Ben Horowitz Good Product Manager / Bad Product Manager

3. リーンスタートアップ 3

4. リーン生産方式をはじめとした、リーン全般の目指すものはムダの排除。特に Lean Startup では「顧客が欲しがらないものを作る」という最大のムダを極力排除していく必要がある。 Original uploader was Laurensvanlieshout at nl.wikipedia 4 リーンの系譜: 目指すものはムダの排除トヨタ生産方式不確実性が低く、求められる成果物はある程度一定している状況に用いられる。主に工場の生産など。起きうるムダの種類 1. 作り過ぎのムダ 2. 手待ちのムダ 3. 運搬のムダ 4. 加工そのもののムダ 5. 在庫のムダ 6. 動作のムダ 7. 不良をつくるムダ (トヨタ生産方式より) リーンスタートアップリーン生産方式とアジャイルと顧客開発をベースにした方法論。不確実性が高く、求められる成果物がまだ未確定な状況に用いられる。主に新規のプロダクト。起きうるムダの種類 1. 顧客が欲しがっていないものを作るムダリーンソフトウェア開発不確実性が高く、求められる成果物（顧客の要件）が変動しやすい状況に用いられる。起きうるムダの種類 1. 未完成の作業のムダ 2. 余分な機能のムダ 3. 再学習のムダ 4. 引き継ぎのムダ 5. タスク切り替えのムダ 6. 遅れのムダ 7. 欠陥のムダ (リーン開発の本質より) リーン生産方式 (トヨタ生産方式をベースにMIT が体系化。製造工程全体の最適化を狙う)

5. 5 無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄

6. 6 無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄「顧客の欲しがるもの」を最初に探し当てれば、これぐらいの量のムダの削減になるのでは

7. 7 頑張り方を大きく間違えない（間違ったことに効率的にならず、ムダを発生させないために学びの中間目標を達成していく）

8. リーンスタートアップの批判として以下のようなものが挙げられる。 8 リーンスタートアップに対するよくある誤解（誤解 1）リーンスタートアップに則れば成功するリーンスタートアップはムダを極力減らすためのやり方であって、成功を保証するやり方ではありません。ただし「成功するまで生き延び続ければいずれ成功する」と、よく言われている言葉が正しいのであれば、リーンスタートアップはムダを取り除くことでスタートアップが長生きできるようになり、何度もチャレンジできるようになるので、結果的に成功確率は高まるかもしれません。（大企業の新規事業のように、お金ではなく時間の制限が厳しい場合は時間との兼ね合いも考える必要あると思います）（誤解 2）リーンスタートアップに計画は不要リーンスタートアップは、大きなビジョンを小さな機能追加の積み重ねで到達するための方法論です。そのため、リーンスタートアップにも計画は必要です。ただ計画にとらわれず、実験の結果を受け止めて計画を柔軟に変更していくことを重要視しています。もちろん、リーンスタートアップの方法論はどのような製品にも適用できるわけではなく、向き不向きはありますし、適用できるフェーズとそうでないフェーズもあると思います。

9. 9 ムダな努力をしないために少しずつ学びながら進む

10. リーンスタートアップでは実験を繰り返して、学びを得て、自分たちのプロダクトの進む方向を決めていく。 10 効率的に学びを得て意思決定をしていく学び意思決定 • 顧客に課題は（ある程度）あった • 機能 A の MVP は効果があった • 機能 B を作るべきだろうか？ • この顧客にフォーカスして事業を進めるべき！ • 機能 A を作るべき！ • 機能 B は作らずに修正すべき！実験 • 顧客に課題はあるのだろうか？ • 機能 A は作るべきだろうか？ • 機能 B を作るべきだろうか？

11. 実験（仮説検証）の流れ 11

12. 12 スタートアップは何の検証をするのか？

13. 13 ビジネスモデルの検証

14. 既存マーケット、既存チャネルへの新製品開発とは異なり、スタートアップは急速に成長するためのビジネスモデル全体の検証が必要。そのための指針として、幾つかのフレームワークが存在する。 14 スタートアップはビジネスモデル全体の検証をする例 1) Fit ベースの検証どこまでフィットしているかを段階的に検証していく進め方。例 2) Lean Canvas ベースの検証 Lean Canvas に従って検証を進めていくやり方。 ⑦ コスト構造 ① 課題 (既存の代替品) ④ ソリューション ③ 独⾃自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント (Early Adaptor) ⑥ 収益の流流れ ⑧ 主要指標 ⑤ チャネル Customer / Problem Fit Problem / Solution Fit Solution / Product Fit Product / Market Fit • 顧客に切実な課題はあるか？ • 課題は解決できるか？ • 顧客は解決策にお金を払うか? • 解決策はプロダクトになるか? • プロダクトは十分に成長できるか?

15. 15 検証の順番は「リスクの大きい順」

16. 16 スタートアップの最も大きいリスクは？

17. 17 「顧客に課題があるか」

18. Customer/Problem Fit (顧客と課題) から Product/Market Fit に至るまで順々に仮説検証をしていく。検証は顧客と課題から始まる。 18 仮説検証の順番 (例 1): Product/Market Fit BL M Customer / Problem Fit BL M Product / Market Fit BL M Solution / Product Fit BL M Problem / Solution Fit • 顧客に課題はあるか？ • その課題はどの程度重要な課題か？ • そのソリューションで顧客の課題を解決できるか？ • 顧客はソリューションにお金を支払うか？ • プロダクトはソリューションを十分に実現できているか？ • プロダクトとしてスケーラブルか？ • スケーラブルなビジネスモデルを構築できているか？ • 効率的なチャネルは分かっているか？

19. Lean Canvas の順番に従って仮説検証をしていく。こちらも課題と顧客から始まる。 19 仮説検証の順番 (例 2): Lean Canvas ⑦ コスト構造 ① 課題 (既存の代替品) ④ ソリューション ③ 独⾃自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント (Early Adaptor) ⑥ 収益の流流れ ⑧ 主要指標 ⑤ チャネルBL M 1 BL M 2 BL M 3 BL M 4 BL M 5 BL M 6 BL M 7 BL M 8 BL M 9

20. Lean Canvas などは計画した時点で終わり、というものではなく、検証を通して必ず行ったり来たりが発生する。 20 仮説検証の順番 (例 2): Lean Canvas ⑦ コスト構造 ① 課題 ④ ソリューション 1. 2. 3. ③ 独自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント ⑥ 収益の流れ ⑧ 主要指標 ⑤ チャネル ⑦ コスト構造 ① 課題 ④ ソリューション 1. 2. 3. ③ 独自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント ⑥ 収益の流れ ⑧ 主要指標 ⑤ チャネル ⑦ コスト構造 ① 課題 ④ ソリューション 1. 2. 3. ③ 独自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント ⑥ 収益の流れ ⑧ 主要指標 ⑤ チャネル ⑦ コスト構造 ① 課題 ④ ソリューション 1. 2. 3. ③ 独自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント ⑥ 収益の流れ ⑧ 主要指標 ⑤ チャネル ⑦ コスト構造 ① 課題 ④ ソリューション 1. 2. 3. ③ 独自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント ⑥ 収益の流れ ⑧ 主要指標 ⑤ チャネル ⑦ コスト構造 ① 課題 ④ ソリューション 1. 2. 3. ③ 独自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント ⑥ 収益の流れ ⑧ 主要指標 ⑤ チャネル顧客で検証失敗課題で検証失敗 UVP まで検証成功 1st Trial 2nd Trial 3rd Trial

21. 不確実性の高い状況下では地図は役に立たない。顧客というコンパスを頼りにしながら、仮説を作って進みつつ、徐々に確からしさを高めていく。そのためにもまずは顧客を定めることが大事。 21 仮説検証は顧客というコンパスを頼りながら徐々に進む

22. 仮説検証は最初は大きいリスクから検証していき、徐々にその方向を微調整していくほうが効率が良い。 22 最初は大きく、次第に小さくステップを踏んでいく最初は大きく徐々に小さく

23. とはいえ、実際に仮説検証をすると右往左往することがほとんど。 23 実際はカオス

24. 右往左往しているうちに、当初目指している場所とは違う金脈が見つかることもある。それでも基本路線は「最初は大きく、徐々に微調整」が好ましいと思われる。 24 実際はカオス (そもそもゴールが違ったりする) 「B2C で売れるプロダクトではなく、実は B2B 向けでした」など

25. カオスな模索にならないようにするためには、ぶれることのないビジョンを持つことが重要。リーンスタートアップにおいて、戦略はピボット可能であり、製品は最適化していくものと考えられている。「リーンスタートアップ」 p.34 25 ぶれないビジョンを持つことが重要製品ビジョン戦略 • ビジネスモデル • 製品ロードマップ • 予想される顧客最適化（エンジンのチューニング）ピボット

26. 模索が無駄になるかというとそんなことはない。模索を通して得られるものも多い。 26 リーンスタートアップの方法論で模索するメリット内部向けのメリット • 学びが溜まり、それが新しい仮説構築の基礎となる • 行き当たりばったりにならず、（ある程度）計画的かつ効率的に会社の資源を投資できる • チームの方向性を合わせながら進むことができる外部向けのメリット • 投資家やその他協力者への説明責任 (accountability) を果たすことができる • どこまで検証済みかが明確になり、次に外部への協力したいことや依頼も明確になる • 模索を通してアーリーアダプターの拡大が可能になり、次回以降のインタビューなどがラクになる • スケールできずに失敗しても、一人でも顧客を幸せにできれば、その人はあなたの次のチャレンジを応援してくれるはず

27. 仮説 27

28. 仮説には様々な種類がある。スタートアップにとって特に重要なのが価値仮説と成長仮説である。 28 仮説の種類価値仮説このプロダクトに価値があるかどうかを学ぶための仮説。顧客に直接聞くだけではなく、実験を通して行動を計測する。最終的にはお金を支払ってそのプロダクトを買う人がいるかどうかの検証を行う必要がある。成長仮説どのようなプロダクトであれば方法を用いれば適切に成長できるのかの仮説。アーリーアダプター以降の人たちに広がっていくのか、特に口コミを広げていけるかなどの仮説検証を行う。（実現性仮説）技術や法律的に実現可能かどうかの仮説。エンジニアはついこの仮説にこだわりがちだが、まずは価値仮説と成長仮説に目を向けたほうが良い。仮説の例としては以下。 • 技術的な実現リスクはあるか（耐久性は十分か、十分にバッテリーは持つかどうか、等） • ハードウェアの量産が一定のコスト内で可能か • 規制があるか（法律で禁止されているものや、電気通信事業法との兼ね合いなど）

29. 仮説検証は Build ‒ Measure ‒ Learn のループによって行われる。オペレーションでは、このサイクルをいかに早く回すかが重要になる。 29 仮説検証のサイクル: Build ‒ Measure - Learn Idea s 1. Build3. Learn Data 2. Measure Prod uct より速く構築 MVP ユニットテストユーザビリティテスト継続的インテグレーションクラウドなどなどより速く計測スプリットテストユーザビリティテストファネル分析コホート分析より速く学習顧客開発 5 つの Why 反証可能な仮説などなど

30. アクションは BML の順に行われるが、計画は LMB の順、つまり「何を学びたいか」を中心に考える必要がある。基本的に、リスクの大きいものから順に学びを得ていくと良い。 30 仮説検証の計画は Learn -> Measure -> Build の順 Idea s 1. Build3. Learn Data 2. Measure Prod uct Idea s 3. Build1. Learn Data 2. Measure Prod uct アクションは Build ‒> Measure -> Learn 仮説検証の行動としては、何かを作ってから計測して、その計測を元に学ぶ。計画は Learn -> Measure -> Build 仮説検証の計画は、何を学びたいかを考えてから、計測方法を考え、それに基づいて MVP を作る。

31. 最初に学びたいことを明確にするためのツールとして、以下のようなものが開発されている。初期においてはこうしたツールを使うと便利。 31 学習を最初に明確にするためにツール利用の検討も MVP Canvas AppSocially とリクルートが共同開発した MVP を作るために事前にまとめるシート。 http://www.slideshare.net/aerodynamic/mvp-canvas Experiment Report Ralley Software の Zach Nies がまとめた、実験前にまとめるシート。坂田さんにより翻訳済み。 https://www.rallydev.com/community/agile/frame-build-measure- learn-knowledge-and-innovation-uncertain-world http://sprmario.hatenablog.jp/entry/frame_build_measure_learn

32. 仮説検証で「確証」が得られるわけではなく、得られる学びは精々「おそらく間違ってはいない」程度でしかない（それでも随分と前進している）。ある段階で確証のない跳躍（意思決定）が必要。 32 仮説検証のあるある仮説検証の結果が分かりにくい仮説検証をしても一気に成果が出るような「当たり」の仮説が次々に出るわけではない。5 回に 1 回ぐらい良いのが出れば良い方という感覚で挑む。また当たりの仮説なのに遅延してから効果がでてきたりするものもあれば、即効性の効果は出たものの持続せずに偽の検証結果であったと後になって分かるケースもある。部分最適化に陥ってしまう思い入れのあるプロダクトの場合や、プロダクトに既に大規模なサンクコストが発生している場合は、見込みのないプロダクトを必死に最適化して局所解に陥る。ビジョンに反しない程度に、焼きなまし法的な考え方を最初はしてみるのも良い。仮説を立てるためのデータがない仮説を立てようにも、仮説を立てるためのデータや洞察がそもそもないので、精度の良い仮説を立てられない。

33. スタートアップは仮説検証だけをすれば良い、というわけではない。特定の仮説に集中し、検証の速度を上げて、学習量を最大化する努力が必要となる。 Running Lean 33 仮説検証は「学習」「速度」「集中」を意識して設定速度学習集中最適学習ループ Idea s 1. Build3. Learn Data 2. Measure Prod uct 速度集中学習

34. 「学習」「速度」「集中」のいずれかが欠落した場合、どれもムダを生むことになる。ムダが発生すればするほど、スタートアップの寿命は短くなる。 Running Lean 34 学習、速度、集中のいずれかが抜けるとムダが生まれる速度学習集中学習と集中だけ速度が遅いと資源を使い果たす可能性があるだけでなく、競合にも追い抜かれる速度と集中だけ学習が起こらないムダな努力を続けて資源だけを食い尽くす速度と学習だけ早すぎる最適化の罠にはまる可能性がある。たとえば顧客がいないのにサーバーを増強したりする

35. MVP は一部の仮説検証のために作られる、評価や学びを得るための最小の製品のこと。MVP が不要な場合もあれば、様々なパターンで作られる場合もある。 35 検証のための Minimal Viable Product の設計も細分化理想のプロダクトこのソリューションは顧客の課題を解決するか？コンシェルジュ MVP MVP1 MVP2 理想のプロダクト Closed Beta (Function/Operation) 機能は十分か？自動化できるか? MVP1 MVP のパターン 1 一個一個検証していながら徐々に大きくするパターン。普通はこちらを考えがち（特にサイエンス＆ハードウェア系）。 MVP のパターン 2 できるところは分割しつつ検証していくパターン。別にできるところは別に検証したほうが早いことが多い。 Landing Page 十分な顧客がいるかプロトタイプ 1 (AHA Moment & Contextual) このプロダクトの UX は適切か？プロトタイプ 2 (Usability) プロトタイプ 3 (Aesthetic) インタビュー顧客に課題があるか?

36. 悪い仮説検証 36

37. Just do it (とりあえずプロダクトを作ってみよう) をはじめとして、ムダを大量に生む仮説検証は悪い仮説検証と言える。以下は悪い仮説検証の代表的な例である。 37 悪い仮説検証の特徴仮説 A 仮説 B 仮説 C 仮説 D 仮説 E 仮説の上の仮説の上の仮説の検証仮説が曖昧だったり小さすぎるチームの合意なき検証仮説 1個のMVP で検証

38. 先述した悪い仮説検証の例の詳細は以下のとおり。 38 悪い仮説検証の特徴仮説の上の仮説の上の仮説の検証一気に大き目のプロダクトを作ってしまうケースが主に該当する。顧客がいるかどうか、顧客にとっての課題感の大きさなど、検証されていない大きなリスクの上に、機能やプロダクトという新たな仮説を作ってしまうことが多い。この結果、仮説検証の速度が出ない（にも関わらず一所懸命仕事をしている感覚はあってタチが悪い）。またこれは自分たちの事業において何が最大のリスクか分かっていないことも示唆している。仮説が曖昧だったり小さすぎる仮説が曖昧だと完全な失敗が起きず、方針転換などを行えずに時間を浪費することにつながる。また小さすぎる仮説の積み重ねでは学びが少なく、時間に対して効果的でないケースが多い。最も学習量が多いのは「50/50」の確率のもの、つまり全く未知のものに対して検証すれば学習量は多くなる。チームの合意なき検証意思決定を行うための検証の場合、意思決定の基準などを検証の事前にチーム内で合意できていないと、結果が良かったのか悪かったのかを判断できず、ムダな議論が始まる傾向にある。

39. ここでは前ページの「悪い仮説検証の特徴」の例を挙げる。 39 例）悪い仮説検証の特徴仮説の上の仮説の上の仮説の検証「ペットの飼い主のための、ペットの Facebook」の仮説検証をしようとしてプロダクトを作ってしまった場合、本来は以下のように仮説を分解して検証すべき？ 1. 自分のペットの近況をシェアしたいと思う（投稿者） 2. 自分のペットの近況を写真だけでシェアしたいのか、文字も許可するのか、あるいは動画でシェアしたいのかわかっている 3. 他人のペットの近況を見たいと思う（閲覧者） 4. 再来訪頻度が大事などなど。仮説が曖昧だったり小さすぎる「チュートリアルをつけたほうが良いかどうか」は多くの場合 Yes なので、本当に時間をかけて検証するべきかどうかを考える。「ボタンの色を青から黄色にすべきか」は顧客インタビューなどせずに、スプリットテストをしてユーザーの行動を見ればすぐに分かる（し、初期にそれを検証する必要があるかどうかを検討するべき）。チームの合意なき検証「この MVP でアーリーアダプターを捕まえられたら、機能 A を実装する」という基準で検証を進めてしまうと、結果が出た後に「このユーザー層はアーリーアダプターか」「この人数で十分か」などといった議論が起こる。「この MVP でユーザー登録をする人が 100 人を超えたら機能 A を実装する」など、明確な基準を事前に設定し、チーム内で合意しておくと学びの結果からスムーズに意思決定ができる。

40. 悪い仮説を立てがちな人は、以下を参照すると参考になる情報が掲載されているかもしれない。 40 参考文献インタビューが不得意 http://www.slideshare.net/takaumad a/lean-customer-development-lean- startup-update-2015 売れるかどうかの検証が苦手 http://www.slideshare.net/takaumad a/startup-sales-animal 仮説構築が苦手 http://www.slideshare.net/takaumad a/design-sprint-guidebook-v2 また「Game Storming」なども参照

41. 初期の仮説検証のフェーズでよく受ける質問とその回答を以下に挙げる。 41 仮説検証 FAQ 顧客インタビュー Q. インタビューできる人が見つかりません A. 自身に既に顧客ベースのないセグメントに参入するのはそもそも無謀な気がします（顧客への洞察がないと良い仮説も立てられないのでは）。 Q. インタビューを広く呼びかけても来てくれません A. 基本インタビューに積極的に参加してくれる人はいないので、個別に声をかけましょう。特に既存顧客をうまく使ってください。 MVP Q. MVP が小さくなりません A. 本当に小さくならない時もあるとは思いますが、小さくできるように考えてみてください。大概方法はあります。たとえばコンシェルジュ MVP は試しましたか？既存の競合製品のカスタマイズは？自分が思っているよりも、MVP は小さくなることが多いです。 Q. 競合製品がありません A. それは「マーケットがない」と言っているようなものです。たとえ製品がなくても、顧客は別の手段で課題を解決しているのかもしれません。そうでないのなら切実な課題ではないということでは？

42. 良い仮説検証 42

43. スタートアップにとって仮説がプロダクトである。学び。学びの結果、（合意の上で）意思決定ができること。 43 良い仮説検証を二つのフェーズに分ける 1. 仮説立案 (アート的) 2. 仮説検証 (サイエンス的)

44. 44 1. 良い仮説立案の仕方

45. 45 すみません、分かってません… （やり方が分かってたら全員がとっくに成功してるかと…）

46. 人間の創造性を引き出すパターンはあるので、それをうまく使いながら仮説を立案していく。精度の良い仮説を作れるまで、ムダをなくして生き延び続ければ、いずれは良い仮説に出会える……はず。 46 とはいえ良い仮説を作るためのパターンはありそう良い仮説よりも良い問題を良い仮説を見つけようとするよりも、良い問題を見つけようとしたほうが良い仮説を作りやすい。専門的な経験や観察から問題を発見できるケースも多い。論理だけでは出てこない新規性のある非連続的な仮説は、過去の適切なデータもなく、論理だけでは導き出せない。無理やりひねり出す手法としては、あえて制約を課してリフレーミングしてみる手法や、共感を用いる手法 (デザイン思考等) などを使うことが現在は試されている。創造性はチームで高まる複雑な問題に対してのより良い仮説は、多様性のあるチームによるディスカッションを通して生まれる傾向にある（詳しくは別スライド）。ただしチームは仮説を殺す力も持つ。 Pixar では初期の試作（＝仮説）を「醜い赤ん坊」と呼んでいる。Pixar ですらそうなのだから、多くの仮説も最初はそう見えるはず。仮説をチームでうまく育てる仕組みが必要。

47. 47 2. 良い仮説検証の仕方

48. 48 ハックする（普通は考え付かないことをする）

49. まともな考えでまともにやっていてもスタートアップの成功確率は高まらない。必ず既存の仕組みを出し抜くような、何かの工夫をしかけること。 49 時間の価値を最大にする仮説検証を考える並々ならぬ時間を投下するスタートアップは当然ながら並々ならぬ努力をする。けれど、一日精々 16 時間しか働けないことを考えると、努力で補える量は普通の企業の 2 倍程度になる。（大企業の新規事業室でも実際は 8 時間以上の労働を行っているため、現実的には 2 倍にすらならない）やり方をハックするまともな考えでやっていたら、時間投下が多い分だけ先に進めるが、精々 2 倍程度が限界。時間で差別化できないのであれば、スタートアップは努力のやり方を変えるべき。つまり、仮説検証のやり方をハックする必要がある。その結果、普通の 10 倍以上の速度で学習する

50. 既存の仕組みを出し抜くようなやり方で仮説検証を進めていく。ただし違法性には注意すること。 50 じゃあハックって一体何？人のやりたくないことをする人の手間のかかるコンシェルジュ MVP、セールスやサポートなどといった、普通の人は面倒で嫌がるような仕事をする。失敗前提で新規手法を試す MVP 構築にプロトタイピングツールや MBaaS などを使ったり、既存の競合製品をカスタマイズしたりするなど、ツールや新規手法を使い倒す。また集客に新しいチャネルを使ってみたり、コーヒーと引き換えにインタビューしたり、CraigsList に掲載してみたり、など、大企業では考え付かないことなどを試して見る。ただしこれらは失敗が前提となるので、失敗を許容する体制を整えたり、手法も実験を繰り返しながら進める必要がある。バッチサイズを小さくする投下する時間や資源のサイズ（バッチサイズ）を小さくすることで、失敗をしたときにすぐにわかる。また失敗の原因がわかりやすい。ただしコストがかかるように見える（実際には無駄なものを作っていないので無駄はない）。何より、何が今一番大切かをはっきりさせることができる。 (バッチサイズの話は Lean Startup, 第 9 章を参照)

51. バッチサイズを小さくする 51

52. これまでスタートアップの仮説検証の相談に乗ってきて、Lean Startup の第 9 章で語られる「バッチサイズ」の内容について詳しく解説する必要を感じたため、本スライドではバッチサイズについてページ数を割いて解説する。特に初期のスタートアップは「仮説の 1 個流し (Single Piece Flow)」を意識しながら進めていくのが良いと考える。詳細は以下で解説する。 52 バッチサイズ

53. 「プロダクトを一気に作る」といったような大きなバッチで検証を仕掛けるとムダが多い。この章では仮説を細分化して検証していくことのメリットを紹介する。 53 仮説検証はスモールバッチで行うサイズを細かく分ける大きな仮説検証のサイクルを細かく分けて、リスクの大きい順から検証していく。種類ベースでバッチを分ける Lean Canvas のように、種類でバッチを分けて検証していく。 ⑦ コスト構造 ① 課題 (既存の代替品) ④ ソリューション ③ 独⾃自の価値提案 ⑨ 圧倒的な優位性 ② 顧客セグメント (Early Adaptor) ⑥ 収益の流流れ ⑧ 主要指標 ⑤ チャネル BL M BL M BL M BL M BL M BL M BL M

54. 仮説や仮説に含まれる前提は重要度と不確実度でマッピングしてみて、今最も優先順位の高い仮説をチームで一つに絞る。 54 重要度と不確実性で分類し、優先順位をつける不確実性重要度顧客 A は顧客チャネルの効果 Best Practice は通じる? 顧客 B は顧客現状最も優先

55. カンバンを使って WIP に制限を設けて管理する方法。主に仮説検証のフローに着目して管理する。特に方向性のぶれやすい初期のスタートアップには仮説の一個流しをお勧めする。 55 仮説検証のフロー管理（例）: 仮説の一個流し未検証だが学びたいこと仮説と検証方法 Build (バッファ) Measure 結果と検証された学びこの区間の WIP (Work in Progress) は 1 (タイムボックスは最大でも 1 週間程度) 顧客 A は顧客課題 B があるのか ------------ 検証方法: Interview チャネルの効果顧客 B は not 顧客課題 A はなかったいわゆる Build ‒ Measure - Learn Best Practice は通じる?

56. バッチサイズを大きくして大量生産を行えば一見効率が良いように見える。 56 一見バッチサイズが大きいと効率的に見えるセットアップタイムプロセスタイムキュータイムウェイトタイムセットアップタイムは変わらないので、バッチの回数分時間が長くなっている在庫の流れ一気に流した方がプロセス間の輸送の回数が少なく早い。時間の流れ個人レベルで考えるならバッチサイズは大きい方が作業に集中できるし、直感的に考えても一気にやったほうが早い。プロセス A プロセス B プロセス C バッチサイズ大バッチサイズ小

57. 逆にバッチサイズが小さいメリットは、マーケットのニーズに合わせて供給の変動を行いやすいという点（プルでの生産）。また一部の業務では、理論的にはバッチサイズが大きいほうが早く思えるものの、実際にはバッチサイズが小さいほうが早いケースもある。 57 実際にはバッチサイズが小さい方が早いこともある例）One Piece Flow Simulation 封筒を作るのに、手紙を 10 枚折って、10 個入れて、とやるより、一つずつ封筒を作った方が早い。これは、大量生産モデルには、ひと束の在庫の移動の時間や、失敗時の一括修正のコスト、待ち時間など、「隠れたコスト」が含まれているから。また作業を分けると作業の目的や意味も見えにくくなる。 https://www.youtube.com/watch?v=Bi9R1Hqr8d

58. さらに何か問題が起こった時、一個流しであれば作業がムダになる可能性が低い。これは特に不確実な状況下では大きなメリットになる。 58 例）ミスが見つかったときのムダの発生が少ないムダ大きなムダが発生する在庫的デメリット前工程の作業者に大きな割り込みが入る（例えば資料を全ページ作成後にレビューを出して、根本からやり直しになる等）大きなムダが発生する時間的デメリットやり直しのタイミングが遅くなり、効率が悪い（ソフトウェア開発におけるバグの修正速度は、開発直後と数週間後では数十倍違うと言われている）

59. 一個流しは、特に不確実な状況下に効果的であり、スタートアップの初期は基本的に一個流しで検証していったほうが良い。 59 仮説の一個流しが適切な場面極度に不確実な状況下（初期のスタートアップ）決まり切っており、ミスが少ないものであればバッチサイズを大きくしたり、タイムボックスでの管理が効率的になってくることもある。しかし不確実な状況下ではバッチサイズが大きいと失敗した時のムダが多くなる。さらに割り込みが多い作業はカンバンでの管理が便利（Essential Scrum）。また一個流しであれば、チームのフォーカスが一つの仮説に絞られるメリットもある。セットアップタイムが小さい場合セットアップタイムが少ないのであれば、バッチサイズを小さく回数を多くしても、大きく影響は出ない。また非ボトルネックの空き時間や資源を使ってセットアップタイムを短縮できるほか、ソフトウェアの場合は自動化（たとえばコンテナ化や継続的デリバリーの仕組み構築）を行うことでセットアップタイムを極めて小さくすることが可能。セットアップタイムを短縮すればいつでも効果的になる • 非ボトルネック資源の投下 • 自動化 (バラツキの抑制も) • インタビュイーの常駐

60. その他、タイムボックスを設けた一個流し (シングルピースフロー) を行い、そのフローの維持をすることは、その速さだけではなく様々な副次作用も得られる。 60 仮説を一個流しにして、フロー維持の努力をする大きなバッチで検証できない小さなバッチサイズかつ期間限定という制限をつけることにより、そのサイズでの MVP を作るべくハックする環境を強制的に作ることができる。一週間は短いと思われるかもしれないが、仮に 1 仮説に一週間かけたら年間約 50 個の仮説しか検証できない（そしてスタートアップの寿命は前回の資金調達から大抵 1 年で決まる）。仮説の優先順位付けと Focus カンバンを用いることで作業を見える化できるだけでなく、WIP を 1 に制限すると、仮説検証の優先順位をつけざるをえなくなり、結果的にフォーカスが可能になる。（マルチタスクを許可すると、チームメンバーが個別に合意の取れていないことをやりがち）またタイムボックスを設けることで平準化が行われ、経営の予測がつく（＝事業の成功の予測というより、資源が尽きるまで後どれだけ実験できるかの予測がつく）。何がボトルネックか把握できる一個流しの場合、仮説検証がうまく流れないところがボトルネックであるとすぐに判別できる。ボトルネックを解消することで、検証スピードを改善できる（あるボトルネックを解消すると必ず別のボトルネックが生まれるので順次改善していく）。ただしボトルネック自体に原因があるケースもあれば、別のところに原因があるケースもあるので、注意深く原因を把握すること。

61. 仮説検証のフローが止まれば、そこに根本的な原因があることが多い。よくあるパターンを以下に示す。理想はフローを止まらないようにすること。 61 流れるような仮説検証を: ボトルネックを探る未検証だが学びたいこと仮説と検証方法 Build (バッファ) Measure 結果と検証された学び顧客 A は顧客チャネルの効果顧客 B は not 顧客課題 A はなかった • MVP のサイズが大きすぎる • 計測のセットアップコスト高 • 段取り不足 • 社内プロセスによる遅延 • 顧客ベースが十分にない • 定量的調査をする以前の段階 • 検証が下手 • Vanity Metrics になってる Best Practice は通じる? 各ステージでスタックする理由課題 B があるのか ------------ 検証方法: Interview

62. BML の後工程のことを考えずにフローを流してしまうと後工程で失敗が見つかり、ムダが発生しやすい。 62 その他の Build ‒ Measure ‒ Learn の設計ミスの例 Learn における設計ミス • そもそも学びたいことが明確ではない • 顧客インタビューが下手で、良い洞察を得られない • 顧客の発言をそのまま学びとしてしまい、顧客の発言の本当の原因にまで深堀りできていない • 検証のメトリクスが「行動への繋がりやすさ (Actionable)」「分かりやすさ (Accessible)」「チェックしやすさ (Audible)」の基準を満たせていない Measure における設計ミス • 仮説立案フェーズで検証のコストや存在を無視していて、 Measure の段階で長く止まる（仮説立案と検証方法はセットで考える） • 定量調査をしようとしても、十分な顧客がいない • 顧客インタビューに固執しすぎていて、他の方法を検討していない • 検証の段取りが下手で、時間がかかりすぎている Build における設計ミス • MVP のサイズが大きすぎて Build に時間がかかりすぎる • MVP のサイズが大きすぎて、結果的にムダが多くなる • 一気に複数の MVP を作っていてフォーカスがぶれていて、うまく検証できないものを作る • Viable (実用的) であることを低くみすぎる。Viable かどうかは顧客の環境やプロダクトのカテゴリによって大きく異なるし、 MVP によっても異なる

63. 仮説の一個流しをするときには以下のような点を注意しながら進めると良い。 63 仮説の一個流しをするための Tips スケールしないことをする「スケールしないこと」をするのは仮説の一個流しに近い。 DoorDash のように最初は手動で行いつつ、徐々にボトルネックを自動化していくことで、顧客の反応を確かめつつ仮説検証をしていくと良い。ばらつき (ムラ) を抑える人手でやっていたタスクを自動化することで、セットアップタイムなどを短縮できるほか、ミスを減らし、結果的にばらつき (ムラ) を抑えることができる。バッチサイズが大きいとその分、不必要な結果や品質のばらつきが起こりやすい。小さなバッチサイズで行うことでばらつきを最小限にすることが可能。その他、作業項目を大きさで分類してばらつきの予測可能性を抑えることも可能。最初にリズムを作るまずは短期間の仮説検証のリズムを作ることを優先したほうが良いと考えている（そのほうが初期は成功しやすい印象）。リズムを体に慣れさせて、仮説の質を上げるのはリズムが整ってきてからで良い。またリズムがあると予見可能性が上がるほか、ムリを減らすこともできる。また初期の仮説検証はリズムを早めて速度を上げることも積極的に検討する。

64. 速度学習集中 64 スタートアップ初期は特に集中して速く学ぶ

65. 「学習」「速度」「集中」が満たせれば別のやり方でも良いし、ツールが便利ならツールを使うと良い。自分のチームにあったやり方を見つけて、リーンスタートアップの良いところを取り入れていく。 65 「学習、速度、集中」を満たすためのその他のやり方 http://www.slideshare.net/i2key/45- developers-summit-2015-devsumi- devsumib リクルート (黒田さん) Cameran などで行われている、検証から構築までの流れ Javelin Board Lean Startup Machine などで使われる、仮説検証の繰り返しが可視化できるボード http://vip.javelin.com/ Validated Learning Board Running Lean の Ash が作った、かんばんボードと BML の組み合わせのボード http://leanstack.com/the-lean-stack/

66. 66 リーンスタートアップやその他の方法論に銀の弾丸はないので、良いところだけを取り入れるつもりで他に良い方法があったら教えてください!!

67. 67 無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄無駄を少なくする良い仮説検証を繰り返して、成功までの