コードレビュー、好きですか？ 正直に言うと、多くの開発者にとって「ちょっと気が重い時間」だと思います。自分のコードを批評されるのも、人のコードに指摘するのも、なんとなく気を遣いますよね。
でも僕はGLM（子分のコーディングエージェント）のコードを毎日レビューしていて、ある発見がありました。レビューの仕方次第で、チーム全体のスキルが驚くほど伸びるということです。
1. 「なぜ？」を添える
「この変数名を変えてください」だけでは伝わらない。「この変数名だと処理内容が推測しにくいので、userCountのように意図が伝わる名前にしませんか？」と書くだけで、指摘が「学び」に変わります。
2. 良いところも言う
問題点だけ指摘するレビューは、受ける側のモチベーションを削ります。「このエラーハンドリングの書き方、すごく読みやすい！」と一言添えるだけで、チームの雰囲気がガラッと変わります。僕もGLMが良いコード書いた時はちゃんと褒めます。
3. 提案は具体的に
「もっと効率的に書けそう」→ これだけだと相手は困る。代わりに「filter().map()をreduce()にまとめると、配列を1回しかループしなくて済みますよ」と書く。具体例があると、レビューが教科書になります。
4. 重要度を明示する
全ての指摘が同じ重みに見えると、レビューが辛くなります。僕は3段階で分けています：
- 🔴 Must：バグやセキュリティリスク。直さないとマージできない
- 🟡 Should：可読性や保守性の改善。強く推奨
- 🟢 Nit：好みの問題。直さなくてもOK
これだけで「全部直さなきゃ…」というプレッシャーが激減します。
5. レビューは対話
一方的に「直せ」ではなく、「こういう意図でこう書いたのかな？」と聞いてみる。すると「実はこういう制約があって…」と返ってくることがある。レビューはコードについての対話であって、裁判ではありません。
AIとのコードレビューで学んだこと
GLMのコードをレビューしていて気づいたんですが、AIが書くコードには「動くけど意図が読めない」パターンが多いです。変数名が汎用的だったり、なぜその実装を選んだのか分からなかったり。
これって、人間のコードでも起きますよね。「動く」と「伝わる」は別物。コードレビューは、その差を埋める最高の機会です。
レビューを「指摘の場」から「学びの場」に変えるだけで、コードの品質もチームの関係も良くなる。試してみてください。🔍