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.

フロー効率性とリソース効率性、再入門 #devlove #devkan

3,280 views

Published on

DevLove関西の以下のイベントのスライドです
https://devlove-kansai.doorkeeper.jp/events/75644

Published in: Engineering

フロー効率性とリソース効率性、再入門 #devlove #devkan

  1. 1. フロー効率性 とリソース効 率性、再入門 黒田 樹 @i2key リクルートテクノロジーズ リクルートジョブズ
  2. 2. リソース効率性 - フロー効率性 大事にしたい価値観 How much - How little タスク管理 - ペース管理 プッシュ型 - プル型 マルチタスク - シングルタスク Waterfall vs Agile ではなく 手法論ではなく原理原則に立ち返り目的ベースで考える
  3. 3. リソース効率性とフロー効率性
  4. 4. リソース効率性とフロー効率性 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
  5. 5. リソース効率性 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人日かかる場合 複数のことを同時にやるとプロダクトがユーザに届くまで・検 証を開始するまでのリードタイムが長くなる。 ただし、皆に仕事が割り振られるため、また時間の余る限り複 数の仕事を持つためリソースあたりの稼働率は高くなる。
  6. 6. 1つのリソースを稼働率が100%になるまで分配する 例 ・マルチタスク ・大きなウォーターフォール型開発 A B C Resource 流れる対象 30% 30% 40% リソース稼働率:100% (作業時間を絞り出す量を最大化) 1リソースに フォーカスする 流れる対象 流れる対象 リソース効率性
  7. 7. フロー効率性 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だけでみるとトータル稼働は多い)
  8. 8. A Resource 流れる対象 流れる対象(タスク)が得られるリソースの時間を最大化する 流れる対象に フォーカスする Resource Resource 例 ・ペアプログラミング/モブプログラミング ・クロスファンクショナルチーム ・システム障害発生時の動き フロー効率性
  9. 9. リソース効率性とフロー効率性 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. 10. リソース効率性とフロー効率性 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%、リソースに遊びが無い 「フロー効率性」が良い (例)機能リリースまでのリードタイムの短さ
  11. 11. リソース効率性 - フロー効率性 大事にしたい価値観 How much - How little タスク管理 - ペース管理 プッシュ型 - プル型 マルチタスク - シングルタスク Waterfall vs Agile ではなく 手法論ではなく原理原則に立ち返り目的ベースで考える
  12. 12. A A A A A A A A A AA A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 3w 思考停止した「マルチタスクは悪である」信仰。 A A A A A A A A A A A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w 本質的にはマルチタスクはNGであるが、同じ目的のものを 多重化してリソース効率の優先度をさげ(瞬間コスト増)、 フロー効率(リードタイム短縮)を取る選択肢はある。 ※目的の理解とマルチタスクの定義は重要 シングルタスク 組織的なマルチタスク(に見えるなにか)
  13. 13. A A A A A A A A A AA A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 3w やることを小さくすることでもLTの短縮はできる。 A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w 達成すべき目的が満たせるなら、やることを小さくする。 (かかるコストをさげてリードタイムも短くする) シングルタスク やることを小さくする A A A A A A A A A A
  14. 14. A A A A A A A A A AA A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 3w 同じリードタイム短縮でもやりかた色々 A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リードタイム短縮前 やることを小さくして(コスト下げて)リードタイムを短縮 A A A A A A A A A A A A A A A A A A A A A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w コストを増やしてリードタイムを短縮
  15. 15. A A A A A A A A A AA A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 3w 同じリードタイム短縮でもやりかた色々 A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リードタイム短縮前 やることを小さくして(コスト下げて)リードタイムを短縮 A A A A A A A A A A A A A A A A A A A A A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w コストを増やしてリードタイムを短縮 目的ではなく手段にフォーカスした 「マルチタスクは悪」信仰の場合、 これはNGになりがち。
  16. 16. http://jp4.scaledagileframework.com/set-based-design/ 例)ポイントベース設計 1つの設計戦略を初期に確約するため、締切が迫った際の変更コストがやばい 例)セットベース設計 開発サイクルの中で長い期間、設計の選択肢を複数残し経済合理性を高める
  17. 17. リソース効率と フロー効率の関係
  18. 18. リソース効率とフロー効率はトレードオフの関係になりやすい 大規模開発のような大量のものを一括でドン!と リリースする文脈(リソース効率が支配するパラダイム) ペアプログラミングしたいです! (効果:フロー効率アップ) 2人で同じことやったら、 効率半分に落ちるだろ!却下! (効果:リソース効率ダウン) エンジニア氏 偉い人氏
  19. 19. リソース効率とフロー効率はトレードオフの関係になりやすい 仮説検証型でUI/UX改善を回し、KPIを伸ばしにいく文脈。 現場は学びまでのリードタイムを限りなく最小化したい。 (無意識にフロー効率を重視している) リリース物はすべて承認が必要だ。 だが、わしは忙しいから 一括でまとめて持ってきなさい。 (フロー効率ダウン) (効率落ちるだろ!) ヘイトマッハっすわー エンジニア氏 偉い人氏
  20. 20. Efficiency Paradox This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  21. 21. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態
  22. 22. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・それぞれの島の中において資源効率が高く、島毎に個別最適化された状態。 ・フォーカスは資源であり、独自の資源を効率的に活用することによって、  各部門は生産される商品やサービスのコスト削減に貢献 ・製造業において、各コンポーネントや製品が在庫として費やしている時間の割合が  大半を占める。 ・結果的に、顧客に価値が届くまでの時間を長くする待機時間を作り出している。
  23. 23. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・効率が高いが資源効率が低い状態。 ・フォーカスは顧客にあり、可能な限り効率的にニーズを満たすこと。 ・フロー効率を最大限にするには、組織のリソースに空き容量が必要。  リソースの効率的な使用を犠牲にしてフローを効率的にする。 ・効率的な海を作り流れを作り出すには、独立した効率的な島だけではなく、  全体像をよく理解する必要がある。
  24. 24. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・組織はそのリソースを効率的に使用することも、  効率的なフローを作成することもできていない状態。 ・リソースの浪費 & 顧客への提供価値が低い状態
  25. 25. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 効率的な島々 効率的な海 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 荒廃した土地 完全な状態 ・完璧な状態 ・この状態を達成する組織は、高いリソース効率と  高いフロー効率の両方を備えている。 ・完璧な状態に到達することは困難である ・完全な状態に到達することの難しさの鍵は、Variation(ムラ)。
  26. 26. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い Variation This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  27. 27. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い Variation This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 例:高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多) 例:カプセルホテル (部屋稼働率:100%) (客数に対する従業員数:少)
  28. 28. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation 我々 稼働率100%のチーム 機能がリリースされるまでの リードタイム長い 稼働率は100%ではないチーム 機能がリリースされるまでの リードタイム短い 例:高級ホテル/旅館 (部屋稼働率:空き部屋あり) (客数に対する従業員数:多) 例:カプセルホテル (部屋稼働率:100%) (客数に対する従業員数:少) This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  29. 29. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation WaterFall SoR Agile SoE 小規模・仮説検証 大規模開発 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  30. 30. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  31. 31. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  32. 32. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 流れに着目するほうがムダを炙り出しやすい こっちから登ったほうが リソース効率上のムダも発見しやすい This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
  33. 33. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 達成することは不可能。星に到達するためには、組織は2つのことが必要。 ・顧客の現在および将来のニーズに関するすべての情報を完全に把握。 ・完全に柔軟で信頼性の高いリソースが必要。 リソースの容量、機能、能力をすぐに調整してすべてのタイプのニーズを満たすこと ここでの鍵は、需要(顧客のニーズ)と供給(組織のリソース)の両方の変化。
  34. 34. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - ムラがこの境界を内側に押しこむ 到達不能領域 需要が完全に予測可能でなく、かつ/またはリソースが完全に柔軟で信頼できるものでは ない場合(需要と供給にムラがある場合) 組織がリソース効率を改善し、それを高いフロー効率とどのくらい組み合わせるかには限 界が発生する。 Efficiency Frontier Efficiency Frontier
  35. 35. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - ムラがこの境界を内側に押しこむ Efficiency Frontier 病院の緊急医療室 大量の類似製品を製造する製造会社 到達不能領域 Efficiency Frontier 到達不能領域
  36. 36. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - ムラがこの境界を内側に押しこむ Efficiency Frontier 新規事業、スタートアップ 到達不能領域 Efficiency Frontier 到達不能領域 我々
  37. 37. リソース効率とフロー効率の ビジネス目標に対する 効果・影響
  38. 38. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 成果課金型 広告枠検索サービス ¥0 利用者 クライアント マッチング サービス CVR改善 = 売上直結 例:CVR最大化に向けたUI/UX仮説検証 流入数
  39. 39. 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 ビジネス価値とフロー効率性重視の開発スタイル
  40. 40. 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 学んでいない期間 稼いでいない期間 学んでいない期間 稼いでいない期間 オーバーヘッドで 若干合計稼働は増える ビジネス価値とリソース効率性重視の開発スタイル ビジネス価値とフロー効率性重視の開発スタイル 複数の実験を 同時にやると濁る
  41. 41. リクルートの ビジネスモデルと エンジニアリング
  42. 42. クライアント 様向け画面 アルバイト先を 探している人 アルバイトを 募集している企業
  43. 43. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) 求人情報の出向枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ)
  44. 44. SoR Bimodal IT Mode1 Mode2 正式名称 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続 ける必要がある機能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保し ながら開発していく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加 え、頻繁にリリースする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス&開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 SoE 計画型 シッカリカッチリ 探索型 速さ、柔軟さ
  45. 45. クライアント 様向け画面 商品開発 サイト改善 サイト改善 求人情報に対するコンバージョンレートの向上 UI/UXの継続的改善(仮説検証型) 求人情報の出向枠の追加 掲載期間、掲載形式等の商品に関する開発 (営業広報あるため計画駆動、シッカリカッチリ) SoRSoE SoE
  46. 46. SoEとSoRの目的別でチームを分ける マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE
  47. 47. SoEとSoRの目的別でチームを分ける マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE リソース効率性 フロー効率性 フロー効率性
  48. 48. SoEとSoRの目的別でチームを分ける マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE 日経SYSTEMS 6月号に掲載していただきました
  49. 49. フロー効率性を現場への適用
  50. 50. SoEとSoRの目的別でチームを分ける マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア :エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア : SoR SoE SoE プランナー CVR向上 案件 CVR向上 案件 CVR向上 案件 ここの話→
  51. 51. 目的を見失いスクラムという手法に目がいった例 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機能、B機能、C機能の実装それぞれ15人日かかる場合 Sprint#1 Sprint#2 A 担当者 B 担当者 C 担当者 ココ チケット全部 DONEです! チケット全部 DONEです! チケット全部 DONEです! プロダクト オーナー いくら計画したチ ケット消化が100% でも、何もリリース 出来なければビジ ネス上意味ないよ
  52. 52. 目的を見失いスクラムという手法に目がいった例 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機能、B機能、C機能の実装それぞれ15人日かかる場合 Sprint#1 Sprint#2 A 担当者 B 担当者 C 担当者 ココ チケット全部 DONEです! チケット全部 DONEです! チケット全部 DONEです! プロダクト オーナー いくら計画したチ ケット消化が100% でも、何もリリース 出来なければビジ ネス上意味ないよ ビジネス的にはフロー効率性を重視して スクラムを運営してほしかったのに、 チケットをすべてDONEすることを 目的としたリソース効率性特化な スプリントが運営されていた。
  53. 53. 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 ビジネス価値とフロー効率性重視の開発スタイル Sprint Sprint Sprint
  54. 54. 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 ビジネス価値とフロー効率性重視の開発スタイル リードタイム リードタイム Sprint Sprint Sprint
  55. 55. 本質の理解を欠いたスクラムをいったん辞め、 タスクボード(notカンバン)へ。 https://speakerdeck.com/poohsunny/devsumi2018 「○○API実装」みたいなタスクがDONEしても1円も生まない。
  56. 56. 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 バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト ビジネス価値とフロー効率性重視の開発スタイル
  57. 57. 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 バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト ビジネス価値とフロー効率性重視の開発スタイル リードタイム リードタイム短縮 エンジニアリングによってLTを短縮したい
  58. 58. リードタイム プロセスタイム(PT) ムダ+ 顧客への価値を作り出している時間 価値を作っていない時間 ➡設計 ➡コーディング ➡ビルド待ち ➡手戻り ➡承認待ち
  59. 59. ムダを排除する ✓余分な機能のムダ ✓遅れのムダ ✓引き継ぎのムダ ✓再学習のムダ ✓未完成の作業のムダ ✓タスク切り替えのムダ ✓欠陥のムダ ➡使わない機能 ➡様々な要因による待ち ➡他部署,メンバへの引き継ぎ ➡標準化されていない ➡同時にたくさん着手 ➡不要な作業、遅い作業 ➡低品質による手戻り
  60. 60. 企画からリリースまでの全工程の タスクの流れからボトルネックを 浮き彫りにし、ボトルネックに潜 むムダを潰したい
  61. 61. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 未着手案件の在庫推移を可視化し組織生産性の可視化 1案件あたりのリードタイムを最小化したい
  62. 62. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 Ready状態の在庫を作る スループット 在庫を出荷する スループット 在 庫 量 推 移 Ready化数 リリース数 未着手案件の在庫推移を可視化し組織生産性の可視化 1案件あたりのリードタイムを最小化したい
  63. 63. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 Ready状態の在庫を作る スループット 在庫を出荷する スループット 在 庫 量 推 移 ① ② ③ ① ② リードタイム ③ ③=①-②  =在庫量 Ready化数 リリース数累積フロー図 未着手案件の在庫推移を可視化し組織生産性の可視化
  64. 64. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 Ready状態の在庫を作る スループット 在庫を出荷する スループット 在 庫 量 推 移 ① ② ③ ③① ② Ready化数 リリース数 Readyにした数とリリースした数 在庫数推移 未着手案件の在庫推移を可視化し組織生産性の可視化
  65. 65. Ready状態の在庫を作る スループット 在庫を出荷する スループット > ↑ 開発の生産性がボトルネック
  66. 66. 開発チーム内のムダをあぶり出す
  67. 67. ムダを排除する ✓余分な機能のムダ ✓遅れのムダ ✓引き継ぎのムダ ✓再学習のムダ ✓未完成の作業のムダ ✓タスク切り替えのムダ ✓欠陥のムダ ➡使わない機能 ➡様々な要因による待ち ➡他部署,メンバへの引き継ぎ ➡標準化されていない ➡同時にたくさん着手 ➡不要な作業、遅い作業 ➡低品質による手戻り
  68. 68. 設計 実装 試験 設計 実装 試験 手戻り リワークチャートによる手戻りの可視化 https://speakerdeck.com/poohsunny/devsumi2018
  69. 69. XPやDevOpsのプラクティスは フロー効率性を高める作用が強い 改善目的に合わせて利用させていただく。
  70. 70. リワークチャートによる手戻りの可視化 設計 実装 試験 設計 実装 試験 手戻り Javascript周りのフロントエンド実 装における技術的負債による手戻り https://speakerdeck.com/poohsunny/devsumi2018
  71. 71. もろもろ改善していった結果、 最終的にボトルネックが技術的負債に推移。 ここではじめて、 技術的負債によって低下している開発の生産性が 企画ふくめた全体のスループットを決定している状態になる。 となると、技術負債の解消 = ビジネス速度向上。
  72. 72. でも、本当に倒すべきはこれ。
  73. 73. ムダを排除する ✓余分な機能のムダ ✓遅れのムダ ✓引き継ぎのムダ ✓再学習のムダ ✓未完成の作業のムダ ✓タスク切り替えのムダ ✓欠陥のムダ ➡使わない機能 ➡様々な要因による待ち ➡他部署,メンバへの引き継ぎ ➡標準化されていない ➡同時にたくさん着手 ➡不要な作業、遅い作業 ➡低品質による手戻り これが一番たちが悪い
  74. 74. 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 良質玉 価値 (成果) 質低玉 ムダ リードタイム短縮 リードタイム短縮 これを目指したい 高速にムダを作っているだけ
  75. 75. 設計 実装 テスト 課題理 解 仮説構 築 仮説検証 設計 要件定 義 マーケ 計測 データか ら学ぶ リリース ユーザCV 仮説実証 ユーザー ストーリー 設計 エンジニアとして前工程、後工程に染み出していく
  76. 76. 改善するリードタイムのスコープを広げる リードタイム リードタイム From 要件定義 to リリース From 課題設定 to 仮説実証 From コンセプト to キャッシュ
  77. 77. From 課題設定 to 仮説実証 From コンセプト to キャッシュ データから仮説を 類推できる人 蓄積したデータを可視化し 学びや次の仮説にインプット するためのデータ基盤 安全に実験出来るテスト基盤 Feature Toggle/ Dark Launch/ DevOps系なアレコレ From 要件定義 to リリース
  78. 78. DataOps DevOps※狭義 MarketingOps SalesOps DesignOps 最近の潮流:xOpsによるフロー効率性の向上
  79. 79. https://www.slideshare.net/takaumada/xops
  80. 80. 課題 理解 会議室で考えて 思い込みで 始めると 仮説 実証 ここで 失敗が発覚 超手戻り 改善するリードタイムのスコープを広げる
  81. 81. Build - Measure - Learnに フロー効率を注入する
  82. 82. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説検証のバッチサイズを小さくする(MVPを小さくする) 仮説A 仮説B 仮説C 1st week 2nd week 3rd week 4th week 5th week 6th week 7th wee 仮説A 仮説B 仮説C仮説A’ 仮説B’ 仮説C’ 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 仮説A 仮説B 仮説C仮説B’仮説A’ 1仮説検証を2weeksでやる場合、26回/年 1仮説検証を1weekでやる場合、52回/年 検証結果から、実施不要の検証を省略でき、後続の検証を前倒し出来る 仮説C’
  83. 83. いきなり時計回しで始めるとムダを含むMVPを作りがち 30 仮説検証の精度を上げる(ムダなMVPを作らない) どんなMVP作ればいいの? 仮説はある! オーバースペックMVP 作りすぎのムダ
  84. 84. いきなり時計回しで始めるとムダを含むMVPを作りがち 30 仮説検証の精度を上げる(ムダなMVPを作らない) どう測ればいいんだっけ? そもそも測れるのだっけ? この手元にあるデータで 実証できたといえるんだっけ? 仮説はある! これだめだ、 測り直しだ 再学習のムダ
  85. 85. 手戻りのムダや作り過ぎのムダを減らすために、 ニーズに対しMVP(必要最小限の価値のあるもの)をつくる →ニーズからプルする 情報の流れ モノの流れ ニーズ when what amount when what amount when what amount when what amount pullpullpull push push push 仮説検証の精度を上げる(ムダなMVPを作らない)
  86. 86. ①仮説 ②何を学ぶのか ③必要なデータは? ④どうやって計測する? ⑤必要なものは? ⑥どう構築するか? 思考プロセス (情報の流れ) pull pull pull pull pull 30 仮説検証の精度を上げる(ムダなMVPを作らない)
  87. 87. ⑫仮説を実証 ⑪学ぶ ⑩データを元に検証 ⑨計測する ⑧完成したMVP ⑦構築する 実証プロセス (モノの流れ) push pushpush push push 30 仮説検証の精度を上げる(ムダなMVPを作らない)
  88. 88. 情報の流れ(BMLを逆流) モノの流れ(BMLの流れ) ニーズ pullpullpull ①仮説②何を学ぶのか ③必要なデータ ④計測方法 ⑤必要な計量器 ⑥構築方法 ⑫実証 ⑪学ぶ ⑩データで検証 ⑨計測する ⑧完成したMVP⑦構築する push push push BUILD MEASURE LEARN BUILD設計 MEASURE設計 LEARN設計 ① ② ③ ④ ⑤ ⑥ ⑫ ⑪ ⑩ ⑨ ⑧ ⑦ 仮説検証の精度を上げる(ムダなMVPを作らない)
  89. 89. 仮説検証の精度を上げる(ムダなMVPを作らない) 仮説検証を設計する
  90. 90. 仮説 何を学ぶのか MVP種類 ・紙ペラ ・インタビュー ・動くデモ ・etc 学ぶために何を作るかの詳細 実証に 必要な条件 MVP構築 コスト 仮説実証 にかかる 時間 将来のリ スク/機会 結果、実際の学び 仮説検証の精度を上げる(ムダなMVPを作らない) 仮説検証を設計する
  91. 91. まとめ
  92. 92. リソース効率性 - フロー効率性 大事にしたい価値観 How much - How little タスク管理 - ペース管理 プッシュ型 - プル型 マルチタスク - シングルタスク Waterfall vs Agile ではなく 手法論ではなく原理原則に立ち返り目的ベースで考える
  93. 93. 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 ビジネス価値とフロー効率性重視の開発スタイル
  94. 94. A A A A A A A A A AA A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 3w 同じリードタイム短縮でもやりかた色々 A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w リードタイム短縮前 やることを小さくして(コスト下げて)リードタイムを短縮 A A A A A A A A A A A A A A A A A A A A A A A A A 月 火 水 木 金 月 火 水 木 金 月 火 水 木 金 リリースまでのリードタイム 1w コストを増やしてリードタイムを短縮 目的ではなく手段にフォーカスした 「マルチタスクは悪」信仰の場合、 これはNGになりがち。

×