学生から、既存プロジェクトのチーム開発研修にAIコードレビューを活用したい、という相談を受けた。

Gemini Code AssistやCodeRabbitのようなツールを使えば、人間が見落とした問題を見つけたり、レビューの負担を減らしたりできるかもしれない。 新人にとっても、自分だけでは気づけない問題を知る機会になるだろう。

ただ、AIの指摘どおりにコマンドを実行し、修正を反映するだけで研修になるのだろうか。

AIレビューによってコードは良くなる。では、そのコードを書いた人も成長するのか。

AIを使わなくても学ばないことはある

新人がAIを使うには、事前知識が必要ではないか。最初はそう考えた。

知識がなければ、AIの指摘が正しいか判断できない。 理由を理解しないまま修正しても、次に似た問題が起きたとき、自分で気づけるとは限らない。

一方で、この問題はAIが登場する前からあった。

先輩から「このコマンドを実行して」「ここをこう直して」と指示され、そのとおりに作業する。 コードは直っても、なぜ直したのかは分からない。 AIを使わなければ、自動的に知識が身につくわけではない。

AIを使う人と使わない人の差ではなく、指示を処理して終わる人と、理由を理解しようとする人の差なのだと思う。

AIはその差を生み出すというより、広げる可能性がある。 すぐに具体的な修正案を返してくれるため、理解しなくても作業を先へ進められるからだ。

調べれば分かることと、対話しなければ分からないこと

新人に、すべての文法やフレームワークを覚えてからAIを使ってほしいわけではない。

文法、API、フレームワークの仕様には、公式ドキュメントやAIを使って調べた方がよいものも多い。 バージョンアップによって、以前の知識がそのまま使えないこともある。 覚えていることより、現在の情報を調べ、確かめられることの方が重要な場面もある。

しかし、Gitの運用、プルリクエストの作り方、チーム規約は少し異なる。

一般的な方法は調べられる。 操作手順も見つかる。 それでも、なぜこのチームがその運用を選び、何を守ろうとしているのかは、外部の情報だけでは分からない。

たとえば、コミットを分けるという規約があるとする。

「コミットは小さくする」とだけ覚えれば、不便な決まりに見えるかもしれない。 だが、その目的はコミット数を増やすことではない。 誰が読んでも、後から見返しても、短時間で変更の意図を理解できる状態を目指している。

規約を適用するだけならAIにもできる。 規約によって、誰とのどのような協働を守ろうとしているのかは、人間同士で共有する必要がある。

巨大な一コミットに残る説明の負債

新人が一つの機能を実装し、最後にすべての変更をまとめてコミットしたとする。

新人から見れば、これは自然な流れだ。

実装が終わった。動作も確認した。だから、すべてコミットする。

しかし、そのコミットに機能追加、変数名の整理、フォーマット変更、別のバグ修正が混ざっていたら、レビュアーは変更の意図を分解し直さなければならない。

最終的なコードが動いていても、どの差分が機能追加に必要なのか分からない。 問題が起きたとき、どの変更を戻せばよいのかも判断しにくい。 実装者が整理しなかった思考を、レビュアーや未来の担当者が復元することになる。

これは、説明の負債と言えるかもしれない。

読みにくいコードが理解の負担を未来へ残すように、巨大な一コミットも変更を読み解く負担を未来へ残す。

ブランチやコミットは、作業を保存するためだけのものではない。

ブランチは、何を目的とした変更なのかを区切る。 コミットは、なぜこの変更をひとまとまりにしたのかを伝える。 プルリクエストは、変更の意図をチームへ説明する。

コードだけでなく、変更履歴も読みやすくする必要がある。

AIが読めることと、人間が読みやすいことは違う

AIコードレビューは、大きな差分からも個別の問題を見つけられるかもしれない。 それ自体は便利なことだ。

一方で、AIが巨大な差分を読み解いてくれるほど、新人は変更を説明可能な単位へ分けなくても作業を進められる。

AIが解析できるから、このコミットの分け方で問題ない。 そのように考えてしまえば、人間が読みやすい変更を作る経験は減っていく。

AIにコミットを分割してもらえば解決する、という話でもない。 AIが分けた結果をそのまま採用するだけなら、どの変更が同じ意図に属するのかを新人自身は判断していない。

AIがコードを読めることと、人間が短い時間で変更の意図を理解できることは別の問題だ。

チーム開発の研修で身につけてほしいのは、AIが処理できる差分を作る力ではない。 自分の変更を、他者が理解できる形に編集する力だと思う。

答えを出す前に、説明を求める

研修でAIレビューを使うなら、最初から答えを見せるのではなく、新人が一度判断した後に使うのがよいのではないか。

たとえば、次の順序が考えられる。

  1. 新人が自分で変更を見返す
  2. ブランチの目的と、各コミットを分けた理由を書く
  3. AIでレビューする
  4. 自分の判断とAIの指摘を比較する
  5. 指摘を採用するか決め、その理由を説明する
  6. 人間がコードと判断過程をレビューする

AIの役割は、修正を完成させることだけではない。

  • 「このコミットには別の目的が混ざっていないか」
  • 「フォーマット変更は、機能追加と同じコミットである必要があるか」
  • 「このブランチの目的を一文で説明できるか」

このように問い返すこともできる。

新人が自分で考え、AIが説明の足りない部分を問い、人間がプロジェクト固有の意図を伝える。 AIを人間の代わりとなるレビュアーではなく、対話を始めるための相手として置く。

AIレビューの導入だけでは、レビュー教育にはならない。 いつ使うのか、何を説明させるのか、誰が最後に判断するのかまで決める必要がある。

判断する経験を新人に残す

以前、学びを奪わない支援の設計 で、支援は親切であればあるほどよいとは限らないと書いた。

入口が分からなければ挑戦できない。 しかし、すべての手順と答えを渡せば、自分で調べ、仮説を立て、失敗する経験を奪ってしまう。 AIコードレビューにも、同じことが言える。

AIは、知らないことを学ぶ入口になれる。 人間が見落とした問題を示し、別の考え方を知る機会も作れる。

ただし、AIの指摘を反映して終わる研修では、コードが直っても、レビューを判断する力は残らない。

AIが学びを奪うのではない。

考える前に答えを示し、判断までAIへ委ねる支援の設計が、学びを奪うのだと思う。

巨大な一コミットを見たとき、AIに分割してもらうだけで終わらせない。 なぜ分けるのか、誰が後から読むのかを新人自身に考えてもらう。

AIを使っても、変更の意図を説明し、最後に判断するのは新人である。 その経験を残せるなら、AIは学びを奪わない支援者になれるはずだ。

関連記事