PHPカンファレンス名古屋2025 タスク分解の試行錯誤〜レビュー負荷を下げるために〜

Transcript

1. タスク分解の試行錯誤 〜レビュー負荷を下げるために〜 PHPカンファレンス名古屋 2025（2025/02/22）
2. 2 アジェンダ はじめに レビュー負荷を下げるとは？ 01 02 タスク分解の取り組みをご紹介 まとめ 03 04
3. はじめに 3
4. 5 背景 • Four Keys（※1） を測定し、開発の高速化を目指す ◦ 現状を把握して改善のアクションを起こせるようにする ◦ 2022年12月から運用開始 • スモールスタート ◦ 「変更のリードタイム（※2）」に着目 ◦ 中でもレビューを迅速に行うことを目指してきた ▪ 取り組みやすく、効果があることが分かっているため ▪ 「レビューを迅速に行う」＝「レビュー負荷を下げる」 ※1 ソフトウェア開発チームのパフォーマンスを測る4つの指標 ※2 commit から本番環境稼働までの所要時間 「エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ」より
5. レビュー負荷を 下げるとは？ 6
6. 開発スピードと品質の両立がしやすくなり チーム全体の士気と生産性を高めることができる！ 7 なぜレビュー負荷を下げるのか？ 1. チームの生産性向上 ◦ レビュー時間短縮により付加価値の高い作業へ集中 2. 品質向上につながる迅速なフィードバックループ ◦ 見落としが少なくなりレビュー精度が向上 3. コミュニケーションの活性化 ◦ 「早く終わらせたい」「まとまった時間がないとつらい」だと消極的になりやすい 4. モチベーションの維持 ◦ レビューがつらいとチーム全体のモチベーションが低下 レビュー負荷を 下げると
7. 分解方法をいろいろ試行錯誤してみよう！！ よく聞く方法から独自の方法まで！ 8 どうすればレビュー負荷が下がるのか？ • 1つの方法としてタスクの粒度を小さくするのが有効 どのように 小さくする...？
8. タスク分解の 取り組みをご紹介 9
9. 10 試行錯誤したタスクの分け方 1. 機能単位 ◦ 1タスク＝1機能として実装・レビュー 2. 処理単位 ◦ 1機能を処理ごとにタスク分解して実装・レビュー 3. レイヤー単位 ◦ ドメイン層・アプリケーション層・インフラ層などでタスク分解して実装・レビュー ◦ 今回は処理単位にタスク分解したものを更にレイヤー単位に分解した 4. 補完単位
10. 11 補完単位とは？ • 最初にミニマム実装で1タスク ◦ 本番用の正常系のみ ◦ プリミティブしか使わない • その後、不足部分を補完していくかのごとくタスク分解 ◦ 例えば ▪ オブジェクトへの置き換え → 1タスク ▪ 本番環境・開発環境での処理の分岐 → 1タスク ▪ 異常系の実装 → 1タスク
11. 12 タスク概要〜機能単位で分ける〜 タスクはすべて非同期処理基盤の構築プロジェクト • 4機能を実装・レビュー 機能概要 言語 実装難易度 設計 実装時期 非同期イベント登録 Go 中 なし 初期 非同期イベント検索（サーバー） Go 高 なし 初期 イベントのステータス更新② Go 低 なし 中期 ファイルアップロード Go 中 あり 後期
12. 13 タスク概要〜処理単位で分ける〜 • 3機能を実装・レビュー（※ 部分的にレイヤー単位に分割 → 集計外） • 計測対象：13タスク 機能概要 タスク数 言語 実装難易度 設計 実装時期 非同期イベント発行（サーバー） 5 Go 中 あり 初期 イベントのステータス更新① 3 Go 中 なし 中期 非同期イベント リトライ※ 5 Go 高 あり 後期
13. 14 タスク概要〜レイヤー単位で分ける〜 • 1機能の一部を実装・レビュー（他は処理単位） • 計測対象：7タスク 機能概要 言語 実装難易度 設計 実装時期 非同期イベントリトライ Go 高 あり 後期
14. 15 タスク概要〜補完単位で分ける〜 • 3機能を実装・レビュー • 計測対象：14タスク 機能概要 タスク数 言語 実装難易度 設計 実装時期 非同期イベント発行（クライアント） 5 PHP 中 あり 中期 非同期イベント検索（クライアント） 5 PHP 中 あり 後期 ファイルアップロード 4 PHP 中 あり 後期
15. 16 今回の計測対象メトリクス 1. 変更行数 ◦ 少ないほどレビュー負荷は低いはず 2. オープンからマージまでの時間 ◦ 短いほどレビュー負荷は低いはず 3. Conversation ◦ 少ないほどレビュー負荷は低いはず ※ 箱ひげ図でデータのばらつきを見える化
16. 17 箱ひげ図とは？ 外れ値 最大値・最小値 中央値 第3四分位 第1四分位
17. 18 計測における前提 • レビューは実装者以外のメンバー全員で実施 • CI で静的解析を実施 • 各々レビュー負荷を下げるために事前に PR にコメントを付与 ◦ Conversation に含まれている • 設計がないタスクはレビューで設計の議論が生じたものがある ◦ Conversation が膨らんでいる • PHP には慣れ親しんでいるが Go には不慣れ... ◦ 実装時期が後ろに行くほど慣れてきている
18. 19 計測結果〜変更行数〜
19. 20 計測結果から得られたこと〜変更行数〜 • 処理単位 ◦ 行数のブレ幅は大きいが、ものによっては「レイヤー単位」や「補完単位」と同程度 ◦ 外れ値が発生しているので、大きく上振れる可能性がある • 「レイヤー単位」と「補完単位」は同程度 ◦ 「補完単位」の方が少しだけ大きな変更行数になった ◦ 「補完単位」の方が少ない変更行数になる割合が高い
20. 21 計測結果〜オープンからマージまでの時間〜
21. 22 計測結果から得られたこと〜オープンからマージまでの時間〜 • 処理単位 ◦ 上にも下にも外れ値が発生していて、ブレ幅が大きい ◦ 最小値は「機能単位」の最小値とあまり変わらなかった • 「レイヤー単位」と「補完単位」は同程度 ◦ 「レイヤー単位」の方がブレ幅が少ない ◦ 「補完単位」の方が早くレビューが終わることがあった
22. 23 計測結果〜Conversation〜
23. 24 計測結果から得られたこと〜Conversation〜 • 処理単位 ◦ 上に外れ値が発生していて、議論が多いレビューが発生したことが見受けられる ◦ 最小値は「機能単位」の最小値とあまり変わらなかった • 「レイヤー単位」と「補完単位」は同程度 ◦ 「レイヤー単位」の方がブレ幅が少ない
24. まとめ 25
25. 26 ご紹介したこと • レビュー負荷を下げたいモチベーション • レビュー負荷を下げるためにタスク分解の方法 a. 機能単位 b. 処理単位 c. レイヤー単位 d. 補完単位 • タスク分解の方法ごとのレビュー負荷の計測結果 ◦ 変更行数・オープンからマージまでの時間・Conversation
26. 27 試行錯誤の結果 • 分解しないとレビュー負荷はやはり高い！（機能単位） • 「処理単位」はさらなる分解が不要なケースもある ◦ が、多くは分解したほうがレビュー負荷は低くなりそう • 「レイヤー単位」と「補完単位」は同程度 ◦ 変更行数は最大500行強程度までおさえられた ◦ タスクの特徴に応じて使い分けられそう
27. ご清聴 ありがとうございました 〜エンジニア募集中〜