1. リーン・スタートアップとは
何であって何でないのか
2014/2/22 JVCC栃⽊木 分科会
ヤフー株式会社 CMO室
河合 太郎郎

2. ソフトウェアの歴史は
開発プロセスの歴史
主にウォーターフォールとの戦い

3. 理理想的な
ウォーターフォール
⼯工程1
100%
⼯工程2
100%
⼯工程3
100%
成果:100
成果:100
成果:100

4. しかし⼈人間なので
100％はうまくいかない
⼯工程1
90%
⼯工程2
90%
⼯工程3
90%
成果:90
成果:81
成果:73

5. ＼全部やり直し！／
しかも最終⼯工程に⾄至って
初期⼯工程での不不具合が発覚
「絶対に失敗しない前提」
⼯工程1
90%
⼯工程2
90%
⼯工程3
90%
成果:90
成果:81
成果:73

6. ソフトウェア産業：
• 機械ではなく⼈人間が主体
• ⼤大量量⽣生産ではなくワンアンドオンリー
ウォーターフォールは機能しない

7. 「⼈人間は失敗する」「確かなもの
など何もない」という前提
↓
ソフトウェアの開発プロセスが
様々な分野に応⽤用される理理由
⼈人が関わる不不確かな問題すべての課題解決に共通

8. 「課題の本質を明らかにし、
その成果を最⼤大化する」
すべての⽅方法論論に共通するメタ的な⽅方法論論

9. 領領域をフォーカスし、
具象化したのが各々の⽅方法論論
「何にでも使える」は何にも使えない

10. リーン・スタートアップの
フォーカスする領領域
• いかにして解決に値する顧客の課題を⾒見見出すか
• 開発するソリューションは顧客が求めるものか
• 継続的に成⻑⾧長していくためには
課題
開発
リリース
成⻑⾧長

11. リーン・スタートアップが
フォーカスしない領領域
• 具体的な開発の進め⽅方
• チームビルディング
• 開発やリリースの技術的なレイヤ
課題
課題発掘
開発
開発⼿手法
リリース
技術レイヤ
顧客開発（顧客へのアプローチ）
チームビルディング
成⻑⾧長

12. リーン・スタートアップの
背景にある課題

13. 企画書あるある
•「この分野には強い需要があり..」
•「マーケット規模は1,283億円..」
•「初期DUBの想定は11万8千..」
look at alll the papers! by Sara Grajeda
http://www.flickr.com/photos/20220847@N05/3695743740/
http://creativecommons.org/licenses/by/2.0/legalcode

14. Not amused by Matthijs
http://www.flickr.com/photos/35211570@N00/1414777160/
http://creativecommons.org/licenses/by/2.0/legalcode
全部ウソです
控えめに⾔言えば希望的観測です

15. 「最⼤大のムダは、誰も求めて
いないものを作ることだ」
-‐‑‒ エリック・リース（”The Lean Startup”著者）
思い込みの
KIKAKU
思
いと
凄
る
って
App
誰も欲しがって
くれなかった！

16. サービスの出発点は
もちろんアイデア

17. でもアイデアは
あくまで仮説にすぎない

18. 検証されない仮説は
思い込みでしかない

19. 「リアリティ」に
意味は無い
必要なのは「リアル」

20. ジレンマ
• 顧客の求めるものを作らなければそれ
•
はムダである
しかし顧客の求めるものかどうかは顧
客に実際に確かめなければ分からない
ムダなものを作らないとムダかどうか
分からない
•

21. リーン・スタートアップが
提案する解決
• 製品全体ではなく、もっと⼩小さい単位で顧客
•
•
の仮説を検証する
仮説を検証するために最低限な要素を備えた
プロダクトを作る
仮説→検証→修正のサイクルを効率率率よく回す

22. 仮説→検証→修正サイクル
仮説
idea
学習する
learn
構築する
build
データ
data
MVP
計測する
measure

23. ⼩小さい単位の仮説
•ex)「このテーマで本を書いた
ら読む⼈人はいるだろうか？」
•ex)「この技術は本当に実⽤用的
だろうか？」等々

24. MVP(Minimum
Viable Products)
仮説を検証するための最低限な要素を
備えたプロダクト

25. プロトタイプとMVPの違い
• MBPには背後に検証すべき仮説がある
• MBPは実際のプロダクトに限らない。ビデオや
ペーパーモックアップもMBPになり得る
MVP＝意思決定のためのシンプルで本質的な問い
プロトタイプ＝イメージの外部化・共通化

26. 効率率率良良く回すために
• 仮説は最適か
最もリスクの⾼高いも
のから確認しなけれ
ばいけない
• 学習は充分か
学習がなければムダ
な努⼒力力になる
• 速度度は速いか
速度度が遅いとリソー
スを浪浪費してサイク
ルが進まない
仮説
idea
学習する
learn
構築する
build
データ
data
MVP
計測する
measure

27. 理理想的な場合
⼤大きな振れ幅からだんだん
⼩小さい振れ幅に、効率率率よく
本質にフォーカスしていく

28. 仮説が最適でない場合
より優先的に確かめるべき仮説から
検証していないので、いつまで経っても
フレーム内に対象を捉えられない

29. 学習が⾜足りない場合
仮説と検証から学ばないと
いつまで経っても振れ幅が
収束せず、ピントが合わない

30. 速度度が遅い場合
振れ幅は収束していても速度度が遅いため
リソースを使い切切る前に対象を捉えきれない

31. 部分最適化 vs 全体最適化
最適化は領領域全体で⾏行行わなければ意味が無い
この鎖の強度度は？

32. リーン・スタートアップだけを
実践しても全体最適化にならない
現場全体を最適化する⽅方法は都度度考えなければならない
⽅方法論論だけ学んでも使い物にならないのはこれが理理由
課題
課題発掘
開発
開発⼿手法
リリース
技術レイヤ
顧客開発（顧客へのアプローチ）
チームビルディング
成⻑⾧長

33. Wrap up
•
•
•
ソフトウェアの開発⽅方法論論は⼈人間主体の課題解決なので様々
な分野に応⽤用できる
リーン・スタートアップは課題の発⾒見見と継続的な顧客へのア
プローチにフォーカスし、⼩小さい仮説の検証サイクルを早く
多く回すことを提案している
⽅方法論論のカバーする領領域と実際の現場の問題領領域は⼀一致しな
いため、ある⽅方法論論だけを実践しても全体最適化にならない