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