Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

結果的に組織がAgileな状態であること #agile #scrum #leanstartup

4,777 views

Published on

NTTデータ様 Agile Forum講演資料

Published in: Engineering
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

結果的に組織がAgileな状態であること #agile #scrum #leanstartup

  1. 1. 結果的に組織 がAgileな状 態であること。 黒田 樹 @i2key ~IDEAをCASHに変えるフローの効率化~ リクルート テクノロジーズ
  2. 2. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア CVR最大化等のUI/UX仮説検証 価格設定/商品検討のための仮説検証 クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ
  3. 3. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 AARRRモデル
  4. 4. Acquisition 獲得 Retention 継続 Churn 解約 Revenue 収益 Activation 活性化 Retention 継続しているということは、 顧客の課題を解決し続けている(と言える) ✔顧客セグメントが存在する  & ✔顧客が抱える課題を認識出来ている  & ✔それに対する解決策が正しい
  5. 5. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 CAC < LTV その上で、顧客獲得コストよりも、 ライフタイムバリューのが高い状態 (ビジネスモデルとして成立)
  6. 6. Acquisition 獲得 Retention 継続 Churn 解約 Referral 紹介 Activation 活性化 Revenue 収益 売上最大化 売り方(チャネル)の最適化、 アップセル、クロスセル、水漏れ防止、 グロースハック、etc
  7. 7. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア CVR最大化等のUI/UX仮説検証 価格設定/商品検討のための仮説検証 クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ
  8. 8. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア CVR最大化等のUI/UX仮説検証 価格設定/商品検討のための仮説検証 クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ IDEAをCASHに変える フローの効率化
  9. 9. そもそも「効率が良い」って どういう意味で使いますか? IDEAをCASHに変える フローの効率化
  10. 10. 稼働率が100%?
  11. 11. 速く作業が出来ること?
  12. 12. 「リソース効率性」が良い (例)稼働率100%、リソースに遊びが無い 「フロー効率性」が良い (例)機能リリースまでのリードタイムの短さ
  13. 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 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人日かかる場合
  14. 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%、リソースに遊びが無い 「フロー効率性」が良い (例)機能リリースまでのリードタイムの短さ
  15. 15. リソース効率性 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人日かかる場合 複数のことを同時にやるとプロダクトがユーザに届くまで・検 証を開始するまでのリードタイムが長くなる。 ただし、皆に仕事が割り振られるため、また時間の余る限り複 数の仕事を持つためリソースあたりの稼働率は高くなる。
  16. 16. 1つのリソースを稼働率が100%になるまで分配する 例 ・マルチタスク ・大きなウォーターフォール型開発(SOR的) A B C Resource 流れる対象 30% 30% 40% リソース稼働率:100% (作業時間を絞り出す量を最大化) 1リソースに フォーカスする 流れる対象 流れる対象 リソース効率性
  17. 17. フロー効率性 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 同時にやることをひとつにするとプロダクトがユーザに届くま でのリードタイムは短くなる。しかし、全員が同じことをやる ため、一時的に手持ちがなくなる人が出たりするためリソース の稼働率は下がる。(Aだけでみるとトータル稼働は多い)
  18. 18. A Resource 流れる対象 流れる対象(タスク)が得られるリソースの時間を最大化する 流れる対象に フォーカスする Resource Resource 例 ・ペアプログラミング/モブプログラミング ・クロスファンクショナルチーム(SOE的) ・システム障害発生時の動き フロー効率性
  19. 19. リソース効率性とフロー効率性 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
  20. 20. リソース効率性とフロー効率性 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
  21. 21. リソース効率と フロー効率の関係 10
  22. 22. リソース効率とフロー効率はトレードオフの関係になりやすい 大規模開発のような大量のものを一括でドン!と リリースする文脈(リソース効率が支配するパラダイム) ペアプログラミングしたいです! (効果:フロー効率アップ) 2人で同じことやったら、 効率半分に落ちるだろ!却下! (効果:リソース効率ダウン) エンジニア氏 偉い人氏 10
  23. 23. リソース効率とフロー効率はトレードオフの関係になりやすい 仮説検証型でUI/UX改善を回し、KPIを伸ばしにいく文脈。 現場は学びまでのリードタイムを限りなく最小化したい。 (無意識にフロー効率を重視している) リリース物はすべて承認が必要だ。 だが、わしは忙しいから 一括でまとめて持ってきなさい。 (フロー効率ダウン) (効率落ちるだろ!) ヘイトマッハっすわー エンジニア氏 偉い人氏 10
  24. 24. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い Variation This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  25. 25. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い Variation This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 例:高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多) 例:カプセルホテル (部屋稼働率:100%) (客数に対する従業員数:少)
  26. 26. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation 我々 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い 例:高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多) 例:カプセルホテル (部屋稼働率:100%) (客数に対する従業員数:少)
  27. 27. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation WaterFall SoR Agile SoE 小規模・仮説検証 大規模開発 我々
  28. 28. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low SoR SoE 大規模開発 ココに 行きたい 我々 小規模・仮説検証 WaterFall Agile
  29. 29. 小規模・仮説検証 リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low SoR SoE 大規模開発 ココに 行きたい 我々 WaterFall Agile
  30. 30. 小規模・仮説検証 リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low SoR SoE 大規模開発 ココに 行きたい 我々 流れに着目するほうがムダを炙り出しやすい こっちから登ったほうが リソース効率上のムダも発見しやすい WaterFall Agile
  31. 31. ビジネスフェーズ毎に、 目的、追うべき目標がある
  32. 32. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ CVR最大化等のUI/UX仮説検 証 価格設定/商品検討のための仮 説検証
  33. 33. リソース効率とフロー効率の ビジネス目標に対する 効果・影響
  34. 34. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 例:CVR最大化に向けたUI/UX仮説検証 流入数
  35. 35. 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 ビジネス価値とフロー効率性重視の開発スタイル
  36. 36. 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 学んでいない期間 稼いでいない期間 学んでいない期間 稼いでいない期間 オーバーヘッドで 若干合計稼働は増える ビジネス価値とリソース効率性重視の開発スタイル ビジネス価値とフロー効率性重視の開発スタイル 複数の実験を 同時にやると濁る
  37. 37. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 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. 38. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 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 Scrumの場合 Sprint#1 Sprint#2 Sprint#3 スプリント毎に成果を積み上げていく
  39. 39. 個別案件における さらなるリードタイム削減 20
  40. 40. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 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 Scrumの場合 Sprint#1 Sprint#2 Sprint#3 スプリント毎に成果を積み上げていく バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト 20
  41. 41. バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト クロスファンクショナル エンジニア (フロント&バックエンド) プロダクト オーナー 顧客 承認条件(広義のBDD化) Front&API開発(ペアプロ)テスト&デプロイ(自動化&パイプライン上の承認) 待ち 待ち (手戻りのムダ排除) (引き継ぎのムダ排除) (手作業のムダ排除) +1 DevOpsやアジャイル等の各種プラクティス活用 目的:学びまでのリードタイム短縮    (フロー効率性を高める) 20
  42. 42. DevOpsやアジャイル等の各種プラクティス活用 目的:学びまでのリードタイム短縮    (フロー効率性を高める) 20
  43. 43. 低下するとリードタイムを悪化させる(=品質下げるという選択肢がそもそも無い) • プロセス品質下げると手順ミス等により手戻りが発生しデリバリへのリードタイムが長く なる • 内部品質さげるとバグの発生、コードレビューの指摘、技術的負債による実装の複雑さな どにより手戻りや速度低下を招き、デリバリへのリードタイムが長くなる • 外部品質さげるとUXバグをうみ、本来検証したいことが検証できず学びまでのリードタイ ムが長くなる。障害発生により、それの対応に終われリソースが枯渇し本来やるべきこと の足かせになり、リードタイムが長くなる • 利用時の品質さげると、カスタマーサポートが頻発しその対応に組織のパワーが持って行 かれリードタイムが長くなる 品質 = 速度 品質が悪いと手戻りを生むので速度に跳ね返る。 手戻っている時間=価値提供しない時間、学び のない時間 20
  44. 44. バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト クロスファンクショナル エンジニア (フロント&バックエンド) プロダクト オーナー 顧客 承認条件(広義のBDD化) Front&API開発(ペアプロ)テスト&デプロイ(自動化&パイプライン上の承認) 待ち 待ち (手戻りのムダ排除) (引き継ぎのムダ排除) (手作業のムダ排除) +1 DevOpsやアジャイル等の各種プラクティス活用 目的:学びまでのリードタイム短縮    (フロー効率性を高める) 学びまでのリードタイム 学びまでのリードタイム 20
  45. 45. バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト クロスファンクショナル エンジニア (フロント&バックエンド) プロダクト オーナー 顧客 承認条件(広義のBDD化) Front&API開発(ペアプロ)テスト&デプロイ(自動化&パイプライン上の承認) 待ち 待ち (手戻りのムダ排除) (引き継ぎのムダ排除) (手作業のムダ排除) +1 DevOpsやアジャイル等の各種プラクティス活用 目的:学びまでのリードタイム短縮    (フロー効率性を高める) 学びまでのリードタイム 学びまでのリードタイム 使われない場合、 ムダを高速で造り だしたことになる
  46. 46. 使われないものを作るムダを省く
  47. 47. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 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 Scrumの場合 Sprint#1 Sprint#2 Sprint#3 スプリント毎に成果を積み上げていく 良質玉 価値 (成果) 質低玉 ムダ
  48. 48. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 僕の考えた最強 の機能リスト PBLの質、超重要。 (やる必然性・エビデンスの有無) どんなに開発チームがフロー効率を高めても、開発チームへのインプット の質が悪いと、価値を生まないゴミを高速生産する ことになる ボトルネックが 開発→ビジネスへ遷移
  49. 49. PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト 思い込みにより発生する各種ムダを 省くためにビジネスサイド、企画サイドもリーンにやる ※(元)僕の考えた 最強の機能リスト
  50. 50. 従来の 開発タスクリスト 仮説検証型の 開発タスクリスト ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 わざわざ開発せずに インタビューやエンジニアリング以外で検証できそう 根拠無し 根拠無し 根拠無し 事前検証 (エビデンス収集) 実証後の実装 使われない機能を作るムダ
  51. 51. 使われないものを 作らないようにする例
  52. 52. 例)写真加工アプリにフィルター購入機能を作ろう!!やり たいことの実装工数は3人月くらいかかりそうです。 あなたがこのプロダクトのオーナーならどうしますか? ①フィルター購入機能を3人月かけて実装する  (一切購入されないリスクそのまま) ②フィルタ購入するボタン(ダミー)を用意して、全体のユー ザーの10%に表示して確認し、本当に購入ボタンが押された 回数を測定してから開発着手の判断をする。工数は2人日。 (本当に購入されるのかのみを検証) ②のほうが無駄の無い判断 仮説を小さく実証する例
  53. 53. 100円で 購入 100円で 購入 現在開発中です! 近日リリース予定です! <ポップアップ> ユーザー全体の10%にだけ 表示されるボタン
  54. 54. 保有リスク量 時間引用: http://www.slideshare.net/clevergirl/ux-jackson-2013-oneday-lean-startup-workshop ①3人月かけて作った場合 あれ?流行らない。 よし、機能追加だ! もっと豪華な フィルターを売るぞ! まだまだ機能が 足らんぞおおお! マーケットプレイスに すべきだ!!!! フィルター購入機能を つくるぞ! 3人月 使われない機能を作るムダ 使われない機能を作るムダ
  55. 55. 時間 ②ダミーで仮説検証した場合 保有リスク量 2人日
  56. 56. 結果から学ぶ 仮説の実験 結果の計測 時間 保有リスク量 2人日 全体の10%のみに出す ダミー購入ボタン作る 計測した結果、全然 クリックされていない 需要ないんだね、 あぶなかった・・・ (リスクがゼロになる) ②ダミーで仮説検証した場合
  57. 57. 時間 顧客いる? 課題あってる? 解決策あってる? ②ダミーで仮説検証した場合 保有リスク量
  58. 58. 従来の 開発タスクリスト 仮説検証型の 開発タスクリスト ・仮説A検証用モック作成 ・仮説B検証用ダミーボタン実装 ・検証済み○○機能本実装 ・検証済み○○機能本実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 ・○○機能実装 わざわざ開発せずに インタビューやエンジニアリング以外で検証できそう 根拠無し 根拠無し 根拠無し 事前検証 (エビデンス収集) 実証後の実装 フィルタ購入機能実装 検証用フィルタ購入 ダミーボタン実装 使われない機能を作るムダ
  59. 59. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 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 Sprint#1 Sprint#2 Sprint#3 事前検証A 事前検証B A実証後の本格実装 仮説の 検証 効果 ありそう 本実装 成果
  60. 60. エンジニアリングビジネス PBL リリー ス プランニ ング 振り返り MTG レビュー デイリー MTG Sprint/2weeks 開発タスク/Day 計測 構築 学習 デー タ アイ デア ビジネス 仮説リスト ※(元)僕の考えた 最強の機能リスト
  61. 61. 目的にあった 本当に必要なことだけやる (玉のサイズを必要最低限:MVP)
  62. 62. 顧客発見 【ニーズ検証】 顧客実証 【売って検証】 組織構築 【本格拡大】 Problem/Solution Fit Product/Market Fit Scaling Retention CAC < LTV 売上 課題解決可能 な最小限 売り方最適化 / 売上最大化売る 品質 モデル 魅力的品質 最低限の性能品質 魅力的品質 当たり前品質 アップセル/クロスセルに向けた性能品質 魅力的品質 当たり前品質 指標値例 検証アク ション 検証 ポイント MVP 目標 MVP作って壊す MVP 品質 最低限の 売れる状態 セグメントに応じて売れる状態 検証が既存ユーザに影響与えない 独自な価値提供を出来ているか 深い課題を抱えた顧客がいるか その課題の解決策は妥当か 開発 モデル例 独自な価値提供を出来ているか 顧客は本当に買ってくれるか コスト構造に無理がないか 顧客開拓 【リーチ検証】 独自な価値提供を出来ているか 最適な売り方の検証 最適な価格設定の検証 導入期 成長期 成熟期 【SoE】Agile【SoE】カウボーイ 【SoE】Agile 【SoR】WaterFall 利益 独自な価値提供を出来ているか CPA最適化 マーケットシェア クロスセルのためのエンタープライズ個別対応開発 仮説検証済み機能によるマーケット刈り取り開発 納期必達型の商品開発 負債解消ビックリライト(ObjC->Swift化) ビジネス仮説検証の高速化文化祭前夜感と全能感を味わ う時期 & ALL高品質 競合との性能競争(消耗戦) キードライバー値 最大化 利益最大化 ビジネス フェーズ CVR最大化等のUI/UX仮説検 証 価格設定/商品検討のための仮 説検証
  63. 63. 手戻りのムダや作り過ぎのムダを減らすために、 ニーズに対しMVP(必要最小限の価値のあるもの)をつくる →ニーズからプルする 情報の流れ モノの流れ ニーズ when what amount when what amount when what amount when what amount pullpullpull push push push
  64. 64. 情報とモノのフローを意識した リーンスタートアップの正しいやり方 いきなりこの流れでやると 小さくやってもムダを生む 30
  65. 65. ①仮説 ②何を学ぶのか ③必要なデータは? ④どうやって計測する? ⑤必要なものは? ⑥どう構築するか? 思考プロセス (情報の流れ) pull pull pull pull pull 30
  66. 66. ⑫仮説を実証 ⑪学ぶ ⑩データを元に検証 ⑨計測する ⑧完成したMVP ⑦構築する 実証プロセス (モノの流れ) push pushpush push push 30
  67. 67. 情報の流れ(BMLを逆流) モノの流れ(BMLの流れ) ニーズ pullpullpull ①仮説②何を学ぶのか ③必要なデータ ④計測方法 ⑤必要な計量器 ⑥構築方法 ⑫実証 ⑪学ぶ ⑩データで検証 ⑨計測する ⑧完成したMVP⑦構築する push push push BUILD MEASURE LEARN BUILD設計 MEASURE設計 LEARN設計 ① ② ③ ④ ⑤ ⑥ ⑫ ⑪ ⑩ ⑨ ⑧ ⑦
  68. 68. 【事例】 フロー効率重視で開発プロセスを 組んだものの、チームが知らず知 らずのうちにリソース効率にフォー カスした選択をしていった話
  69. 69. Sprint #N Sprint #N+1 Sprint #N+2 Sprint #N-1 1Q 2Q 3Q バックログ ・デザインの改善(CVR向上目的) ・UI/UX改善(CVR向上目的) ・技術負債解消(保守性) ・ログ周りの改善(モニタリング) 開発案件リスト ・Web開発タスク #1 ・Web開発タスク #2 ・Web開発タスク #3 API開発チーム(アウトソース) 3ヶ月周期のWF型の計画駆動開発 アプリ開発チーム(インハウス) 2週間スプリントのスクラム開発 ↑ こっちの話
  70. 70. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th A B C フロー効率性重視の当初の開発計画 A B デザイン改善・UI/IX改善 技術負債解消 C C C C その他、改善
  71. 71. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th A B C A B C デザイン改善・UI/IX改善 技術負債解消 急遽、ビジネス的に大きな変更が舞い込んできた 商品の変更(営業連携、API連携=リリース日FIX) リリース日 C その他、改善 フロー効率性重視の当初の開発計画
  72. 72. リリース日固定だし、他の案件も全部まとめて やったほうが効率がよい(特に試験とか) (フロー効率の考えが何処かに行ってしまい、いつのまにかリソース効率で考えるように切 り替わってしまっている)                ↓ でも、もともとある案件と全部まとめるとリリー ス日に間に合わないなあ (大きなバッチサイズで一括でやることを前提にしてしまっている)                ↓ もともとある案件の仕様を調整して一括でリリー ス出来るようにしよう (期日に合わせてすべてをまとめてリリースすることが目的になる。結果的に、学びの無い期 間をチームが自ら作り出している。)                ↓ もとの案件の劣化版を提案する (本来の狙ったビジネス効果は得られない) リソース効率バイアスをかけた選択をチームがとりはじめて、 本来の目的を達成できるかわからない機能仕様になってしまう。
  73. 73. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 +1 +1 +1+1 +1 ±0 ±0 +1 +1+1±0 ±0 ±0 ±0 +1±0 ±0 ±0 ±0 売上 or KPI 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th A B C リリース日フロー効率性重視の当初の開発計画 1st week 2nd week 3rd week 4th week 5th week 6th week 7th we CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 売上 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 リソース効率性重視の大きなバッチサイズ開発 リリース日 価値を生んでいない期間を最大化・・・ 価値を積み上げていく予定が・・
  74. 74. チームがリリース日という制約を前提としてしまった - 前提を疑うべき - 制約をコントロール対象にする - そのリリース日って本当に固定なの? - 例えば事前にデプロイしておき、当日に切り替える - Feature Toggle運用とかやりようはある - エンジニアリングで制約をコントロール対象にできれ ば、フロー効率で考えられる。 - デプロイとリリースを切り離す。 【教訓】
  75. 75. 【事例】 スクラム等のセレモニーを形骸化 したまま実施しており、本来のビ ジネス上のリードタイムを意識し ていないケース (仕掛中在庫、DONEしないタスク群)
  76. 76. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th w CVR ±0 ±0 ±0 ±0 ±0 ±0 +3 売上 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 余談(場合によっては、目的にそぐわないケース) Sprint#1 Sprint#2 Sprint#3 リソース効率に振り切ったスクラム 価値までのリードタイムが長く、中々効果に繋がらない スクラムという手段に溺れた状態 目的を意識せずに形骸化したセレモニーをやっている状態 【教訓】何のためにアジャイルなのか目的を問うこと
  77. 77. まとめ
  78. 78. “How Much”どれだけ多くできるかという押し込むバイアス。 制約を前提として、まとめてたくさんのことをやるときのバイアス。 リソース効率性のパラダイムが強い。 VS “How Little”どれだけ細かく刻めるかを考えると変化に強くなる。 どれだけ小さく価値提供できるか。 フロー効率性のパラダイムが強い。 ビジネスの目的・文脈に合わせて以下を選択すると同時に その選択によってどのようなバイアスが働くかを考慮すること
  79. 79. 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 ビジネス価値とフロー効率性重視の開発スタイル
  80. 80. 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 ビジネス価値とフロー効率性重視の開発スタイル “How Much”どれだけ多くできるかという押し込むバイアス。 制約を前提として、まとめてたくさんのことをやるときのバイアス。 リソース効率性のパラダイムが強い。 “How Little”どれだけ細かく刻めるかを考えると変化に強くなる。 どれだけ小さく価値提供できるか。 フロー効率性のパラダイムが強い。
  81. 81. IDEAがCASHに変わるまでのバリューストリームにおける リードタイムを短くする改善活動の末、 結果的にアジャイルな状態になっているのが望ましい。 常に、目的を意識し、 目的からプルして 目的のための手段を選択する
  82. 82. 結果的に組織 がAgileな状態 であること。
  83. 83. ご清聴&ご静聴 ありがとうございました

×