Leanstartupをリーンにヤル #リーンスタートアップ
32 likes27,999 views
Lean Startup Update! 2018 〜3年間のリーンスタートアップのアップデート会〜 の資料になります。 https://leanstartup.connpass.com/event/72252/
More Related Content
What's hot (20)
Similar to Leanstartupをリーンにヤル #リーンスタートアップ (20)
More from Itsuki Kuroda (14)
Leanstartupをリーンにヤル #リーンスタートアップ
- 2. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行
- 3. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行 ここを効率よくすすめる話
- 7. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B 10
- 8. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B 10 「リソース効率性」が良い （例）稼働率100%、リソースに遊びが無い 「フロー効率性」が良い （例）機能リリースまでのリードタイムの短さ
- 9. リソース効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 複数のことを同時にやるとプロダクトがユーザに届くまで・検 証を開始するまでのリードタイムが長くなる。 ただし、皆に仕事が割り振られるため、また時間の余る限り複 数の仕事を持つためリソースあたりの稼働率は高くなる。
- 10. 1つのリソースを稼働率が100%になるまで分配する 例 ・マルチタスク ・大きなウォーターフォール型開発（SOR的） A B C Resource 流れる対象 30% 30% 40% リソース稼働率：100% (作業時間を絞り出す量を最大化) 1リソースに フォーカスする 流れる対象 流れる対象 リソース効率性
- 11. フロー効率性 A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B 同時にやることをひとつにするとプロダクトがユーザに届くま でのリードタイムは短くなる。しかし、全員が同じことをやる ため、一時的に手持ちがなくなる人が出たりするためリソース の稼働率は下がる。 （総生産量は期間のとり方によっては下がる）
- 13. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 約2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 A A A B B B B B B 10
- 14. リソース効率性とフロー効率性 A A A A A A A A A A A A A A A B C B C B C B C B C B C B C B C B C B C B C B C B C B C B C A A A A A A A A A A A A A A A B B B B B B B B B B B B B B B C C C C C C C C C C C C C C C 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リリースまでのリードタイム 2w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w リリースまでのリードタイム 3w A機能、B機能、C機能の実装それぞれ15人日かかる場合 「リソース効率性」が良い （例）稼働率100%、リソースに遊びが無い 「フロー効率性」が良い （例）機能リリースまでのリードタイムの短さ 10
- 18. Efficiency Paradox This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 19. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態
- 20. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・それぞれの島の中において資源効率が高く、島毎に個別最適化された状態。 ・フォーカスは資源であり、独自の資源を効率的に活用することによって、 各部門は生産される商品やサービスのコスト削減に貢献 ・製造業において、各コンポーネントや製品が在庫として費やしている時間の割合が 大半を占める。 ・結果的に、顧客に価値が届くまでの時間を長くする待機時間を作り出している。
- 21. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・効率が高いが資源効率が低い状態。 ・フォーカスは顧客にあり、可能な限り効率的にニーズを満たすこと。 ・フロー効率を最大限にするには、組織のリソースに空き容量が必要。 リソースの効率的な使用を犠牲にしてフローを効率的にする。 ・効率的な海を作り流れを作り出すには、独立した効率的な島だけではなく、 全体像をよく理解する必要がある。
- 22. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・組織はそのリソースを効率的に使用することも、 効率的なフローを作成することもできていない状態。 ・リソースの浪費 & 顧客への提供価値が低い状態
- 23. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・完璧な状態 ・この状態を達成する組織は、高いリソース効率と 高いフロー効率の両方を備えている。 ・完璧な状態に到達することは困難である ・完全な状態に到達することの難しさの鍵は、Variation(ムラ)。
- 24. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い Variation This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 25. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い Variation This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 例：高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多) 例：カプセルホテル (部屋稼働率:100%) (客数に対する従業員数:少)
- 26. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation 我々 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い 例：高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多) 例：カプセルホテル (部屋稼働率:100%) (客数に対する従業員数:少) This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 27. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation WaterFall SoR Agile SoE 小規模・仮説検証 大規模開発 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 28. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 29. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 30. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 流れに着目するほうがムダを炙り出しやすい こっちから登ったほうが リソース効率上のムダも発見しやすい This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 31. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 達成することは不可能。星に到達するためには、組織は2つのことが必要。 ・顧客の現在および将来のニーズに関するすべての情報を完全に把握。 ・完全に柔軟で信頼性の高いリソースが必要。 リソースの容量、機能、能力をすぐに調整してすべてのタイプのニーズを満たすこと ここでの鍵は、需要（顧客のニーズ）と供給（組織のリソース）の両方の変化。
- 32. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 需要と供給のムラがこの境界を内側に押しこむ 到達不能領域 需要が完全に予測可能でなく、かつ/またはリソースが完全に柔軟で信頼できるものでは ない場合（需要と供給にムラがある場合） 組織がリソース効率を改善し、それを高いフロー効率とどのくらい組み合わせるかには限 界が発生する。 Efficiency Frontier Efficiency Frontier
- 33. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - Efficiency Frontier 病院の緊急医療室 大量の類似製品を製造する製造会社 到達不能領域 Efficiency Frontier 到達不能領域 需要と供給のムラがこの境界を内側に押しこむ
- 34. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - Efficiency Frontier 新規事業、スタートアップ 到達不能領域 Efficiency Frontier 到達不能領域 我々 （大量の類似製品を製造する仕事ではないため両方取りが難しい） 需要と供給のムラがこの境界を内側に押しこむ
- 36. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 ＝ 売上直結 例：CVR最大化に向けたUI/UX仮説検証 流入数
- 37. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th w 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th w ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル
- 38. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 売上 or KPI release A B C 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th w 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th w A B C 学んでいない期間 稼いでいない期間 学んでいない期間 稼いでいない期間 オーバーヘッドで 若干合計稼働は増える ビジネス価値とリソース効率性重視の開発スタイル ビジネス価値とフロー効率性重視の開発スタイル 複数の実験を 同時にやると濁る
- 40. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行
- 41. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行 ここを効率よくすすめる話
- 42. 仮説検証の学びまでのリードタイムを長くするマルチタスクをやめる 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説Aの検証 仮説Bの検証 仮説Cの検証 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説Aの検証 仮説Bの検証 仮説Cの検証 1st week 7th week 学習コスト 失敗時の損失 不確実さ リスク 学習コスト 失敗時の損失 不確実さ リスク 仮説検証をマルチタスクでやる場合 仮説検証をシングルタスク（WIP制限1）でやる場合
- 43. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説Aの検証 仮説Bの検証 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説Aの検証 仮説Bの検証 仮説Cの検証 1st week 7th week 学習コスト 失敗時の損失 不確実さ リスク 学習コスト 失敗時の損失 不確実さ リスク 仮説検証をマルチタスクでやる場合 仮説検証をシングルタスク（WIP制限1）でやる場合 学んでいない期間 学びを次のインプットへ (軌道修正し易い） 失敗の手戻りがでかい 短期間で学ぶ 失敗の痛みが小さい 仮説Cの検証 仮説検証の学びまでのリードタイムを長くするマルチタスクをやめる 軌道修正が早期に出来る
- 44. 仮説 Resource 流れる対象 1つの仮説に メンバ全員が フォーカスする Resource Resource 仮説検証をシングルタスク（WIP制限1）でやる場合 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説Aの検証 仮説Bの検証 仮説Cの検証 学習コスト 失敗時の損失 不確実さ リスク 学びを次のインプットへ (軌道修正し易い） 短期間で学ぶ 失敗の痛みが小さい 軌道修正が早期に出来る
- 45. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説検証のバッチサイズを小さくする（MVPを小さくする） 仮説A 仮説B 仮説C 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説A 仮説B 仮説C仮説A’ 仮説B’ 仮説C’ 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説A 仮説B 仮説C仮説B’仮説A’ 1仮説検証を2weeksでやる場合、26回/年 1仮説検証を1weekでやる場合、52回/年 検証結果から、実施不要の検証を省略でき、後続の検証を前倒し出来る 仮説C’
- 51. 情報の流れ（BMLを逆流） モノの流れ（BMLの流れ） ニーズ pullpullpull ①仮説②何を学ぶのか ③必要なデータ ④計測方法 ⑤必要な計量器 ⑥構築方法 ⑫実証 ⑪学ぶ ⑩データで検証 ⑨計測する ⑧完成したMVP⑦構築する push push push BUILD MEASURE LEARN BUILD設計 MEASURE設計 LEARN設計 ① ② ③ ④ ⑤ ⑥ ⑫ ⑪ ⑩ ⑨ ⑧ ⑦ 仮説検証の精度を上げる（ムダなMVPを作らない）
- 55. ① ② ① ② リードタイム ③ ③=①-② =在庫量 Ready化数 リリース数 累積フロー図 BuildPlanning Measure 工程別 滞留数 (在庫数) 在 庫 量 推 移 Learn ③ 累積Ready数 累積リリース数 ：MVP 学びまでのリードタイムを削減する（まずは開発効率化）
- 56. ③① ② Readyにした数とリリースした数 在庫数推移 ① ②Ready化数 リリース数 BuildPlanning Measure 工程別 滞留数 (在庫数) 在 庫 量 推 移 Learn ③ ：MVP 学びまでのリードタイムを削減する（まずは開発効率化）
- 58. 仮説B’ 最初に一つの仮説に絞らない/決定を遅らせる/決定時の選択肢を最大化する 仮説A 仮説A’ 仮説B 仮説C 仮説C’ 仮説D 仮説D’ 仮説D” 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説E 仮説E’ 仮説F 仮説G 解決策案の実証① 解決策案の実証② 解決策案の実証③ 仮説F’ 仮説G’ こんな感じ？ Scaling Leanの GOLEAN感 リソース効率を高める（単位時間あたりの実証ロット数を上げる）
- 59. まとめ
- 60. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア キードライバー値 最大化 利益最大化 ビジネス フェーズ AARRR ①ビジネス 仮説 ①② ③ ⑤ ① ①② ③ ④ ⑥ ⑤ ① ①② ③ ④ ⑥ ⑦⑦ ⑦⑦ ⑦ 仮説検証 実行 ここを効率よくすすめる話
- 61. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 需要と供給のムラがこの境界を内側に押しこむ Efficiency Frontier 新規事業、スタートアップ 到達不能領域 Efficiency Frontier 到達不能領域 我々
- 62. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説Aの検証 仮説Bの検証 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説Aの検証 仮説Bの検証 仮説Cの検証 1st week 7th week 学習コスト 失敗時の損失 不確実さ リスク 学習コスト 失敗時の損失 不確実さ リスク 仮説検証をマルチタスクでやる場合 仮説検証をシングルタスク（WIP制限1）でやる場合 学んでいない期間 学びを次のインプットへ (軌道修正し易い） 失敗の手戻りがでかい 短期間で学ぶ 失敗の痛みが小さい 仮説Cの検証 仮説検証の学びまでのリードタイムを長くするマルチタスクをやめる
- 63. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説検証のバッチサイズを小さくする（MVPを小さくする） 仮説A 仮説B 仮説C 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説A 仮説B 仮説C仮説A’ 仮説B’ 仮説C’ 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説A 仮説B 仮説C仮説B’仮説A’ 1仮説検証を2weeksでやる場合、26回/年 1仮説検証を1weekでやる場合、52回/年 検証結果から、実施不要の検証を省略でき、後続の検証を前倒し出来る 仮説C’
- 64. 情報の流れ（BMLを逆流） モノの流れ（BMLの流れ） ニーズ pullpullpull ①仮説②何を学ぶのか ③必要なデータ ④計測方法 ⑤必要な計量器 ⑥構築方法 ⑫実証 ⑪学ぶ ⑩データで検証 ⑨計測する ⑧完成したMVP⑦構築する push push push BUILD MEASURE LEARN BUILD設計 MEASURE設計 LEARN設計 ① ② ③ ④ ⑤ ⑥ ⑫ ⑪ ⑩ ⑨ ⑧ ⑦ 仮説検証の精度を上げる（ムダなMVPを作らない）