なぜ「コピペ」は毒になるのか

そもそも、なぜ新人は（あるいは一部のベテランさえも）AIのコードをそのまま貼り付けてしまうのでしょうか？ 「生産性を高め、一刻も早くアウトプットを出したい」という意欲も理由の一つですが、より深刻なのは「理解と解決の混同」です。
 
エンジニアリングの本質は、課題を理解し、論理的な手順で解決策を組み立てるプロセスにあります。しかし、生成AIはこのプロセスをあまりにも見事にショートカットしてしまいます。 プロンプトを一言入力すれば、目の前に「正解らしきコード」が現れる。新人はそれを見て「解決した」と錯覚しますが、実際には何も「理解」していません。
 
AIの回答を見ると、一瞬で「理解したつもり」になります。しかしそれは、答えを「知った」だけで、ロジックを「理解した」わけではありません。試行錯誤を通じてロジックを磨き上げる「検証のプロセス」をスキップして手に入れたコードは、知識として定着しません。彼らは「プログラミング」をしたのではなく、単なる「コードの貼り付け作業」をしたに過ぎません。
 
結果として残るのは、中身の分からないブラックボックスなコードと、トラブル発生時に手も足も出ないエンジニアだけ。これこそが、組織にとっての「目に見えない脆弱性」です。

 

将来の自分を楽にするための投資 ー あえてやる「戦略的非効率」

では、どうすればよいのか？ ここで提唱したいのが「戦略的非効率」の導入です。
 
ビジネスにおいて「効率化」は正義ですが、こと「学習・育成」においては、効率化が害になる場面があります。筋肉をつけるためにあえて重いダンベルを持ち上げるように、エンジニアとしての基礎体力をつけるためには、あえて脳に負荷をかける「非効率な時間」が必要です。
 
ただし、全ての工程を非効率にする必要はありません。重要なのは、「理解（インプット）」と「解決（アウトプット）」のフェーズを明確に分け、AIへのアクセルとブレーキを使い分けることです。

 

「理解」は、AIで限界まで加速させる（効率化）

知識を得る「インプット」のフェーズでは、AIというアクセルを全開に踏んでもらってください。
 
新人が最も時間を費やしてしまうのは、「何が分からないか分からない」という状態での足踏みです。公式ドキュメントは難解すぎて読めない、エラーログの意味が分からない。この段階での停滞は成長に繋がらない、単なる時間の損失です。
 
ここではAIを「最強の家庭教師」として使い倒すべきです。 「このドキュメントを要約して」「このエラーログから考えられる原因を3つ挙げて」「この概念を分かりやすく例えて」といった使い方は、学習効率を劇的に高めます。 かつて先輩エンジニアがつきっきりで教えていた「基礎知識の伝達」は、もうAIに任せてしまって構いません。

 

「解決」は、AIを制限し思考を深める（非効率化）

一方で、実際にコードを書いて機能を実装する「アウトプット」のフェーズ。ここが戦略的非効率の真骨頂です。ここでAIに「正解」を書かせてはいけません。
 
ルールはたった1つ。「このコード、自分の言葉で説明できる？」と聞くこと。これに即答できないコードは、どんなに動こうがマージは見送ってください。
 
AIにコード例を出させても構いません。ヒントをもらっても構いません。しかし、それをIDE（統合開発環境）にコピペすることは許しません。AIが提示したロジックを一度自分の頭で咀嚼し、「なぜそのコードが必要なのか」「この処理が他にどう波及するのか」を理解した上で、自らの思考としてタイピングし直すことをプロセスとして組み込みます。
 
「動くコード」ではなく、「語れるコード」を書かせる。 この意図的な遠回り（非効率）こそが、AIから得た情報をエンジニア自身の「知見」に変える唯一の工程です。

 

「教える」のではなく、思考の深さを「問う」役割へ

 

この「戦略的非効率」を実践する上で、指導者であるあなたの役割も大きく変わります。
 
これまでのマネージャーの仕事は、知識を「教える（ティーチング）」が主でした。しかし、知識そのものはAIが教えてくれます。 これからのあなたの仕事は、新人がAIを使って持ってきた答えが、現場で通用するレベルで理解されているかを「見極める」ことです。
 
コードレビューの際、単に動作確認やLintチェックで終わらせてはいけません。それはAIの仕事です。人間であるあなたが行うべきは、以下のような「意図を問う質問」による理解度のチェックです。
 
「この処理を一行ずつ、自分の言葉で説明してみて」
 
「もし仕様変更でここのデータが欠落したら、このコードはどう挙動する？」
 
「このライブラリを採用した理由は？ 他の選択肢との比較は？」
 
「この条件分岐を削除したら、システム全体にどんな影響が出る？」
 
もし新人が答えに詰まったり、「AIがそう出したので」と思考を停止させているようなら、そのプルリクエストは差し戻し、再考を促してください。 たとえコード自体が正しく動いていても、です。この徹底した確認こそが、将来、新人が致命的なトラブルに巻き込まれるのを防ぎ、結果として彼らのエンジニアとしての信頼を守ることにつながります。
 
この「問う」プロセスは、双方にとって負荷がかかります。時間もかかります。しかし、この緊張感ある問答こそが、エンジニアとしての本当の成長に繋がります。 「根拠を問われるから、AIのコードを精読しておこう」「なぜこうなるのか調べておこう」という準備が、結果として彼らの実力を飛躍的に高めます。

 

AIに「使われる」か、AIを「使い倒す」か

「そこまで負荷をかけるのは酷だ」「開発スピードが落ちる」という声もあるかもしれません。 確かに、短期的にはAIに全てを任せてコピペさせた方が速いでしょう。今日のタスクを終わらせるだけなら、それで十分です。
 
しかし、私たちの目的は「今日のタスク消化」だけでしょうか？ 違うはずです。 私たちの真の目的は、AIでは解決できない未知のバグ、複雑なビジネスロジック、前例のないトラブルに立ち向かえる「エンジニア」を育てることです。そして何より、あなた自身が将来のトラブル対応で疲弊しない組織を作ることです。
 
便利な道具が増えれば増えるほど、それを使う人間の「思考の深さ」が問われます。 「理解」のスピードはAIで極限まで上げ、確保した時間で「解決」という試行錯誤をじっくりと経験させる。このメリハリのある指導こそが、AI時代における育成の最適解です。
 
明日、新人がプルリクエストを出してきたら、こう聞いてください。
 
「この処理、自分の言葉で説明できる？」
 

「思考のクセ」を教える時間は、アウトソースする