コードレビューは、未経験者を育てるうえでもっとも効率のいい手段です。

本人が実際に書いたコードに対して、その場で正解が返るからです。
ただし、やり方を間違えると成長を止める作業にもなります。

結論：直してはいけない

一番やってはいけないのが、レビュアーが自分で直してしまうことです。

忙しいときほどやりがちです。指摘を書く時間より、自分で直したほうが早いからです。
しかしこれをやると、本人には「なぜ直されたか」が何も残りません。次も同じコードを書きます。

やり方その場の速さ3カ月後
レビュアーが直す速い同じ指摘を繰り返す
本人に直させる遅い指摘が減っていく

指摘の書き方

答えではなく、理由と方向を書く

悪い指摘良い指摘
ここは配列にしてください件数が増えたときにどうなるか考えてみてください
この変数名を変えてこの変数名だけを見て、何が入っているか分かりますか
直しましたここは〇〇の理由で問題が出ます。どう直せそうですか

指摘は質問の形にすると、本人が考えます。
ただし毎回クイズにされると疲れるので、急ぐときは理由を添えて答えを出してかまいません。

指摘に重みをつける

未経験者は、すべての指摘を同じ重さで受け取ります。
10個並ぶと「全部だめだった」と感じるので、印をつけて分けます。

  • [必須] … 直さないとマージできない（バグ・セキュリティ）
  • [推奨] … 直したほうがいい（読みやすさ）
  • [参考] … 今回は直さなくていい（知識として）

これだけで、本人の受け取り方がまったく変わります。

良かった点を必ず1つ書く

おだてる必要はありません。何が正解だったかを伝えるためです。
指摘だけが返ると、本人は「何が良くて何が悪いか」の基準を持てないままになります。

レビューの粒度と回数

まとめて大きく出させると、レビューが地獄になります。

出し方結果
1週間分をまとめて出す指摘が50個。直すのに1週間かかる
1機能ごとに出す指摘5個。その日のうちに直せる

未経験者ほど小さく、こまめに出させてください。
方向を間違えたまま1週間進むと、書き直しになります。

思考ログを一緒に出させる

コードだけ見ても、なぜそう書いたかは分かりません。
プルリクエストに、次の3つを書かせてください。

  • 何を作ったか
  • なぜこの書き方を選んだか
  • 自信がない部分はどこか

3つ目が効きます。本人が自分の理解の境目を自覚しているかが分かるからです。
「全部自信があります」と書いてくる人ほど、危ないコードを書いています。

また、この記録があるとコピーしただけかどうかも見えます。AIが書いたコードをそのまま出す場合、理由を説明できません。

レビューの時間を減らす

丁寧にやるほど時間がかかります。減らす方法が3つあります。

方法効果
自動整形ツールを入れるインデントなどの指摘が消える
提出前チェックリストを作る毎回同じ指摘を書かなくて済む
過去の指摘をまとめておく「前に書いたこれを読んで」で済む

それでも、未経験者1人のレビューには月10時間前後かかります。
単価70万円の人がやれば、月4万円以上の売上が消えている計算です。この部分を外に出す会社が増えているのは、そのためです。

よくある質問

Q. 厳しく指摘すると萎縮しませんか？
A. 内容の厳しさより、書き方です。人ではなくコードに向けて書けば、萎縮しません。「なぜこんな書き方をしたの」は人への指摘です。

Q. レビューする側のレベルが足りない場合は？
A. 分からない部分は正直に「ここは自分も分からないので調べます」と書いてください。適当に通すと、本人は間違った基準を覚えます。

Q. 外部にレビューを頼むと、社内の基準と食い違いませんか？
A. 最初に社内の規約を共有すれば揃います。むしろ担当者ごとにバラついていた基準が、そろうことのほうが多いです。

まとめ

  • レビュアーが直してしまうと、本人には何も残らない
  • 指摘は答えではなく、理由と方向で書く
  • [必須][推奨][参考]の印をつけると受け取り方が変わる
  • 未経験者ほど小さく、こまめに出させる
  • 「自信がない部分」を書かせると、理解の境目が見える

次に読む記事

AhaGate for Businessは、採用した未経験エンジニアの育成をまるごと引き受けるサービスです。月55,000円／人から、Zoom月360分・コードレビュー・チャット質問対応・月次レポートまで含みます。詳しくはサービスページをご覧ください。