組織横断で 生産性向上を生むまでの道筋とは？ 開発生産性 Meetup #1 1 Masato Ishigaki April 25, 2023

2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム事業本部 部長 / VPoE室 / アルファ室 ・略歴 : エンジニア新卒入社 → PjM → PdM / EM → 部長 + 横断 （URL） ・ID基盤 / CS-Platform / DMMポイントクラブ / ユーザーレビュー基盤 : PdM ・著 : 『DMMを支えるデータ駆動戦略』（マイナビ出版,2020） ・連携 : 『スモールチームが武器になる時代へ』（ProductZine） @i35_267 @i35_267 @i35_267

3 - 問題提起 - なぜ広める必要があったのか - 可観測性と再現性 - 導入アプローチ - 2つのMetrics - FindyTeam+導入時 - 良かったところ - 他チーム比較による効用 - 開発手法→生産性の合理性 - 採用アトラクト Outline

4 - 問題提起 - なぜ広める必要があったのか - 可観測性と再現性 - 導入アプローチ - 2つのMetrics - FindyTeam+導入時 - 良かったところ - 他チーム比較による効用 - 開発手法→生産性の合理性 - 採用アトラクト Outline

5 なぜ広める必要があったのか 独立採算の事業部制・カンパニー制 - 60事業、エンジニア数 700 ~ 1,000名の規模 ※ - 事業部制・カンパニー制のプロダクトチーム - コンウェイの法則、独立したエンジニア組織と文化 - GitHub Cloud / GitHub Enterprise. 主にGHCの方へ移行中 ※ DMM.comおよびEXNOA、2022年2月時点

6 なぜ広める必要があったのか 強い開発組織になりたい Div. x n Dev. x n

7 可観測性と再現性 強い開発組織のなるための課題（の一部） - 組織のサイロ化 - リソースマネジメント - 知見のサイロ化 - 同じ失敗 - 車輪の再開発 - 人が多ければ多いほど深刻 - 可観測性と再現性 - まず戦闘力を観測可能にする（Observability） - Observe（観測）Ability（能力） - 観測可能にすることで”再現性”が生まれる Div. x n Dev. x n

8 - 問題提起 - なぜ広める必要があったのか - 可観測性と再現性 - 導入アプローチ - 2つのMetrics - FindyTeam+導入時 - 良かったところ - 他チーム比較による効用 - 開発手法→生産性の合理性 - 採用アトラクト Outline

9 ２つのMetrics 2つのMetricsと抽象度 1. コードを書く → レビュー → Approve → CI → マージ a. FindyTeam+などを筆頭としたGitHubベースでの可視化 b. 機能開発だけにフォーカスした数値 c. Metrics : i. プルリク→マージまでの時間,etc… 2. プロジェクトとしてのバリューストリーム a. 工数・工期。ソフトウェアライフサイクル b. 実際の機能がリリースされるまでの俯瞰した数値 c. Metrics : i. 開発比率/ 非開発比率 / 運用保守 Delivery １ 2

10 ２つのMetrics 1. コードを書く → レビュー → Approve → CI → マージ a. FindyTeam+などを筆頭としたGitHubベースでの可視化 b. 機能開発だけにフォーカスした数値 c. Metrics : i. プルリク→マージまでの時間 ,etc… 2. プロジェクトとしてのバリューストリーム a. 工数・工期。ソフトウェアライフサイクル b. 実際の機能がリリースされるまでの俯瞰した数値 c. Metrics : i. 開発比率/ 非開発比率 / 運用保守 ※会社として勤怠と紐付けて推進中 プロジェクトA

11 FindyTeam+ 導入時 Findy Team+ 導入までの流れ - 2022/05/24 : 商談開始 - 2022/06/01 : トライアルチーム選出 - 2022/06/11 : 稟議作業 - 2022/06/xx : トライアル終了 - 2022/07/01 : 契約開始 導入のコツ - 仲間集め→効果測定→稟議→さらに広げる - 一番、人がいるOrgへの導入（事業部側の導入コストゼロ） - デモ共有会の実施 → 動画共有でアトラクト - 費用を一元管理（会計上の話）

1 2 - 問題提起 - なぜ広める必要があったのか - 可観測性と再現性 - 導入アプローチ - 2つのMetrics - FindyTeam+導入時 - 良かったところ - 他チーム比較による効用 - 開発手法→生産性の合理性 - 採用アトラクト Outline

1 3 “数値を出すことが、すべてではないが そこからしか始まらないこともある“

14 他チーム比較による効用 1. 技術投資の経済合理性へのちょっとした理解 Pain - 事業部長 : - 「開発が遅い」「競合との機能優位性に勝てない」 - エンジニア : - 「依存関係激しく変更行数が多くてアジリティがでない」 アプローチ - 決裁者へのわかりやすい説明 - 開発工数の短縮、コストダウン - 技術投資・デットテックへの価値観 醸成 - コストダウンを継続的に行う価値観（リファクタリング） - 腐敗させると、みるみる数値が下がっていく

15 他にも導入してよかったこと 2. 開発手法→生産性の合理性 - ブランチ戦略が見えてくる - 開発手法が見えてくる - 手法ごとに数値に変化が見えてくるa - アジャイルでやる。よりも抽象度が1つ下がる - CS定例による、客観的な視点も新鮮 引用 : DevOps 技術: トランクベース開発 3. 採用アトラクト - きちんと開発に投資しているイメージをもってもらえる - メンバーのDeveloper Productivity への関心UP

16 - 問題提起 → 強い開発組織を作る、一歩目 - 導入アプローチ → 決裁者目線でコストを考え、仲間を見つける - 良かったところ → 数値化することで会話が生まれ、改善が起こせる まとめ