プルリクがでかすぎる！レビュアーの負荷を下げるためにしてみたこと

SEARCH WRITE DevOpsユニットでテックリードをしている高橋です。
開発、運用、チームビルディング、カスタマーサポートなどを担当しています。
弊社の開発ではコードの品質を高めるためにコードレビューを取り入れています。コードレビューをするということはとても大切なことです。コードレビューのおかげで僕たちは問題を未然に防ぐことができています。ただ、コードレビューをしていくなかでつらいこともあります。
今回の記事では、プルリクエスト（以下、プルリク）が大きいことでコードレビューがつらくなっていた状況を改善するためにやってきたことを書きます。

変更が多いコードレビューはつらい

「コードレビューをする」という行為自体がつらく悪いものではないと思っています。僕の考えでは、コードレビューには以下のようなメリットがあり、どんどんするべきです。

こんなにもメリットがあるのに、なぜコードレビューがつらいのか…。
僕の場合は、多くの変更が含まれたコードを、100%の自信を持って「レビューできた」と思えないからです。
もしかしたらバグを見逃しているかも、パフォーマンスを改善できる箇所があるかも、でもこんなに多くの変更があるコードを全部レビューするには時間が足りない…
このような状況を無くし、100%の自信を持ってレビューができるようにするために改善を始めました。

プルリクに問題があった

コードレビューに関するデータを集め、分析をしていく中でわかったことがありました。

そこで、コードの変更行数が500行以上あるものを「プルリクのサイズが大きい」と定義し、以下の仮説を立てました。

コードレビューが終わらない理由

この仮説を検証するために、コードの変更行数が500行未満の「小さなプルリク」を出すように変更していこうと考えました。

チームで改善をしていく

チームで改善するために以下のことを行いました。

チームに問題意識を共有し、1週間小さなプルリクを出す取り組みを実施してみた

開発チームチャットに、「プルリクの出し方を改善する時が来た！」とフランクな感じで送ってみました。
元々問題意識を持っていたメンバーもおり、これがきっかけとなってチームでふりかえりの時間に話し合いました。
議論の中で、小さなプルリクを出すために細かいルールを作っても運用に乗らなければ意味がないため、「オレの考えた最強の分割プルリクを出していく」というテーマのもと、1週間各自が考えた方法でプルリクの分割を実施してもらいました。

１週間の実施を経て、どう変わったかを話し合った

チームメンバーにやってみたことや感想を聞いてみました。内容をまとめると以下になります。

今後発生しそうな問題はありつつも、結果としてはコードレビューのつらさを軽減することができました。

またデータとしても以下のような変化がありました。

まとめ

コードレビューには多くのメリットがあり、バグやパフォーマンス低下など将来発生する可能性があった問題を未然に防ぐことができます。ただ、コードレビューがスムーズに行える環境がなければこのメリットを享受できません。
もしコードレビューがつらいと思う場合は、この記事に書いている取り組みを実施してみてはいかがでしょうか?
もし一人だと行動しづらい場合は、昔僕が書いた味方づくりの記事をぜひ参考にしてください。

こわがりエンジニアは味方づくりと小さな改善を繰り返す

PLAN-Bに入社して、2年の月日が経ちます。入社してすぐに自社プロダクトSEARCH WRITEの開発チーム立ち上げにジョインしました。現在はそのチームのリーダーとして、もともと興味のあったアジャイル開発に力を入れる日…

本文中に使用している計測ツールはFindy Team+です。