TL;DR
- AIに丸投げするサイクルでは、若手の成長機会が失われやすい
- これは「若手の意欲の問題」ではなく、 育成設計の問題
- 同じAI利用でも、 学べる使い方 と 学べない使い方 がある
- 上司・PM側が学習機会を意図的に設計する責任がある
対象読者
- 新人・若手エンジニアの育成を担うPM・テックリード
- 自分のチームの伸び悩みが気になっている方
- AI時代のエンジニア教育に関心がある方
はじめに
エンジニア育成の前提が、AIによって明確に変わりました。
少し前までは、若手エンジニアは 「分からないことを調べながら、四苦八苦して動くコードを書く」 という過程を通じて成長していました。エラーを読み、ドキュメントを漁り、Stack Overflowを彷徨い、何度も失敗しながら自分なりの引き出しを増やしていく。これが標準的な育ち方でした。
AIの登場で、この過程はほぼスキップ可能になりました。プロンプトを投げれば動くコードが返ってくる。便利である一方、 この試行錯誤の過程そのものに学習効果があった という事実を、私たちは改めて考え直す必要があると感じています。
本記事は「AIを使う若手」を批判する記事ではありません。育成する側であるPM・上司の責任として、この問題をどう設計するかを考える記事です。
起きていること
最近の現場でよく見る仕事の流れです。
このサイクル、 動くコードは速く出来上がります。短期的には成果も出ているように見える。しかし、若手側に残る学びは限定的です。
数ヶ月後、 「動いているコードが、なぜ動いているか説明できない」 という状況になります。
若手側の事情を考える
ここで一度、若手側の立場に立ってみる必要があります。
多くの記事は「最近の若手はAIに頼りすぎ」という論調で書かれていますが、私はこの構図にやや違和感があります。
若手側にも事情があります。
これらを踏まえると、 「AIに頼ってでも早く成果を出す」のは、若手にとって極めて合理的な行動 です。意欲がないわけでも、怠けているわけでもありません。組織が要求している通りに動いているだけです。
問題は若手の心構えではなく、 「AIを使いつつも学べる環境」を育成側が用意できていないこと だと考えています。
何が失われつつあるのか
AIに丸投げするサイクルで失われる能力を、具体的に言語化すると下記のようになります。
1. エラーから情報を抽出する力
エラーメッセージを読み解き、原因を仮説立てる力。AIに「このエラーを直して」と投げると、ここがスキップされます。
2. ドキュメントを読み解く力
公式ドキュメントを読んで「自分のケースにどう当てはめるか」を考える力。AIが翻訳・要約してくれると、原典に当たる習慣が消えます。
3. 「これは動かないだろう」という直感
経験から来る「この書き方は怪しい」という勘。これは数百回の失敗を経験して初めて身につきます。
4. 設計の引き出し
「この場面ではこのパターンが使える」というストックは、自分で考えて失敗してきた人にしか溜まりません。AIが出力する設計を 理解せずに採用する だけでは育ちません。
これらは、 AIに代替させると育たない能力 です。そして、これらが欠けたエンジニアは、AIが間違ったとき・予想外の挙動をしたときに対処できません。AI時代だからこそ、これらの基礎能力の価値はむしろ上がっています。
「学べるAI活用」と「学べないAI活用」の違い
AIを使うこと自体は、もはや避けられません。ただし、 同じAI利用でも、学習効果には大きな差 があります。
左側の使い方であれば、AIは 強力な学習補助ツール になります。むしろAI以前より速く、効率的に学べる可能性すらあります。
問題は、 左側の使い方を自然にできるようになるには訓練が必要 であり、誰も訓練を設計していないことです。
PM・上司側のジレンマ
ここで、育成する側であるPM・上司の本音にも触れておきます。
正直に書くと、PM・上司側にもジレンマがあります。
この構造の中で、 「学べる使い方を訓練する時間を確保する」 のは、現場任せでは無理です。組織として 学習時間を業務時間として認める意思決定 が必要です。
つまり、これは個人の問題ではなく、 組織としての育成設計の問題 だと捉えるべきだと考えています。
育成設計の提案
上記を踏まえて、PM・上司側ができる具体的な設計を整理します。
1. 学習タスクと業務タスクを分ける
すべてのタスクで「学べる使い方」を要求すると、業務スピードが落ちます。代わりに、 明確に「学習目的」のタスクを業務時間内に確保する のが現実的です。
具体例：
- 月1回、AI禁止の小タスクを設計する
- 新機能の小さい部分を学習用として割り当てる
- 学習時間として週○時間をブロックする
2. レビュー観点に「理解度」を加える
コードレビューで動作確認だけでなく、 「このコード、なぜこの実装にしたか説明して」 と聞く習慣を持つ。説明できなければAIに頼りすぎている合図です。
3. ペアプロでAI使用ルールを明文化する
ペア・モブプロのときに AIを使う場面と使わない場面のルール を決めておく。「最初の30分は仮説立てだけ、その後AIで検証」のような区切りが効果的です。
4. AI以前の知識を伝える機会を作る
ベテランが「AI以前はこう調べていた」を意識的に共有する。エラーの読み方、ドキュメントの探し方、デバッグの考え方など、 明文化されていない暗黙知 を言語化して渡す。
5. 「学べる使い方」をベテランがやって見せる
最も効果的なのは、 ベテラン自身がAIを使って学んでいる姿を見せること です。AIに丸投げではなく仮説を立てて使う、回答を批判的に検証する、こういった行動を育成側が実践していなければ若手も真似できません。
共通する原則
ここまでの提案には共通点があります。
若手の意欲ではなく、組織の構造を変える。
これは前作 「PMが向き合う3つの壁」 で書いた原則と同じです。 相手の能力や性格を変えようとせず、相手が動きやすい構造を作る 。育成も同じで、 若手のマインドを変えようとするのではなく、学べる環境を設計する 方が現実的に効きます。
おわりに
「最近の若手はAIに頼りすぎだ」という意見は、ある意味で正しいです。しかし、その状況を作っているのは若手ではなく、 AIを使うことだけが評価される環境を作ってしまった育成側 だと思っています。
若手の意欲を問う前に、まず自分が育成設計に時間を割いているか。学習機会を業務として認める仕組みを作れているか。AI時代の育成は、そういう問いから始まると考えています。
皆さんの現場では、AI時代の若手育成をどう設計していますか？「こうしている」「こんな失敗をした」など、コメントで共有いただけると嬉しいです。
関連記事
PMが開発者にどう向き合うべきか
PMがステークホルダーにどう向き合うべきか