開発生産性が組織文化になるまでの軌跡

2025/11/12 僕・私が考える最強の開発生産性を紹介します！【D-Plus Tokyo#19】

Transcript

1. 2025.11.12 | D-Plus Tokyo#19 開発生産性が組織文化に
 なるまでの軌跡
 D-Plus Tokyo#19 僕・私が考える最強の開発生産性を紹介します！
 福田 佑介 / ふくすけ (@tonegawa07)

2. 2025.11.12 | D-Plus Tokyo#19 自己紹介
 福田 佑介 / ふくすけ (@tonegawa07) 
 スタークス株式会社
 エンジニアリングマネージャー / テックリード
 • 仕事
 ◦ バックエンド / フロントエンド / 最近はデータエンジニアリングも 
 • 趣味
 ◦ サッカー観戦 (Jリーグ) 
 ◦ パン作り
 • ひとこと
 ◦ 社内勉強会や社内テックブログの運営をしています 
 ▪ 社内LTで醸成する開発組織のアウトプット文化 
 2
3. 2025.11.12 | D-Plus Tokyo#19 以前あった課題
 レビュー滞留が常態化 
 • PR出してもなかなかレビューされない
 • 数日後に大量のコメントがつきレビュー対応に追われる
 • PR Openからマージまで時間がかかる
 3
4. 2025.11.12 | D-Plus Tokyo#19 PRが腐る🤮
 4
5. 2025.11.12 | D-Plus Tokyo#19 腐った (放置された) PRに起こる問題
 • 実装者も記憶が薄れている
 • レビュアーはさらに薄れている
 • コンフリクト地獄
 5
6. 2025.11.12 | D-Plus Tokyo#19 リリースしようにもデグレが怖い💀
 6
7. 2025.11.12 | D-Plus Tokyo#19 レビュー負荷 = 認知負荷
 認知負荷を下げよう
 7
8. 2025.11.12 | D-Plus Tokyo#19 認知負荷を下げるために
 • 設計レビュー会
 ◦ 設計時点で情報共有することでレビュー負荷を下げる
 • PR分割
 ◦ 1PRあたりの変更量を減らすことでレビュー負荷を下げる
 8
9. 2025.11.12 | D-Plus Tokyo#19 PR分割のメリット
 • ビッグバンリリースを回避できる
 • レビューコストが下がる
 • タスクが細分化されているので進捗管理しやすい
 • メンタルヘルス (PRが腐らない)
 9
10. 2025.11.12 | D-Plus Tokyo#19 なんだかいい感じかも
 10
11. 2025.11.12 | D-Plus Tokyo#19 とはいえ
 まだ個人レベルの取り組み
 11
12. 2025.11.12 | D-Plus Tokyo#19 開発生産性指標をKPIに設定する
 Findy Team+ 導入をきっかけに設定したKPI
 • マージPR数
 ◦ 開発出力
 • オープンからレビューまでの平均時間
 ◦ レビュー着手の速さ
 • レビューからApproveまでの平均時間
 ◦ レビュー対応の速さ
 12
13. 2025.11.12 | D-Plus Tokyo#19 PR分割を行う上での考え方①
 1PR:1目的 
 ❌: 〇〇機能の追加と△△機能のリファクタリング
 ⭕: ①〇〇機能の追加, ②△△機能のリファクタリング
 13
14. 2025.11.12 | D-Plus Tokyo#19 PR分割を行う上での考え方②
 処理と呼び出しは分割できる 
 • モデル・エンティティ定義
 • CRUD処理 [バックエンド]
 • APIエンドポイント追加 [バックエンド]
 • API呼び出し [フロントエンド]
 • UI [フロントエンド]
 14
15. 2025.11.12 | D-Plus Tokyo#19 PR分割を行う上での考え方③
 デプロイとリリース (サービスイン) を切り離す 
 • 機能フラグやUI非表示などで内部処理だけを先に
 デプロイできる
 • ビッグバンリリースを避ける
 15
16. 2025.11.12 | D-Plus Tokyo#19 PR分割が徐々に浸透していく
 16
17. 2025.11.12 | D-Plus Tokyo#19 PR分割 = タスク分割
 タスク分割までを設計段階で行う (あとで変わっても良い) 
 17
18. 2025.11.12 | D-Plus Tokyo#19 1日1PR
 PR粒度の基準 
 • 1PR:1目的
 • 工数1日以内 (目安)
 18
19. 2025.11.12 | D-Plus Tokyo#19 当時のKPI
 • 月間マージPR数: 20件/人
 • オープンからレビューまでの平均時間: 12時間以内
 • レビューからApproveまでの平均時間: 24時間以内
 19
20. 2025.11.12 | D-Plus Tokyo#19 開発生産性施策の成果
 Findy Team+ Award 2023 Quick Success Division 受賞 
 20
21. 2025.11.12 | D-Plus Tokyo#19 PR分割も浸透して、成果も出て、
 めでたしめでたし
 21
22. 2025.11.12 | D-Plus Tokyo#19 とはならず
 22
23. 2025.11.12 | D-Plus Tokyo#19 調査タスクが計上されない問題
 サポート対応や不具合報告で発生する調査タスク
 • マージPR数にカウントされない
 • 貧乏くじのように感じてしまう
 実際の業務の優先度とKPIがコンフリクト 
 23
24. 2025.11.12 | D-Plus Tokyo#19 Product Team Value (PTV)
 PTV: 開発生産性指標 
 PTV = マージPR数 + (調査チケット対応数 × 負荷係数)
 ※ 負荷係数は状況に応じて調整
 チケット対応を含む開発チームのアウトプット量を定量評価
 24
25. 2025.11.12 | D-Plus Tokyo#19 開発生産性への意識が向上
 KPIに設定することで組織全体に浸透
 生産性向上のための施策が生まれる
 • Dependabot消化会
 • もくもくレビュー会
 • 設計相談/レビュー会
 25
26. 2025.11.12 | D-Plus Tokyo#19 継続したことで文化レベルで
 組織に根付く
 26
27. 2025.11.12 | D-Plus Tokyo#19 27 解決したい課題をKPIに落とし込む
 • チーム/個人の評価と紐づける
 • KPI軸で振り返り、議論する
 • 改善施策を回す

28. 2025.11.12 | D-Plus Tokyo#19 開発環境の大きな変化
 28
29. 2025.11.12 | D-Plus Tokyo#19 29
30. 2025.11.12 | D-Plus Tokyo#19 AIコーディングエージェントの登場
 • コーディングにかかる時間が大幅に短縮
 • 従来の1日1PRとは基準が変わる
 • レビューがボトルネックに
 30
31. 2025.11.12 | D-Plus Tokyo#19 やることは変わらない
 • 開発速度が上がっても分割の有効性は変わらない
 • PR分割が文化として定着していたことで
 AIによる開発時間短縮の恩恵を受けた
 31
32. 2025.11.12 | D-Plus Tokyo#19 レビュー負荷を下げるために
 • Claude Code Action
 ◦ PR要約、レビュー自動化
 • CodeRabbit
 ◦ PR要約、レビュー自動化
 • Devin
 ◦ Dependabotで更新されるライブラリ
 破壊的変更の有無を確認し推奨アクションを提案
 32
33. 2025.11.12 | D-Plus Tokyo#19 文化になったその先に
 現在、マージPR数 (PTV) やサイクルタイムは
 KPIとしては追っておらず、定点観測指標として計測
 • 開発組織の文化として定着した
 • 一定以上の水準を維持できているか確認
 33
34. 2025.11.12 | D-Plus Tokyo#19 プロダクトの価値に向き合う開発組織へ
 開発生産性1.0 : 出力量・生産量
 • 定点観測で一定以上の出力を維持
 (AI活用等でさらに進化させる)
 開発生産性2.0 : プロダクト価値
 • アクティブユーザー数、機能別利用数など
 プロダクト価値指標にフォーカス
 34
35. 2025.11.12 | D-Plus Tokyo#19 35 プロダクト価値に向き合う
 • PR数やサイクルタイムはヘルスチェック指標
 • 基準をクリアしながら (開発生産性を維持しながら)
 プロダクト価値・品質に向き合う

36. 2025.11.12 | D-Plus Tokyo#19 まとめ
 36
37. 2025.11.12 | D-Plus Tokyo#19 組織にフィットした指標と継続が
 文化形成につながる
 37
38. 2025.11.12 | D-Plus Tokyo#19 組織文化に根付いたことで
 プロダクト価値に向き合える
 38
39. 2025.11.12 | D-Plus Tokyo#19 開発生産性が組織文化に
 なるまでの軌跡
 ご清聴ありがとうございました