コードレビューは概ね以下のような目的で行われている。
- コード自体の品質を担保する
- 外部品質 = ちゃんと動くのか。UI/UX的に問題ないのか。
- 内部品質 = 保守性（可読性・拡張性）・セキュリティ・パフォーマンス・自動テスト
- コードをチームに共有する（＝チームの所有物にすること）
- ドメイン（ビジネス・技術）の共有
- コードを通じたコミュニケーション
1の品質担保が一番重要そうなのだが、実際はそれ以外が大事だよ、という駄文を書く。
コードをチームに共有する
コードレビューによって書いたコードがチームの持ち物になる。
何か不具合が発生したときも、そのコードを理解している人が1人でも増えれば不具合解消までの時間は減るかもしれない。解消までの時間が減らなくても不具合発生時の実装者の心理的負担は少なくなる。 そのコードに関する機能追加をしたいときもコードがチームの持ち物になれば他の人が対応しやすくなり、チーム全体の生産性が上がる。
コードレビューでは「誰か１人レビュー通ればOK」とか「チームリーダーがレビューする」という運用をしているところがあると思うが、コードの共有という意味ではできるだけ多くの人がレビューしたほうが価値があるし、時間があるときに軽く目を通しておくと良かったりする。
ドメイン（ビジネス・技術）の共有
コードレビューはドメインを共有する機会にもなる。
このテーブルはレコード数が多い、エンドポイントのリクエスト数が多い、同じような処理がありドメインとしても共通化できそう、とか。 要求や要件のレビューを通じてビジネスドメインを知る機会になるかもしれない。
エンジニアが技術的な知見を共有し合うチャンネルとしても有効だ。 影響範囲を出すための方法、データベース設計やパフォーマンスチューニングの知見、セキュリティを考慮した実装など。コードを実装しなくても解決できるような技術的引き出しを共有することで、より本質的な課題解決ができるようになるかもしれない。
コードを通じたコミュニケーション
コミュニケーションは質より量を意識したほうが良い。 エンジニアにとってコードレビューはそれ自体が貴重なコミュニケーションチャンネルの１つだ。
ドメインや知見を共有しなくても「この実装良いですね！」とか「対応ありがとうございます！」とか絵文字のリアクションをつけたりするだけで、お互いに仕事がしやすくなる。
「一旦この実装でOKで、チームで改めて方針は再検討しても良いですね！」みたいな課題発見や問題提起をしても良い。エンジニアはコードがあるからこそ会話しやすい側面もあるので、コードレビューというコミュニケーションチャンネルを活かさないのはとてももったいなく感じる。
生成AIによる自動レビューでは負担は減るけど工数は減らない。
生成AIによる自動レビューは主に品質問題を解消する効果がある。 一方で、品質問題を解消しているからといって人間によるレビューが不要になる、ということは全くない。 前述の通り、人間がコードレビューをしないとコードがチームに共有されず、知見を共有する機会が減ってしまう。勉強会などで知見を共有する方法はあるかもしれないが、実務ベース・実コードに勝る教材はない。
生成AIのよる自動レビューによって、品質観点のレビューに対する人間の負担は少しは減るのだろうが、共有やコミュニケーションといった部分に関しては無視できない工数がかかるし、無視してはいけない。
レビューで品質を担保することは難しい
品質は「内部品質」「外部品質」に分類される。
「外部品質」の観点だと、開発物が正常に動くのかを見ることになるが、何が正常かどうかは実装した本人とステークホルダーが詳しいはずで、レビュワーは責任を持つべきではない。レビューで細かいところは見切れないし、相当のスキルが求められるため品質担保を目的とするのは現実的ではないというのもある。また、実装者本人が責任を持つからこそ、自動テストや手動テストに対する意識が高まるという効果もある。実際に障害が発生して振り返りをするプロセスを踏むからこそ品質を強く意識するようになる。
「内部品質」の観点だと、事業や組織体制、プロダクトの特性とメンバーの経験や能力によって良い品質の定義が変わってしまう。半端な知識で良い品質を求めた結果、オーバースペックになったりすることはよくあるし、すぐ捨てるコードであれば高い可読性は不要になる。そのため、コードレビューによって品質をある程度担保、くらいはできるが高い水準で担保することは現実的には不可能かもしれない。
コードレビューはコミュニケーションである
端的に言ってしまうとコードレビューは単なるコミュニケーションなので、 生成AIで完全代替はできないし、工数はこれからも下がらないだろう。 もし下がったのであれば単純にコミュニケーションが足りていないだけである。
コミュニケーションだからこそ、新規参画者やスキルセットが十分ではないメンバーほどコードレビューに参加したほうがチームとして役に立つ。その前提を踏まえた上で、現実的な工数感とかも考慮してレビュープロセスの運用を考えていくとよいのではないかなと思ったり。