LEANSTARTUPの現場 #leanstartup

1. LEAN STARTUPの現場 Recruit Holdings Recruit Institute of Technology Media Technology Lab Itsuki KURODA @i2key <- Follow Me Plz :-)

2. 自己紹介 Recruit Holdings Recruit Institute of Technology Media Technology Lab 黒田樹 (@i2key) ! 全世界でシリーズ累計1000万DLのアプリcameranシリーズの開発責任者（開発、採用、組織構築、プロセスetc）社内でリーンスタートアップやアジャイルの導入を推進しています http://mtl.recruit.co.jp

3. 100

4. 速度注意本日は100スライドです。発表時間は20分です。 ! Velocity 5枚/分速すぎて見えなかったら後ほどSlideShareで・・・

5. 前回までのあらすじサービス大ヒット ↓ 増員 ↓ カオス ↓ 炎上 ↓ ギスギス ↓ 鎮火 http://www.slideshare.net/i2key/rebuild-devlove-scrum-leanstartup

6. 現場の悩みプロダクトバックログに起票されるタスクが本当にやるべきことなのか。やるべき理由はあるのか。 ! もっと効率よく出来ないのか ! そのタスク（機能）をリリースしたあとの効果はタスク（機能）毎にわかるのか。結果から学びを得ているのか。 ! やっていることはサービスの成長に直結しているのか。

7. LEAN STARTUPで解決する！

8. 守りつくして離るるとても本を忘るな破るとも千利休

9. 守破離 Shu - Ha - Ri

10. 守破離ひたすら師の教えを守り、学ぶ教えの言葉から抜け出し、他流まで理解を広げ、真意を会得する型に一切とらわれず、自分の境地に入�る

12. スタートアップマニュアルアントレプレナーの教科書リーンスタートアップ顧客開発モデルのトリセツ RUNNING LEAN LEAN UX LEAN Analytics リーン開発の現場：：：先人の知恵に触れる

13. 500Startupsメンター James氏（LeanStartup）

14. Pivotal Labs Janice氏（Lean UX)

15. Hooked著者 Nir氏 (UX)

16. Lean Analytics著者 Alistair氏 (Lean Analytics)

17. IDEO @SFオフィスデザインシンキングワークショップ（デザインシンキング)

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

19. 全ての意思決定において無駄の無い判断をしていること・思い込みを排除し全てを仮説と捉える・コストに対する学びを最大化する・失敗による損失を最小化する成功を保証するプロセス ! そのために、効率的(例:小さく/短く/安く)に仮説を検証して学びを得る（ことが多い）真意当時は真意を2ミリも理解できていないけど・・・浅い理解

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

21. 100円で購入 100円で購入現在開発中です！近日リリース予定です！インタビューで「あったら買いますか？」「買います！」みたいなやりとりよりも確度が高いそういう聴き方したときの「買います」は大抵買わないwww ＜ポップアップ＞

22. 顧客開発モデルに則って現状の理解をする。ビジネス仮説を全てLeanCanvasに書き出す。既に実証済みのことと、そうでないこを明らかにする顧客セグメントを明らかにする市場タイプを選ぶ顧客との関係キーパートナー売上/プライシング顧客理解トラフィック/競合分析顧客の行動測定アドバイザリーボードメンバーの選定開始：：顧客開発でやるべきこと Lean Canvas

23. 顧客発見顧客実証顧客開拓組織構築 Problem Solution Fit Product Market Fit Pivot Scaling Agile 実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み実証済み今自分達がスタートアップのどのフェーズにいるかを認識する

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

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

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

27. まだ実証出来ていない仮説に対してリスクの高い順に優先順位をつけて実証していく実証済実証済実証済実証済

28. じゃあ、どうやって仮説を検証するの？？？ ! MVPってのがあってな

29. MVPとはMinumum Viable Product（検証可能な最小限の製品）。 Productと言ってるけど製品じゃなくてよい。目的である仮説を検証できればよいので、それができるものならなんでもMVPと言ってよい（と思う） Build->Measure->Learn MVP ビジネスアイデアを仮説として捉えて検証するためのプロセス。仮説検証のためのMVPをBuildしてそれを元にMeasureし、その結果得られたデータからLearnする。

30. 開発をしなくても、仮説を検証できるものであればそれはMVPになる。例えばインタビュースクリプトもそう。それを作るフェーズがBUILDだと理解している。顧客開発におけるユーザーインタビューについては馬田さんのスライドに全てお任せしますので、インタビューによる仮説検証については言及しません！！

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

32. んなこた、知らん！ 5min

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

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

35. 既存市場に参入する場合には、ユーザーは競合サービスによって学習がすんでおり、その最低限ここまで出来るでしょう？という最低限品質を担保するように追ってしまうとMVPは肥大化していきます。最初にサービスを当てにいくのはなぜアーリーアダプターなのか、彼らはそのあって当たり前はなくても補完してくれる存在。それでも、競合と同等の機能がないとMVPと言えないと言うのであれば、その市場の再セグメント化をして競争しないようにするとか、戦わない選択をするとかしたほうがよいかも。既存市場での性能競争がはじまると資金を持っている企業との体力勝負になるのでつらいだけ。（個人的にそう思います）

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

37. 型を学ぶ

38. アジャイル開発 Scrum コホート分析/ファネル分析/ A/Bテスト基盤 MVP Canvas 仮説検証設計我々のLeanStartupの型

40. http://www.slideshare.net/i2key/rebuild-devlove-scrum-leanstartup

42. 実装した機能（MVP）毎に効果を検証するコホートAにリリース結果数値をウォッチコホートBにリリース結果数値をウォッチコホートCにリリース結果数値をウォッチやったことの単位に結果を見ること

43. https://www.leanplum.com A/BテストプラットフォームとしてLeanplumを採用

44. 計測例 •仮説 • SNS型サービスだが、ユーザのサインアップ率が悪い。現在他人の投稿はクローズドでサインアップしたユーザーにしか見えない。サインアップしてないユーザにも見えるようにすることでSNSのUXを事前体験・学習させるとアカウント登録率があがるのはないか。 •MVP • サインアップ不要で他人の投稿を閲覧出来る機能を実装しユーザ数%対象に公開して計測。 •学びたいこと • サインアップ率の上昇。及び、既存機能への悪影響度。

45. 実装した機能毎にコホートxA/Bテストを行い、様々なトレードオフを意識して判断する。

46. http://www.localytics.jp 全体の指標モニタリングのために Localytics採用（GAの代わり）

47. リリース後はコホートで対象バージョンのリテンション等を計測。この画面は7日間継続率。 ※サンプルデータです！

48. ver1から参加したユーザー ver2から参加したユーザー ver3から参加したユーザーフォロワー数▲人のユーザーフォロワー数■人のユーザーフォロワー数●人のユーザーこのように縦に見ないほうがよい場合がある

49. コホート分析の例・Version○○から使い始めた人の継続率・○○機能をβ公開しているユーザーの継続率・○○に「いいね」した人の継続率・○○した人の継続率・フォロワー○○人の人の継続率・○○をフォローしている人の継続率 ! 何で測るか Localytics最高。 MixPanelやLeanPlumもよい。コホートを作って、そこに向けてプッシュが打てるものもある。

51. リーンスタートアップとは科学的アプローチというけれど、その場合、実験の計画の思考プロセスは逆。こうじゃなく実際の思考プロセスはこう考えて計画する

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

53. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビュー思考プロセス

54. ⑥どう構築するか？ (MVP案1)A/Bテスト (MVP案2)ティザーページ (MVP案3)ユーザインタビューもっとも効果的に学びが得られるMVPはどれか選択する・費用対効果・期間・工数・この検証方法により回避できる将来のリスク・この検証方法により逆に発生する将来のリスク思考プロセス

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

56. http://www.slideshare.net/aerodynamic/mvp-canvas この一連の思考プロセス・実証プロセスを髙橋さんとフォーマット化！

57. http://www.slideshare.net/aerodynamic/mvp-canvas 仮説何を学ぶのか仮説実証に必要なデータ条件 MVP構築に必要なコスト仮説実証に必要な時間回避/発生する将来のリスク結果と、得た学び MVPのタイプ・紙プロト・インタビュー・A/Bテスト・動くデモ etc 何を作るのかどうやってそのMVPで実証するのか

58. LeanCanvas - MVPCanvas - Scrum 型の整理

59. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ Out of Building!!! MVPがインタビューの場合 MVPがエンジニア稼働必要な場合改善タスク・改善目的A/Bテスト・計測装置導入メンテナンスタスク・技術的負債解消・OSバージョンアップ対応・バグ対応アライアンスタスク直接仮説検証には関係ないけどサービス維持に必要なタスク

60. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞顧客発見顧客実証顧客開拓組織構築 Problem Solution Fit Product Market Fit Pivot

61. 守破離ひたすら師の教えを守り、学ぶ教えの言葉から抜け出し、他流まで理解を広げ、真意を会得する型に一切とらわれず、自分の境地に入�る 10min

62. この型をひたすら回すと・・・・

63. プロダクトバックログが最小化されていく＝やらないことが最大化されていくエンジニアの働き方（活躍出来る場所）に一部変化が出てくる＝グロースハッカーというロールの出現

65. LeanStartup以前の Product Backlog LeanStartup以後の Product Backlog ・○○検証用モック作成・○○検証用ダミーボタン実装・検証済み○○機能本実装・検証済み○○機能本実装・リファラル向上改善・登録ファネル改善・計測基盤実装・コホートに対するプッシュ実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装・○○機能実装

66. Product Backlog ＜開発タスク＞ 10個ひらめいた！ Product Owner 10個のエンジニアタスク LeanStartup以前

67. Lean Canvas ＜ビジネス仮説＞ MVP Canvas ＜仮説検証MVPの設計＞ Product Backlog ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築（エンジニアタスク） 10個のMVP設計 7個のOutOfBuilding （プロダクトオーナータスク） LeanStartup以後

68. 新規機能追加コスト＞仮説検証コスト新規機能追加コスト＜仮説検証コスト

69. プロダクトバックログが最小化されていく＝やらないことが最大化されていく＝エンジニアの開発タスクが減る＝エンジニア体制の縮小（最適化） or 技術的負債解消に当てる時間 or エンジニアドリブンで改善する時間

71. Lean Engineer 価値：仮説検証サイクルの速度を上げることコミット：サービスの成長生産性：仮説検証できた回数/時間 Not Lean Engineer 価値：開発をやりきることコミット：開発の完遂生産性：Step/時間エンジニアの働き方＝グロースハッカー

72. ここでのグロースハックの定義ボタンの色を赤から緑に変えてコンバージョン率あがりました！！ではなく

73. ここでのグロースハックの定義本質的なサービスの成長に寄与するエンジニア →ビジネスKPIにコミットする ! エンジニアはテーマを持って改善を行う例えば【継続率】及びそれを構成する意味のある数値【チャーンレート改善】 ! その数値を改善するために、自身で仮説検証サイクルを自らエンジニアリングすることにより高速で実施しビジネスKPIを向上させる。数値にコミット出来るため、権限と成果責任がエンジニアに発生する。エンジニアの適正によってはこっちのが、やりがいがある（場合もある）し、成長速度はあがる。

74. プロダクトチーム仮説に対して機能を実装する ! プロダクトオーナーエンジニアデザイナマーケタセールスアライアンスグロースチーム実証された仮説の機能を磨き上げて成長率を改善する ! エンジニアデザイナデータアナリスト（いれば） ! 数値にコミットするデータから仮説を導き出し改善サイクルを高速に回す各施策がバッティングしないための基盤が必要 A/Bテストやコホート

75. プロダクトチームグロースチームプロダクトチームP/S Fit前 P/M Fit Scaling プロダクトグロースチーム体制コスト比率フェーズに応じた体制コスト比率（例、業態やドメインによる）基盤

76. ※ただし、エンジニアリングのみにコミットしたいスーパーハっカーを否定しているわけではなく、その場合は、チーム全体としてリーンに回るようにチームデザインをするべき。望まない働き方の強要をして、スーパーハっカーの生産性をさげても意味がない。

77. 闇雲に改善しても意味ないので、 AARRRを元にスタートアップのフェーズに応じてやるべき改善をするようにする

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

79. LEAN STARTUPを理解した上で AARRRを再度見てみるといろいろスッキリする

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

81. 継続して利用してくれているということは顧客の課題を解決していること（それが想定していた課題と想定していた解決策かはまた別だけど） ! ユーザーがプロダクトに価値を感じている状態エンゲージしている状態 ! Problem Solution Fit 15min

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

83. 実証済み実証済み実証済み実証済み

84. MAU ＝新規流入ユーザ数＋継続ユーザ数＋復活ユーザ数 MAUの構成要素を分解して理解する買える増やせる SEO ASO テクニックバイラル P/S FIT ！！！

85. Acquisition Retention Churn Referral Activation Revenue

86. あと数日でチャーンしそうなユーザーをチャーンさせない例えば、あと数日で退会してしまいそうなユーザーの母集団に対して、コホートをきり、そこに対してアクションをするような仕組みを実装し再びサービスの価値を感じるようにしてもらい退会率を下げる。 ! チャーンしたユーザーを復活させる使うのを辞めてしまったユーザーの母集団に対しては、友達の誕生日にプッシュ通知を出したり、友達が結婚したらプッシュ通知したり再びサービスの価値を感じてもらえるようにする。

87. Acquisition Retention Churn Referral Activation Revenue ユーザーが全くRetention （P/S Fit）していないのに AcquisitionやActivationの改善をする人が多い。 ! 例）ボタンの色変えて○％UP 例）有料集客、キャンペーンユーザーが全くRetention （P/S Fit）してないのに Referralの改善をする人が多い。例）ソーシャル投稿例）友達招待機能 !

88. 顧客発見顧客実証顧客開拓組織構築 Problem Solution Fit Product Market Fit Pivot Scaling 売り上げを最大化するというチューニングの意味でここら辺でそういうことはして欲しいまずは価値を高めることが先

89. 引用 - Lean Entrepreneur P163 P/S Fitしてない何か

90. Acquisition Retention Churn Referral Activation Revenue 本当に良いものは、テクニックを使わなくても自然と広まるもの。テクニックはそれを加速させるため。

91. Growth Hack(er) AARRR LEAN STARTUP Customer Development 全て、ひとつの真理を様々な側面から見た投影どれも言ってる本質は同じ

92. 河合さんの「大組織の中でのリーン」で既に出てた… http://www.slideshare.net/inuro/ss-15681262

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

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

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

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

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

99. まとめはデブサミ2015で！！

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

101. Appendix という名の書きなぐりボツメモ置き場

102. チーム構成（アジャイルチーム） Scrum Master Server Scrum team Android Scrum team iOS Scrum team Scrum Master PO team Product Owner Sub PO iOS team Product Backlog Server team Product Backlog Android team Product Backlog Scrum Master BOSS Client Customer Designer

103. • 全てのプロセスへのインプットは仮説であり、仮説を立てる力がすべて • 仮説の質があがれば、どんどんゴールに近づく。 • 仮説の質をあげるには、その業界・ドメインに誰よりも詳しくなること。顧客開発をすること。24時間サービスのことを考えること。常に課題意識を持つこと。そういう生き方をすること。当たり前だけど再確認。 • リーンスタートアップはあくまで仮説がある前提で、それを科学的＋アートに実証する方法。だから、リーンスタートアップをやったからといって成功するわけではないよ！あくまで、失敗による損失を小さくする方法。バーンアウトしていく資金の中、無駄を省き切り詰めてリスクを取り除いていく方法。 • 今も昔も変わらず、これやるだけで成功するなんて方法はない。

104. このループへのインプット自体はかってに沸いてこないこのプロセスに放り込むアイデアを作るのは自分。市場の見立て、自分達のケーパビリティ、時代の流れ、様々な変数がある。リーンやったから成功するわけじゃない。これはあくまでリスクを最小化するプロセス。

105. BMLループを皆が理解するとき、エンジニアはロールの壁を越境する。 BMLサイクルの速度があげるための振る舞いになるエンジニアがビジネスKPIを持つことが可能になる ! Churnを減らすことを目標とするエンジニア Retentionを増やすこととを目標とするエンジニア・各自が仮説をたて、実装し、計測するそれを支える技術が、A/Bテストやコホート分析 ! 機能実装のエンジニアチームとグロースハックチーム

106. ビジネスKPIにエンジニアがコミットすることは大事。 →各自の評価制度上の業務目標になる社内新規事業やストックオプションを持っていないようなケースでは特に重要。 ! 社内新規事業においては、ファウンダーとメンバーとの熱量の差は埋められない。業務目標設定が重要。 ! エンジニアに仕様決定の裁量を与え、なおかつ最適なエンジニアリングを行うためには数値の結果目標・責任をあたえる。 ! 技術的負債が発生すると自らの改善速度低下を招くため、高度なエンジニアリングとビジネスマインドを要する。

107. ■良くある質問 MVPとは言え、完成品と比べると不完全になってしまうが、それでもユーザーは理解してもらえるのか ! →だからアーリーアダプターで実験する。彼らは製品にかけている部分は脳内で補完してくれる存在。

108. ■よくある質問リーンキャンバスの記述レベル。粒度について。 →特にない。自由で良い。 ! ただし、そのドメイン知識がある人と無い人では出来上がったものは全く違う。自分の戦うドメインの知識が充分にあることが前提。それが無い場合は、顧客に会う、聴く、勉強する。顧客理解を深めると自ずとキャンバスの記述レベルが深くなるし、具体性が増す。これこそが顧客開発でもある。 ! あっさりしたものしか書けない場合は、そのドメインの知識が浅いのかもしれないと一度立ち戻ることも必要。

109. CUSTOMER SEGMENT ・顧客の想定は明確か - セグメント・ペルソナに納得感があるか。・理想的な顧客（アーリーアダプター）の見立てが正しいか - リアルにその顧客が顧客の中でのアーリーアダプターに属するか。 ! ★想定している顧客が実際にいるか、いる場合のエビデンスもしくは実証実験結果はあるか ★その精度はどれくらいか。

110. PROBLEM ・想定顧客が抱える課題を構造的に把握し、優先順位が立てられているか。・その課題は深い痛みがあるか。解決すべき課題か。・その想定顧客の現状の代替手段が明確に想定できているか。 ! ★その課題の存在を実証できているか ★その精度はどれくらいか。

111. UNIQUE VALUE PROPOSITION & SOLUTION ・課題に対する解決策が明確かどうか。・アーリーアダプターが既に代替手段で解決している状況において、スイッチングコストを支払ってまでやるべき解決策になっているか。（Facebookでいいじゃん、LINEでいいじゃん、○○でいいじゃんに答えられるか。プラットフォーマーがやったらどうするの？に答えられるか。）・解決策に実現性があるか。（チームのケーパも含む）・性能競争になっていないか。（消耗戦になるだけ） ! ★その解決策によって、課題を本当に解決出来ることを実証出来ているか。 ★その精度はどれくらいか。

112. ★検証精度の高さとは？例えば、「送った写真が１０秒で消えるコミュニケーションアプリが欲しいかまわりの人１０人に聞いて、６人が欲しいと言いました！このソリューションは的を得ています！」という仮説検証結果と、 ! 「実際に１０秒で写真が消えてしまうアプリのプロトタイプをつくり、大学の１００人限定で使ってもらったところ、継続率が50％、フリークエンシーが25回/ 週でした！このソリューションは的を得ています！」という仮説検証結果では、後者の方が検証精度が高い。

LEANSTARTUPの現場 #leanstartup

Itsuki Kuroda

LEANSTARTUPの現場 #leanstartup