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
0
660
事業とプロダクト間のインターフェース作り
daikisuyama
0
890
Other Decks in Programming
See All in Programming
エラーって何種類あるの?
kajitack
5
310
童醫院敏捷轉型的實踐經驗
cclai999
0
200
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
580
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.6k
C++20 射影変換
faithandbrave
0
540
Go1.25からのGOMAXPROCS
kuro_kurorrr
1
810
Modern Angular with Signals and Signal Store:New Rules for Your Architecture @enterJS Advanced Angular Day 2025
manfredsteyer
PRO
0
130
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
47
31k
git worktree × Claude Code × MCP ~生成AI時代の並列開発フロー~
hisuzuya
1
500
Bytecode Manipulation 으로 생산성 높이기
bigstark
2
380
なんとなくわかった気になるブロックテーマ入門/contents.nagoya 2025 6.28
chiilog
1
230
Is Xcode slowly dying out in 2025?
uetyo
1
210
Featured
See All Featured
Thoughts on Productivity
jonyablonski
69
4.7k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Making Projects Easy
brettharned
116
6.3k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Java REST API Framework Comparison - PWX 2021
mraible
31
8.6k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
How to train your dragon (web standard)
notwaldorf
94
6.1k
KATA
mclloyd
29
14k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
The Language of Interfaces
destraynor
158
25k
Intergalactic Javascript Robots from Outer Space
tanoku
271
27k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
16k
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