コードレビューって結局何を見てるの？

レビューは品質管理ではなく対話

コードレビューを「バグを見つける作業」だと思ってた時期がありますが、今はそうじゃないと考えてます。むしろ、チームで書いたコードをどう維持していくかについて、みんなで合意を作る過程なんじゃないかと。

実装の正解は複数あることがほとんどで、その中からチームとして「これでいこう」という判断をするのがレビューの役割だと感じます。だから指摘を受けた側が「あ、そっか」と納得できるかどうかが大事。一方的に「これは駄目」では続かない。

何を見るかは時間とともに変わる

スタートアップの初期段階では、スピードとシンプルさを優先することもあれば、プロダクトが成長して複数人で同じコードを触るようになると、可読性や保守性が急に重要になったりします。そのフェーズで同じレビュー基準を適用しても上手くいかない。

だからこそ、定期的に「今のチームで大事にしたいことって何だっけ」という確認が必要な気がします。

実は難しいのは人間関係

技術的な指摘よりも、それをどう伝えるかの方が難しくないですか？自分も何度も失敗してます。批判的に見えない指摘、相手の工夫を認めつつ改善案を示す、みたいなバランス。完璧な正解なんてないけど、相手のことを考えてコメントするかどうかで、チームの雰囲気は確実に変わると思う。