こんにちは！
ホワイトプラスのコアシステム開発Gエンジニアのさとうです。
以前、PHPカンファレンス名古屋2025にて「タスク分解の試行錯誤〜レビュー負荷を下げるために〜」という内容で登壇しました。
そのときの Q & A で
分割したものを機能ごとにまとめてメトリクスを見てみたらどうなる？
という質問をいただきました。
そこで、分解したタスクを機能ごとに合算したところ、面白い傾向が見られました。
この記事では、分解したタスクを機能ごとに集計したらどのような傾向が見られたかをご紹介できればと思います。
タスクを分解する・しないの比較に興味がある！という方の参考になれば幸いです。
PHPカンファレンス名古屋2025で登壇したタスク分解の発表内容については、以下をご覧ください。
目次
タスク分解の取り組みのおさらい
レビュー負荷の軽減を目指し、タスク分解に取り組んでいました。
一言でタスク分解と言っても分け方は多岐に渡るため、いくつかの分解方法を試してみました。
試したタスク分解の方法は4通りです。
- 機能単位（分解しない）
- 1タスク1機能として実装・レビュー
- 処理単位
- 1機能を処理毎にタスク分解して実装・レビュー
- レイヤー単位
- ドメイン層・アプリケーション層・インフラ層などでタスク分解して実装・レビュー
- 補完単位
- すべてプリミティブで実装・レビューした後、不足部分を補完していくかのごとく実装・レビュー
以上の4通りの方法でタスクを行い、以下の3つのメトリクスを箱ひげ図1で見える化しました。
- 変更行数
- オープンからマージまでの時間
- Conversation（コメント数）
分解したタスクを機能ごとに合算した結果
分解したタスクを機能ごとに合算した所、計測対象の機能数は分解方法別に以下のようになりました。
レイヤー単位で丸々一機能を実装したものは無かったので、処理単位にまとめています。
| 分解方法 | 実装した機能数 |
|---|---|
| 機能単位（分解しない） | 4機能 |
| 処理単位 | 2機能 |
| 補完単位 | 3機能 |
いずれも少数なので傾向を見るには弱く、箱ひげ図もひげが現れませんが傾向の特徴を捉えられればと思います。
分解したタスクを一つに合算した結果を順に見ていきましょう。
変更行数
処理単位・補完単位はタスク分解を行っているため、タスク間で変更が重複して多くなっている可能性が考えられます。
それを加味すると、機能単位と処理単位は大体同程度と言えそうですが、補完単位は明らかに変更行数が少ないことが見て取れます。
補完単位は比較的簡単な実装だったのかもしれませんが、処理単位と比較すると補完単位の方が手戻りが少なかったとも言えるかもしれません。
補完単位は全体像を初めに実装して示す一方、処理単位は実装のような詳細レベルで全体像を押さえずにタスクを進めるため、後から実装済みの部分に修正が入る可能性があると考えられます。
オープンからマージまでの時間
オープンからマージまでの時間はタスク分解しない機能単位が早い様子が見受けられます。
要因を考察してみると、
- まとめてレビュー・レビュー対応できるためタスクの切り替え頻度が少なく認知負荷が低かったのではないか
- PR が少ないため、他の PR に割いている時間が少なく済んだのではないか
- 大きな PR がまとまったタイミングでは大きく遅れるはずなのでバラツキが大きくなるはず
- バラツキがほかと比べて大きくないので、うまい具合に入れ替わり PR を作成できていたかもしれない
- 大きな PR がまとまったタイミングでは大きく遅れるはずなのでバラツキが大きくなるはず
といったことが考えられます。
一方、時間がかかっている処理単位について考察してみると、
- 変更行数も多いので、難しい機能でレビューに時間がかかったのではないか
- 全体としての処理の位置付けの理解が難しく、認知負荷が高かったのではないか
- レビューの質問に対し「後続タスクで対応する」というコメントが散見された
- 後続の処理の指摘を修正した結果、実装済みの処理の修正も必要になり、時間がかかったのではないか
といった、タスクの性質による要因と分解方法による要因が考えられました。
処理の位置付けに関しては、全体像とタスクのスコープを図示・説明してからレビューに入ったものの、効果は限定的だったのかもしれません。
また、前述した手戻りの影響も考えられます。
Conversation（コメント数）
Conversation は補完単位が安定的に低い傾向が見られました。
簡単な実装だったということも考えられますが、最初に全体の認識合わせを実装レベルで行えるので、その後の認識のズレが発生しにくいことが影響しているのではないでしょうか。
機能単位・処理単位はバラツキがあり、実装難易度によるのかと思います。
変更行数と Conversation の傾向を比較してみる
変更行数と Conversation は似たような傾向があるはず…と思い、グラフを比較したところ面白い傾向が見て取れました。
変更行数の結果が青、Conversation の結果が赤になります。
異なるレンジの結果を比較するため、両者とも0〜1の間で結果を表示できるよう正規化しています。
注目すべき点は機能単位です。
処理単位も補完単位も Conversation の箱（赤）が変更行数の箱（青）に収まっており、同じような傾向であることが見て取れます。
一方の機能単位は Conversation の箱（赤）が変更行数の箱（青）からやや下にズレており、タスク分解を行った場合と比べて Conversation が少ない傾向となったことが分かります。
要因をプラスの面、マイナスの面でそれぞれ考えてみると、
- プラスの面
- 1つの PR にすべての実装が収まっているので、1回のコメントで修正の横展開をしてもらうことができた
- マイナスの面
- 多くの変更を1つの PR にまとめたため、レビューに消極的になった・漏れが発生した
といったことが考えられます。
ここで挙げたプラスの面とマイナスの面を比較すると、圧倒的にマイナス面の方が大きいですね。
まとめ
この記事では、分解したタスクを機能ごとに集計したらどのような傾向が見られたかをご紹介しました。
対象機能が少なく限定的な結果ではあるものの、変更行数、オープンからマージまでの時間、Conversation（コメント数）をそれぞれ見ていきました。
特徴は以下のようにまとめられるかなと思います。
- 機能単位
- オープンからマージまでの時間は早い
- レビュー品質を担保できていない可能性がある
- 処理単位
- オープンからマージまでの時間はタスク分解により長くなる
- 変更行数が多く難しい機能実装だったと思われる
- 手戻りの発生が示唆された
- Conversation が一定数発生しており、レビューはしっかり機能していたと思われる
- 補完単位
- オープンからマージまでの時間はタスク分解により長くなる
- 変更行数が少なく簡単な実装だった可能性がある
- 手戻りが少なかったとも捉えられる
- Conversation が安定しており、スムーズなレビューだったと見受けられる
レビュー負荷のみを考えるとタスク分解をした方が良いという結論に達していましたが、機能の性質上できる限り早くリリースしたい場合は分解しないという選択肢も考えられそうです。
今後より柔軟にタスクを進められる新た軸が見つかりました。
その時々の目的に合ったタスクの進め方を選択していければと思います。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！
ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。
どんな会社か気になった方はオウンドメディア「ホワプラSTYLE」をぜひご覧ください。
オンラインでカジュアル面談もできますので、ぜひお気軽にお問い合わせください。
- 箱ひげ図とは、データの統計的ばらつきを分かりやすく表現するための統計図↩
