どうすればPull Requestのレビュー精度を向上できるか？

はじめに

土居です。元々あまり家から出ない方ですが、昨今の新型コロナによる外出自粛ムードでどうしても鬱々とした気分になってしまいます。みなさまはどのようにお過ごしでしょうか。

今回のブログ記事では、Pull Requestのレビューの精度を向上するための試みについて話してみたいと思います。

Pull Requestの粒度に関する課題

以前から、レビューをしやすくするため、Pull Requestをする際にファイル数や変更行数などを大きくし過ぎないようにしようという意識が社内にありました。ところが具体的なルールは無く、Pull Requestの粒度が大きいせいで、レビュワーの負担が重くなってしまうことがありました。

そのためPull Requestの粒度を小さくするためにはどうしたらいいか、メンバーで議論を重ねてきました。結論としては、シンプルにPull Requestの数を皆の目標とする方法を試すことになりました。前四半期のPull Request数は400弱。今四半期に、1.5倍となる「600」のPull Request数を達成することを目標に設定しました。

Pull Requestの粒度を小さくするには

MMMでは、Backlogのチケットをもとに、[プロジェクト名]-[No]といった風にGitブランチを切り、作業を進める形をとっています。Pull Requestの粒度を小さくしようとすると、形式的には[プロジェクト名]-[No]-[Option]となるのが自然です。この切り方自体は今までも例があるため、Pull Request数を1.5倍にするには、この方法だけでは難しい気がしました。

また、例えばフロントエンドのNuxt.jsを用いたSPA開発のプロジェクトでは、1つの機能の実装をstoreとviewで分けています。このような分け方をさらに進めてPull Requestを小さくすることもできますが、レビュー精度の向上に寄与しないため、本質的ではありません。

Backlogのチケット自体の切り方にも一考の余地はありそうです。具体的なところはこれから試行錯誤を重ねてまたご紹介できたらと思います。

もちろん、Pull Requestの数を増やすことだけを考えてしまったら本末転倒です。適切なPull Requestの切り方を常に意識し、定期的に振り返りを行いたいです。皆の議論を深めるためのきっかけとして、今回の目標を活用したいと思っています。

おわりに

レビュアーに優しいPull Requestを実現できれば、自然とレビューの精度も高くなっていくでしょう。それは最終的に、製品の品質向上や、サービス提供のスピードアップに繋がっていくはずです。よりレビューのしやすいPull Requestを目指していこうと思います。

どいけん