以下の記事で個人的にチームに共有したいなと思った箇所の抜粋です。
https://google.github.io/eng-practices/review/reviewer/speed.html
個人の最適化ではなくチーム全体の最適化
At Google, we optimize for the speed at which a team of developers can produce a product together, as opposed to optimizing for the speed at which an individual developer can write code. The speed of individual development is important, it’s just not as important as the velocity of the entire team.
Googleでは、個々の開発者がコードを書く速度を最適化するのではなく、開発者チーム全体が製品を共同で生産する速度を最適化します。個々の開発の速度は重要ですが、チーム全体の速度ほどではありません。
レビューはどのくらい早く着手すべきか？
How Fast Should Code Reviews Be?
If you are not in the middle of a focused task, you should do a code review shortly after it comes in.One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).
Following these guidelines means that a typical CL should get multiple rounds of review (if needed) within a single day.
コードレビューはどれくらい早くすべきか？
集中しているタスクの最中でなければ、コードレビューはその依頼が来た後すぐに行うべきです。
営業日1日が、コードレビュー依頼に対応するための最大の時間枠です（つまり、翌朝一番に）。
これらのガイドラインに従えば、通常のCLは必要に応じて1日以内に複数回のレビューを受けることになります。
レビューと今やっている作業どちらを優先すべきか？
There is one time where the consideration of personal velocity trumps team velocity. If you are in the middle of a focused task, such as writing code, don’t interrupt yourself to do a code review. Research has shown that it can take a long time for a developer to get back into a smooth flow of development after being interrupted. So interrupting yourself while coding is actually more expensive to the team than making another developer wait a bit for a code review.
Instead, wait for a break point in your work before you respond to a request for review. This could be when your current coding task is completed, after lunch, returning from a meeting, coming back from the breakroom, etc.
個人の作業の流れを最優先すべき時があります。たとえば、コードを書くなど、集中しているタスクの最中には、自分自身を中断してコードレビューを行うべきではありません。研究によれば、開発者が中断された後、スムーズな開発の流れに戻るのには長い時間がかかることが示されています。そのため、コーディング中に自分自身を中断することは、他の開発者にコードレビューのために少し待ってもらうよりも、チームにとってのコストが高くなります。
代わりに、レビューリクエストに応答する前に、作業の中断点を待ちます。これは、現在のコーディングタスクが完了した時、昼食後、会議から戻った時、休憩室から戻ってきた時などが該当します。
レビュー依頼に対して素早い反応
When we talk about the speed of code reviews, it is the response time that we are concerned with, as opposed to how long it takes a CL to get through the whole review and be submitted. The whole process should also be fast, ideally, but it’s even more important for the individual responses to come quickly than it is for the whole process to happen rapidly.
Even if it sometimes takes a long time to get through the entire review process, having quick responses from the reviewer throughout the process significantly eases the frustration developers can feel with “slow” code reviews.
If you are too busy to do a full review on a CL when it comes in, you can still send a quick response that lets the developer know when you will get to it, suggest other reviewers who might be able to respond more quickly, or provide some initial broad comments. (Note: none of this means you should interrupt coding even to send a response like this—send the response at a reasonable break point in your work.)
コードレビューの速度について話すとき、私たちが重視しているのは、CLが全体のレビュープロセスを通過して提出されるまでにかかる時間ではなく、レスポンスタイムです。全プロセスも理想的には迅速であるべきですが、個々のレスポンスが迅速に来ることの方が、全プロセスが速く進むことよりもさらに重要です。
全レビュープロセスを通過するのに時には時間がかかることがありますが、レビュアーからの迅速なレスポンスがプロセス全体にわたってあると、「遅い」と感じられるコードレビューに対する開発者のフラストレーションを大きく軽減します。
CLが届いたときに完全なレビューを行うのにあまりに忙しい場合でも、いつ対応できるか開発者に知らせる短いレスポンスを送る、より迅速に対応できる可能性のある他のレビュアーを提案する、またはいくつかの初期の広範なコメントを提供することができます。（注意：これは、このようなレスポンスを送るためにさえもコーディングを中断すべきだという意味ではありません。作業の合理的な中断点でレスポンスを送ってください。）
大きなChange List
If somebody sends you a code review that is so large you’re not sure when you will be able to have time to review it, your typical response should be to ask the developer to split the CL into several smaller CLs that build on each other, instead of one huge CL that has to be reviewed all at once. This is usually possible and very helpful to reviewers, even if it takes additional work from the developer.
もし誰かがあなたに非常に大きなコードレビューを送ってきて、いつそれをレビューする時間が取れるか分からない場合、通常の対応は、開発者にそのCL（変更リスト）を、一度にレビューしなければならない大きなCLではなく、お互いに構築されるいくつかの小さなCLに分割するように依頼することです。これは通常可能であり、開発者からの追加作業が必要であっても、レビュアーにとって非常に役立ちます。
まとめ
以下のことをルールとして取り入れて行きたいと感じました。
- レビューを着手していること、またはいつから着手できることを実装者に伝える
- 朝一、現在のタスクが完了した後、昼食後、会議後、休憩後に優先的にコードレビューを実施する