Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

50,847 views

Published on

Lean Startup についての講演準備資料です。すでに Eric Ries の Lean Startup の青本は読んでる前提で、良い仮説と悪い仮説について、これまで相談などに乗ってきた中で見てきた傾向から私見をまとめています。

今回は顧客発見フェーズのスタートアップや新規事業を念頭に置いています。またバッチサイズの縮小について多めにページを割いています。

Published in: Technology

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

  1. 1. リーンスタートアップにおける 良い仮説、悪い仮説 Good Hypothesis, Bad Hypothesis Takaaki Umada / https://medium.com/@tumada/ September 1st, 2015 @ 某社向けクローズド勉強会資料 1
  2. 2. このスライドでは、これまでスタートアップの 皆さんからの相談を受けてきた経験やプロダク トマネージャー時代の経験から、リーンスター トアップの方法論で用いられる良い仮説と悪い 仮説について解説します。 クローズドでの社内勉強会のベースの資料のた め、一部口頭での補足がないと分かり難い部分 があるかもしれません。ご了承ください。 左記は今回特に参考にした文献です。 • リーンスタートアップ • Running Lean 実践リーンスタートアップ • カンバン ソフトウェア開発の変革 タイトルは Ben Horowitz Good Product Manager/Bad Product Manager から。 2 スタートアップの 良い仮説検証 を実現するために Ben Horowitz Good Product Manager / Bad Product Manager
  3. 3. リーンスタートアップ 3
  4. 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. 5 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄
  6. 6. 6 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 「顧客の欲しがるもの」を最初に探し当てれば、 これぐらいの量のムダの削減になるのでは
  7. 7. 7 頑張り方を大きく間違えない (間違ったことに効率的にならず、 ムダを発生させないために学びの中間目標を達成していく)
  8. 8. リーンスタートアップの批判として以下のようなものが挙げられる。 8 リーンスタートアップに対するよくある誤解 (誤解 1)リーンスタートアップに則れば成功する リーンスタートアップはムダを極力減らすためのやり 方であって、成功を保証するやり方ではありません。 ただし「成功するまで生き延び続ければいずれ成功す る」と、よく言われている言葉が正しいのであれば、 リーンスタートアップはムダを取り除くことでスター トアップが長生きできるようになり、何度もチャレン ジできるようになるので、結果的に成功確率は高まる かもしれません。 (大企業の新規事業のように、お金ではなく時間の制 限が厳しい場合は時間との兼ね合いも考える必要ある と思います) (誤解 2)リーンスタートアップに計画は不要 リーンスタートアップは、大きなビジョンを小さな機 能追加の積み重ねで到達するための方法論です。その ため、リーンスタートアップにも計画は必要です。た だ計画にとらわれず、実験の結果を受け止めて計画を 柔軟に変更していくことを重要視しています。 もちろん、リーンスタートアップの方法論はどのよう な製品にも適用できるわけではなく、向き不向きはあ りますし、適用できるフェーズとそうでないフェーズ もあると思います。
  9. 9. 9 ムダな努力をしないために 少しずつ学びながら進む
  10. 10. リーンスタートアップでは実験を繰り返して、学びを得て、自分たちのプロダクトの進む方向を決め ていく。 10 効率的に学びを得て意思決定をしていく 学び 意思決定 • 顧客に課題は(ある程 度)あった • 機能 A の MVP は効果が あった • 機能 B を作るべきだろう か? • この顧客にフォーカスし て事業を進めるべき! • 機能 A を作るべき! • 機能 B は作らずに修正す べき! 実験 • 顧客に課題はあるのだろ うか? • 機能 A は作るべきだろう か? • 機能 B を作るべきだろう か?
  11. 11. 実験(仮説検証)の流れ 11
  12. 12. 12 スタートアップは 何の検証をするのか?
  13. 13. 13 ビジネスモデルの検証
  14. 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. 15 検証の順番は 「リスクの大きい順」
  16. 16. 16 スタートアップの 最も大きいリスクは?
  17. 17. 17 「顧客に課題があるか」
  18. 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. 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. 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. 不確実性の高い状況下では地図は役に立たない。顧客というコンパスを頼りにしながら、仮説を作っ て進みつつ、徐々に確からしさを高めていく。そのためにもまずは顧客を定めることが大事。 21 仮説検証は顧客というコンパスを頼りながら徐々に進む
  22. 22. 仮説検証は最初は大きいリスクから検証していき、徐々にその方向を微調整していくほうが効率が良 い。 22 最初は大きく、次第に小さくステップを踏んでいく 最初は大きく 徐々に小さく
  23. 23. とはいえ、実際に仮説検証をすると右往左往することがほとんど。 23 実際はカオス
  24. 24. 右往左往しているうちに、当初目指している場所とは違う金脈が見つかることもある。それでも基本 路線は「最初は大きく、徐々に微調整」が好ましいと思われる。 24 実際はカオス (そもそもゴールが違ったりする) 「B2C で売れるプロダクトではなく、 実は B2B 向けでした」など
  25. 25. カオスな模索にならないようにするためには、ぶれることのないビジョンを持つことが重要。リーン スタートアップにおいて、戦略はピボット可能であり、製品は最適化していくものと考えられている。 「リーンスタートアップ」 p.34 25 ぶれないビジョンを持つことが重要 製品 ビジョン 戦略 • ビジネスモデル • 製品ロードマップ • 予想される顧客 最適化(エンジンのチューニング) ピボット
  26. 26. 模索が無駄になるかというとそんなことはない。模索を通して得られるものも多い。 26 リーンスタートアップの方法論で模索するメリット 内部向けのメリット • 学びが溜まり、それが新しい仮説構築の基礎となる • 行き当たりばったりにならず、(ある程度)計画的 かつ効率的に会社の資源を投資できる • チームの方向性を合わせながら進むことができる 外部向けのメリット • 投資家やその他協力者への説明責任 (accountability) を果たすことができる • どこまで検証済みかが明確になり、次に外部への協 力したいことや依頼も明確になる • 模索を通してアーリーアダプターの拡大が可能にな り、次回以降のインタビューなどがラクになる • スケールできずに失敗しても、一人でも顧客を幸せ にできれば、その人はあなたの次のチャレンジを応 援してくれるはず
  27. 27. 仮説 27
  28. 28. 仮説には様々な種類がある。スタートアップにとって特に重要なのが価値仮説と成長仮説である。 28 仮説の種類 価値仮説 このプロダクトに価値があるかど うかを学ぶための仮説。 顧客に直接聞くだけではなく、実 験を通して行動を計測する。 最終的にはお金を支払ってそのプ ロダクトを買う人がいるかどうか の検証を行う必要がある。 成長仮説 どのようなプロダクトであれば方 法を用いれば適切に成長できるの かの仮説。 アーリーアダプター以降の人たち に広がっていくのか、特に口コミ を広げていけるかなどの仮説検証 を行う。 (実現性仮説) 技術や法律的に実現可能かどうか の仮説。 エンジニアはついこの仮説にこだ わりがちだが、まずは価値仮説と 成長仮説に目を向けたほうが良い。 仮説の例としては以下。 • 技術的な実現リスクはあるか (耐久性は十分か、十分にバッ テリーは持つかどうか、等) • ハードウェアの量産が一定のコ スト内で可能か • 規制があるか(法律で禁止され ているものや、電気通信事業法 との兼ね合いなど)
  29. 29. 仮説検証は Build ‒ Measure ‒ Learn のループによって行われる。オペレーションでは、このサイ クルをいかに早く回すかが重要になる。 29 仮説検証のサイクル: Build ‒ Measure - Learn Idea s 1. Build3. Learn Data 2. Measure Prod uct より速く構築 MVP ユニットテスト ユーザビリティテスト 継続的インテグレーション クラウド などなど より速く計測 スプリットテスト ユーザビリティテスト ファネル分析 コホート分析 より速く学習 顧客開発 5 つの Why 反証可能な仮説 などなど
  30. 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. 最初に学びたいことを明確にするためのツールとして、以下のようなものが開発されている。初期に おいてはこうしたツールを使うと便利。 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. 仮説検証で「確証」が得られるわけではなく、得られる学びは精々「おそらく間違ってはいない」程 度でしかない(それでも随分と前進している)。ある段階で確証のない跳躍(意思決定)が必要。 32 仮説検証の あるある 仮説検証の結果が分かりにくい 仮説検証をしても一気に成果が出 るような「当たり」の仮説が次々 に出るわけではない。5 回に 1 回 ぐらい良いのが出れば良い方とい う感覚で挑む。 また当たりの仮説なのに遅延して から効果がでてきたりするものも あれば、即効性の効果は出たもの の持続せずに偽の検証結果であっ たと後になって分かるケースもあ る。 部分最適化に陥ってしまう 思い入れのあるプロダクトの場合 や、プロダクトに既に大規模なサ ンクコストが発生している場合は、 見込みのないプロダクトを必死に 最適化して局所解に陥る。 ビジョンに反しない程度に、焼き なまし法的な考え方を最初はして みるのも良い。 仮説を立てるためのデータがない 仮説を立てようにも、仮説を立て るためのデータや洞察がそもそも ないので、精度の良い仮説を立て られない。
  33. 33. スタートアップは仮説検証だけをすれば良い、というわけではない。特定の仮説に集中し、検証の速 度を上げて、学習量を最大化する努力が必要となる。 Running Lean 33 仮説検証は「学習」「速度」「集中」を意識して設定 速度 学習 集中 最適学習ループ Idea s 1. Build3. Learn Data 2. Measure Prod uct 速度 集中 学習
  34. 34. 「学習」「速度」「集中」のいずれかが欠落した場合、どれもムダを生むことになる。ムダが発生す ればするほど、スタートアップの寿命は短くなる。 Running Lean 34 学習、速度、集中のいずれかが抜けるとムダが生まれる 速度 学習 集中 学習と集中だけ 速度が遅いと資源を使い果たす可能 性があるだけでなく、競合にも追い 抜かれる 速度と集中だけ 学習が起こらないムダな努力を続けて 資源だけを食い尽くす 速度と学習だけ 早すぎる最適化の罠にはまる 可能性がある。たとえば顧客 がいないのにサーバーを増強 したりする
  35. 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. 悪い仮説検証 36
  37. 37. Just do it (とりあえずプロダクトを作ってみよう) をはじめとして、ムダを大量に生む仮説検証は 悪い仮説検証と言える。以下は悪い仮説検証の代表的な例である。 37 悪い仮説検証の特徴 仮説 A 仮説 B 仮説 C 仮説 D 仮説 E 仮説の上の仮説の上の仮説の検証 仮説が曖昧だったり小さすぎる チームの合意なき検証 仮説 1個のMVP で検証
  38. 38. 先述した悪い仮説検証の例の詳細は以下のとおり。 38 悪い仮説検証の特徴 仮説の上の仮説の上の仮説の検証 一気に大き目のプロダクトを作っ てしまうケースが主に該当する。 顧客がいるかどうか、顧客にとっ ての課題感の大きさなど、検証さ れていない大きなリスクの上に、 機能やプロダクトという新たな仮 説を作ってしまうことが多い。 この結果、仮説検証の速度が出な い(にも関わらず 一所懸命 仕事を している感覚はあってタチが悪 い)。またこれは自分たちの事業 において何が最大のリスクか分 かっていないことも示唆している。 仮説が曖昧だったり小さすぎる 仮説が曖昧だと完全な失敗が起き ず、方針転換などを行えずに時間 を浪費することにつながる。 また小さすぎる仮説の積み重ねで は学びが少なく、時間に対して効 果的でないケースが多い。最も学 習量が多いのは「50/50」の確率 のもの、つまり全く未知のものに 対して検証すれば学習量は多くな る。 チームの合意なき検証 意思決定を行うための検証の場合、 意思決定の基準などを検証の事前 にチーム内で合意できていないと、 結果が良かったのか悪かったのか を判断できず、ムダな議論が始ま る傾向にある。
  39. 39. ここでは前ページの「悪い仮説検証の特徴」の例を挙げる。 39 例)悪い仮説検証の特徴 仮説の上の仮説の上の仮説の検証 「ペットの飼い主のための、ペッ トの Facebook」の仮説検証をし ようとしてプロダクトを作ってし まった場合、本来は以下のように 仮説を分解して検証すべき? 1. 自分のペットの近況をシェアし たいと思う(投稿者) 2. 自分のペットの近況を写真だけ でシェアしたいのか、文字も許 可するのか、あるいは動画で シェアしたいのかわかっている 3. 他人のペットの近況を見たいと 思う(閲覧者) 4. 再来訪頻度が大事 などなど。 仮説が曖昧だったり小さすぎる 「チュートリアルをつけたほうが 良いかどうか」は多くの場合 Yes なので、本当に時間をかけて検証 するべきかどうかを考える。 「ボタンの色を青から黄色にすべ きか」は顧客インタビューなどせ ずに、スプリットテストをして ユーザーの行動を見ればすぐに分 かる(し、初期にそれを検証する 必要があるかどうかを検討するべ き)。 チームの合意なき検証 「この MVP でアーリーアダプ ターを捕まえられたら、機能 A を 実装する」という基準で検証を進 めてしまうと、結果が出た後に 「このユーザー層はアーリーアダ プターか」「この人数で十分か」 などといった議論が起こる。 「この MVP でユーザー登録をす る人が 100 人を超えたら機能 A を実装する」など、明確な基準を 事前に設定し、チーム内で合意し ておくと学びの結果からスムーズ に意思決定ができる。
  40. 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. 初期の仮説検証のフェーズでよく受ける質問とその回答を以下に挙げる。 41 仮説検証 FAQ 顧客インタビュー Q. インタビューできる人が見つかりません A. 自身に既に顧客ベースのないセグメントに参入する のはそもそも無謀な気がします(顧客への洞察がない と良い仮説も立てられないのでは)。 Q. インタビューを広く呼びかけても来てくれません A. 基本インタビューに積極的に参加してくれる人はい ないので、個別に声をかけましょう。特に既存顧客を うまく使ってください。 MVP Q. MVP が小さくなりません A. 本当に小さくならない時もあるとは思いますが、小 さくできるように考えてみてください。大概方法はあ ります。たとえばコンシェルジュ MVP は試しました か?既存の競合製品のカスタマイズは? 自分が思っ ているよりも、MVP は小さくなることが多いです。 Q. 競合製品がありません A. それは「マーケットがない」と言っているようなも のです。たとえ製品がなくても、顧客は別の手段で課 題を解決しているのかもしれません。そうでないのな ら切実な課題ではないということでは?
  42. 42. 良い仮説検証 42
  43. 43. スタートアップにとって仮説がプロダクトである。学び。学びの結果、(合意の上で)意思決定がで きること。 43 良い 仮説検証 を二つのフェーズに分ける 1. 仮説立案 (アート的) 2. 仮説検証 (サイエンス的)
  44. 44. 44 1. 良い仮説立案の仕方
  45. 45. 45 すみません、分かってません… (やり方が分かってたら全員がとっくに成功してるかと…)
  46. 46. 人間の創造性を引き出すパターンはあるので、それをうまく使いながら仮説を立案していく。精度の 良い仮説を作れるまで、ムダをなくして生き延び続ければ、いずれは良い仮説に出会える……はず。 46 とはいえ良い仮説を作るためのパターンはありそう 良い仮説よりも良い問題を 良い仮説を見つけようとするより も、良い問題を見つけようとした ほうが良い仮説を作りやすい。 専門的な経験や観察から問題を発 見できるケースも多い。 論理だけでは出てこない 新規性のある非連続的な仮説は、 過去の適切なデータもなく、論理 だけでは導き出せない。 無理やりひねり出す手法としては、 あえて制約を課してリフレーミン グしてみる手法や、共感を用いる 手法 (デザイン思考等) などを使う ことが現在は試されている。 創造性はチームで高まる 複雑な問題に対してのより良い仮 説は、多様性のあるチームによる ディスカッションを通して生まれ る傾向にある(詳しくは別スライ ド)。 ただしチームは仮説を殺す力も持 つ。 Pixar では初期の試作(=仮 説)を「醜い赤ん坊」と呼んでい る。Pixar ですらそうなのだから、 多くの仮説も最初はそう見えるは ず。仮説をチームでうまく育てる 仕組みが必要。
  47. 47. 47 2. 良い仮説検証の仕方
  48. 48. 48 ハック する (普通は考え付かないことをする)
  49. 49. まともな考えでまともにやっていてもスタートアップの成功確率は高まらない。必ず既存の仕組みを 出し抜くような、何かの工夫をしかけること。 49 時間の価値を最大にする仮説検証を考える 並々ならぬ時間を投下する スタートアップは当然ながら並々ならぬ努力 をする。けれど、一日精々 16 時間しか働け ないことを考えると、努力で補える量は普通 の企業の 2 倍程度になる。 (大企業の新規事業室でも実際は 8 時間以上 の労働を行っているため、現実的には 2 倍に すらならない) やり方を ハック する まともな考えでやっていたら、時間投下が多 い分だけ先に進めるが、精々 2 倍程度が限界。 時間で差別化できないのであれば、スタート アップは努力のやり方を変えるべき。つまり、 仮説検証のやり方を ハック する必要がある。 その結果、普通の 10 倍以上の速度で学習する
  50. 50. 既存の仕組みを出し抜く ようなやり方で仮説検証を進めていく。ただし違法性には注意すること。 50 じゃあハックって一体何? 人のやりたくないことをする 人の手間のかかるコンシェルジュ MVP、セールスやサポートなどと いった、普通の人は面倒で嫌がる ような仕事をする。 失敗前提で新規手法を試す MVP 構築にプロトタイピングツー ルや MBaaS などを使ったり、既 存の競合製品をカスタマイズした りするなど、ツールや新規手法を 使い倒す。 また集客に新しいチャネルを使っ てみたり、コーヒーと引き換えに インタビューしたり、CraigsList に掲載してみたり、など、大企業 では考え付かないことなどを試し て見る。 ただしこれらは失敗が前提となる ので、失敗を許容する体制を整え たり、手法も実験を繰り返しなが ら進める必要がある。 バッチサイズを小さくする 投下する時間や資源のサイズ (バッチサイズ)を小さくするこ とで、失敗をしたときにすぐにわ かる。また失敗の原因がわかりや すい。ただしコストがかかるよう に見える(実際には無駄なものを 作っていないので無駄はない)。 何より、何が今一番大切かをはっ きりさせることができる。 (バッチサイズの話は Lean Startup, 第 9 章を参照)
  51. 51. バッチサイズを小さくする 51
  52. 52. これまでスタートアップの仮説検証の相談に乗ってきて、Lean Startup の第 9 章で語られる「バッチサイズ」の内容について 詳しく解説する必要を感じたため、本スライドではバッチサイ ズについてページ数を割いて解説する。 特に初期のスタートアップは「仮説の 1 個流し (Single Piece Flow)」を意識しながら進めていくのが良いと考える。詳細は以 下で解説する。 52 バッチサイズ
  53. 53. 「プロダクトを一気に作る」といったような大きなバッチで検証を仕掛けるとムダが多い。この章で は仮説を細分化して検証していくことのメリットを紹介する。 53 仮説検証はスモールバッチで行う サイズを細かく分ける 大きな仮説検証のサイクルを細かく分けて、リスクの 大きい順から検証していく。 種類ベースでバッチを分ける Lean Canvas のように、種類でバッチを分けて検証 していく。 ⑦ コスト構造 ① 課題 (既存の代 替品) ④ ソ リュー ション ③ 独⾃自の 価値提案 ⑨ 圧倒的 な優位性 ② 顧客セ グメント (Early Adaptor) ⑥ 収益の流流れ ⑧ 主要指 標 ⑤ チャネ ル BL M BL M BL M BL M BL M BL M BL M
  54. 54. 仮説や仮説に含まれる前提は重要度と不確実度でマッピングしてみて、今最も優先順位の高い仮説を チームで一つに絞る。 54 重要度と不確実性で分類し、優先順位をつける 不確実性 重要度 顧客 A は 顧客 チャネル の効果 Best Practice は通じる? 顧客 B は 顧客 現状最も優先
  55. 55. カンバンを使って WIP に制限を設けて管理する方法。主に仮説検証のフローに着目して管理する。 特に方向性のぶれやすい初期のスタートアップには仮説の一個流しをお勧めする。 55 仮説検証のフロー管理(例): 仮説の一個流し 未検証だが 学びたいこと 仮説と検証方法 Build (バッファ) Measure 結果と 検証された学び この区間の WIP (Work in Progress) は 1 (タイムボックスは最大でも 1 週間程度) 顧客 A は 顧客 課題 B が あるのか ------------ 検証方法: Interview チャネル の効果 顧客 B は not 顧客 課題 A は なかった いわゆる Build ‒ Measure - Learn Best Practice は通じる?
  56. 56. バッチサイズを大きくして大量生産を行えば一見効率が良いように見える。 56 一見バッチサイズが大きいと効率的に見える セットアップタイム プロセスタイム キュータイム ウェイトタイム セットアップタイムは変わ らないので、バッチの回数分 時間が長くなっている 在庫の流れ 一気に流した方がプロセス間の輸送の回数 が少なく早い。 時間の流れ 個人レベルで考えるならバッチサイズは大きい方が作業に集中 できるし、直感的に考えても一気にやったほうが早い。 プロセス A プロセス B プロセス C バッチサイズ大バッチサイズ小
  57. 57. 逆にバッチサイズが小さいメリットは、マーケットのニーズに合わせて供給の変動を行いやすいとい う点(プルでの生産)。 また一部の業務では、理論的にはバッチサイズが大きいほうが早く思えるものの、実際にはバッチサ イズが小さいほうが早いケースもある。 57 実際にはバッチサイズが小さい方が早いこともある 例)One Piece Flow Simulation 封筒を作るのに、手紙を 10 枚折って、10 個入れ て、とやるより、一つずつ封筒を作った方が早い。 これは、大量生産モデルには、ひと束の在庫の移動 の時間や、失敗時の一括修正のコスト、待ち時間な ど、「隠れたコスト」が含まれているから。また作 業を分けると作業の目的や意味も見えにくくなる。 https://www.youtube.com/watch?v=Bi9R1Hqr8d
  58. 58. さらに何か問題が起こった時、一個流しであれば作業がムダになる可能性が低い。これは特に不確実 な状況下では大きなメリットになる。 58 例)ミスが見つかったときのムダの発生が少ない ムダ 大きなムダが発生する在庫的デメリット 前工程の作業者に大きな割り込みが入る (例えば資料を全ページ作成後にレビュー を出して、根本からやり直しになる等) 大きなムダが発生する時間的デメリット やり直しのタイミングが遅くなり、効率が悪い(ソフトウェア 開発におけるバグの修正速度は、開発直後と数週間後では数十 倍違うと言われている)
  59. 59. 一個流しは、特に不確実な状況下に効果的であり、スタートアップの初期は基本的に一個流しで検証 していったほうが良い。 59 仮説の一個流しが適切な場面 極度に不確実な状況下(初期のスタートアップ) 決まり切っており、ミスが少ないものであればバッチ サイズを大きくしたり、タイムボックスでの管理が効 率的になってくることもある。 しかし不確実な状況下ではバッチサイズが大きいと失 敗した時のムダが多くなる。 さらに割り込みが多い作業はカンバンでの管理が便利 (Essential Scrum)。また一個流しであれば、チー ムのフォーカスが一つの仮説に絞られるメリットもあ る。 セットアップタイムが小さい場合 セットアップタイムが少ないのであれば、バッチサイ ズを小さく回数を多くしても、大きく影響は出ない。 また非ボトルネックの空き時間や資源を使ってセット アップタイムを短縮できるほか、ソフトウェアの場合 は自動化(たとえばコンテナ化や継続的デリバリーの 仕組み構築)を行うことでセットアップタイムを極め て小さくすることが可能。 セットアップタイムを短縮すれば いつでも効果的になる • 非ボトルネック資源の投下 • 自動化 (バラツキの抑制も) • インタビュイーの常駐
  60. 60. その他、タイムボックスを設けた一個流し (シングルピースフロー) を行い、そのフローの維持をす ることは、その速さだけではなく様々な副次作用も得られる。 60 仮説を一個流しにして、フロー維持の努力をする 大きなバッチで検証できない 小さなバッチサイズかつ期間限定 という制限をつけることにより、 そのサイズでの MVP を作るべく ハック する環境を強制的に作る ことができる。 一週間は短いと思われるかもしれ ないが、仮に 1 仮説に一週間かけ たら年間約 50 個の仮説しか検証 できない(そしてスタートアップ の寿命は前回の資金調達から大抵 1 年で決まる)。 仮説の優先順位付けと Focus カンバンを用いることで作業を見 える化できるだけでなく、WIP を 1 に制限すると、仮説検証の優先 順位をつけざるをえなくなり、結 果的にフォーカスが可能になる。 (マルチタスクを許可すると、 チームメンバーが個別に合意の取 れていないことをやりがち) またタイムボックスを設けること で平準化が行われ、経営の予測が つく(=事業の成功の予測という より、資源が尽きるまで後どれだ け実験できるかの予測がつく)。 何がボトルネックか把握できる 一個流しの場合、仮説検証がうま く流れないところがボトルネック であるとすぐに判別できる。ボト ルネックを解消することで、検証 スピードを改善できる(あるボト ルネックを解消すると必ず別のボ トルネックが生まれるので順次改 善していく)。 ただしボトルネック自体に原因が あるケースもあれば、別のところ に原因があるケースもあるので、 注意深く原因を把握すること。
  61. 61. 仮説検証のフローが止まれば、そこに根本的な原因があることが多い。よくあるパターンを以下に示 す。理想はフローを止まらないようにすること。 61 流れるような仮説検証を: ボトルネックを探る 未検証だが 学びたいこと 仮説と検証方法 Build (バッファ) Measure 結果と 検証された学び 顧客 A は 顧客 チャネル の効果 顧客 B は not 顧客 課題 A は なかった • MVP のサイズ が大きすぎる • 計測のセット アップコスト高 • 段取り不足 • 社内プロセスに よる遅延 • 顧客ベースが十 分にない • 定量的調査をす る以前の段階 • 検証が下手 • Vanity Metrics になってる Best Practice は通じる? 各ステージで スタックする理由 課題 B が あるのか ------------ 検証方法: Interview
  62. 62. BML の後工程のことを考えずにフローを流してしまうと後工程で失敗が見つかり、ムダが発生しや すい。 62 その他の Build ‒ Measure ‒ Learn の設計ミスの例 Learn における設計ミス • そもそも学びたいことが明確で はない • 顧客インタビューが下手で、良 い洞察を得られない • 顧客の発言をそのまま学びとし てしまい、顧客の発言の本当 の 原因 にまで深堀りできてい ない • 検証のメトリクスが「行動への 繋がりやすさ (Actionable)」 「分かりやすさ (Accessible)」 「チェックしやすさ (Audible)」の基準を満たせてい ない Measure における設計ミス • 仮説立案フェーズで検証のコス トや存在を無視していて、 Measure の段階で長く止まる (仮説立案と検証方法はセット で考える) • 定量調査をしようとしても、十 分な顧客がいない • 顧客インタビューに固執しすぎ ていて、他の方法を検討してい ない • 検証の段取りが下手で、時間が かかりすぎている Build における設計ミス • MVP のサイズが大きすぎて Build に時間がかかりすぎる • MVP のサイズが大きすぎて、 結果的にムダが多くなる • 一気に複数の MVP を作ってい てフォーカスがぶれていて、う まく検証できないものを作る • Viable (実用的) であることを低 くみすぎる。Viable かどうかは 顧客の環境やプロダクトのカテ ゴリによって大きく異なるし、 MVP によっても異なる
  63. 63. 仮説の一個流しをするときには以下のような点を注意しながら進めると良い。 63 仮説の一個流しをするための Tips スケールしないことをする 「スケールしないこと」をするの は仮説の一個流しに近い。 DoorDash のように最初は手動で 行いつつ、徐々にボトルネックを 自動化していくことで、顧客の反 応を確かめつつ仮説検証をしてい くと良い。 ばらつき (ムラ) を抑える 人手でやっていたタスクを自動化 することで、セットアップタイム などを短縮できるほか、ミスを減 らし、結果的にばらつき (ムラ) を 抑えることができる。 バッチサイズが大きいとその分、 不必要な結果や品質のばらつきが 起こりやすい。小さなバッチサイ ズで行うことでばらつきを最小限 にすることが可能。その他、作業 項目を大きさで分類してばらつき の予測可能性を抑えることも可能。 最初にリズムを作る まずは短期間の仮説検証のリズム を作ることを優先したほうが良い と考えている(そのほうが初期は 成功しやすい印象)。リズムを体 に慣れさせて、仮説の質を上げる のはリズムが整ってきてからで良 い。またリズムがあると予見可能 性が上がるほか、ムリを減らすこ ともできる。 また初期の仮説検証はリズムを早 めて速度を上げることも積極的に 検討する。
  64. 64. 速度 学習 集中 64 スタートアップ初期は特に 集中して速く学ぶ
  65. 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. 66 リーンスタートアップや その他の方法論に銀の弾丸はないので、 良いところだけを取り入れるつもりで 他に良い方法があったら教えてください!!
  67. 67. 67 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 無 駄 を少なくする 良い仮説検証を繰り返して、成功までの

×