はじめに
開発におけるコードレビューについて、レビュワー・レビュイー双方の立場から「レスポンスの速さ」の重要性について、私が最近心がけていることをまとめます。
なお、ここで言う「速さ」とは、レビューそのものを雑に素早くこなすことではありません。
「ボールを持ったらすぐに投げる（着手・対応する）」という、着手の速さについての話です。
レビュワーのとき
可能な限り早く着手する
自分にレビュー依頼が来た際、私は可能な限り早く着手するようにしています。
これは「レビューにかけている時間（精査する時間）」を減らすわけではありません。
「レビュー依頼が来てから、実際に見始めるまでの時間」を短くするよう意識しています。
その理由は大きく3つあります。
-
デプロイまでのリードタイム
相手を待たせないことで、マージからデプロイまでの時間が短くなります。 -
記憶の鮮度
待ち時間が長くなればなるほど、書いた本人でさえも「なぜそのとき、そのようなコードを書いたのか」ということを忘れてしまいがちです。
記憶が鮮明なうちにフィードバックを返すことで、スムーズなコミュニケーションが可能になります。 -
手戻りのリスクを最小化する
レビューを待っている間、レビュイーが手持ち無沙汰にならないよう、そのプルリクエストに依存する次の Issue に取り組み始めるケースがあります。
もし、レビュー結果として「根本的な設計の見直し」や「大幅な修正」が必要になった場合、先行して進めていた作業もやり直しになり、大きな手戻りが発生してしまいます。
早い段階で方向性を確認するためにも、早めの着手が重要です。
レビュイーのとき
返されたレビューには即対応する
逆に、自分がレビューを出して指摘をもらった場合も、できる限り早く対応するようにしています。
これは、上述した「レビュワーの記憶」への配慮が大きな理由です。
レビュワーが文脈を思い出すことのコスト
自分がレビュワーをやっていると痛感するのですが、数日前に見たコードの内容が再レビューで飛んできたとき、詳細までをきちんと覚えていないことが多いです。
特に、以下のようなケースではそのコストが顕著になります。
- 変更行数が多い大きめのプルリクエスト
- 自分がコンテキストをあまり把握していない箇所の実装
こういったレビューを行う際、レビュワーはその場で仕様を調べたり、有識者に聞いたりしながら理解を深めると思います。
しかし、数日も経てばその苦労して理解した内容も忘れてしまいます。
もちろん、調べたことはコメントに残すなど工夫は行うと思いますが、再レビューの際にそれを見直し、当時の思考プロセスを思い出すのは意外と時間がかかり、少なからず負担になります。
レビュワーに思い出すコストを払わせないためにも、指摘をもらったら、相手の記憶が残っているうちに打ち返すのが、結果としてチーム全体の効率につながると思います。
レビュー自体の時間を短縮するための AI 活用
着手や対応の速さとは別に、レビューにかかる時間そのものを短縮するために AI (GitHub Copilot, Gemini, CodeRabbit など) を活用するのも良い手段だと思います。
もちろん、これにはチーム内の文化醸成が必要です。
ここで言う文化とは、単に「AI を使っても良い」という合意だけではありません。
AI による機械的なレビューがアサインされても、「手抜き」や「責任放棄」と受け取られず、あくまで効率化のための手段だと信頼してもらえる状態ができていることを指します。
そういった文化があると、以下のようなメリットを感じられるかと思います。
-
「事前のレビュー」と「要約」
AI レビューツールを通すことで、人間が見る前に細かな指摘をしてくれたり、プルリクエストの内容を要約してくれたりします。
Description はレビュイーが書いているとは思いますが、ファイル単位の細かい変更理由などは書かれないことも多いため、AI が補足的に内容をまとめてくれると意外と便利で、コードを読み解く時間を多少削減できることもあります。 -
レビュイーの「伝えるコスト」の削減
Description の作成を AI に手伝ってもらうことで、文章作成にかかる時間を短縮することもできます。
ただし、AI だけに任せきりにして、人に伝えることをおろそかにすると、かえって意図が伝わらず全体の効率が下がってしまうため注意が必要です。
あくまで「文章化・伝言のためにかかるコスト」を削減するために適切に使うと、お互いにとって嬉しい結果になると思います。
おわりに
レビューはお互いの時間を少なからず使う作業です。
レビュワー・レビュイーの双方が「相手の記憶」や「手戻りコスト」を意識して、ボールを長く持たないようにするだけで、開発体験・サイクルが良くなるのではないかと思います。