大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
•
18 likes•15,904 views
https://event.shoeisha.jp/devsumi/20190702/session/2083/ デベロッパーズサミット2019夏のスライドです。
大規模レガシー環境に立ち向かう有機的な開発フォーメーション #devsumi #devsumic
- 7. リソース効率性とフロー効率性 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
- 8. 1つのリソースを稼働率が100%になるまで分配する 例 ・マルチタスク ・大きなウォーターフォール型開発 A B C Resource 流れる対象 30% 30% 40% リソース稼働率：100% (作業時間を絞り出す量を最大化) 1リソースに フォーカスする 流れる対象 流れる対象 リソース効率性
- 10. 検索条件 入力画面 検索結果 一覧画面 詳細画面 予約画面 口コミ SEO SEM ETC サービス トップ 画面 if(isBooked){ } 口コミ SEO SEM ETC 掲載枠検索 ¥0 利用者 クライアント 広告 ビジネス CVR改善 ＝ 売上直結 例：CVR最大化に向けたUI/UX仮説検証 流入数
- 11. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C リソース効率を重視して開発した場合 フロー効率を重視して開発した場合
- 12. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week A B C 学んでいない期間 稼いでいない期間 学んでいない期間 稼いでいない期間 オーバーヘッドで 若干合計稼働は増える 複数の実験を 同時にやると濁る リソース効率を重視して開発した場合 フロー効率を重視して開発した場合
- 13. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low Variation 一度に沢山 SoR 一個ずつ SoE 小規模・仮説検証 大規模開発 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix -
- 14. リソース効率 フロー効率 リソース効率とフロー効率の関係 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - どう登っていくか
- 19. ビジネス構造の理解
- 26. SoR Bimodal IT Mode1 Mode2 正式名称 System of Record(SoR) System of Engagement(SoE) 適正 基幹系・勘定系、 ミッションクリティカルな機能・システム (決済システム、顧客管理等) 正解が無い中、柔軟に変化をしながら走り続ける必要がある機 能・サービス (スマホアプリ、ウェブサービスのフロント) 目的 信頼性、安定性 定めた仕様に従って安定性や品質を担保しながら開発して いく必要がある 俊敏性、速度 フィードバックに基づいて速やかに改善を加え、頻繁にリリー スする 価値・評価 費用対効果、コスト 売上、ブランド、UX アプローチ ウォーターフォール、V-model、重量IID アジャイル、リーン、カンバン、軽量IID 調達 エンタープライズサプライヤー、 長期的な取引 小さい、新しいベンダー、短期間の取引 メンバ適正 従来のプロセス、プロジェクトが得意 新しくて不確実なプロジェクトが得意 組織/文化 開発部門・計画型 ビジネス＆開発混在・探索型 サイクルタイム 数ヶ月 数日、数週間 SoE 計画型 シッカリカッチリ 探索型 速さ、柔軟さ
- 36. マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア ：エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア ： SoR SoE SoE カンバン ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア ： 安定稼働、アーキ (組織的ゆとり) グロースハックチーム商品開発チーム
- 38. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟
- 39. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム
- 40. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 調 整 ネ ジ
- 41. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム 予算：目的：責任：チームが1対1の状態 投資側からすれば目 的が達成できればよ いのでHOWは自由。 あとは任せた！ →チームに自治権 →現場裁量で推進 →精神論ではなく構 造的アプローチによ る自己組織化
- 42. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム アーキテクチャ （余談）マイクロサービス 予算：目的：責任：チームが1対1の状態
- 43. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム 予算枠 目的&責任 チーム 予算：目的：責任：チームが1対1の状態 予算枠 目的&責任 チーム 予算枠 目的&責任 チーム
- 45. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」
- 46. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」 複数のことをまとめてV字 モデルでやる （ウォーターフォール？） 一個ずつV字モデルでやる （アジャイル？カンバン？ スクラム？それ系のやつ） 「ゆとり」を投資して効率 化で「ゆとり」をつくる
- 47. マーケ組織 商品企画組織 営業組織 データ系組織 プロダクト開発組織 プロダクトオーナー プロジェクト(WF) スクラム or カンバン スクラム or カンバン アーキテクト プロダクトオーナー プロキシー プロダクトオーナー プロキシー プロジェクトリーダー スクラムマスター ○○○○○ XXXXXX △△△△△ ○○○○○ プロダクトオーナー プロキシー ○○○○○ XXXXXX △△△△△ ○○○○○ ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア ：エンジニア x N人 UI/UXデザイナー スクラムマスター エンジニア エンジニア エンジニア ： リソース効率 フロー効率 フロー効率 カンバン ○○○○○ XXXXXX △△△△△ ○○○○○ エンジニア エンジニア エンジニア ： 安定稼働、アーキ (組織的ゆとり) グロースハックチーム商品開発チーム
- 49. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C フロー効率を重視して開発した場合 毎回リグレッションテストを 手動でやるのだるいし、オーバーヘッド大きすぎ。 だったら複数まとめて一回でテストしたほうが効率が良い →リソース効率のパラダイムに戻りたい 1個流しを志向すると最初に発生する壁
- 50. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C フロー効率を重視して開発した場合 毎回リグレッションテストを 手動でやるのだるいし、オーバーヘッド大きすぎ。 だったら複数まとめて一回でテストしたほうが効率が良い →リソース効率のパラダイムに戻りたい 1個流しを志向すると最初に発生する壁 テストコードかけばいいのでは？
- 51. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C フロー効率を重視して開発した場合 毎回リグレッションテストを 手動でやるのだるいし、オーバーヘッド大きすぎ。 だったら複数まとめて一回でテストしたほうが効率が良い →リソース効率のパラダイムに戻りたい 1個流しを志向すると最初に発生する壁 テストコードかけばいいのでは？ メソッド単位が大きすぎるし、テストコード書くなら リファクタリングしないととんでもないテストコードになる でも、リファクタリングして品質担保できる気がしない
- 52. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」
- 58. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C フロー効率を重視して開発した場合 1個流しを志向すると最初に発生する壁 2週間サイクルの開発においてリグレッションテスト時間が 3日→45分
- 59. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C フロー効率を重視して開発した場合 1個流しを志向すると最初に発生する壁 2週間サイクルの開発においてリグレッションテスト時間が 3日→45分 「ゆとり」の投資でさらなる 「ゆとり」を創出
- 60. SoEにおける エンジニアリング
- 61. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル
- 62. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル 1個ずつV字モデル開発 複数まとめてV字モデル開発
- 63. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week 0 0.75 1.5 2.25 3 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week ビジネス価値とリソース効率性重視の開発スタイル A B C ビジネス価値とフロー効率性重視の開発スタイル リードタイム リードタイム
- 64. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト ビジネス価値とフロー効率性重視の開発スタイル
- 65. 1st week 2nd week 3rd week 4th week 5th week 6th week 7th week 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 week A B C バックエンド エンジニア フロント エンジニア プロダクト オーナー 顧客 +1 承認レビュー 仕様確認 API開発 API開発 Front開発 デプロイ待ち 待ち待ち テスト テスト ビジネス価値とフロー効率性重視の開発スタイル リードタイム リードタイム短縮 エンジニアリングによってLTを短縮したい
- 67. DevelopmentPlanning Design Measure Ph.1 Ph.2 Ready会 SprintDesign AB Testing 工程別 滞留数 (在庫数) 工程別 スルー プット 4個/2週 3個/2週 3個/2週 4個/2週 1個/2週 4個/2週 未着手案件の在庫推移を可視化し組織生産性の可視化 1案件あたりのリードタイムを最小化したい
- 68. 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案件あたりのリードタイムを最小化したい
- 69. 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化数 リリース数累積フロー図 未着手案件の在庫推移を可視化し組織生産性の可視化
- 70. 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にした数とリリースした数 在庫数推移 未着手案件の在庫推移を可視化し組織生産性の可視化
- 71. SoRにおける エンジニアリング
- 75. 障害対応/SRE マーケ・プロモ 法令・要請 商品開発(掲載枠等) グロースハック （UI/UX改善） 4月 7月 10月 1月 予算 Time 投資ポートフォリオとエンジニアチーム構成の関係 責務：コンバージョン率UP 予算ロック & 納期柔軟 責務：売上 + α 予算ロック & 納期コミット 責務：安定稼働 + アーキテクト 予算ロック & 納期柔軟 グロースハックチーム 商品開発チーム 安定稼働チーム =>フロー効率重視 =>リソース効率重視 =>組織的「ゆとり」
- 81. これを繰り返した結果
- 86. これを倒す
- 103. リソース効率 フロー効率 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 稼働率 リードタイム 高稼働率 高バッチサイズ コスト効率を目指すオフショア（これもやってます） より安く
- 104. リソース効率 フロー効率 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 稼働率 リードタイム 高稼働率 高バッチサイズ フロー効率でリフレームするオフショア(今回の話)
- 105. リソース効率 フロー効率 High HighLow Low ココに 行きたい 我々 This is Lean https://www.amazon.co.jp/dp/919803930X/The Efficiency Matrix - 稼働率 リードタイム オフショアで リードタイム短縮 オフショアはセットベースやフロー効率を意識することで、 人月の神話(ブルックス)の逆張りで効率化を図ることが可能 （組織としての予算は固定でスループットは増加している） フロー効率でリフレームするオフショア(今回の話)
- 106. まとめ
- 110. ご静聴&ご清聴 ありがとうございました