はじめに
以下の Advent Calendar に参加し、
レビューの滞留・レビュアーの偏りを改善するために実施したことを書きます。
チーム開発において、Pull Request のレビューが滞留したり、
特定のメンバーにレビューが偏ったりする問題に直面することがありました。
本記事では、それらの課題に対してチームで実際に行った改善施策をまとめます。
大きなルール変更ではなく、運用と仕組みの見直しが中心です。
背景となっていた課題
当時、以下のような問題が発生していました。
- レビューが特定のメンバーに集中していた
- レビュー待ちの PR が可視化されておらず、滞留に気づきにくかった
- レビューのタイミングが人によってまちまちだった
偏り対策として実施したこと
GitHub の自動アサインを Load Balance アルゴリズムに変更
元々レビュアーの自動アサインは実施していましたが、
ラウンドロビンアルゴリズム を設定していました。
この設定では、レビュアーにアサインされたものの実際にはレビューを行わなかった場合でも、
次の Pull Request では次のメンバーにアサインされてしまいます。
これを ロードバランスアルゴリズム に変更しました。
ロードバランスアルゴリズムは、各メンバーの最近のレビューリクエスト合計数に基づいてレビュー担当者を選択し、メンバーごとの未処理レビューの数を考慮します。
各 Team メンバーが 30 日間に等しい数のプルリクエストをレビューすることを保証しようとします。
これにより、
レビューを多く行っている人は自動アサインされにくくなり、
レビュー数の少ない人が優先的にアサインされるため、負荷の分散が期待できます。
ただし、この設定にしておけば理想的なアサインになるわけではありません。
途中から参画したメンバーがアサインされ続けてしまうなど、
予期せぬ挙動が発生することもありました。
アサイン状況は定期的にウォッチしておき、
問題がありそうな場合は「一時的にラウンドロビンに戻す」など、
柔軟な運用が大切だと感じています。
自動アサインと「自主レビュー」の共存
レビューの進め方には個人差があります。
- 自分のタイミングでレビューしたい人
- アサインされている方が動きやすい人
これらを両立させるため、
アサインされていなくてもレビューしてよい というルールを明示しました。
自動アサインはあくまで「最低限の保証」と位置づけ、
自発的なレビューを妨げない運用としています。
また、マージ条件としては 2 Approve を必須としていますが、
自主的なレビューとアサインによるレビューが重なることもあるため、
3 Approve 以上つけることも許容しています。
ただし、常に 3 Approve、4 Approve が付いている状態になる場合、
不要なレビューコストが発生している可能性が高いため、状況は意識して確認するようにしています。
レビュー中にマージされてしまうのを防ぐため、
レビュー開始時に「Changes Requested」のコメントを付ける運用を一時期行っていました。
しかし、手動運用が必要だったため定着せず、最終的には廃れてしまいました。
人手による運用が前提となるルールは、なるべく避けるべきだと感じています。
滞留対策として実施したこと
未レビュー PR を Slack に通知する仕組みを作成
レビューの滞留を防ぐため、
未レビューの Pull Request 一覧を Slack に通知する仕組みを作成しました。
運用は以下の通りです。
- GitHub API を利用して、残っている Pull Request を取得
- 未レビューの PR 一覧を、アサインされているメンバーへのメンション付きで Slack に通知
- GitHub Actions を利用し、営業日のみ毎朝実行
これにより、
- レビューが溜まっていることに気づきやすくなる
- 「誰が見るべきか」をチーム全体で意識できる
ようになりました。
通知の目的は、特定の人を責めることではなく、
レビューが詰まっている状態そのものを可視化することです。
その他の取り組み：レビューの粒度を揃える
レビューの滞留や負荷の偏りは、
仕組みだけでなく Pull Request 自体のサイズ に起因することも多いと感じました。
そのため、以下の点をチーム内で意識するようにしました。
- Pull Request が大きくなりそうな場合は、適切な単位に分割して提出する
- 「1 PR = 1 つの変更意図」が分かる粒度を目安とする
- やむを得ず大きなサイズとなる場合は、事前または別途説明の場を設ける
PR が大きくなりすぎると、
- レビューに着手する心理的ハードルが上がる
- まとまった時間が取れず後回しになりやすい
- レビュアーが限定されやすい
といった問題が起きやすくなります。
一方で、PR の粒度を適切に保つことで、
- レビュー開始までの時間が短くなる
- 複数人が気軽にレビューに参加しやすくなる
- 指摘内容が限定され、やり取りがスムーズになる
といった効果があります。
なお、大きな PR が頻発するようであれば、機械的なサイズチェック（例：変更行数 400 行以内など）の導入も検討していました。
ただし、現時点では運用上の工夫で十分に回っており、ルールによる強制は行っていません。
まとめ
以上、レビューの滞留やレビュアーの偏りに対して実施した取り組みを紹介しました。
「人に頑張ってもらう」のではなく、自然にレビューが回る状態を作ることを意識して改善を行いました。
GitHub の設定変更など、比較的簡単に試せるものもありますので、同様の課題を抱えているチームの参考になれば幸いです。