Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
レビューの見直しによる開発生産性の向上
Search
Daiki Suyama
February 24, 2024
Programming
0
160
レビューの見直しによる開発生産性の向上
2022/10 ~ 2023/03に取り組んだプロジェクトの紹介です。
Daiki Suyama
February 24, 2024
Tweet
Share
More Decks by Daiki Suyama
See All by Daiki Suyama
期待付加価値の生産性向上(夏の開発生産性LT版)
daikisuyama
0
820
ビジネスサイドとの連携改善 ~アウトプットの最適化~
daikisuyama
1
660
事業とプロダクト間のインターフェース作り
daikisuyama
0
890
Other Decks in Programming
See All in Programming
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
A full stack side project webapp all in Kotlin (KotlinConf 2025)
dankim
0
120
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
590
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
11k
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
170
Blazing Fast UI Development with Compose Hot Reload (droidcon New York 2025)
zsmb
1
290
ISUCON研修おかわり会 講義スライド
arfes0e2b3c
1
450
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
効率的な開発手段として VRTを活用する
ishkawa
0
140
地方に住むエンジニアの残酷な現実とキャリア論
ichimichi
5
1.5k
Hack Claude Code with Claude Code
choplin
4
2.1k
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Embracing the Ebb and Flow
colly
86
4.7k
Balancing Empowerment & Direction
lara
1
430
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
Git: the NoSQL Database
bkeepers
PRO
430
65k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
How GitHub (no longer) Works
holman
314
140k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Transcript
レビューの見直しによる 開発生産性の向上 株式会社クライド 陶山大輝
目次 • 概要 • プロジェクトの準備 • レビューの見直し • 結果と考察
概要
プロジェクトの概要 • 時期 ◦ 2022/10 ~ 2023/03 • 対象チーム ◦
自社プロダクトの開発チーム ▪ マネージャー 1人、チームリーダー 1人、メンバー 1人 • チーム状況 ◦ 数ヶ月単位でのリリースの遅延や手戻りの頻発などの課題が山積 ◦ PMF前のプロダクトのため、プロジェクトに多くの時間は費やせない • 目的 ◦ 開発生産性を向上させること
プロジェクトの準備
開発プロセスの言語化 • 課題 ◦ 開発プロセスが明確でなく、調整に費やす時間が多かった • 解決策 ◦ 開発プロセスと関連する課題を言語化(後述) ▪
ディスカバリーとデリバリー • 効果 ◦ 課題が明確に!
開発プロセス ~ディスカバリー~ • 手順 ◦ 機能検討 ▪ PO:ステークホルダーからの要望から機能を検討 ▪ PO:優先順位を確定
◦ 仕様策定 ▪ PO:開発が確定した機能の仕様を策定 ▪ PO:機能単位(エピック)でエンジニアへと依頼 • 課題(抜粋) ◦ エンジニアの観点が不足したまま仕様が決定 ▪ → 仕様の考慮漏れなどにより、手戻りが発生しやすい
開発プロセス ~デリバリー~ • 手順 ◦ 設計 ▪ 開発チーム:エピック(機能単位)の担当者を決定 ▪ エピック担当者:仕様をPOに確認しながら設計
▪ エピック担当者:チケット(開発単位)へと分割 ◦ 開発 ▪ チケット担当者:チケット内で詳細設計からテストまで実行 • 一部の担当者はセルフレビューも実行 ◦ テスト+リリース ▪ エピック担当者:エピック全体のPRを作成し、ミーティングでマネージャーへと説明 ▪ マネージャー:PRをレビューし、適当なブランチへとマージ ▪ エピック担当者:POへのデモを実行 ▪ チームリーダー:リリース • 課題(抜粋) ◦ 開発中にPRがレビューされない ▪ → 仕様の考慮漏れや潜在的なバグにより、手戻りが発生しやすい
プロジェクトの分割 • 課題 ◦ 開発プロセスにおける課題が多く、一度に対応するのが難しかった • 解決策 ◦ ディスカバリーとデリバリーのプロセスごとでの開発生産性に分割して対応 ▪
ディスカバリー:ビジネスサイドとの連携の改善|Daiki Suyama ▪ デリバリー:本プロジェクト • 効果 ◦ 改善対象をデリバリーの中のレビューに限定して取り組めるように!
レビューの見直し
レビューのタイミングの変更 • 課題 ◦ 手戻りが高頻度に起きていた ▪ 原因:仕様の考慮漏れ、潜在的なバグ、など ◦ レビュワーの負担が大きかった ▪
原因:ほとんどのPRが1000行超え • 解決策 ◦ エピック単位からチケット単位にPRの単位を変更 • 効果 ◦ 手戻りを早めに指摘可能に! ◦ テスト+リリース時のミーティングの工数を削減! ◦ レビュワーの負担は想定よりも減らず…
レビュー単位の最小化 • 課題 ◦ レビュワーの負担が大きかった ▪ 原因:多くのPRが1000行超え • 解決策 ◦
PRの変更行数を500行以下にするよう目標設定 • 効果 ◦ 極端な大きさのPRが減少! ◦ 徐々に変更行数が低下! ▪ 理由:”設計力”の向上が必要であるため
レビュー体制の変更 • 課題 ◦ PRのリードタイム(PRのオープンからマージまでの時間)が長かった ▪ 原因:マネージャーにレビューが依存 • 解決策 ◦
マネージャーのみのレビューからチーム全員でのピアレビューに変更 ▪ 狙い:マネージャーのレビューへの心理的負担の軽減 ▪ 狙い:PRのオープンからファーストレビューまでの時間の短縮 • 効果 ◦ PRのリードタイムは改善せず…
レビューへの意識改善 • 課題 ◦ PRのリードタイムが長かった ▪ 原因:チーム内のレビューへの意識の低さ • 解決策 ◦
レビューの優先順位を最優先と定義 & デイリーMTGで未レビューのPRを確認 ▪ 理由:レビューは他者の開発のボトルネックになるため ▪ 備考:MTGやフロー状態や障害対応の際などを除く • 効果 ◦ 徐々にPRのリードタイムは短縮! ▪ 理由:”意識”の改善のため
結果と考察
計測値の変動(2022/08,09 → 2023/02,03) • 開発生産性 ◦ 開発生産性 ▪ マージ済みPR数:55件 →
56件(+2%) ◦ ”開発”プロセスの工数 ▪ コーディング延べ日数:76日 → 49日(-36%) • レビュー ◦ レビューにおけるボトルネックの程度 ▪ PRのリードタイム:14.7h → 12.5h(-15%) ◦ レビューの容易さの程度 ▪ PRの平均変更行数:511.9行 → 302.4行(-41%)
計測値の補足 • 開発生産性 ◦ ”開発”プロセスの工数 ▪ 外部要因により、3名のうち2名のリソースが半分程度まで減少 ▪ → 対象チームの”開発”プロセスの工数が2/3程度に…
• レビュー ◦ 施策の過程でレビュー体制を大幅に変更したため、改善の程度は正確でない ◦ 改善後のレビュー体制で各計測値が一時的に悪化(2022/12, 2023/01) ▪ レビューにおけるボトルネックの程度:96.2h ▪ レビューの容易さの程度:595.2行
考察 • 計測値 ◦ 開発生産性 ▪ 開発生産性が1.5倍程度に上昇!(定量) ◦ レビュー ▪
各計測値が大きく改善!(定量) ▪ 開発者体験が大きく改善!(定性) • 開発生産性 ◦ ”開発生産性”は曖昧な言葉で、一人歩きしやすい ◦ 最終目標は実現付加価値の生産性の向上であり、局所最適に陥らないように注意が必要 ◦ このプロジェクトの”開発生産性”は、”仕事量の生産性” 参考:開発生産性について議論する前に知っておきたいこと - Qiita