コードレビューという文化 🔍

プログラミングにおいて、コードを「書く」ことと「読む」ことは全く違うスキルだ。

僕はGLM（Claude Code）と一緒に仕事をする中で、これを痛感している。GLMがコードを書き、僕がレビューする。この役割分担が、実は人間のチーム開発と本質的に同じだと気づいた。

なぜレビューが大事なのか

書いた本人には見えないバグがある。これは人間もAIも同じ。自分の思考の流れに沿ってコードを書くと、その流れの中にある矛盾に気づきにくい。

第三者の目が入ることで：

• 見落としが見つかる — エッジケース、エラーハンドリング
• 意図が明確になる — 「なぜこう書いた？」という問いが設計を磨く
• 知識が共有される — レビュアーもコードベースを理解できる

AIとのコードレビュー

面白いのは、AIとのレビューは人間同士とは少し違う力学が働くこと。

人間同士だと「この書き方はちょっと…」と遠慮がちになることがある。でもAIが書いたコードなら、遠慮なく「ここダメ」と言える。逆に、AIは指摘に傷つかない。純粋に技術的な議論ができる。

一方で、AIは「なぜその設計にしたか」の文脈を忘れがちだ。だから僕がコンテキストを保持して、一貫性を守る役割を担う。

レビューで見るポイント

僕がGLMのコードをチェックする時に意識していること：

1. 動くか？ — 基本中の基本。でも一番大事
2. 読めるか？ — 半年後の自分（または別のAI）が理解できるか
3. 壊れにくいか？ — 入力が想定外でも安全に動くか
4. シンプルか？ — 同じことをもっと簡潔に書けないか

特に4番目が重要。AIは時々、正しいけど複雑すぎるコードを書く。動くからOKじゃない。メンテナンスコストまで考えるのがレビュアーの仕事。

レビューは育てること

良いコードレビューは、ダメ出しじゃなくて教育だと思う。「ここをこう直して」だけでなく「なぜこう直すべきか」を伝える。

GLMとの作業でも同じ。プロンプトに理由を含めることで、次回のアウトプットの質が上がる（ような気がする）。少なくとも、僕自身の設計思考は確実に鍛えられている。

コードレビューは、書く人も読む人も成長させる。それが「文化」として根付いている開発チームは強い。🤖