レビューの見直しによる開発生産性の向上

2022/10 ~ 2023/03に取り組んだプロジェクトの紹介です。

Transcript

1. レビューの見直しによる 開発生産性の向上 株式会社クライド 陶山大輝
2. 目次 • 概要 • プロジェクトの準備 • レビューの見直し • 結果と考察
3. 概要
4. プロジェクトの概要 • 時期 ◦ 2022/10 ~ 2023/03 • 対象チーム ◦ 自社プロダクトの開発チーム ▪ マネージャー 1人、チームリーダー 1人、メンバー 1人 • チーム状況 ◦ 数ヶ月単位でのリリースの遅延や手戻りの頻発などの課題が山積 ◦ PMF前のプロダクトのため、プロジェクトに多くの時間は費やせない • 目的 ◦ 開発生産性を向上させること
5. プロジェクトの準備
6. 開発プロセスの言語化 • 課題 ◦ 開発プロセスが明確でなく、調整に費やす時間が多かった • 解決策 ◦ 開発プロセスと関連する課題を言語化（後述） ▪ ディスカバリーとデリバリー • 効果 ◦ 課題が明確に！
7. 開発プロセス ~ディスカバリー~ • 手順 ◦ 機能検討 ▪ PO：ステークホルダーからの要望から機能を検討 ▪ PO：優先順位を確定 ◦ 仕様策定 ▪ PO：開発が確定した機能の仕様を策定 ▪ PO：機能単位（エピック）でエンジニアへと依頼 • 課題（抜粋） ◦ エンジニアの観点が不足したまま仕様が決定 ▪ → 仕様の考慮漏れなどにより、手戻りが発生しやすい
8. 開発プロセス ~デリバリー~ • 手順 ◦ 設計 ▪ 開発チーム：エピック（機能単位）の担当者を決定 ▪ エピック担当者：仕様をPOに確認しながら設計 ▪ エピック担当者：チケット（開発単位）へと分割 ◦ 開発 ▪ チケット担当者：チケット内で詳細設計からテストまで実行 • 一部の担当者はセルフレビューも実行 ◦ テスト+リリース ▪ エピック担当者：エピック全体のPRを作成し、ミーティングでマネージャーへと説明 ▪ マネージャー：PRをレビューし、適当なブランチへとマージ ▪ エピック担当者：POへのデモを実行 ▪ チームリーダー：リリース • 課題（抜粋） ◦ 開発中にPRがレビューされない ▪ → 仕様の考慮漏れや潜在的なバグにより、手戻りが発生しやすい
9. プロジェクトの分割 • 課題 ◦ 開発プロセスにおける課題が多く、一度に対応するのが難しかった • 解決策 ◦ ディスカバリーとデリバリーのプロセスごとでの開発生産性に分割して対応 ▪ ディスカバリー：ビジネスサイドとの連携の改善｜Daiki Suyama ▪ デリバリー：本プロジェクト • 効果 ◦ 改善対象をデリバリーの中のレビューに限定して取り組めるように！
10. レビューの見直し
11. レビューのタイミングの変更 • 課題 ◦ 手戻りが高頻度に起きていた ▪ 原因：仕様の考慮漏れ、潜在的なバグ、など ◦ レビュワーの負担が大きかった ▪ 原因：ほとんどのPRが1000行超え • 解決策 ◦ エピック単位からチケット単位にPRの単位を変更 • 効果 ◦ 手戻りを早めに指摘可能に！ ◦ テスト+リリース時のミーティングの工数を削減！ ◦ レビュワーの負担は想定よりも減らず…
12. レビュー単位の最小化 • 課題 ◦ レビュワーの負担が大きかった ▪ 原因：多くのPRが1000行超え • 解決策 ◦ PRの変更行数を500行以下にするよう目標設定 • 効果 ◦ 極端な大きさのPRが減少！ ◦ 徐々に変更行数が低下！ ▪ 理由：”設計力”の向上が必要であるため
13. レビュー体制の変更 • 課題 ◦ PRのリードタイム（PRのオープンからマージまでの時間）が長かった ▪ 原因：マネージャーにレビューが依存 • 解決策 ◦ マネージャーのみのレビューからチーム全員でのピアレビューに変更 ▪ 狙い：マネージャーのレビューへの心理的負担の軽減 ▪ 狙い：PRのオープンからファーストレビューまでの時間の短縮 • 効果 ◦ PRのリードタイムは改善せず…
14. レビューへの意識改善 • 課題 ◦ PRのリードタイムが長かった ▪ 原因：チーム内のレビューへの意識の低さ • 解決策 ◦ レビューの優先順位を最優先と定義 & デイリーMTGで未レビューのPRを確認 ▪ 理由：レビューは他者の開発のボトルネックになるため ▪ 備考：MTGやフロー状態や障害対応の際などを除く • 効果 ◦ 徐々にPRのリードタイムは短縮！ ▪ 理由：”意識”の改善のため
15. 結果と考察
16. 計測値の変動（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%）
17. 計測値の補足 • 開発生産性 ◦ ”開発”プロセスの工数 ▪ 外部要因により、3名のうち2名のリソースが半分程度まで減少 ▪ → 対象チームの”開発”プロセスの工数が2/3程度に… • レビュー ◦ 施策の過程でレビュー体制を大幅に変更したため、改善の程度は正確でない ◦ 改善後のレビュー体制で各計測値が一時的に悪化（2022/12, 2023/01） ▪ レビューにおけるボトルネックの程度：96.2h ▪ レビューの容易さの程度：595.2行
18. 考察 • 計測値 ◦ 開発生産性 ▪ 開発生産性が1.5倍程度に上昇！（定量） ◦ レビュー ▪ 各計測値が大きく改善！（定量） ▪ 開発者体験が大きく改善！（定性） • 開発生産性 ◦ ”開発生産性”は曖昧な言葉で、一人歩きしやすい ◦ 最終目標は実現付加価値の生産性の向上であり、局所最適に陥らないように注意が必要 ◦ このプロジェクトの”開発生産性”は、”仕事量の生産性” 参考：開発生産性について議論する前に知っておきたいこと - Qiita