チームで1年間コードレビューを最優先に実施したら開発生産性に良い影響を与えてくれたかも

＼スニダンを開発しているSODA inc.の Advent Calendar 10日目の記事です!!!／

こんにちは！！！！SODA開発部の矢野です！！！

はじめに

私のチームでは一年前からコードレビューを最優先に実施するという取り組みをしています。この取り組みを継続した結果開発生産性にも良い影響を与えてくれたかもしれないので記事にしようと思います！

ちょうどこの記事を作成しているときにX(旧Twitter)で「PRのレビューを最優先にしたらチームの生産性が上がった」の投稿にたくさんのいいねがついていたので、コードレビューを最優先に取り組んで効果を実感している組織やチームが多いのかもしれないですね。

レビューを最優先にした結果

結果から書くと、
「コードレビューを最優先にする」取り組み前後の「レビューからアプルーブまでの平均時間」を比較すると6.5時間から2.5時間に縮まりました（本当かな？）レビュー最優先以外にも複数の要因はありそうですが、「レビューを最優先」プラスαで「PRを小さくしよう」や「翌日ではなく当日にレビューする」の意識が根付いた結果、全体のサイクルタイムが短くなったのではないかと分析しています。

2022/07/01-2022/11/30

2023/07/01-2023/11/30

2023年

ここからはコードレビューを後回しにすると発生する問題と原因、対策について以下で詳しく解説していきます。

コードレビューを後回しにすると発生する問題

1.リリースまでのリードタイムが伸びる

レビューまでの時間が長くなるとリリースまでのリードタイムが伸びます。結果として仕掛品が溜まり、開発のサイクルタイムが伸び、プロダクトへの価値提供が遅くなります。Four Keysの指標「変更のリードタイム」にも影響を与えますね。

2.レビューが溜まれば、その分一つのレビューに対しての抜け漏れが発生しやすくなる

溜まったレビューを一気に処理していくと、一つのレビューの抜け漏れが発生し、不具合や問題が見落とされやすくなります。結果、仕様に対しての漏れやプロダクトの品質の低下に繋がります。

3.コンフリクトが発生する

最初のコミットからマージまでの時間が伸びると、コンフリクトが発生する可能性が高まります。コンフリクト箇所を把握している他の開発者とコミュニケーションを取りながら、コンフリクトの修正作業をしなければならないので、その分工数が上乗せします。

4.他の箇所の作業がブロックされる

他の開発者やチームメンバーの作業がブロックされる可能性が高まります。特に依存関係がある場合、あるコードや変更がレビュー待ちの状態にあると、それに依存する他の作業も進行が難しくなります。

レビューが後回しになる原因

レビューが後回しになるのは何故なのかと考えた時に主に以下の原因があると思いました！

• チーム内でレビューを最優先にするという意識が浸透していない
• プルリクエストのコード差分が大きい
• 特定のメンバーにレビューの負担がかかっている
• レビューにアサインされていることに気づかない

私のチーム(組織全体で取り組んでいる対策もありますが。)ではコードレビューを後回ししないよう一つ一つ対策を立てているので、紹介していきます！

1.チーム内でレビューを最優先にするという共通認識を持ち、定期的に振り返る

チームでは定期的にFour Keys指標を見ながら振り返りをしています。開発のリードタイムが伸びていないか、レビューするまでに時間がかかっているプルリクエストがないかを確認し、気になる指標があれば、何故そうなったのだろう？という振り返りをするようにしています。
確認していくと「プルリクエストが大きかった」、「アサインされたのを気づいていなかった」など理由が特定できるので、次は「プルリクエストを小さくすることを意識しよう」や「リマインドしよう」などのアクションに繋がります。

一年前に「レビューを最優先にしよう」という取り組みを共有

スプリント期間のリードタイムが伸びていたら振り返る

4.プルリクエストを小さい単位に分割する

プルリクエストの変更行数が多いと修正があった際の変更コストが高くなったり、レビュー負担が上がったり、確認事項が多くなり抜け漏れが発生します。また、大きいプルリクエストだと心理的に「レビュー大変そうだから後回しにしよう。。」という気持ちにさせてしまいます。
そのためチームでは「プルリクエストの粒度は最小単位にしよう」というルールを設けています。

具体的には以下を意識してPRを作成することが多いです。

• 基本の分割方法はusecaceやhandlerなどレイヤーごと
• ドメインモデルの定義
• interfaceだけPRを作成し、usecase層とinfrastructure層を並行して実装できるようにする
• 実装とリファクタリングは分ける
• PRが最小単位になるようにプランニング時にタスク分割する

上を意識してPRが作成できるようにプランニングの段階からPRの粒度でタスク分解するようにしています。

レビュー配分は均等に

レビューをする回数は特定のメンバーに負担がかからないようにチーム内で均等にアサインするようにしています。GitHubのレビュアーの自動割り当て設定でラウンドロビンを設定することでチーム内でバランスよくレビュー担当者を選んでくれます。

ドメインやDBスキーマなどの全体に関わる変更や処理が複雑な箇所については全員アサインしてレビューをするようにしたり、新しいメンバーが参画した際は慣れるまでは複数人アサインしたり同期レビューをしたりと臨機応変にレビュワーをアサインするようにしています。

レビュワーはラウンドロビン方式で均等にアサインする

ラウンドロビンアルゴリズムは、現在未処理のレビューの数とは関係なく、Team のすべてのメンバー間で交互に、最も新しいレビューリクエストを誰が受け取ったかに基づいてレビュー担当者を選択します。

https://docs.github.com/ja/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#routing-algorithms

レビューを忘れないようにリマインド設定

MTGが重なったり、休日が挟まるとレビューを忘れるときがあります。忘れている時のためにGitHubの「スケジュールされたリマインダーの管理」で平日の毎朝9時に通知が届くように設定しています。

リマインドが翌日の9時だと少し遅いので、レビュー依頼をして2,3時間しても反応がなければPRのコメントで「レビューお願いします〜」とコメントするようにしています！

私がレビューするの忘れた時は、リマインドしてくれます。

終わり

「コードレビュー最優先」を実践すると「PRやタスクを小さくしていこう」や「レビューの負担を減らそう」という意識につながり、結果として「リードタイムの短縮」や「開発生産性の向上」の効果がありそう？ということが分かりました。これからもチーム全員で意識的に「レビューすぐ見るチャレンジしてます」にトライしていきます。

明日は@ayumi_sekiyaさんによる「CSがプロダクト改善に足を踏み入れてみたの話」です。お楽しみに！わ〜わ〜(拍手)