はじめに
AWS認定資格を全冠している、いちエンジニアです。
資格の話は今日の本題ではありません。今日書きたいのは、ここ数年で一番「やってしまった」と反省した、新人指導の失敗談です。
数年前まで、新人や後輩にこう言っていました。
「わからないことがあったら、まずAIに聞いてみて」
一見、今どきの正しい指導に見えますよね。私もそう思っていました。
ですが結論から言うと、この一言が新人の成長を止めていました。 そして、伝え方を3つのルールに変えたところ、質問の質が明らかに変わり、半年後の立ち上がり方がまるで違いました。
この記事では、
- なぜ「AIに聞いて」が失敗だったのか
- 代わりに導入した3つのルール（コピペで使えるテンプレ付き）
- 導入前後で何が変わったか
をまとめます。新人・若手を指導する立場の方はもちろん、新人側の方が読んでも今日から使える内容にしたつもりです。
「AIに聞いて」の何がダメだったのか
症状1：質問が来なくなった
AIは怒らないし、何度同じことを聞いても嫌な顔をしません。その結果、新人は人間に質問するコストを異常に高く感じるようになりました。
「先輩の時間を奪うくらいなら、AIともう1時間格闘しよう」
こうして、AIが答えられない種類の問題（社内固有の仕様、暗黙の前提、そもそも問いの立て方が間違っているケース）で延々と沼にハマる新人が生まれました。
症状2：「動いたけど説明できない」コードの量産
AIの提案をそのまま貼って動いた。レビューで「ここ、なんでこの書き方にしたの？」と聞くと、
「AIがこう出したので……」
責める気にはなれません。「AIに聞いて」と言ったのは私だからです。指示どおりに動いた結果がこれなら、悪いのは指示です。
症状3：エラーメッセージを読まなくなった
エラーが出る → 全文コピー → AIに貼る → 出てきた対処を試す → 直らない → また貼る。
このループの中に「自分でエラーメッセージを読む」という工程が存在しません。エラーを読む力は、エンジニアの基礎体力です。ここが育たないのは致命的でした。
代わりに導入した3つのルール
反省して、チームの新人向けに次の3つをルール化しました。どれも紙に書けるくらいシンプルです。
ルール1：「15分ルール」をAI時代版にアップデートする
昔からある「15分悩んだら人に聞け」を、こう作り替えました。
| フェーズ | 時間 | やること |
|---|---|---|
| 第1フェーズ | 〜15分 | AI禁止。 エラーメッセージと公式ドキュメントだけで戦う |
| 第2フェーズ | 〜30分 | AI解禁。ただし「答え」ではなく「調べ方・観点」を聞く |
| 第3フェーズ | 30分超 | 人間に質問する（ここまでの記録を持って） |
ポイントは第1フェーズの「AI禁止タイム」です。たった15分ですが、まず自分の目でエラーを読むという習慣がここで作られます。
そして第2フェーズのAIへの聞き方も指定します。
NG：このエラーを直して
OK：このエラーの原因として考えられる可能性を列挙して。
それぞれ、何を確認すれば切り分けられる？
答えをもらうのではなく、切り分けの観点をもらう。これだけでAIが「答えを出す機械」から「思考の壁打ち相手」に変わります。
ルール2：人間への質問は「質問テンプレート」で来てもらう
第3フェーズで人間に聞きに来るとき用のテンプレートです。チームのWikiに貼ってあり、新人はこれを埋めてから来ます。
## やりたいこと
（1〜2行で。「〇〇画面で△△できるようにしたい」など）
## 起きていること
（エラーメッセージ全文、または期待と違う挙動）
## 試したこと
1. 自力で調べたこと（15分）：
2. AIに聞いた観点と、その結果：
3. その他試したこと：
## 自分の仮説
（間違っていてもいいので「たぶん〇〇が原因だと思う」を書く）
導入時、新人からは「埋めるのが大変」と言われました。ですが1ヶ月後、面白いことが起きます。
テンプレートを埋めている途中で、自己解決するケースが激増したのです。
「試したこと」と「自分の仮説」を言語化する過程は、そのままデバッグの思考プロセスです。これはいわゆるラバーダッキング（ぬいぐるみに説明していたら答えに気づくアレ）と同じ構造で、テンプレートが自動的にそれを強制してくれます。
しかも、埋めた上で来る質問は回答側も30秒で状況を把握できるので、指導コストも激減しました。質問する側・される側の両方が得をします。
ルール3：「AIの回答は、説明できたら採用していい」
AIの利用は一切禁止していません。むしろ推奨しています。ただし1つだけ条件をつけました。
AIが出したコードは、1行ずつ「これは何をしているか」を自分の言葉で説明できたら採用してよい。説明できない行が1行でもあれば、その行について調べるか、質問すること。
これを徹底すると、レビューでの会話がこう変わります。
Before：「AIがこう出したので……」
After ：「ここは〇〇のためにAIの提案を採用しました。
ただ△△の部分は意図が読めなかったので、
□□に書き換えています」
同じ「AIを使ったコード」でも、中身への理解度がまったく違います。そして新人自身も「説明できるまで調べる」過程で、AIの出力を教材として消化できるようになります。
AIを禁止するのではなく、「理解の壁」を1枚だけ挟む。 これが一番効きました。
導入して半年後、何が変わったか
定量的な計測をしていたわけではないので体感ベースですが、変化は明らかでした。
- 質問の数は減り、質の高い質問が増えた。 「これどうすればいいですか」が消え、「〇〇と考えて△△を試したがダメだった。仮説は□□」という質問になった
- エラーメッセージを読んで自己解決する速度が上がった。 第1フェーズの15分が効いている
- レビュー指摘の手戻りが減った。 「説明できるコード」しか上がってこないため
- 指導側の負担が下がった。 テンプレートのおかげで、質問対応が「状況のヒアリング」から「仮説へのフィードバック」に変わった
一番嬉しかったのは、新人本人からの一言です。
「前は『AIに聞いても解決しない自分はダメだ』と思ってたんですけど、今は『どこまで切り分けたか』を見てもらえるので、質問が怖くなくなりました」
「AIに聞いて」という指導は、実は**「AIで解決できない＝能力不足」という無言のプレッシャー**を生んでいたのだと、このとき気づきました。
指導する側へ：私が一緒にやめたこと
新人側のルールだけ変えても片手落ちなので、指導側の自分も2つやめました。
1. 「そんなのAIに聞けばすぐわかるよ」と言うのをやめた
この一言は質問の芽を摘みます。代わりに「いい質問だね。ちなみにAIにはどう聞いた？」と返すようにしました。質問を受け止めた上で、聞き方のフィードバックに変える形です。
2. 質問テンプレートの「自分の仮説」を絶対に笑わないと決めた
仮説が的外れでも「その仮説を立てた理由」には必ずロジックがあります。そこを聞くと、新人がどこで認識を間違えたかが正確にわかるので、指導の精度が上がります。仮説を笑われた新人は、二度と仮説を書かなくなります。
おわりに
AI時代の新人指導は、「AIを使わせるか否か」ではなく、「AIと自力思考の境界線をどう設計するか」 の問題なのだと思います。
まとめると、
- 15分のAI禁止タイムで、エラーを読む基礎体力を作る
- 質問テンプレートで、言語化＝デバッグの型を作る
- 「説明できたら採用」ルールで、AIの出力を教材に変える
どれも明日から導入できます。特に質問テンプレートは、新人がいないチームでも普通に便利なので、ぜひWikiに貼ってみてください。
「うちのチームではこうしてる」という工夫があれば、コメントで教えていただけると嬉しいです。私自身まだ試行錯誤の途中なので、参考にさせてください。
最後まで読んでいただき、ありがとうございました。