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
A2A プロトコルを試してみる
azukiazusa1
2
1.4k
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
260
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
320
Porting a visionOS App to Android XR
akkeylab
0
470
Hack Claude Code with Claude Code
choplin
4
2.1k
新メンバーも今日から大活躍!SREが支えるスケールし続ける組織のオンボーディング
honmarkhunt
5
7.4k
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
110
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
170
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
590
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
Agentic Coding: The Future of Software Development with Agents
mitsuhiko
0
100
Railsアプリケーションと パフォーマンスチューニング ー 秒間5万リクエストの モバイルオーダーシステムを支える事例 ー Rubyセミナー 大阪
falcon8823
5
1.1k
Featured
See All Featured
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
970
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Music & Morning Musume
bryan
46
6.6k
Statistics for Hackers
jakevdp
799
220k
Producing Creativity
orderedlist
PRO
346
40k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.1k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
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