海外の開発者コミュニティで、あるマネージャーの投稿が大きな反響を呼びました。
「最近採用したジュニアエンジニア3人が、自分のプルリクエストを説明できない」という内容です。
彼らはAIツールを駆使し、機能を素早く実装する。
テストも通る。
コードの見た目も問題ない。
ところがPRレビューで「なぜこの構造にしたの？」「Xがnullだったらどうなる？」と質問すると、答えられない。
あるジュニアは、エラーハンドリングについて聞かれました。
返答は「Claudeがこのパターンを提案した」というもの。
そのパターンが何をしているのか、なぜ優れているのかは説明できなかったそうです。
別のジュニアは、複雑な非同期処理を完璧に実装しました。
しかし、タイムアウト処理の追加に4時間もかかった。
理由は、Promiseの仕組みを理解していなかったからです。
この投稿は多くの共感と議論を生みました。
さまざまな視点からの意見も寄せられています。
本記事では、この議論の内容を整理しながら、AI時代のエンジニア育成について考えてみます。
「動くコード」と「理解しているコード」は別物
この問題の核心は、コードの品質ではありません。
理解の不在です。
AIが生成したコードは、多くの場合そのまま動きます。
テストも書ける。
パターンも適切。
でも、書いた本人がそのコードの意図を把握していなかったら？
仕様変更が入ったとき、修正箇所の判断がつきません。
本番環境で障害が発生しても、原因の推測すらできない。
結局、AIに「このエラーを直して」と再度プロンプトを投げることになります。
投稿者自身もこう述べていました。
彼らはAIなしではデバッグできない。 自分のコードを説明できない。 プロンプトを再入力しないと何も変更できない
これは能力の問題というより、学習プロセスの断絶と言えるのではないでしょうか。
「プロンプトオペレーター」と「エンジニア」の境界線
投稿者の言葉で、特に印象的だったフレーズがあります。
「私たちは気づかないうちに、エンジニアではなくプロンプトオペレーターを育成しているのかもしれない」
エンジニアの価値は、コードを書く速度ではなく判断力にあります。
この設計で本当にスケールするか。
このエラー処理で漏れはないか。
なぜこのパターンが適切なのか。
こうした問いに、自分なりの回答を持っていること。
それがエンジニアとしての基盤です。
AIはこの基盤の構築を加速させるツールにもなり得ます。
しかし同時に、基盤の構築を完全に迂回させるツールにもなり得るのです。
ある開発者は、入社後にAIツールを渡されたものの、あえてエージェントモードの使用をやめたと語っていました。
「数秒でコードの制御を失う感覚があった」と。
そこから自分でコードを書く方針に切り替えたそうです。
AIは同僚のように質問を投げかけたり、ディスカッションする相手として使うようになった。
結果として、設計を考えるようになり、プロジェクトへの理解も深まったとのこと。
ただし、この自制心をすべてのジュニアに期待するのは現実的でしょうか。
テストが通り、PRが承認されれば「成功」に見える。
そんな環境で、あえて遠回りを選ぶ人はどれくらいいるのか。
組織としてのガードレールが必要になる理由は、ここにあります。
速度を評価する組織が生む構造的な問題
この議論で見落とせないのは、組織側の責任です。
あるジュニアエンジニアは、こんな現実を打ち明けていました。
自分の会社ではAIの利用が義務付けられている。 使わなければ評価が下がる。 手書きでコードを書けば学びは増える。 でも、周囲より遅くなり『パフォーマンスが低い』と見なされる。 そのリスクは負えない
これは個人の怠慢ではありません。
組織のインセンティブ設計が生み出した、構造的な問題です。
アウトプットの量だけで評価し、理解度を問わなければどうなるか。
合理的な人間は、速度に最適化します。
その結果、学習が静かに止まる。
そしてギャップが顕在化するのは、デバッグ時やインシデント対応時、要件変更時です。
つまり、最も理解が求められる場面で初めて問題が表面化するわけです。
投稿者はこう指摘していました。
速度が唯一のシグナルであれば、人は自然にアウトプットと引き換えに学習を手放す。 長期的に見ると、それは脆弱なエンジニアと脆弱なシステムを生む
AIツールの禁止は正しいアプローチか
「ジュニアからAIツールを取り上げるべきか」という問いに対して、議論は二分しました。
禁止派の主張は明快です。
制約こそが成長を促す。
AIがなければ、自分で考えざるを得ない。
基礎体力をつける期間には、ツールの制限が有効だという考え方です。
投稿者自身も「AIを一時的に制限するのは罰ではない。
基礎を叩き込むためのトレーニングだ」と述べています。
一方、禁止に反対する意見も根強い。
ツールを奪えば、公開版のAIサービスに社内コードを貼り付けるリスクが生まれます。
セキュリティ面で逆効果になりかねません。
また、ジュニアだけにツールを禁止すれば、チーム内に不公平感が広がるという懸念も出ていました。
より現実的なアプローチとして、複数の開発者が推していたのが「説明責任の導入」です。
あるシニアエンジニアのやり方が参考になります。
そのチームでは、PRのコードからランダムに行を選び、「この行は何をしている？」と質問する運用を取り入れていました。
説明できなければ、PRはChanges Requestedに戻る。
すべての行を説明するウォークスルーが完了するまで、マージはされません。
この運用を早期から導入した結果、説明できないコードが提出されるケースは激減したそうです。
チームの障害率も、他チームの3分の1以下に抑えられたとのこと。
ツールを禁止するのではなく、理解を証明する仕組みを作る。
この発想は、シンプルながら強力です。
ジュニアを「書き捨て」にしない
議論の中で、厳しい意見もありました。
「彼らは開発者じゃない」「即クビにすべき」といったものです。
でも、投稿者自身はこうした意見に同意していません。
彼らは動くコードを書けるし、学習も速い。 問題は知性や努力ではなく、フィードバックループが壊れていることだ
ジュニアは本来、学びながら成長する存在です。
説明できないコードを書いている段階は、「まだ学習が完了していない」だけの話。
育成不可能を意味するわけではありません。
あるコメントが、この点をうまくまとめていました。
ジュニアを技術力で採用したわけじゃないでしょう。 学ぶ力とその意欲で採用したはず。 だったら、学べる環境を整えるのはシニアの仕事だ
AIツールが登場する前も、ジュニアは先輩に質問し、ドキュメントを読み漁っていました。
自分なりのアプローチを提案して、フィードバックを受ける。
その試行錯誤のプロセスが、メンタルモデルの構築に繋がっていたのです。
AIはこのプロセスをショートカットできてしまう。
だからこそ、組織が意図的にそのプロセスを設計し直す必要があります。
具体的な対策
議論から見えてきた実践的なアプローチを、いくつか紹介します。
まず、ペアプログラミングセッションをAIなしで実施する方法です。
目的はコードを書く力の測定ではなく、問題を分解する力や思考プロセスの観察にあります。
ジュニアの現在地を正確に把握するのに役立つでしょう。
次に、PRの説明文を本人の手で書く運用も効果的です。
AIが生成した要約ではなく、自分の言葉で「何を変更し、なぜそうしたか」を記述させる。
小さなPRで始めれば、負担も少なく済みます。
コードレビューの質問を、教育的に設計するアプローチも有効でしょう。
「なぜこうした？」という質問は、ミドル以上には適切です。
しかし、ジュニアにはハードルが高い場合もある。
「XよりYを使ったのはZの理由から？」のように、誘導しながら思考を促す質問のほうが効果的です。
そして、評価基準にコードの説明能力を含めること。
「動くコードを書いた」だけでなく「そのコードについて質問に答えられた」も評価の一部とする。
こうすれば、理解を伴わないアウトプットへのインセンティブが弱まります。
コンパイラとAIの違い
議論の中で、興味深い反論がありました。
「バイトコードやアセンブリの書き方を説明できますか？コンパイラがなぜそうコードを生成するか分かりますか？」というものです。つまり、AIもコンパイラと同じ抽象化ツールではないか、と。
これに対するある開発者の回答が秀逸でした。
コンパイラは、プログラミング言語のメモリモデルと実行モデルに基づき、決定論的に動作します。
もし期待通りに動かなければ、それはバグであり修正すべきもの。
コンパイラは機械語レベルの思考を不要にするために、意図的かつ厳密に設計された抽象化ツールだ、と。
一方、LLMはパターン認識システムです。
間違いを起こし得る構造を内在しています。
コンパイラのバグは開発者の責任ではない。
しかし、LLMの出力に基づくミスは、それを採用したエンジニアの責任になります。
だからこそ、出力を検証し理解する能力が求められるのです。
この区別は、AIツールとの正しい付き合い方を考える上で非常に重要でしょう。
まとめ
この議論が示しているのは、AIツールそのものの善悪ではありません。
学習プロセスの設計が追いついていないという現実です。
AIは開発の生産性を高める強力なツールです。
ただし、そのツールが思考の代替として使われたとき、エンジニアの成長は止まります。
コードは動く。
でも、誰もそのコードを理解していない。
短期的には問題なく見えても、長期的には大きなリスクとなるでしょう。
鍵となるのは、「コードを書く」ことと「コードを理解する」ことを分けて捉えること。
そして、後者を組織として求め続けることです。
AIの使用を禁止する必要はありません。
理解を証明する仕組みを導入すればよいのです。
説明できないコードはマージしない。
このシンプルなルールだけで、学習のフィードバックループは回り始めます。
エンジニアの価値は、コードの生成速度ではなく、判断力と説明能力にあります。
AIがどれだけ進化しても、この本質は変わらないはずです。
