はじめに

こんにちは。with で Android エンジニアをしている石田です。
突然ですが普段の仕事の中でコードレビューはどのタイミングで行っていますか？

ついつい後回しにしてしまうことも多いのではないでしょうか。しかしこれがチームの生産性を低下させてしまっているかもしれません。

通常コードレビューの話題が上がるときってコードレビューのやり方について議論することが多いと思うのですが、本記事では 「コードレビューのスループットが下がると実は結構生産性下がってるよね」 という話と 「どのようにコードレビューのスループットを向上させるか」 という話をしたいと思います。以下、コードレビューを単にレビューと呼びます。また with の Android チームを with-android と呼びます。

コードがマージされるまでの過程

本題に入る前に書いたコードがマージされるまでの過程を整理してみます。
3. のレビュー依頼 と 4. のレビュー返却 のやりとりは通常何度か繰り返し発生します。ちなみに with-android の場合は平均すると 2 往復くらいのやりとりをマージまでに行っています。

これまでコードレビューをやるタイミングはメンバーの裁量に任されていました。レビューを依頼した同日中にレビューを返してくれることもあれば、依頼から数日たった後に催促されてようやく取り掛かるということもありました。

それでは 3. と 4. のレビューのやりとりが遅れることによりどのような問題が発生し得るのか考えてみます。

レビューが遅れることによるオーバーヘッド

レビューが遅くなることによるオーバーヘッドは想像以上に大きいです。 with-android で感じていた課題感を3つ挙げます。

1. マージコンフリクトが発生しやすくなる

実装開始からマージするまでの時間が長くなると、当然ながらマージコンフリクトが発生しやすくなります。レビューが完了していざマージしようと思ったらコンフリクトしててマージできない😇 といった経験は誰しもあるのではないでしょうか。レビューを早く済ませることで無駄なマージコンフリクトの修正作業をある程度減らすことができます。

2. Pull Request の内容を忘れてしまう

エビングハウスの忘却曲線で示されているように人間の記憶はかなりのペースで失われていきます。レビューが遅れるとレビュアーどころかコードを書いたオーナーの記憶すら怪しくなっていきます。レビューを早く済ませることでプルリクの内容を思い出すのに余計な体力を使わずに済みます。

3. レビューのレスポンスが遅いと、双方のレスポンスが遅くなる悪循環に陥る

人間はレスポンスが遅いものに対して関心が減っていきます。サイトの表示速度が数秒遅いだけで直帰率が大幅に上がる話とおそらく同じ話で、レビューに対するレスポンスが遅いと連鎖的にレビューのやりとりが遅くなるという現象が with-android では発生していました。レビュー依頼やレビュー返却をお互いに早く済ませて~~互いに圧をかけることで~~レビューのペースを維持することができます。

レビューを早くする方法

レビューが遅くなることによるオーバーヘッドは大きいぞという話をしたので、ここからはレビューを早くするために with-android が実施した 3 つの方法(+ おまけ)を紹介します。

1. 「レビューはできるだけ早くやるべき」という共通認識をチームで持つ

「コードレビューを後回しにすることは結局チームの生産性を下げることになるから、これからはコードレビューにはできるだけ早く対応しましょう」という話をチームでした上でコードレビュー依頼は Slack のメンションと同じ という合言葉を繰り返し使って浸透させました。

「できるだけ早く」と言うとその言葉の意味が人によって違いますし、形骸化しそうだったので Slack のメンションと同じくらい早くレスポンスしましょうという風に、チームメンバーが具体的にイメージしやすい例えを使うのがよいと思います。

加えて 1 日に 1 回、後回しにならないようにできれば午前中にレビューを全部消化する習慣をつけるといいですよという話もしました。

2. GitHub の Scheduled reminders を設定する

GitHub に Scheduled reminders という機能があり、レビュー待ち状態の Pull Requests を Slack に通知することができます。 with-android ではこの通知をリマインダーではなくアラートと呼んでいます。 通知が飛んでくる=レビューに遅れが発生していることを意味しているからです。通知する条件はチームに合わせて設定するとよいと思いますが、with-android の場合は 少なくともプルリクを出した翌日にはレビューが返ってきている状態を意識して平日に 18 時間以上レスポンスがない場合に通知する 設定にしています。

3. Pull Request のサイズを小さくする

これは研究でもたびたび指摘されていることなのですが¹、Pull Request のサイズが大きいとレビューが遅くなりますし、バグを発見する頻度も下がると言われています。なので Pull Request のサイズは小さく保つのがよいです。そのために with-android では実装に入る前にタスク分割を行い計画を立てることを推奨しています。

おまけ: レビューを優秀なエンジニアに集中させない

これは努力目標といった感じなのですが、レビューを優秀なエンジニアに集中させない方がいいよねという話があります。with-android のように 4~5 人くらいの規模のチームだと一番優秀な人がマネージメントなりの開発業務以外の役割を兼務しているものです。なのでチームメンバーの中で最も忙しく、すぐにレビューを返せるとは限りません。従って可能な限りレビューを属人化させず、全チームメンバーに適切に分散してボトルネックを作らないようにできればよいと思います。

まとめ

コードレビューのスループットが下がると生産性が下がるという話とその改善方法を紹介しました。コードレビューはついつい後回しにされがちなタスクだと思いますが、もしチームで課題感を感じているならば一度議題に挙げてみてはいかがでしょうか。

例えばこちらの論文 ↩