リーンスタートアップにおける良い仮説、悪い仮説
•
464 gefällt mir•91,131 views
Lean Startup についての講演準備資料です。すでに Eric Ries の Lean Startup の青本は読んでる前提で、良い仮説と悪い仮説について、これまで相談などに乗ってきた中で見てきた傾向から私見をまとめています。 今回は顧客発見フェーズのスタートアップや新規事業を念頭に置いています。またバッチサイズの縮小について多めにページを割いています。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie リーンスタートアップにおける良い仮説、悪い仮説
Ähnlich wie リーンスタートアップにおける良い仮説、悪い仮説 (20)
Mehr von Takaaki Umada
Mehr von Takaaki Umada (15)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
リーンスタートアップにおける良い仮説、悪い仮説
- 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 が体系化。製 造工程全体の最適化を 狙う)
- 10. リーンスタートアップでは実験を繰り返して、学びを得て、自分たちのプロダクトの進む方向を決め ていく。 10 効率的に学びを得て意思決定をしていく 学び 意思決定 • 顧客に課題は（ある程 度）あった • 機能 A の MVP は効果が あった • 機能 B を作るべきだろう か？ • この顧客にフォーカスし て事業を進めるべき！ • 機能 A を作るべき！ • 機能 B は作らずに修正す べき！ 実験 • 顧客に課題はあるのだろ うか？ • 機能 A は作るべきだろう か？ • 機能 B を作るべきだろう か？
- 11. 実験（仮説検証）の流れ 11
- 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 • 顧客に切実な課題はあるか？ • 課題は解決できるか？ • 顧客は解決策にお金を払うか? • 解決策はプロダクトになるか? • プロダクトは十分に成長でき るか?
- 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
- 24. 右往左往しているうちに、当初目指している場所とは違う金脈が見つかることもある。それでも基本 路線は「最初は大きく、徐々に微調整」が好ましいと思われる。 24 実際はカオス (そもそもゴールが違ったりする) 「B2C で売れるプロダクトではなく、 実は B2B 向けでした」など
- 25. カオスな模索にならないようにするためには、ぶれることのないビジョンを持つことが重要。リーン スタートアップにおいて、戦略はピボット可能であり、製品は最適化していくものと考えられている。 「リーンスタートアップ」 p.34 25 ぶれないビジョンを持つことが重要 製品 ビジョン 戦略 • ビジネスモデル • 製品ロードマップ • 予想される顧客 最適化（エンジンのチューニング） ピボット
- 26. 模索が無駄になるかというとそんなことはない。模索を通して得られるものも多い。 26 リーンスタートアップの方法論で模索するメリット 内部向けのメリット • 学びが溜まり、それが新しい仮説構築の基礎となる • 行き当たりばったりにならず、（ある程度）計画的 かつ効率的に会社の資源を投資できる • チームの方向性を合わせながら進むことができる 外部向けのメリット • 投資家やその他協力者への説明責任 (accountability) を果たすことができる • どこまで検証済みかが明確になり、次に外部への協 力したいことや依頼も明確になる • 模索を通してアーリーアダプターの拡大が可能にな り、次回以降のインタビューなどがラクになる • スケールできずに失敗しても、一人でも顧客を幸せ にできれば、その人はあなたの次のチャレンジを応 援してくれるはず
- 27. 仮説 27
- 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 で検証
- 39. ここでは前ページの「悪い仮説検証の特徴」の例を挙げる。 39 例）悪い仮説検証の特徴 仮説の上の仮説の上の仮説の検証 「ペットの飼い主のための、ペッ トの Facebook」の仮説検証をし ようとしてプロダクトを作ってし まった場合、本来は以下のように 仮説を分解して検証すべき？ 1. 自分のペットの近況をシェアし たいと思う（投稿者） 2. 自分のペットの近況を写真だけ でシェアしたいのか、文字も許 可するのか、あるいは動画で シェアしたいのかわかっている 3. 他人のペットの近況を見たいと 思う（閲覧者） 4. 再来訪頻度が大事 などなど。 仮説が曖昧だったり小さすぎる 「チュートリアルをつけたほうが 良いかどうか」は多くの場合 Yes なので、本当に時間をかけて検証 するべきかどうかを考える。 「ボタンの色を青から黄色にすべ きか」は顧客インタビューなどせ ずに、スプリットテストをして ユーザーの行動を見ればすぐに分 かる（し、初期にそれを検証する 必要があるかどうかを検討するべ き）。 チームの合意なき検証 「この MVP でアーリーアダプ ターを捕まえられたら、機能 A を 実装する」という基準で検証を進 めてしまうと、結果が出た後に 「このユーザー層はアーリーアダ プターか」「この人数で十分か」 などといった議論が起こる。 「この MVP でユーザー登録をす る人が 100 人を超えたら機能 A を実装する」など、明確な基準を 事前に設定し、チーム内で合意し ておくと学びの結果からスムーズ に意思決定ができる。
- 41. 初期の仮説検証のフェーズでよく受ける質問とその回答を以下に挙げる。 41 仮説検証 FAQ 顧客インタビュー Q. インタビューできる人が見つかりません A. 自身に既に顧客ベースのないセグメントに参入する のはそもそも無謀な気がします（顧客への洞察がない と良い仮説も立てられないのでは）。 Q. インタビューを広く呼びかけても来てくれません A. 基本インタビューに積極的に参加してくれる人はい ないので、個別に声をかけましょう。特に既存顧客を うまく使ってください。 MVP Q. MVP が小さくなりません A. 本当に小さくならない時もあるとは思いますが、小 さくできるように考えてみてください。大概方法はあ ります。たとえばコンシェルジュ MVP は試しました か？既存の競合製品のカスタマイズは？ 自分が思っ ているよりも、MVP は小さくなることが多いです。 Q. 競合製品がありません A. それは「マーケットがない」と言っているようなも のです。たとえ製品がなくても、顧客は別の手段で課 題を解決しているのかもしれません。そうでないのな ら切実な課題ではないということでは？
- 42. 良い仮説検証 42
- 43. スタートアップにとって仮説がプロダクトである。学び。学びの結果、（合意の上で）意思決定がで きること。 43 良い 仮説検証 を二つのフェーズに分ける 1. 仮説立案 (アート的) 2. 仮説検証 (サイエンス的)
- 44. 44 1. 良い仮説立案の仕方
- 46. 人間の創造性を引き出すパターンはあるので、それをうまく使いながら仮説を立案していく。精度の 良い仮説を作れるまで、ムダをなくして生き延び続ければ、いずれは良い仮説に出会える……はず。 46 とはいえ良い仮説を作るためのパターンはありそう 良い仮説よりも良い問題を 良い仮説を見つけようとするより も、良い問題を見つけようとした ほうが良い仮説を作りやすい。 専門的な経験や観察から問題を発 見できるケースも多い。 論理だけでは出てこない 新規性のある非連続的な仮説は、 過去の適切なデータもなく、論理 だけでは導き出せない。 無理やりひねり出す手法としては、 あえて制約を課してリフレーミン グしてみる手法や、共感を用いる 手法 (デザイン思考等) などを使う ことが現在は試されている。 創造性はチームで高まる 複雑な問題に対してのより良い仮 説は、多様性のあるチームによる ディスカッションを通して生まれ る傾向にある（詳しくは別スライ ド）。 ただしチームは仮説を殺す力も持 つ。 Pixar では初期の試作（＝仮 説）を「醜い赤ん坊」と呼んでい る。Pixar ですらそうなのだから、 多くの仮説も最初はそう見えるは ず。仮説をチームでうまく育てる 仕組みが必要。
- 47. 47 2. 良い仮説検証の仕方
- 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
- 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 のように最初は手動で 行いつつ、徐々にボトルネックを 自動化していくことで、顧客の反 応を確かめつつ仮説検証をしてい くと良い。 ばらつき (ムラ) を抑える 人手でやっていたタスクを自動化 することで、セットアップタイム などを短縮できるほか、ミスを減 らし、結果的にばらつき (ムラ) を 抑えることができる。 バッチサイズが大きいとその分、 不必要な結果や品質のばらつきが 起こりやすい。小さなバッチサイ ズで行うことでばらつきを最小限 にすることが可能。その他、作業 項目を大きさで分類してばらつき の予測可能性を抑えることも可能。 最初にリズムを作る まずは短期間の仮説検証のリズム を作ることを優先したほうが良い と考えている（そのほうが初期は 成功しやすい印象）。リズムを体 に慣れさせて、仮説の質を上げる のはリズムが整ってきてからで良 い。またリズムがあると予見可能 性が上がるほか、ムリを減らすこ ともできる。 また初期の仮説検証はリズムを早 めて速度を上げることも積極的に 検討する。
- 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/