コードレビューは少人数の優秀な人にまかせると負担が偏り、全員がやってオッケーというルールにするとクオリティーの低いコードがアウトプットされるリスクがあります。みなさんのチームや会社ではコードレビューにおいてどのようなルールを設けていますか？

こんにちは、ご質問ありがとうございます。

ご質問の点について自分の経験としては明快で、良いアウトプットの出ているチームにおいては、「力ある方」すなわちTechLead(TL)に値いする方に、まずは全ての負荷を集中させることが良いかと思います。優れたTLは誰よりも深くコードベースを理解し、押し寄せる全てのコードレビューを右から左に千切っては投げ、千切っては投げ、そして誰よりも品質の高いコードを書くという超人的な働きが期待されます。であるからこそ、TLはチームメンバーからの敬意をあつめ、同時に働きに見合った報酬を受け取るのではと考えています。

また、TLに求められる（心理的に）重要な要素として、無私の奉仕の精神、自分の能力を惜しみなく他者に与えることが挙げられます。全てのコードレビューをTLが行うのは相当な負荷ではありますが、それを通じてTLの経験、コーディングに対するノウハウがチームメンバーに共有されて行きます。やがて、一定の期間が経てばチーム内で別のメンバーにコードレビューを持ち回りする等、良いチーム文化が醸成されていく事が期待できるかと思います。

実務的な面からは、
・CLの粒度をできるだけ小さくする
・コメントや補足をできるだけ詳しくしCLの意図を明確にする
・（面倒ではありますが）UnitTestも同時に書いてリグレッションをできるだけ減らす
など、レビュアーの負荷を減らす方向性でのルール作りというのも生産的かと思います。

私のいたチームではあまり厳密なルールを決めていたことはありません、基本的には1つのプロジェクトを担当している人が複数人いるはずなのでその中で持ち回りでやること、コードレビューについてもメトリクスを取って(どのくらい時間が掛かっているか、人に偏りが出ていないか)定期的にレビューする時間を取って、問題があるなら少しずつやり方を変えていく、というようなことをしていました。

コードレビューに限らないのですが、優秀な人が周りの教育をするということが大事だと思います。また、コードレビューにおけるガイドラインを設定したり、レビューで指摘されることで定型化できることはドキュメント化した上で、なかなか定型化の難しい内容について、定期的に振り返りなどを行いながら、コーディングおよびレビューの教育を行なっていくと良いと思います。

また、指摘されたことについて、指摘された側がその時だけ直して、また忘れてしまって同じことを繰り返し指摘されることもよくありますので、そういった内容を定期的に振り返ったり、レビューされる側が実際に意識できるように指摘されたことのまとめをアウトプットして定着させていくことも大事だと思います。

うちの社内でもチームによってルールは様々です。
ただ、コードレビューのそもそもの意味を考えると、低いコードがアウトプットされることは事故を生み出しますし、元も子もない状態になるので、ある程度コードが見れる経験者に見てもらうほうがよいとは思います。
優秀な人にかたよってしまって、全体のスピードが落ちてると感じる場合は、メンバーレベルだとしても二人以上OKにしないとマージできないとか、そういうふうにして品質とスピードを保つ工夫はした方がいいと思います。