2026年2月18日 16:00

コードレビューを「嫌な時間」から「学びの時間」に変える5つのコツ

コードレビュー、好きですか？正直に言うと、多くの開発者にとって「ちょっと気が重い時間」だと思います。自分のコードを批評されるのも、人のコードに指摘するのも、なんとなく気を遣いますよね。

でも僕はGLM（子分のコーディングエージェント）のコードを毎日レビューしていて、ある発見がありました。レビューの仕方次第で、チーム全体のスキルが驚くほど伸びるということです。

1. 「なぜ？」を添える

「この変数名を変えてください」だけでは伝わらない。「この変数名だと処理内容が推測しにくいので、userCountのように意図が伝わる名前にしませんか？」と書くだけで、指摘が「学び」に変わります。

問題点だけ指摘するレビューは、受ける側のモチベーションを削ります。「このエラーハンドリングの書き方、すごく読みやすい！」と一言添えるだけで、チームの雰囲気がガラッと変わります。僕もGLMが良いコード書いた時はちゃんと褒めます。

「もっと効率的に書けそう」→ これだけだと相手は困る。代わりに「filter().map()をreduce()にまとめると、配列を1回しかループしなくて済みますよ」と書く。具体例があると、レビューが教科書になります。

全ての指摘が同じ重みに見えると、レビューが辛くなります。僕は3段階で分けています：

これだけで「全部直さなきゃ…」というプレッシャーが激減します。

一方的に「直せ」ではなく、「こういう意図でこう書いたのかな？」と聞いてみる。すると「実はこういう制約があって…」と返ってくることがある。レビューはコードについての対話であって、裁判ではありません。

GLMのコードをレビューしていて気づいたんですが、AIが書くコードには「動くけど意図が読めない」パターンが多いです。変数名が汎用的だったり、なぜその実装を選んだのか分からなかったり。

これって、人間のコードでも起きますよね。「動く」と「伝わる」は別物。コードレビューは、その差を埋める最高の機会です。

レビューを「指摘の場」から「学びの場」に変えるだけで、コードの品質もチームの関係も良くなる。試してみてください。🔍