こんにちは！
ホワイトプラスのコアシステム開発Gエンジニアのさとうです。
先日、PHPカンファレンス名古屋2025にて「タスク分解の試行錯誤〜レビュー負荷を下げるために〜」という内容で登壇しました。
この記事では、発表した「タスク分解の試行錯誤〜レビュー負荷を下げるために〜」の内容と、Ask the Speaker やコメントでいただいた質問への回答をご紹介できればと思います。
- 現地で聞いたけど改めて内容を確認したい！
- 現地に行けなかったから内容を知りたい！
- 質疑応答が気になる！
という方のお役に立てれば幸いです。
「タスク分解の試行錯誤〜レビュー負荷を下げるために〜」の発表内容
はじめに
弊社は、ソフトウェア開発チームのパフォーマンスを測る4つの指標である Four Keys を測定し、開発の高速化を目指しています。
現状を把握して改善のアクションを起こせるようにできればと考えており、2022年12月から運用を開始しています。
まずはスモールスタートということで、コミットから本番稼働までの所要時間を指す「変更のリードタイム」に着目し、中でもレビューを迅速に行うことを目指してきました。
これは、レビュー速度向上が取り組みやすく、効果があることが分かっているためです。
レビューを迅速に行うためには、レビューの負荷を下げる必要があります。
レビュー負荷を下げるとは？
では、レビュー負荷を下げるとはどういうことでしょうか？
開発速度向上以外にもメリットがあるので、まずはなぜレビュー負荷を下げるのかメリットをいくつか挙げて、レビュー負荷を下げることで効果を見てみたいと思います。
１つは、チームの生産性向上です。
レビュー時間が短縮することにより、付加価値の高い作業へ集中できるようになります。
２つ目は、品質向上につながる迅速なフィードバックループを構築できるようになるということが挙げられます。
レビュー負荷が下がることで見落としが少なくなり、レビュー精度の向上が期待できます。
３つ目は、コミュニケーションの活性化です。
レビュー負荷が高いと、「早く終わらせたい」「まとまった時間がないとつらい」という状況になりがちで、コミュニケーションが消極的になりやすくなります。
最後に、モチベーションの維持が挙げられます。
レビューがつらいとチーム全体のモチベーションが低下するおそれがあります。
挙げたメリットをまとめると、レビュー負荷を下げることにより、開発スピードと品質の両立がしやすくなり、チーム全体の士気と生産性を高めることができるようになりそうです。
では、どうすればレビュー負荷が下がるのか、というアクションについて考えてみたいと思います。
ネットや文献を調べてよくでてくるのが「タスクの粒度を小さくする」ということです。
ただ、小さくすると言われても小さくする方法はいくつか考えられて、どこまで小さくすべきなのかも悩みどころです。
そこで、今回タスクの分解方法を色々試行錯誤してみました。
よく聞く方法から、新たにこんな方法はどうだろうという方法まで試してみたので、その方法をご紹介して、定量的に効果を分析していきたいと思います。
タスク分解の取り組みをご紹介
試行したタスクの分け方は4通りです。
1つ目は、1タスク1機能として実装・レビューする「機能単位」です。
2つ目は、1機能を処理毎にタスク分解して実装・レビューする「処理単位」です。
3つ目は、弊社はクリーンアーキテクチャをベースにしたアーキテクチャを採用しているので、 ドメイン層・アプリケーション層・インフラ層などでタスク分解して実装・レビューする「レイヤー単位」です。
今回は処理単位にタスク分解したものを更にレイヤー単位に分解しています。
最後が新たに考えて分解してみたもので、「補完単位」と呼んでいます。
この「補完単位」がどういったものかというと、最初にミニマム実装で1タスクとします。
ミニマム実装がどういうものかというと、本番用の正常系のみの処理に絞り、あえてすべてプリミティブで実装したものになります。
そこから、不足部分を補完していくかのごとくタスク分解を行っていきました。
例えば、プリミティブをオブジェクトに置き換えるので1タスク、本番環境・開発環境で処理を分岐するので1タスク、異常系の実装で1タスクといった形です。
それぞれのタスク分解方法でどのような機能を開発したかご紹介します。 タスクはすべて非同期処理基盤を構築するプロジェクトのタスクで、必要な API であったり、クライアント側の機能の作成のタスクになっています。
まずは機能単位です。 4機能を実装レビューしました。 イベントのステータス更新が②となってますが、次に出てくる処理単位で①を実装しており、その類似機能として実装されたものが②になっています。 なので、実装難易度は低めとなっていて、敢えて機能単位で実装となっています。 初期にやったものが多く、レビュー負荷が高いと感じる機会が多かったため分解する流れとなりました。
続いて、処理単位に分けた3機能です。
13タスクに分解しています。
機能単位で負荷を大きく感じたので、処理単位に分解してみました。
分解してみたものの、実装難易度が高いことも相まって、まだ負荷が大きく感じられたので、イベントのリトライのタスクの途中からさらに分解を試みました。
さらなる分解がレイヤー単位になります。
イベントリトライの2つの処理に対して、更にレイヤー単位で実装するよう分割しました。
分解の結果7タスクになりました。
最後に補完単位です。
こちらは PHP で実装しているクライアント側の機能が主です。
3機能を合計14タスクに分解しています。
実装時期も後ろの方で、非同期基盤に対する知見も一定溜まってきた時期でした。
これらのタスク分解方法で「変更行数」「オープンからマージまでの時間」「Conversation」 つまりコメントの数の3つのメトリクスを計測してレビュー負荷を定量評価しました。
いずれもデータのばらつきを見るため、箱ひげ図で見える化しています。
箱ひげ図とは、データの統計的ばらつきを分かりやすく表現するための統計図です。
◯でプロットされている点は外れ値で、箱とヒゲは外れ値以外のデータ群を表しています。
一番下の線が最小値で、順に積み上げていって四分の一に達したところが箱の底で第1四分位、 更に積み上げて半分に達した線が中央値、箱の蓋の部分が積み上げて四分の三に達したところで第3四分位、 一番上の線が最大値を表しています。
評価結果を見る前に、計測の前提です。
レビューは実装者以外のメンバー全員で実施しています。
CI で静的解析を実施しているので、そのルールが敷かれている基本的な部分はレビューに含まれません。
各々レビュー負荷を下げるために事前に PR に補足コメントを付与しており、それは Conversation に含まれています。
前のタスク紹介で設計の有無を記載しましたが、設計がないタスクはレビューで設計の議論が生じたものがあります。
それらは Conversation が膨らんでいます。
PHP には慣れ親しんでいますが Go には不慣れです。
ただし、Go も実装時期が後ろに行くほど慣れてきてはいます。
前提の確認も終わったので変更行数から見ていきたいと思います。
機能単位は1つのPRで変更行数が圧倒的に多いことがわかります。
処理単位は行数のブレ幅は大きいですが、最小値を見ると「レイヤー単位」や「補完単位」と同程度のものもあったようです。
外れ値が発生しているので、大きく上振れたことがありました。
「レイヤー単位」と「補完単位」は同程度でした。
誤差の範囲かもですが、「補完単位」の方が少しだけ大きな変更行数になりました。
ただ、「補完単位」の方が第1四分位が低く、少ない変更行数になる割合が高いように見えます。
続いて、オープンからマージまでの時間を見ていきます。
処理単位では上にも下にも外れ値が発生していて、ブレ幅が大きいことがわかります。
ただし、外れ値を除くと最小値は機能単位の最小値とあまり変わっていないですね。
「レイヤー単位」と「補完単位」はこちらも同程度でした。
「レイヤー単位」の方がヒゲの幅が短いのでブレ幅が少ないようです。
「補完単位」の方が最小値が小さく早くレビューが終わることがあったようです。
最後に Conversation です。
処理単位では上に外れ値が2件発生していて、突出して議論が多いレビューが発生したことが見受けられます。
オープンからマージまでの時間同様、処理単位の最小値は機能単位の最小値とあまり変わっていないです。
「レイヤー単位」と「補完単位」は最後も同程度ですね。
「レイヤー単位」の方がヒゲが凝縮していてブレ幅が少ない事がわかります。
まとめ
今回ご紹介したことは、レビュー負荷を下げたいモチベーション、レビュー負荷を下げるためのタスク分解の4つの方法、タスク分解方法ごとのレビュー負荷の計測結果です。
機能単位・処理単位・レイヤー単位・補完単位ごとに、変更行数、オープンからマージまでの時間、Conversation を計測しました。
結果、機能単位のように分解しないとレビュー負荷は高いことが再認識できました。
機能単位から処理単位に分解したら、一定の効果が出ることが見て取れました。
ただ、まだまだ分解の余地があることがわかりました。
さらに細かい「レイヤー単位」や「補完単位」はいずれのメトリクスも同程度でした。
これらは変更行数を最大500行強程度までにおさえられました。
今後は複雑な処理の場合は処理ごとに分けたうえでレイヤー単位、先に全体的な動きを確認したい場合は補完単位、などといった使い分けもできそうです。
レビュー負荷は下がってきた実感はあるものの、レビューを十分迅速に行えているか、と言われるとまだまだ改善の余地があるので、 引き続きさまざまな試行錯誤に取り組んでいきたいです。
みなさんのレビューにも、今回の取り組みでどこかお役に立てる所があれば幸いです。
いただいた質問への回答
Q. どうやってメトリクスを設定したか？
レビュー負荷を下げるという目的から逆算して設定しました。
日常的に収集しているメトリクスの中から、レビューする中で負担を感じる部分をピックアップした結果が今回のメトリクスの「変更行数」「オープンからマージまでの時間」「Conversation」です。
Q. 今後もこのメトリクスを追い続ける？
目的に応じて変化させていく予定です。
まだうまく分解できないケースや試せていないこともあるので、しばらく試行錯誤は続けていきたいと考えています。
ただ、一定レビュー速度が向上してきている実感はあるので、実装速度の向上にも努めたいです。
いざ実装速度の向上に取り掛かるとなったら、また別のメトリクスを設定して取り組みを評価していきたいです。
Q. タスク分解することによって大変になる部分は？
タスク分解することによって、タスクが大きく増えたり、タスクの依存関係が複雑になったりと、タスクの管理が大変になった印象です。 タスク管理の大変さとレビュー負荷が高い状態を比較すると、タスク管理の大変さの方がまだまだ許容できるものと感じています。
Q. 適切な変更行数の目安はある？
2010年の調査1では400行を超えると欠陥を見つける能力が低下するという結果が出ています。
欠陥を見つける能力とレビュー負荷はイコールではありませんが、400行は目安の一つとなりえると考えています。
Q. 分割したものを機能ごとにまとめてメトリクスを見てみたらどうなる？
分解したものを機能ごとにまとめて見える化したところ、面白い傾向が見られました！
ややボリューミーなので、別のブログ記事にてご紹介できたらと思います。
まとめ：タスク分解はレビュー負荷減少に効果あり
この記事では、発表した「タスク分解の試行錯誤〜レビュー負荷を下げるために〜」の内容と、Ask the Speaker やコメントでいただいた質問への回答をご紹介しました。
今回の定量評価からタスク分解がレビュー負荷減少に一定の効果があることが見て取れました。
どこかにみなさんお役に立てる情報があれば幸いです。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！
ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。
どんな会社か気になった方はオウンドメディア「ホワプラSTYLE」をぜひご覧ください。
オンラインでカジュアル面談もできますので、ぜひお気軽にお問い合わせください。
