Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

2 アジェンダ はじめに レビュー負荷を下げるとは? 01 02 タスク分解の取り組みをご紹介 まとめ 03 04

Slide 3

Slide 3 text

はじめに 3

Slide 4

Slide 4 text

5 背景 ● Four Keys(※1) を測定し、開発の高速化を目指す ○ 現状を把握して改善のアクションを起こせるようにする ○ 2022年12月から運用開始 ● スモールスタート ○ 「変更のリードタイム(※2)」に着目 ○ 中でもレビューを迅速に行うことを目指してきた ■ 取り組みやすく、効果があることが分かっているため ■ 「レビューを迅速に行う」=「レビュー負荷を下げる」 ※1 ソフトウェア開発チームのパフォーマンスを測る4つの指標 ※2 commit から本番環境稼働までの所要時間 「エリート DevOps チームであることを Four Keys プロジェクトで確認する | Google Cloud 公式ブログ」より

Slide 5

Slide 5 text

レビュー負荷を 下げるとは? 6

Slide 6

Slide 6 text

開発スピードと品質の両立がしやすくなり チーム全体の士気と生産性を高めることができる! 7 なぜレビュー負荷を下げるのか? 1. チームの生産性向上 ○ レビュー時間短縮により付加価値の高い作業へ集中 2. 品質向上につながる迅速なフィードバックループ ○ 見落としが少なくなりレビュー精度が向上 3. コミュニケーションの活性化 ○ 「早く終わらせたい」「まとまった時間がないとつらい」だと消極的になりやすい 4. モチベーションの維持 ○ レビューがつらいとチーム全体のモチベーションが低下 レビュー負荷を 下げると

Slide 7

Slide 7 text

分解方法をいろいろ試行錯誤してみよう!! よく聞く方法から独自の方法まで! 8 どうすればレビュー負荷が下がるのか? ● 1つの方法としてタスクの粒度を小さくするのが有効 どのように 小さくする...?

Slide 8

Slide 8 text

タスク分解の 取り組みをご紹介 9

Slide 9

Slide 9 text

10 試行錯誤したタスクの分け方 1. 機能単位 ○ 1タスク=1機能として実装・レビュー 2. 処理単位 ○ 1機能を処理ごとにタスク分解して実装・レビュー 3. レイヤー単位 ○ ドメイン層・アプリケーション層・インフラ層などでタスク分解して実装・レビュー ○ 今回は処理単位にタスク分解したものを更にレイヤー単位に分解した 4. 補完単位

Slide 10

Slide 10 text

11 補完単位とは? ● 最初にミニマム実装で1タスク ○ 本番用の正常系のみ ○ プリミティブしか使わない ● その後、不足部分を補完していくかのごとくタスク分解 ○ 例えば ■ オブジェクトへの置き換え → 1タスク ■ 本番環境・開発環境での処理の分岐 → 1タスク ■ 異常系の実装 → 1タスク

Slide 11

Slide 11 text

12 タスク概要〜機能単位で分ける〜 タスクはすべて非同期処理基盤の構築プロジェクト ● 4機能を実装・レビュー 機能概要 言語 実装難易度 設計 実装時期 非同期イベント登録 Go 中 なし 初期 非同期イベント検索(サーバー) Go 高 なし 初期 イベントのステータス更新② Go 低 なし 中期 ファイルアップロード Go 中 あり 後期

Slide 12

Slide 12 text

13 タスク概要〜処理単位で分ける〜 ● 3機能を実装・レビュー(※ 部分的にレイヤー単位に分割 → 集計外) ● 計測対象:13タスク 機能概要 タスク数 言語 実装難易度 設計 実装時期 非同期イベント発行(サーバー) 5 Go 中 あり 初期 イベントのステータス更新① 3 Go 中 なし 中期 非同期イベント リトライ※ 5 Go 高 あり 後期

Slide 13

Slide 13 text

14 タスク概要〜レイヤー単位で分ける〜 ● 1機能の一部を実装・レビュー(他は処理単位) ● 計測対象:7タスク 機能概要 言語 実装難易度 設計 実装時期 非同期イベントリトライ Go 高 あり 後期

Slide 14

Slide 14 text

15 タスク概要〜補完単位で分ける〜 ● 3機能を実装・レビュー ● 計測対象:14タスク 機能概要 タスク数 言語 実装難易度 設計 実装時期 非同期イベント発行(クライアント) 5 PHP 中 あり 中期 非同期イベント検索(クライアント) 5 PHP 中 あり 後期 ファイルアップロード 4 PHP 中 あり 後期

Slide 15

Slide 15 text

16 今回の計測対象メトリクス 1. 変更行数 ○ 少ないほどレビュー負荷は低いはず 2. オープンからマージまでの時間 ○ 短いほどレビュー負荷は低いはず 3. Conversation ○ 少ないほどレビュー負荷は低いはず ※ 箱ひげ図でデータのばらつきを見える化

Slide 16

Slide 16 text

17 箱ひげ図とは? 外れ値 最大値・最小値 中央値 第3四分位 第1四分位

Slide 17

Slide 17 text

18 計測における前提 ● レビューは実装者以外のメンバー全員で実施 ● CI で静的解析を実施 ● 各々レビュー負荷を下げるために事前に PR にコメントを付与 ○ Conversation に含まれている ● 設計がないタスクはレビューで設計の議論が生じたものがある ○ Conversation が膨らんでいる ● PHP には慣れ親しんでいるが Go には不慣れ... ○ 実装時期が後ろに行くほど慣れてきている

Slide 18

Slide 18 text

19 計測結果〜変更行数〜

Slide 19

Slide 19 text

20 計測結果から得られたこと〜変更行数〜 ● 処理単位 ○ 行数のブレ幅は大きいが、ものによっては「レイヤー単位」や「補完単位」と同程度 ○ 外れ値が発生しているので、大きく上振れる可能性がある ● 「レイヤー単位」と「補完単位」は同程度 ○ 「補完単位」の方が少しだけ大きな変更行数になった ○ 「補完単位」の方が少ない変更行数になる割合が高い

Slide 20

Slide 20 text

21 計測結果〜オープンからマージまでの時間〜

Slide 21

Slide 21 text

22 計測結果から得られたこと〜オープンからマージまでの時間〜 ● 処理単位 ○ 上にも下にも外れ値が発生していて、ブレ幅が大きい ○ 最小値は「機能単位」の最小値とあまり変わらなかった ● 「レイヤー単位」と「補完単位」は同程度 ○ 「レイヤー単位」の方がブレ幅が少ない ○ 「補完単位」の方が早くレビューが終わることがあった

Slide 22

Slide 22 text

23 計測結果〜Conversation〜

Slide 23

Slide 23 text

24 計測結果から得られたこと〜Conversation〜 ● 処理単位 ○ 上に外れ値が発生していて、議論が多いレビューが発生したことが見受けられる ○ 最小値は「機能単位」の最小値とあまり変わらなかった ● 「レイヤー単位」と「補完単位」は同程度 ○ 「レイヤー単位」の方がブレ幅が少ない

Slide 24

Slide 24 text

まとめ 25

Slide 25

Slide 25 text

26 ご紹介したこと ● レビュー負荷を下げたいモチベーション ● レビュー負荷を下げるためにタスク分解の方法 a. 機能単位 b. 処理単位 c. レイヤー単位 d. 補完単位 ● タスク分解の方法ごとのレビュー負荷の計測結果 ○ 変更行数・オープンからマージまでの時間・Conversation

Slide 26

Slide 26 text

27 試行錯誤の結果 ● 分解しないとレビュー負荷はやはり高い!(機能単位) ● 「処理単位」はさらなる分解が不要なケースもある ○ が、多くは分解したほうがレビュー負荷は低くなりそう ● 「レイヤー単位」と「補完単位」は同程度 ○ 変更行数は最大500行強程度までおさえられた ○ タスクの特徴に応じて使い分けられそう

Slide 27

Slide 27 text

ご清聴 ありがとうございました 〜エンジニア募集中〜