リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan

リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan

1. 1. リーンスタートアッ プと顧客開発と アジャイル開発 を一気通貫するッ Recruit Technologies Co.,Ltd. ITM Dev2部 DevOps推進 黒田 樹 @i2key
2. 2. 本スライドは、下記イベントのために @i2key の過去講演資料を悪魔合体させたものになります。 https://devlove-kansai.doorkeeper.jp/events/57834 DevLOVE関西 主催 リンスタ関ヶ原（新大阪の変） 2017/03/17 #DevKan #DevLove https://www.slideshare.net/i2key/devsumibhttps://www.slideshare.net/i2key/bp-leanstartup https://www.slideshare.net/i2key/ lean-startup-overview-51898723 https://www.slideshare.net/i2key/ leanstartup-devlove-leanstartup ＋ ＋ ＋ 配合レシピ
3. 3. 仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明) ビジネスモデル上の ムダを減らすための仮説検証 (リーンキャンバス＆BMLループ) 学びまでのリードタイムを減 らすエンジニアリング (アジャイル、リーンソフトウェア開発)
4. 4. 仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明) ビジネスモデル上の ムダを減らすための仮説検証 (リーンキャンバス＆BMLループ) 学びまでのリードタイムを減 らすエンジニアリング (アジャイル、リーンソフトウェア開発)
5. 5. ビジネスアイデア全てを仮説と捉えて、 それらを小さく分割して検証すること ビジネスモデル上のボトルネックを 効率よく発見し効率よく解消する ビジネスモデルのムリ・ムダ・ムラを省く
6. 6. ビジネスアイデア全てを仮説と捉えて、 それらを小さく分割して検証すること ビジネスモデル上のボトルネックを 効率よく発見し効率よく解消する ビジネスモデルのムリ・ムダ・ムラを省く 全部仮説 全部思い込み
7. 7. ・思い込みを排除し全てを仮説と捉える ・コストに対する学びを最大化する ・失敗による損失を最小化する 思い込みで打席にたって フルスイング怖くない？
8. 8. ファイル同期がいかに便利か、どのように動作す るのかのプロモーション動画を作成し、Youtube にアップロード。HackerNewsに流して、 事前登録者数をモニタリングでニーズを実証。 仮説を小さく実証する例①
9. 9. 例）写真加工アプリにフィルター購入機能を作ろう！！やり たいことの実装工数は3人月くらいかかりそうです。 あなたがこのプロダクトのオーナーならどうしますか？ ①フィルター購入機能を3人月かけて実装する 　（一切購入されないリスクそのまま） ②フィルタ購入するボタン（ダミー）を用意して、全体のユー ザーの10%に表示して確認し、本当に購入ボタンが押された 回数を測定してから開発着手の判断をする。工数は2人日。 （本当に購入されるのかのみを検証） ②のほうが無駄の無い判断 仮説を小さく実証する例②
10. 10. 100円で 購入 100円で 購入 現在開発中です！ 近日リリース予定です！ ＜ポップアップ＞ ユーザー全体の10%にだけ 表示されるボタン
11. 11. あくまで事例。 テクニックではない。 何でもダミーボタン等で検 証するべきとかではない。 価値観を学ぶことが大事。
12. 12. 製品コン セプト作り 製品開発 評価試験 発売/リ リース 製品開発プロセス （ウォーターフォール型プロセス） 作れるかのリスクよりも 作ったものが売れるかのリスク
13. 13. 保有リスク量 時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop 製品開発モデルプロセス あれ？流行らない。 よし、機能追加だ！ もっと豪華な フィルターを売るぞ！ まだまだ機能が 足らんぞおおお！ マーケットプレイスに すべきだ！！！！ フィルター購入機能を つくるぞ！ 3人月 使われない機能を作るムダ 使われない機能を作るムダ
14. 14. 顧客発見 顧客実証 顧客開拓 組織構築 顧客開発モデルによるプロセス （仮説検証型プロセス） 「ヒト・モノ・カネを散々投じた挙げ句誰も欲しがらないものを開発して しまう」という新規事業・新商品の典型的失敗を避けるためのプロセス 顧客相手に仮説検証を繰り返し、リスクを潰していく [ニーズ検証] [売って検証] [リーチ検証] [本格拡大]
15. 15. 時間 顧客開発モデルによるプロセス 保有リスク量 2人日
16. 16. 結果から学ぶ 仮説の実験 結果の計測 時間 保有リスク量 2人日 全体の10%のみに出す ダミー購入ボタン作る 計測した結果、全然 クリックされていない 需要ないんだね、 あぶなかった・・・ （リスクがゼロになる） 顧客開発モデルによるプロセス
17. 17. リスク 時間 顧客いる？ 課題あってる？ 解決策あってる？ 顧客開発モデルによるプロセス
18. 18. 開発タスク管理リスト 10個ひらめいた！ 事業責任者・PO 10個のエンジニアタスク 従来のタスク管理あるある シャワー浴びながら・・ トイレに入りながら・・ ktkr!!!! いやいやいや・・・ フィルタを売って 売上をあげる！ フィルタ購入機能実装
19. 19. Lean Canvas ＜ビジネス仮説＞ 仮説検証 MVPの設計 開発タスク管理リスト ＜MVP構築タスク＞ 10個の仮説 3個のMVP構築 （エンジニアタスク） 10個のMVP設計 7個のGetOutOfBuilding ※別に開発しなくても仮説検証できる 仮説検証型タスク エンジニアリング必要 エンジニアリング不要 フィルタが本当に 購入されるのか ダミー x 10%のユーザで 検証 検証用フィルタ購入 ダミーボタン実装 どんなフィルターがウケるか 街頭インタビューしよう
20. 20. 従来の 開発タスクリスト 仮説検証型の 開発タスクリスト ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 わざわざ開発せずに インタビューやエンジニアリング以外で検証できそう 根拠無し 根拠無し 根拠無し 事前検証 (エビデンス収集) 実証後の実装 フィルタ購入機能実装 検証用フィルタ購入 ダミーボタン実装 使われない機能を作るムダ
21. 21. LEAN CANVAS 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？
22. 22. LEAN CANVAS Product （サービス） Market （顧客）
23. 23. LEAN CANVAS 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？ ① ①② ③ 不確実性が高い順に検証していく
24. 24. LEAN CANVAS 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？ 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 目指す状態
25. 25. 深い課題を抱え た顧客がいるか Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み その課題の解決 策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 実証済み 独自な価値提供 を出来ているか 顧客は本当に買っ てくれるか コスト構造に無 理がないか 独自な価値提供 を出来ているか 最適な売り方の 検証 最適な価格設定 の検証 独自な価値提供 を出来ているか ①① ②③ ①① ②③ ①① ②③ ⑤ ④ ⑤ ④ ⑥⑥ 10
26. 26. 深い課題を抱え た顧客がいるか Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み その課題の解決 策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 実証済み 独自な価値提供 を出来ているか 顧客は本当に買っ てくれるか コスト構造に無 理がないか 独自な価値提供 を出来ているか 最適な売り方の 検証 最適な価格設定 の検証 独自な価値提供 を出来ているか ①① ②③ ①① ②③ ①① ②③ ⑤ ④ ⑤ ④ ⑥⑥ Retention CAC < LTV 最大LTVセグメントの 比率を増やす バイラル係数 > 1 指標値の例 10
27. 27. 仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明) ビジネスモデル上の ムダを減らすための仮説検証 (リーンキャンバス＆BMLループ) 学びまでのリードタイムを減 らすエンジニアリング (アジャイル、リーンソフトウェア開発) 10
28. 28. http://99designs.jp/ 10
29. 29. 出資先海外スタートアップの日本展開支援
30. 30. 顧客 デザイナー （世界100万人） 世界最大のデザイン特化型クラウドソーシングサービス 10
31. 31. ロゴデザイン http://99designs.jp/lp/logo-design-oss/
32. 32. を日本に展開する やること
33. 33. を やること US市場においてProduct Market Fitし Scalingフェーズに入ったサービス カスタマーセグメントが異なる 非英語圏である日本に展開する
34. 34. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み Japan
35. 35. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み カスタマーが英語圏から日本語文化 圏になるため、既存サービスに手を いれずにProduct/Market Fitするの かを見極める必要がある Japan
36. 36. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み Japan
37. 37. 顧客発見 顧客実証 顧客開拓 組織構築 Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 課題を解決できていない場合、 Solution（サービス/商材）を日本顧 客（日本文化）に合わせてチューニ ングする必要がある。 Japan
38. 38. 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？ 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み
39. 39. Product Market Japan 売り物に関しては 実証済みとして 一旦、固定する まずは売り方の チューニングだけ でいけるか確認
40. 40. 顧客は誰？課題は何？ 解決策は？ 価値は何？ 圧倒的優位性は何？ コスト構造は？ 売り上げは？ 顧客にリーチするための チャネルは 何を測る？ 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 未実証 (日本市場依存) Japan 未実証 (日本市場依存) 未実証 (日本市場依存)
41. 41. Problem/Solution Fitしている前提に立ち プロダクト自体（売り物）をいじらずに 最適なカスタマーへ、最適なチャネル（売り方）で サービスが届き、利用されている状態をつくる CAC < LTV
42. 42. □日本市場におけるカスタマーセグメントを明らかにする □そのカスタマーセグメントの存在を実証する □リーチできれば利用する（P/S FIT）することを実証する □リーチするためのチャネルの検証をする 　　　　　　　　　　　　　： まず、検証すること
43. 43. 内緒 内緒 Japan はやく安く クオリティの 高いデザイン が欲しい人 はやく安く クオリティの 高いデザイン が手に入る オンライン 広告 世界100万人 のデザイナー 在庫 コンペ型デザ インクラソー 内緒 口コミ 良いデザイナー に出会えない 多種多様な提 案が欲しい
44. 44. 内緒 内緒 Japan はやく安く クオリティの 高いデザイン が欲しい人 はやく安く クオリティの 高いデザイン が手に入る オンライン 広告 世界100万人 のデザイナー 在庫 良いデザイナー に出会えない コンペ型デザ インクラソー 内緒 口コミ トートロジー 何か言っているようで何も言っていない。 よくありがちなバリュープロポジションと そのカスタマーセグメントの関係（笑） ドメインの理解が浅いとこうなりがち。 多種多様な提 案が欲しい
45. 45. 深い課題を抱え た顧客がいるか Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み その課題の解決 策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 実証済み 独自な価値提供 を出来ているか 顧客は本当に買っ てくれるか コスト構造に無 理がないか 独自な価値提供 を出来ているか 最適な売り方の 検証 最適な価格設定 の検証 独自な価値提供 を出来ているか ①① ②③ ①① ②③ ①① ②③ ⑤ ④ ⑤ ④ ⑥⑥ Retention CAC < LTV 最大LTVセグメントの 比率を増やす バイラル係数 > 1 指標値の例
46. 46. 深い課題を抱え た顧客がいるか Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み その課題の解決 策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 実証済み 独自な価値提供 を出来ているか 顧客は本当に買っ てくれるか コスト構造に無 理がないか 独自な価値提供 を出来ているか 最適な売り方の 検証 最適な価格設定 の検証 独自な価値提供 を出来ているか ①① ②③ ①① ②③ ①① ②③ ⑤ ④ ⑤ ④ ⑥⑥ Retention CAC < LTV 最大LTVセグメントの 比率を増やす バイラル係数 > 1 指標値の例 継続して使い続ける人 継続して使い続けるセグメント ＝Problem Solution Fitしてる人 ＝サービスはこの人の課題を解決できている ＝この人はこのサービスを継続して使う理由を持っている
47. 47. 深い課題を抱え た顧客がいるか Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み その課題の解決 策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 実証済み 独自な価値提供 を出来ているか 顧客は本当に買っ てくれるか コスト構造に無 理がないか 独自な価値提供 を出来ているか 最適な売り方の 検証 最適な価格設定 の検証 独自な価値提供 を出来ているか ①① ②③ ①① ②③ ①① ②③ ⑤ ④ ⑤ ④ ⑥⑥ Retention CAC < LTV 最大LTVセグメントの 比率を増やす バイラル係数 > 1 指標値の例 継続して使い続ける人 継続して使い続けるセグメント ＝Problem Solution Fitしてる人 ＝サービスはこの人の課題を解決できている ＝この人はこのサービスを継続して使う理由を持っている この継続している利用者/継続しているセグメント にインタビューをして、使っている理由を知る なぜ99designsを選んだのか(UVP) どこに価値を感じたのか(UVP) どんな課題を解決したのか(Problem/Solution) 今までのやりかたとくらべてどうか(代替手段) どうやって（誰から）知ったか(chanel) ： ： 「過去を振り返って事実のみをきく。」 (使ってくださった直後のユーザーさんとか最高)
48. 48. 深い課題を抱え た顧客がいるか Problem Solution Fit Product Market Fit Scaling 実証済み 実証済み実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み 実証済み その課題の解決 策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 実証済み 独自な価値提供 を出来ているか 顧客は本当に買っ てくれるか コスト構造に無 理がないか 独自な価値提供 を出来ているか 最適な売り方の 検証 最適な価格設定 の検証 独自な価値提供 を出来ているか ①① ②③ ①① ②③ ①① ②③ ⑤ ④ ⑤ ④ ⑥⑥ Retention CAC < LTV 最大LTVセグメントの 比率を増やす バイラル係数 > 1 指標値の例 継続して使い続ける人 継続して使い続けるセグメント ＝Problem Solution Fitしてる人 ＝サービスはこの人の課題を解決できている ＝この人はこのサービスを継続して使う理由を持っている この継続している利用者/継続しているセグメント にインタビューをして、使っている理由を知る なぜ99designsを選んだのか(UVP) どこに価値を感じたのか(UVP) どんな課題を解決したのか(Problem/Solution) 今までのやりかたとくらべてどうか(代替手段) どうやって（誰から）知ったか(chanel) ： ： 「過去を振り返って事実のみをきく。」 (使ってくださった直後のユーザーさんとか最高) これを何人もにやると 共通項（スケーラブルな部分） 「日本国外に通用するデザインのニーズ」 の存在が見えてくる そして いくかのセグメントを見立てることが できるようになる
49. 49. 内緒 内緒 Japan はやく安く クオリティの 高いデザイン が欲しい人 はやく安く クオリティの 高いデザイン が手に入る オンライン 広告 グローバルで 通用するデザ インを手に入 れられる。（は やいやすい質 が良いは前提） 日本から海外 へ国境を越え ていくような カスタマー ・オープンソース・ソフト ウェアのエンジニア ・ウェブサービス/スマホア プリでの起業家 ・プロダクトをグローバル 進出させようとしている企 業（食品会社、化粧品会社、 etc） ・越境ECコンサル ・アーティスト、音楽事務 所 ・SNSカバーデザイン 　　　： 　　　： 海外市場に フィットした デザインが出 来るデザイナ に出会えない コンペ型デザ インクラソー 世界100万人 のデザイナー 在庫 内緒 日本人デザイ ナーが海外で 好まれるデザ インセンスを 持ってない 口コミ
50. 50. ✔日本市場におけるカスタマーセグメントを明らかにする □そのカスタマーセグメントの存在を実証する □リーチできれば利用する（P/S FIT）することを実証する □リーチするためのチャネルの検証をする 　　　　　　　　　　　　　： まず、検証すること 20
51. 51. ①仮説 ②何を学ぶのか ③必要なデータは？ ④どうやって計測する？ ⑤必要なものは？ ⑥どう構築するか？ 思考プロセス 20
52. 52. ⑫仮説を調整する ⑪学ぶ ⑩データを元に検証 ⑨データを計測する ⑧完成したMVP ⑦構築する 実証プロセス 20
53. 53. ②何を学ぶのか ・コンバージョンする セグメントの存在有無 ③必要なデータは？ セグメントに対する 一定量のCV ④どうやって計測する？ セグメント毎に分けて CVページで計測 ⑤必要なものは？ セグメント毎に 集客する装置 ⑥どう構築するか？ うーむ 思考プロセス①仮説 ・○○○なユーザセグメントが 存在するか 20
54. 54. ⑥どう構築するか？ (MVP案1)セグメント単位に少量のオンライン広告 を流してCV検証 (MVP案2)セグメント単位に営業をかけてCV検証 (MVP案3)セグメント単位にオーガニックにまつ もっとも効果的に学びが得られるMVPはどれか選択する ・費用対効果 ・期間 ・工数 ・この検証方法により回避できる将来のリスク ・この検証方法により逆に発生する将来のリスク 思考プロセス
55. 55. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 セグメント毎にいったん少量の水を流して 水漏れをみる(CVするか、PSFitするか) 広告
56. 56. OSSエンジニア向けLP ターゲティング広告
57. 57. 起業家向けLPターゲティング広告
58. 58. カスタマーセグメント毎にLPを作成
59. 59. カスタマーセグメント毎にLPを作成
60. 60. ⑫仮説を調整する ⑪学ぶ ⑩データを元に検証 ⑨広告を少量流しデータを計測する ⑧完成したMVP ⑦構築する 少量広告＋セグメント特化LP 実証プロセス
61. 61. 内緒 内緒 Japan オンライン 広告 グローバルで 通用するデザ インを手に入 れられる。（は やいやすい質 が良いは前提） 海外市場に フィットした デザインが出 来るデザイナ に出会えない コンペ型デザ インクラソー 世界100万人 のデザイナー 在庫 内緒 日本人デザイ ナーが海外で 好まれるデザ インセンスを 持ってない 口コミ 日本から海外 へ国境を越え ていくような カスタマー [○]・オープンソース・ソ フトウェアのエンジニア [○]・ウェブサービス/スマ ホアプリでの起業家 [○]・プロダクトをグロー バル進出させようとしてい る企業（食品会社、化粧品 会社、etc） [○]・越境ECコンサル [×]アーティスト、音楽事務 所 [×]SNSカバーデザイン 　　　： 　　　：
62. 62. ✔日本市場におけるカスタマーセグメントを明らかにする ✔そのカスタマーセグメントの存在を実証する ✔リーチできれば利用する（P/S FIT）することを実証する □リーチするためのチャネルの検証をする 　　　　　　　　　　　　　： まず、検証すること 以後省略
63. 63. リスクを最小化する価値観でやらなかったら どうなってるか
64. 64. 保有リスク量 時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop 製品開発モデルによるプロセス あれ？誰も使わない。 もっと広告をフカセ！ だめだ、 イベントやるぞ！ ドカーンとやるぞ！ PRすっぞ！！！ バーンと広告うつぞ！ 数週間準備
65. 65. 時間 顧客開発モデルによるプロセス 保有リスク量
66. 66. 結果から学ぶ 仮説の実験 結果の計測 時間 保有リスク量 リピートユーザに 会ってヒアリング 同じような 利用シーンが ありそう セグメントの発見 顧客開発モデルによるプロセス
67. 67. 結果から学ぶ 仮説の実験 結果の計測 時間 保有リスク量 リピートユーザから 把握できたセグメントに 広告を少量あてる 全然コンバージョン しない そのセグメントの存在は 幻だったのか。 あぶなかった・・・ （リスクがゼロになる） 顧客開発モデルによるプロセス
68. 68. 結果から学ぶ 仮説の実験 結果の計測 時間 保有リスク量 広告のあてかたが 悪いリスクがある 広告をチューニング それでも全然 コンバージョン しない やっぱなかった （リスクがゼロになる） 顧客開発モデルによるプロセス
69. 69. 仮説検証型でやっていく勘所 (リーンスタートアップや顧客開発の概念説明) ビジネスモデル上の ムダを減らすための仮説検証 (リーンキャンバス＆BMLループ) 学びまでのリードタイムを減 らすエンジニアリング (アジャイル、リーンソフトウェア開発)
70. 70. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト ※スクラムについての説明省きます
71. 71. 従来の プロダクトバックログ 仮説検証型の プロダクトバックログ ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 根拠無し 根拠無し 根拠無し 事前検証 (エビデンス収集) 実証後の実装
72. 72. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト PBLに入ってからリリースされるまでの リードタイムを最小化する （学びまでの待ちを最小化する）
73. 73. エンジニアリング ビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト セールス / マーケ プランニ ング 実行 学習
74. 74. PBLに入ってからリリースされるまでの リードタイムを最小化する （学びまでの待ちを最小化する） 30
75. 75. 余分な機能のムダ 引き継ぎのムダ 再学習のムダ 未完成な作業のムダ 遅れのムダ タスク切り替えのムダ 欠陥のムダ 30
76. 76. 余分な機能のムダ 目的にそぐわない過剰品質 使われない機能の実装 ↓ コードベースの肥大化 メンテコスト増加 バグ混入率増加 30
77. 77. ビジネスフェーズ ↓ 求められる プロダクト品質 30
78. 78. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても 不満ではない）、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ 満足、短いと不満）、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き 取りづらいと不満） 狩野モデル一般論
79. 79. 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 顧客発見 顧客実証 顧客開拓 組織構築 [ニーズ検証] [売って検証] [リーチ検証] [本格拡大] 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 独自な価値提供を出来ているか Problem Solution Fit Product Market Fit Scaling Retention CAC < LTV 最大LTVセグメントの比率 課題解決可能 な最小限 売り方最適化 / 売上最大化売る ビジネス フェーズ 狩野 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル・クロスセルに 向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない
80. 80. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても 不満ではない）、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ 満足、短いと不満）、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き 取りづらいと不満） 狩野モデル
81. 81. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても 不満ではない）、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ 満足、短いと不満）、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き 取りづらいと不満） 狩野モデル
82. 82. 充足 不充足 満足 不満足 顧客の満足感 物理的な充足度 魅力品質 当たり前品質 アーリーアダプターには ここ弱めにするか。とか マネタイズ検証時には 必要だね。とか Minimum Sellable Product 性能品質 魅力品質 性能品質 当たり前品質 不充足でも不満には思わないが、 充足されれば満足 <例> ハイレゾ音源（あれば良いが、なくても 不満ではない）、曲面液晶など 不充足だと不満、充足されると満足 <例> バッテリーの持ち（稼働時間が長ければ 満足、短いと不満）、重量など 不充足だと不満、充足されて当たり前 <例> 通話音声（音が良くて当たり前、聞き 取りづらいと不満） 狩野モデル
83. 83. 引き継ぎのムダ アーリーステージは やることの母数が小さいのに、 役割分担をしすぎるとスイッチングコスト増加 母数が小さいなら1人でやったほうが早い ↓ クロスファンクショナルチーム フルスタックエンジニア マルチロールエンジニア
84. 84. ビジネスフェーズ ↓ 求められる エンジニア像
85. 85. ビジネスフェーズからエンジニア像を俯瞰してみる （ユニークなValuePropositionが技術ではない場合の例） Problem / Solu,on Fit Product / Market Fit Scaling 100% %me Scale MySQL MVP iOS iOS KPI 検証用のMVPを 高速に実装 ビジネス文脈を意識した 品質担保＆成長貢献 セグメントに応じた 性能向上 顧客発見 顧客実証 顧客開拓
86. 86. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する 　　打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する 指標：MAU/継続率/○○率/売上/etc
87. 87. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する 　　打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する 指標：MAU/継続率/○○率/売上/etc マルチロールに しみ出す
88. 88. 検証を設計する （実証条件/実証方法/etc） 効果を計測する KPI（数値目標）を設定する リリースする ユーザがコンバージョンする 仮説をたてる 仕様にする 設計する ユーザーに届く ユーザーが使う ユーザーが気づく KPI（数値目標）達成 指標：ベロシティ/デプロイ回数/性能値/品質/コスト/etc エンジニアのコミットと目標 データから学ぶ （仮説を修正する 　　打ち手を変える） エンジニアが直接結果を コントロール出来る範囲 （コードのみに対峙してる） エンジニアが直接結果を コントロール出来ない範囲 （ユーザーの判断という不確実性が介在） テストする 実装する 指標：MAU/継続率/○○率/売上/etc それぞれのプロ
89. 89. バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 Feedback 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち フロー効率をあげていく 学ぶ（顧客のフィードバックを得る）までのリードタイム エンジニア (フロント＆バックエンド） フロント エンジニア プロダクト オーナー 顧客 Feedback 承認条件 API開発 Front開発 デプロイ 待ち 待ち 待ち ※先に提示された条件をパスすれば リリース承認というルールにする等 ※フルスタック（）な振る舞い をすることで引き継ぎによる ムダが減る ※ここにきて手戻りが 発生することも 学ぶ(顧客のフィードバックを得る)までのリードタイム
90. 90. 再学習のムダ 仮説検証型で実施したとしても、 結果を正しく計測し、学びにつなげていないと 同じ学習がまた必要になる ↓ 複数の検証をしても濁りなく学べる分析基盤 検証設計時のゴール設定
91. 91. 仮説検証プロセス ↓ エンジニアリングによる 仮説検証基盤構築
92. 92. 仮説検証基盤要件 方法 既存のユーザへの影響 を最小化 ユーザーを任意の属性 でセグメントする機能 管理コンソールの実装 (Firebase …etc) 既存のユーザへの影響 を最小化 ユーザーセグメントに 対して機能の出し分け を可能にする 事業フェーズが進めば進むほど、 既にたくさん使われているプロダ クトで仮説検証をすることになる ため必要最低限の影響範囲で仮説 検証をする Feature Flag、A/Bテス ト、Private Beta Test、 Dark Launch、etc (Leanplum, Firebase, Optimizely, etc) 検証結果が濁らないこ と 仮説や施策単位に各種 数値を計測出来る機能 (例)CV数が目標の場合、マーケの 頑張りなのか、プロダクト改善に よるCVR向上なのか切り分けがで きない コホート分析 (Localytics, Google Analytics, Firebase …etc) 検証方法の改善が出来 ること 検証ポイントまでユー ザが漏れずに到達でき ていること UI上の問題で検証ポイントまでユ ーザが到達していないのに、検証 失敗とする事案がある ファネル分析 (Localytics, Google Analytics, etc) ： ： ： DevOps系プラクティス見れば基本ソレ
93. 93. 活動基準会計 仮説検証、ひとつひとつに対して何を学ぶのか、検証するため に何が必要なのか、どのように計測するのか、いくらかかるの かを設計する。学びに対するムダの無い投資をする。 http://www.slideshare.net/i2key/45-developers-summit-2015-devsumi-devsumib#141
94. 94. 未完成な作業のムダ 遅れのムダ タスク切り替えのムダ 大量のことを同時にやろうとすると仕掛中の作業の滞留が増える 一つひとつやるよりも、個々のリードタイムは増加する ↓ マルチタスクやめる 一個流し
95. 95. リソース効率 フロー効率 This is Lean The Efficiency Matrix ① ② ③ ④ Efficient islands 効率的な島々 Wasteland 荒廃した地 Efficient ocean 効率的な海 The perfect state High HighLow Low https://www.amazon.co.jp/dp/919803930X/ ①あなたはここにいると思っている ②実際には多分ここ ③まずはフロー効率化からはじめて ④その後にリソース効率化をしていく 例）稼働率100%のチーム 　　機能がリリースされるまでのリードタイム長い 例）稼働率は100%ではないチーム 　　機能がリリースされるまでのリードタイム短い Variation リソース効率 （例）稼働率100% フロー効率 （例）機能リリースまでのリードタイムの短さ
96. 96. リソース効率 フロー効率 This is Lean The Efficiency Matrix ① ② ③ ④ Efficient islands 効率的な島々 Wasteland 荒廃した地 Efficient ocean 効率的な海 The perfect state High HighLow Low https://www.amazon.co.jp/dp/919803930X/ ①あなたはここにいると思っている ②実際には多分ここ ③まずはフロー効率化からはじめて ④その後にリソース効率化をしていく 例）稼働率100%のチーム 　　機能がリリースされるまでのリードタイム長い 例）稼働率は100%ではないチーム 　　機能がリリースされるまでのリードタイム短い Variation
97. 97. バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 Feedback 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち フロー効率をあげていく 学ぶ（顧客のフィードバックを得る）までのリードタイム エンジニア (フロント＆バックエンド） フロント エンジニア プロダクト オーナー 顧客 Feedback 承認条件 API開発 Front開発 デプロイ 待ち 待ち 待ち ※先に提示された条件をパスすれば リリース承認というルールにする等 ※フルスタック（）な振る舞い をすることで引き継ぎによる ムダが減る ※ここにきて手戻りが 発生することも 学ぶ(顧客のフィードバックを得る)までのリードタイム
98. 98. 待ち行列理論 ・100%の利用率の高速道路は、駐車場といっしょ ・100%利用率のサーバは？ ・稼働率100%のチームは？ スループットを最大化ではなくチームに最適化する ・処理中のもの量の最小化 ・処理中のもののサイズを最小化 チームへの負荷を調整 ・たくさんのこと同時にしない ・タスク管理ではなく、チームのペースを管理する 仕事の許容量を制限する ・スコープボックスではなくタイムボックス ・プッシュ型ではなくプル型でやる フロー効率を高めるために （顧客へ価値が届くまでのリードタイムを短くする）
99. 99. マルチタスクやめる 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 たくさんのことを同時に調整しようとするから 仕様の調整の「会議」やら「定例」やらがうまれる
100. 100. マルチタスクやめる 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 たくさんのことを同時に調整しようとするから 仕様の調整の「会議」やら「定例」やらがうまれる （例） ペアプログラミング（フロー効率高め＆再学習のムダ削減効果） モブプログラミング（フロー効率ビンビンッ＆再学習のムダ削減効果）
101. 101. まとめ
102. 102. ご静聴ありがとうございました