AI 時代の新人育成

今の新人は、最初から AI を使える環境で育ちます。

これは、受け入れ側にとって育成の前提が変わったということです。 そして、まだ誰も正解を持っていません。

「使わせないほうが力がつくのでは」
「いや、使えないと現場で戦力にならない」
「そもそも、どこまで自分でやったのか分からない」

この章では、判断すべきことを整理します。 結論を押し付けるのではなく、チームで決めるための材料を並べます。

何が変わったのか

変わったこと

□ 「動くコードを書く」までの時間が、劇的に短くなった
□ 知らない言語・フレームワークでも、すぐ書き始められる
□ エラーメッセージの意味が、その場で分かる
□ 「調べ方が分からなくて止まる」が減った

新人の初速は、明らかに上がっています。

変わらなかったこと

□ 業務のルールは、AI は知らない（ドメイン知識）
□ 社内の経緯・制約・暗黙の前提も知らない
□ 「なぜそう作るか」の判断はできない
□ 障害時に、実際に手を動かして直すのは人間

つまり、変わったのは「作業」で、変わっていないのは「判断」です。

新しく生まれた問題

新人が PR を出す → 動く → テストも通る
→ レビューで「ここはなぜこう書いたんですか」
→ 答えられない

もう1つ、見落とされやすい変化があります。

□ 「詰まる」経験が減った
□ 詰まりから学ぶ機会も、同時に減った

デバッグ力・調査力は、詰まった経験の量でしか育ちません。 初速が上がったぶん、この部分が育たないまま数ヶ月が過ぎることがあります。

まず決めること

1. 使わせるかどうか

禁止は、現実的な選択肢ではありません。

□ 学生時代から使っている
□ 禁止しても、個人の端末で使う（かえって情報漏洩のリスクが上がる）
□ 使えないまま現場に出ると、周囲との速度差が開く

「使わせる。ただし条件と範囲を決める」が現実的です。

2. どのツールを、どのアカウントで

□ 会社が契約したツールのみか
□ 個人アカウントの利用は禁止か
□ 社内コード・顧客データを貼ってよい範囲はどこまで
□ 生成物のライセンスと権利の扱い

これは初日に明示してください（第2部・契約・労務・情報の扱い）。 新人は「良いこと」だと思って便利に使います。悪意はありません。

3. どこで使わせて、どこで使わせないか

これが、この章で最も重要な判断です。

✕ 「デバッグに AI を使うな」
○ 「まず15分は自分で切り分けて、それから使っていい」

教え方をどう変えるか

課題の出し方

✕ 「この機能を実装してみて」        → AI が数分で書く。学びが少ない
○ 「この機能を実装して、設計判断を3つ説明して」
○ 「この既存コードがなぜこうなっているか調べて説明して」
○ 「この障害を再現して、原因を特定して」

「作れるか」ではなく「説明できるか・見つけられるか」を課題にすると、 AI があっても学びが残ります。

レビューで聞くこと

□ 「ここはなぜこの書き方にしたんですか」
□ 「この処理、データが10万件になったらどうなりますか」
□ 「エラーになるのはどんな時ですか」
□ 「このライブラリを選んだ理由は？ 他の選択肢は見ましたか」

答えられなければ、そこが学ぶべき場所です。 責める必要はありません。「じゃあ一緒に見てみようか」で十分です。

✕ 「これ、AI に書かせたでしょ」

○ 「どうやって作った？ 途中で迷ったところある？」

理解度をどう測るか

アウトプット量で測れなくなったぶん、別の測り方が必要です。

□ 説明させる（私が知らない人だと思って説明して）
□ 図を描かせる（第3部）
□ 変更の影響範囲を聞く（「これを変えたら、どこが壊れますか」）
□ 障害対応をさせてみる（実際に切り分けられるか）
□ 質問の質を見る（第3部）

特に「影響範囲を聞く」は有効です。 コードを理解していないと、絶対に答えられません。

AI で育成が楽になる部分

悪い面ばかりではありません。受け入れ側の負担も減ります。

□ 用語の説明を、その場で自分で調べられる
□ 「こんな初歩的なことを聞いていいのか」の心理的ハードルが下がる
□ コードを読む時の補助になる（第3部のコードツアーの後）
□ ドキュメントの下書きが速い

□ 業務のルール         → 人にしか聞けない
□ 社内の経緯・判断      → 人にしか聞けない
□ 「これ変じゃないですか」→ 人にしか言えない

評価への影響

□ 「たくさん実装した」は、以前ほどの意味を持たない
□ 「理解している」「判断できる」「説明できる」の比重が上がる
□ 「AI を上手に使えている」こと自体も、評価対象になりうる

「実装の速さより、
 なぜそうしたかを説明できることを見ています」

チームで決めておくこと

□ 使ってよいツールとアカウント（初日に明示）
□ 貼ってよい情報の範囲（社内コード・顧客データ）
□ 生成物の扱い（レビュー必須・ライセンス確認）
□ 「まず自分でやる」時間の目安（デバッグ15分、など）
□ レビューで理解度を確認する運用
□ 評価で何を見るか

これらは、AI に限らず「チームの決めごと」として扱ってください。 新人だけのルールにすると、守られませんし、不公平感も生まれます。

この章のまとめ

• 変わったのは作業であって、判断は変わっていない
• 新しい問題は**「動いているが、説明できない」状態**。 アウトプットで理解度が測れなくなった
• 詰まる経験が減ったぶん、デバッグ力と調査力が育ちにくい
• 禁止は現実的でない。「使わせる。ただし条件と範囲を決める」
• 「使うな」ではなく「順番を決める」 （まず15分は自分で）
• 課題は「作れるか」ではなく**「説明できるか・見つけられるか」にする**
• 「AI を使ったか」を問い詰めない。隠されると測れなくなる。 聞くべきは理解しているかだけ
• 理解度は説明・図・影響範囲・障害対応・質問の質で測る
• 人に聞く経験は、意図的に確保する
• 評価基準（説明できること）を先に伝える

参考資料