http://www.slideshare.net/i2key/ss-42646030 のリライト

1. Lean
Startup
Overview
Recruit Holdings
Business Development Office
Kuroda Itsuki @i2key

2. 黒田 樹 (@i2key) <= Follow me :-)
前職ではSIerで官公庁系大規模システムのアーキテクト。
Java屋。数多くのデスマを経験。
昨年度までは、全世界でシリーズ累計1400万DLのアプリ
cameranシリーズの開発全体責任者（開発、採用、組織構
築、プロセスetc）でした。また、社内外でリーンスタート
アップやアジャイルの登壇とかをたまにしています。
現在は、今までの経験やノウハウを使い海外のマイナー出資
先スタートアップの日本展開支援をしています。
http://99designs.jp
支援先スタートアップ

3. LEAN STARTUP
顧客開発モデル
アジャイル開発
仮説検証学習の
サイクル

4. No business plan
survives first contact
with customers.
- Steve Blank
いかなるビジネスプランも
顧客と対話すると無傷では
いられない

5. 傷だらけになったが、
そこから復活を遂げた例

6. 出会い系サイトを作る
↓
うまく行かない
↓
動画共有機能は良く使われている
↓
動画共有サイトにピボット

8. 位置情報チェックインアプリを作る
↓
うまく行かない
↓
写真共有機能は良く使われている
↓
写真共有サイトにピボット

10. オンライン募金サービスを作る
↓
うまく行かない
↓
共同購入機能は良く使われている
↓
共同購入サービスにピボット

12. オンラインゲームを作る
↓
うまく行かない
↓
写真共有機能は良く使われている
↓
写真管理共有サービスにピボット

14. PDA暗号セキュリティサービスを作る
↓
うまく行かない
↓
Web向け送金機能は良く使われている
↓
ネット決済サービスにピボット

16. 世の中の成功してるサービス
の60%以上が、最初のビジ
ネスアイデアを捨てている。
市場にだして顧客に聴いてみ
ないと分からない。

17. なぜ？彼らは死なないですんだのか

18. 失敗から学びを得ている

19. ビジネスアイデア全てを
仮説と捉えて、
それらを小さく分割して
検証すること
効率よく失敗して、
効率よく学ぶ考え方

20. LEAN STARTUP
顧客開発モデル
アジャイル開発
仮説検証学習の
サイクル

21. ビジネスアイデア全てを
仮説と捉えて、
それらを小さく分割して
検証すること
効率よく失敗して、
効率よく学ぶ考え方

22. ビジネスアイデア全てを
仮説と捉えて、
それらを小さく分割して
検証すること
効率よく失敗して、
効率よく学ぶ考え方全部仮説
全部思い込み

23. 無駄を徹底的に省くこと
・思い込みを排除し全てを仮説と捉える
・コストに対する学びを最大化する
・失敗による損失を最小化する
成功を保証するプロセス
そのために、効率的(例:小さく/短く/安く)に
仮説を検証して学びを得る（ことが多い）
価値観

24. ビジネスアイデア全てを仮
説と捉えて、それらを小さ
く分割して検証すること
（大きくやって大きく失敗
するの効率悪いよね！！）

25. ファイル同期がいかに便利か、どのように動作す
るのかのプロモーション動画を作成し、Youtube
にアップロード。HackerNewsに流して、
事前登録者数をモニタリングでニーズを実証。
仮説を小さく実証する例①

26. 例）写真加工アプリにフィルター購入機能を作ろう！！やり
たいことの実装工数は3人月くらいかかりそうです。
あなたがこのプロダクトのオーナーならどうしますか？
①フィルター購入機能を3人月かけて実装する
（一切購入されないリスクそのまま）
②フィルタ購入するボタン（ダミー）を用意して、全体のユー
ザーの10%に表示して確認し、本当に購入ボタンが押された
回数を測定してから開発着手の判断をする。工数は2人日。
（本当に購入されるのかのみを検証）
②のほうが無駄の無い判断してるぽい
仮説を小さく実証する例②
15

27. 100円で
購入
100円で
購入
現在開発中です！
近日リリース予定です！
＜ポップアップ＞
ユーザー全体の10%にだけ
表示されるボタン

28. ただし、あくまで事例であ
りテクニックではないので、
何でもダミーボタン等で検
証するとかではない。その
価値観を学ぶことが大事。

29. これはLean Startupとは関係ない
お金のかからないスタートアップ手法
速いスタートアップ手法
ショートカット出来るスタートアップ手法

30. 非常に参考になる書籍達
①
③
②
④
導入
How to
Case Study
各種ディテール

31. 非常に参考になる書籍達
⑤ビジュアルで全体ふわっと把握

34. 顧客開発モデル
アジャイル開発{

35. LEAN STARTUP
顧客開発モデル
アジャイル開発
仮説検証学習の
サイクル

36. 製品コン
セプト作り
製品開発 評価試験
発売/リ
リース
製品開発プロセス
ウォーターフォール型プロセス

37. 保有リスク量
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
ウォーターフォール型プロセス
あれ？流行らない。
よし、機能追加だ！
もっと豪華な
フィルターを売るぞ！
まだまだ機能が
足らんぞおおお！
マーケットプレイスに
すべきだ！！！！
フィルター購入機能を
つくるぞ！
3人月

38. 顧客発見 顧客実証 顧客開拓 組織構築
顧客開発モデルによるプロセス
「ヒト・モノ・カネを散々投じた挙げ句誰も欲しがらないものを開発して
しまう」という新規事業・新商品の典型的失敗を避けるためのプロセス
4つのステップで顧客相手に仮説検証を繰り返し、リスクを潰していく
[ニーズ検証] [売って検証] [リーチ検証] [本格拡大]

39. 時間
顧客開発モデルによるプロセス
保有リスク量
2人日

40. 結果から学ぶ
仮説の実験
結果の計測
時間
保有リスク量
2人日
全体の10%のみに出す
ダミー購入ボタン作る
計測した結果、全然
クリックされていない
需要ないんだね、
あぶなかった・・・
（リスクがゼロになる）
顧客開発モデルによるプロセス

41. リスク
時間
顧客いる？ 課題あってる？ 解決策あってる？
顧客開発モデルによるプロセス

42. 顧客セグメントを明らかにする
市場タイプを選ぶ
顧客との関係
キーパートナー
売上/プライシング
顧客理解
トラフィック/競合分析
顧客の行動測定
アドバイザリーボードメンバーの選定開始
：
：
そのためにやるべきこと

43. LEAN CANVAS

44. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
27

45. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
スタートアップ（新規事業）の
初期段階における不確実性（リスク）を
一枚のシートにしたもの
※ただし銀の弾丸ではない

46. Product Market
LEAN CANVAS

47. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
① ①③
②
②
③

48. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？ 実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
目指す状態

49. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？ 実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
目指す状態
新規仮説
新規仮説
新規仮説
常に変化するもの（完璧を求めない）

50. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
顧客は誰か
その顧客は本当に存在するのか、脳内の空想じゃないか
そのカスタマーセグメントである必然性はあるのか
カスタマーセグメントが後付ではないか
そのカスタマーセグメントとProblemが紐付いているか
アーリーアダプターは誰か
自分がユーザーですという場合は、自分がそのセグメントの
中央にいるか

51. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
解決すべき深い課題か
その課題は本当の課題か
既存サービスに対する性能的な課題になっていないか
その課題はカスタマーセグメントに紐付いているか
ステレオタイプに対して課題を解決しにいってないか
（代替手段があるか、ある場合どうやっているか
チームのケーパビリティで解決可能な課題か

52. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？課題に対する解決策になっているか
解決策ありきになっていないか
アーリーアダプターが代替手段で解決している状況においてスイッチングコス
トを支払ってまで乗り換えてもらえる解決策になっているか
プラットフォーマーがそれやったらどうするの？に答えられるか
解決策に実現性が伴っているか（チームケーパ/技術動向/etc）

53. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
ユニークバリューを提供できているか。
プラットフォーマーがやっ（ｒｙ
ユニークバリューが圧倒的な○○○であ
るか（注意も必要）
独自の価値提供をできているか。

54. リーンキャンバスの記述レベル。
粒度って、どんくらいすか？
【良くある質問】

55. 決まりはない！
自由で良い！

56. そのドメイン知識がある人と無い人では出来上がったものは全
く違う。自分の戦うドメインの知識が充分にあることが前提。
それが無い場合は、必要な仮説検証サイクルの回数が増える。
顧客に会う、聴く、勉強する。顧客理解を深めると自ずとキャ
ンバスの記述レベルが深くなるし、具体性が増す。これこそが
顧客開発でもある。
あっさりしたものしか書けない場合は、そのドメインの知識が
浅いのかもしれないと一度立ち戻ることも必要。
ただし
Founder / Market FIT

57. 顧客発見 顧客実証 顧客開拓 組織構築
Problem
Solution
Fit
Product
Market
Fit
Pivot
Scaling
アジャイル開発
実証済み 実証済み実証済み
実証済み
実証済み
実証済み 実証済み
実証済み
実証済み 実証済み
実証済み
実証済み
実証済み 実証済み

58. 顧客発見 顧客実証 顧客開拓 組織構築
Problem
Solution
Fit
Product
Market
Fit
Pivot
ユーザーの深い課題/ニーズを把握し
解決策を提示しそれが刺さっている
ビジネスモデルの成立することが
実証できている
（Engine of Growthが装着できている）
例）CAC < LTV
Scaling
例）Retentionしている

59. LEAN STARTUP
顧客開発モデル
アジャイル開発
仮説検証学習の
サイクル

60. 時間
顧客開発モデルによるプロセス
保有リスク量
2人日

61. 結果から学ぶ
検証用開発
結果の計測
時間
保有リスク量
2人日
全体の10%のみに出す
ダミー購入ボタン作る
計測した結果、全然
クリックされていない
需要ないんだね、
あぶなかった・・・
（リスクがゼロになる）
顧客開発モデルによるプロセス

62. リスク
時間
顧客いる？ 課題あってる？ 解決策あってる？
顧客開発モデルによるプロセスアジャイル開発
一定のペースで、短い感覚で開発を繰り返す。
完璧な製品ではなく、
仮説検証に必要な最低限のプロダクトを提供する。

63. アジャイル宣言の背後にある原則
http://agilemanifesto.org/iso/ja/principles.html
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/

64. アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、
価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。
変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月という
できるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して
日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。
環境と支援を与え仕事が無事終わるまで彼らを信頼します。
情報を伝えるもっとも効率的で効果的な方法は
フェイス・トゥ・フェイスで話をすることです。
30

65. 動くソフトウェアこそが進 の最も重要な尺度です。
アジャイル･プロセスは持続可能な開発を促進します。
一定のペースを継続的に維持できるようにしな
ければなりません。
技術的卓越性と優れた設計に対する
不断の注意が機敏さを高めます。
シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
最良のアーキテクチャ・要求・設計は、
自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを
定期的に振り返り、
それに基づいて
自分たちのやり方を最適に調整します。
30

66. いろいろなやり方

67. LEAN STARTUP
顧客開発モデル
アジャイル開発
仮説検証学習の
サイクル
30

68. Dropboxの動画やフィルターのダミーボ
タンみたいなのをMVPと言ったりします
Minimum Viable Product
実行可能な、生存可能な、存続可能な、最小限の製品
仮説を検証するために必要な最小限の何か。
・プロダクト
・インタビュースクリプト
・説明スライド
・ペーパープロトタイピング
and so on…
仮説が検証できれば別に完璧な製品である必要はない

69. 仮説立てる->MVPをつくる->測る->学ぶ
MVP
ビジネスアイデアを
仮説として捉えて
検証するためのプロセス。
仮説検証のためのMVPを
Buildして
それを元にMeasureし、
その結果得られたデータから
Learnする。
つくる
測る
学ぶ
仮説たてる

70. ECサイトを作らずに、近くの靴屋に売れたら
全額支払う&郵送は自分たちでやるといって、
靴の商品写真を撮影。サイトにアップ。靴が
売れたら創業者がその靴屋で靴を買い自ら顧
客に郵送していた。

71. WordPressでGrouponスキンをかぶせ
てブログ形式ではじめて、運用のクー
ポン発行は人力でメール送信。
システム化せずにニーズを検証

72. サンフランシスコにある自分のオフィスのMTG
ルームを人が泊まれるようにして、Googleに広告
を出して、人が応募してきて、お金を払って、泊ま
るのかを検証。

74. MVPの粒度って
どれくらいですか？
【良くある質問】

75. 知らん！

76. MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
MVPで検証する
こういう場合もあるし

77. 1つのMVPで
全ての仮説を検証する
こういう場合もある

78. リスク
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
製品開発プロセス

79. リスク
時間
顧客発見 顧客実証 顧客開拓 組織構築
顧客開発モデルによるプロセス

80. Learn
Build
Build
Measure
Measure
リスク
時間
顧客開発モデルによるプロセス

81. 顧客発見 顧客実証 顧客開拓 組織構築
Problem
Solution
Fit
Product
Market
Fit
Pivot
Scaling
アジャイル開発
実証済み 実証済み実証済み
実証済み
実証済み
実証済み 実証済み
実証済み
実証済み 実証済み
実証済み
実証済み
実証済み 実証済み

82. 仮説検証の設計の仕方
仮説検証のサイクル（BUILD-MEASURE-LEARN）を
まわすためには、下記の流れで検証の設計をします。
（１）仮説は何か
（２）仮説を実証するために、何を学ぶか
（３）そのために必要なデータは何か
（４）そのデータをどう計測するか
（５）計測するために何が必要か
（６）それをどう構築するか（複数案考える）
その中で最も効果的な方法は何か選択する
45

83. ①仮説
②何を学ぶのか
③必要なデータは？
④どうやって計測する？
⑤必要なものは？
⑥どう構築するか？
思考プロセス
45

84. ⑫仮説を調整する
⑪学ぶ
⑩データを元に検証
⑨データを計測する
⑧完成したMVP
⑦構築する
実証プロセス

85. 空いているスペース（もしくは留守中の自分の家）を貸し出せ
ば、それを使ってくれる人がいるのではないか。
※AirBnBを題材にした本スライド用の例であり私の妄想です
大きなチャンクで実験してもツラいので仮説を分解してみる
＜貸し出す側＞
・そもそも貸すのか
・貸す場合は、借りてがつくクオリティの状態の家がでるのか
・需要に対する供給量が確保出来るのか
＜貸りる側＞
・本当に借りるのか（リスクが一番高い。優先度1）
・どのような部屋なら借りるのか（立地、値段、間取り・・）
例

86. ①仮説
・人の家でもお金を払って借り
②何を学ぶのか
・本当に借りるのか
・いくらなら借りるのか
③必要なデータは？
1回以上の利用
応募数
④どうやって計測する？
⑤必要なものは？
集客する装置
⑥どう構築するか？
・マッチングサイト構築
・Googleアド
思考プロセス

87. ⑥どう構築するか？
(MVP案1)マッチングサイト作って他人の家を使う
(MVP案2)自分のオフィス泊まれるアド出す
もっとも効果的に学びが得られるMVPはどれか選択する
・費用対効果
・期間
・工数
・この検証方法により回避できる将来のリスク
・この検証方法により逆に発生する将来のリスク
思考プロセス

88. ⑫仮説を調整する
⑪学ぶ
⑩データを元に検証
⑨データを計測する
⑧完成したMVP
⑦構築する
(MVP)オフィス&アド
実証プロセス

89. Acquisition
獲得 Retention
継続
Churn
解約
Referral
紹介
Activation
活性化 Revenue
収益
AARRRモデル復習
※ChurnはAARRRには
無いけど勝手に付け足しました

90. LEAN STARTUPを
理解した上で
他流（AARRR）に目を向ける

91. Acquisition
Retention
Churn
Referral
Activation
Revenue
一番大事

92. 継続して利用してくれているということは
顧客の課題を解決していること
（それが想定していない課題を解決してることもあるけど）
ユーザーがプロダクトに
価値を感じている状態
エンゲージしている状態
Problem Solution Fit

93. 継続して利用してくれているということは
顧客の課題を解決していること
（それが想定していない課題を解決してることもあるけど）
ユーザーがプロダクトに
価値を感じている状態
エンゲージしている状態
Problem Solution Fit
AARRRAARRR

94. 顧客発見 顧客実証 顧客開拓 組織構築
Problem
Solution
Fit
Product
Market
Fit
Pivot
Scaling

95. 実証済み
実証済み
実証済み
実証済み

96. Acquisition
Retention
Churn
Referral
Activation
Revenue
一番大事

97. 最もスループットの低い部分が、
全体のスループットを決める
（鎖の強度は、最も強度の弱い
輪が全体の強度になる）
最もリスクの高い部分から、
検証していく

98. LEAN CANVAS
顧客は誰？課題は何？
解決策は？
価値は何？
圧倒的優位性は何？
コスト構造は？ 売り上げは？
顧客にリーチするための
チャネルは
何を測る？
リスク高 リスク中リスク中
リスク中
リスク中
リスク中
リスク中
リスク中

99. LEAN CANVAS
①
②
②
②
③
⑩
⑤
⑩
⑫ ②
⑩
⑩
鎖の強度が弱い

100. Growth Hack(er)
AARRR
LEAN STARTUP
Customer Development
メタレベルでとらえると
どれも言ってる本質は同じ
Theory of Constraints(ToC)
Agile

102. 車を売る
オフィスを引き払う
コワーキングスペースに住みつく
エンジニア雇うお金が勿体無いから
自分で勉強してコードを書く
西海岸スタートアップでは
ファウンダーは・・・

103. 黒田「リーンキャンバスの書き方を相談したいのですが」
ファウンダーA「何それ？リーンキャンバスって何？」
500 startupsに入ってるとあるスタートアップとの会話

104. 黒田「スティーブブランクのスタートアップマニュアルに
こうかいてあったんですが、どうやりました？」
ファウンダーB「何それ？へー、そんな本あるのか」
500 startupsに入ってるとあるスタートアップとの会話

105. 資金のバーンダウンしていく速度をいかに遅くして
なおかつ学びを得るか、そして成功するか

106. Growth Hack(er)
AARRR
LEAN STARTUP
Customer Development
メタレベルでとらえると
どれも言ってる本質は同じ
Theory of Constraints(ToC)
Agile

107. 無駄を徹底的に省くこと
・思い込みを排除し全てを仮説と捉える
・コストに対する学びを最大化する
・失敗による損失を最小化する
成功を保証するプロセス
そのために、効率的(例:小さく/短く/安く)に
仮説を検証して学びを得る（ことが多い）
価値観

108. ビジネスアイデア全てを仮
説と捉えて、それらを小さ
く分割して検証すること
（大きくやって大きく失敗
するの効率悪いよね！！）

109. Problem
Solution
Fit
Product
Market
Fit
Scaling
実証済み
顧客/課題
存在するか
解決策
あってるか
解決策に
顧客はお金
はらうか
実証済み 実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み

110. リスク
時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop
ウォーターフォール型プロセス

111. Learn
Build
Build
Measure
Measure
リスク
時間
顧客開発モデルによるプロセス

112. リスク
時間
カスタマ 課題 UVP/解決策
実証済み 実証済み 実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
実証済み
顧客開発モデルによるプロセス

113. No business plan
survives first contact
with customers.
- Steve Blank
いかなるビジネスプランも
顧客と対話すると無傷では
いられない

114. ご清聴ありがとうございました！