コードレビューの優先順位を高めたらチームの生産量が上がった話

※この記事は「COUNTERWORKS Advent Calendar」の14日目の記事です。

はじめまして、株式会社 COUNTERWORKS にてEnterprise向けプロダクトのエンジニアリーダーのshimです。

私のチームは、障害対応や既に決まっていたミーティングなどの次に、コードレビューの優先順位を高くしております。
私がチームのリーダー的存在となって1年半ほど運用してきた振り返ろうと思います。

古くは Google様のドキュメント 、本年も他の会社でも同様の取り組みで良かったと聞くことが増えました。
個人的にかなり良い取り組みとなったので、この文化が広まる一助となるよう筆を執りました。

経緯

開発メンバーも増えたものの、いろいろなバックログがしかかり中で終わって、メンバー数の割になかなか価値提供までいかないスプリントが多かった時期がありました。

それについて複数要因はあったのですが、要因の一つにコードレビューがありました。
レビューしてもらうまで、早いときと遅いときがまちまちで、遅いときは次の作業まで手が空いてしまうので他の作業を進め、レビュワーからフィードバックがあったらまた元の作業に戻って…
と、脳みそのコンテキストスイッチおよびローカルブランチのスイッチ（作業中なものがあったらstashしたりキリがよい所まで進めたりして）の負担感もあって、なかなか上手く前に進めない感じがしておりました。

他のメンバーも同様のようで、スプリントの振り返りでも「レビューが終わらなかった」と言った単語がよく出ておりました。

今考えるとちょうど車の渋滞の発生のメカニズムのように、先頭で進んでいた車両が速度を落とした影響が徐々に後続車両に波及していく、といった所でしょうか。スプリントの後半は待ち行列が溢れておりました。

自分については最初の現場からコードレビュー依頼されたことに気づいたらすぐレビューするように叩き込まれていました。
レビューももちろんスイッチングコストはありますが、読むだけなので実装するのに比べてではありますが負荷は低いのと、じきに慣れたので問題ないと思っておりました。

※当然ながら、じきに慣れるかどうかは個人差がかなり大きかったです

そんな話をした所、試しに優先順位を前述の通りにしようとなり、チームとして取り組むことになりました。

結果どうなったか

取り組んで2〜3ヶ月たった際、そのスプリントでしかかり中で終わるバックログが少なくなり、チームのベロシティが以前より高い状態で安定しました。

自分の感覚として効果を実感した部分は、チームとして合意しているので依頼する際に相手の都合を過度に気にしなくなった点です。
特に急ぎの場合はリマインダをしやすくなりました。

また、自分が業務を抱え込みすぎていてすぐにレビューできない場合は、優先順位の共通認識がある為、他の人にバトンタッチもお願いできるようになりました。

後述の工夫もした結果、最近ではレビューに出すと早いときは数分・遅くても数時間以内に完了するようになっております。
テンポが良くなったので、レビュー待ちによる別作業をしてのスイッチングコストに悩むことはほぼなくなりました。

素早くレビューをする為される為に工夫したこと

濃密なプランニング

レビューする上では既存機能や仕様の認識および理解が不可欠です。

スプリントプランニングの段階で、スプリント内で行うバックログについては、全員でプロダクトオーナーにワイヤーフレームを見せてもらいつつ、なぜそうするのかと説明を受け、疑問や意見はその場で出すようにしています。

また、実際に実装してみて、機能が変わったり作業ボリュームが増えた場合はデイリースクラムイベントで見積もり直す際に詳細に説明してもらうようにしています。

当然メンバー数が多ければ多いほどコストが高くなってしまうので、Amazonのピザ2枚ルールで収まるようなメンバー数が良さそうです。
ちなみに私含めて大食いなメンバーが数名いるので、ピザ2枚ルール(Lサイズ)だと1チーム1〜1.5人になってしまいますので我慢してます。

レビュワーが読みやすい粒度のプルリクエストとコミット

あまりに大きすぎるプルリクエストや、雑なコミットがあるとレビュワーにとっての負荷が高くなります。
特にコミットは大切で、適切な粒度・適切な積み方をしていると多少ファイル数や変更範囲が大きくても、コミット単位で読んで行くとスラスラ読むことができます。

これについてはレビュワーになってみないと実感が難しいので、レビュー力向上のために全員で1つのプルリクエストをレビューすることもあります。
全員レビューについてはコストはかかりますが、他のメンバーの良い書き方やレビューフィードバックの仕方を学べるので、特にチームができた際や新メンバー加入のときに行うと良い実感があります。

レビュワーにレビュイーがコードを説明する会

特に複雑な実装や、レビュワーにとってわかりづらそうなこと、前提条件などがある場合、レビュイーもしくはレビュワーからの発案で、実際に画面を共有して説明する会をオンライン・オフライン限らず開くようにしています。

この会ではレビュイーが、まず仕様についてワイヤーフレームや実装した画面を見せながら説明し、その後GithubのプルリクエストのFile Changesをコミット単位で見つつ、どういう機能実現するためにこのように実装したかをコード差分をそれぞれ説明していきます。

ここでレビュワーは気になる点があったらすぐに質問をしたり、フィードバックを行い、レビュイーとコミュニケーションをとります。

一通り説明が終わって合意が取れればレビュー完了、レビュワーがもう少し見たい場合は会を終了しレビュー継続、フィードバックに対して対応事項があればレビュイーは対応していくことになります。

チームメンバーの声

スプリントごとにベロシティの計測はしていて結果は出てるものの他の施策（別エントリーで書きます）もあり、コードレビューについて効果を実感しているのが自分だけなのか分からなかったので、この優先順位となって良かった点・悪かった点を他のチームメンバーに聞いてみました。

---

ひどいときにはレビューが後回しになることが原因で半分以上のPBIが完了してなかったけど、優先度変更後はレビューの後回しによる未完了のPBIは0になった

早くレビューしてもうための工夫を一切する必要がなくなった

レビューを急かしたり、手が空いてそうな人を探したりする必要がなくなったのが個人的に一番スループットが上昇した気がしますね

当初はすぐレビューすることにネガティブだった(スイッチングコストがかなりでかいと思ってた)けど、実践した結果、スイッチングコストよりもすぐにレビューしてもらえる体験の良さが圧勝してた

今思えばって話ですが、レビューによって自分の作業が中断される時間が短ければ短いほど、レビューを最優先にすることに前向きになれるから、改めて組織としてPRを小さくしよう運動すればよかった(PRは小さくしようという意識が昔からあったけど)

優先順位が高いことが共有されているので、自分のタスク⇔レビューの切り替えがはやい（と思う）

良かったこと

• 他人のコードを読むことで、今までの自分じゃ思いつかなかったような実装を知ることができてとても勉強になる
• （少し話が違うのですが）全員レビュー体制を取るようになって、他人がどのようなことを見てレビューしているのか？知れるようになり、レビューのお作法的なものをインプットできた
• 積極的レビューにより、根本的な問題や議題にまで話が及ぶことがあり、それをそのままチーム内に持ち帰ることで改善サイクルがはやく組めるようになった（気がする）
  悪かったところ
• 自分がほとんど関わっていない実装のレビューは多少時間がかかってしまう

次の作業にどっぷり入る前にレビューをしてもらえるので、複数のタスクを並行で作業している時間が少なく、ワーキングメモリ的に余裕を持てる気がしてます

前の現場もその前もBEのシニアエンジニアが1人で、負担が集中して開発フローがパンクすることが多々ありました。シニアエンジニアが2人以上のレビュー体制だと、開発フローを進めるのがかなりスムーズな印象があります！

現状の課題

現状誰かが見る、と誰がボールを持つかは決めていないので、どうしてもレビュワーが偏ってしまいます。

自動でレビュワーを割り当てるなどしていきたいです。

スイッチングコスト対策

個人的に慣れたとはいえスイッチングコストは感じます。
その際にレビューが終わってすんなり元の作業に戻る為の、個人的な工夫を紹介したいと思います。

ルーティン

ラグビーの五郎丸歩選手を始め、プロスポーツ選手がよくやっているアレです。

これをやるとこうする・こうなる、というスイッチを作り、ルーティンを行うことで強制的に任意の状態になるように自分の体を教育します。

私は新卒時代から十数年間、集中して実装をする際には爆音でトランス期のglobeを聴くようにしています。
長年の調教の結果、聴くことで一発で過集中モードになります。長年ありがとう！そしておかえりなさいKEIKO！

ただ、過集中となってしまうので、ここぞというときのとっておきにしておりまして（現在この記事を書くために追い込まれているので聴いてますが）、普段は少し懐かしい洋楽EDMを聴いております。
本年はCalvin Harrisの曲を世界のSpotifyユーザー上位0.5%に入るぐらい聴いておりました。

両方とも、首を振りながら仕事をすることとなり肩こりがつらいのが難点。
みなさんも自分に合うルーティンを見つけてみてはいかがでしょうか。

おわりに

記事を書くタイミングで改めて振り返ってみましたが、最初は大変なはずなのに、まずこれでやってみようとなってくれて継続してくれたメンバーに感謝したいと思います。
お陰様で実装からマージまでかなりストレスなくできるようになりました。
同様の悩みがある現場の方にとって「あそこもレビューの優先順位を上げたら良かったらしいよ！」と他のメンバーを巻き込むきっかけになれば幸いです。

We are hiring!!

COUNTERWORKS では、一人でglobeの各パートを歌い切るエンジニアリーダーと一緒に働く仲間を絶賛募集しております（お祝いごとのときにはプロダクトオーナーもKEIKOとして参加してくれます）。
まずは気軽にお話でも。皆さまのご応募お待ちしております！

https://counterworks.co.jp/recruit/?utm_source=zenn&utm_medium=referral&utm_campaign=advent-calendar-2023&utm_content=14