はじめに：2026年の研修現場で起きていること
春の新人研修シーズン。プログラミングの研修現場では、毎年このような光景が繰り広げられるのではないでしょうか。
-
教える側（メンター）の悩み：
「新人が自分で考えず、すぐに答えを聞いてくる。少し厳しくすると萎縮してしまう」 -
教わる側（新人）の悩み：
「エラー画面が怖くて動けない。間違えたら怒られる・評価が下がる気がして、誰かの正解を知りたい」
ChatGPTなどの生成AIが当たり前にあり、「タイパ」や「失敗しないこと」が重視される2026年現在。この両者のすれ違いは、かつてないほど大きくなっています。
この記事は、「新人にどう教えればいいか悩むメンター」と、「エラー画面の前でフリーズしている新卒エンジニア」 の両方に向けて書きました。
Javaの研修で必ず立ちはだかる「赤いエラー」を題材に、両者の視点のギャップと、本当に必要な「自走力」の正体を紐解いていきます。
1. 視点のギャップ：Javaの「赤いエラー」はどう見えているか？
コードが動かない時、新人（教わる側）とメンター（教える側）では、見えている景色が全く違います。現場で必ず遭遇する3つの代表的なエラーを例に、その「認知の差」を解剖してみましょう。
① ぬるぽ（NullPointerException）
最も新人を絶望させる、Javaの登竜門的エラーです。
▼ 実際のエラーを引き起こすコード
public class Main {
public static void main(String[] args) {
String text = null; // 値が入っていない空っぽの箱
// 空の箱に対して「文字数を教えて」と命令してしまう
System.out.println(text.length());
}
}
▼ コンソールに出力される赤いエラーログ
Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "text" is null
at Main.main(Main.java:6)
- 新人の視点： 「真っ赤な英語が大量に出てきた！プログラムを完全に壊してしまった。どうしよう…（絶望）」
-
メンターの視点： 「あ、箱（変数）の中身が空っぽなのにアクセスしてるな。スタックトレースの
Main.java:6（6行目）を見れば、どの変数が原因かすぐわかるぞ。」 -
💡 向き合い方のヒント： エラーログは宝の地図です。まずはログの一番下（あるいは
at 〇〇と自分のファイル名が書かれている行）の「行番号」を確認する癖をつけましょう。
② 構文エラー（Syntax Error / コンパイルエラー）
「教科書通りに書いたのに動かない！」という新人のパニックの9割はこれです。
▼ 実際のエラーを引き起こすコード
public class Main {
public static void main(String[] args) {
System.out.println("Hello, World") // ← 行末のセミコロン(;)を忘れている
}
}
▼ コンソールに出力される赤いエラーログ
Main.java:3: error: ';' expected
System.out.println("Hello, World")
^
1 error
- 新人の視点： 「一言一句同じように書いたはずなのに！自分はエンジニアに向いていないのかも…（意気消沈）」
-
メンターの視点： 「ただのセミコロン忘れ、もしくは全角スペースが混ざってるだけ（笑）。エラー文に
';' expectedって答えが書いてある、0.5秒で直るボーナス問題。」 - 💡 向き合い方のヒント： コンピュータは「空気を読む」ことができません。これは英語のスペルミスや句読点の打ち忘れと同じで、「ここが読めないよ！」と親切に教えてくれているだけです。
③ 無限ループ
PCのファンが唸り声を上げ、初心者が最も「PCを壊した！」と錯覚しやすい現象です。
▼ 実際のエラーを引き起こすコード
public class Main {
public static void main(String[] args) {
int count = 0;
// countが5未満なら繰り返す
while (count < 5) {
System.out.println("現在のカウント: " + count);
// 本来ここにあるべき count++; （カウントを増やす処理）を書き忘れた
}
}
}
▼ コンソールに出力される画面（強制終了するまで永遠に止まらない）
現在のカウント: 0
現在のカウント: 0
現在のカウント: 0
...（以下、猛スピードで永遠に続く）
- 新人の視点： 「画面の文字が止まらない！PCが固まった！ファンがすごい音を出してる！どうやって止めるの！？（パニック）」
- メンターの視点： 「終了条件（変数の更新）を書き忘れただけだな。IDEの停止ボタン（赤い四角）を押してプロセスを止めよう。」
- 💡 向き合い方のヒント： PCは簡単なプログラムでは爆発しません。コンピュータが君の書いた命令を忠実に守って、一生懸命走り続けているだけです。落ち着いてプロセスを止め、出口（ループを抜ける条件）を作ってあげましょう。
2. 【新人エンジニアの皆さんへ】エラーは「減点」ではない
もしあなたが今、研修中でこの記事を読んでいるなら、これだけは知っておいてください。
「エラーログは、世界で唯一、あなたに嘘をつかない親切なアドバイス」です。
学校のテストでは、間違えると「減点」されました。SNSでは、一度の失敗がいつまでも残ります。だからこそ、エラーを出すことを「自分の汚点」のように恐れてしまう気持ちはとてもよく分かります。検索やAIで、すぐに「誰かの書いた正解」を探したくなるのも当然です。
しかし、エンジニアの仕事は「一発で正解のコードを書くこと」ではありません。**「エラーという事実と向き合い、コンピュータと対話すること」**です。
画面いっぱいの赤い文字は、警告ではありません。「ここの行の、この変数が空っぽだから動けないよ！」と、コンピュータが必死にヒントをくれているだけです。メンターがスラスラとコードを直せるのは、頭が良いからではなく、過去にあなたより何千回もそのエラーを見て、盛大に失敗してきたからです。
PCは簡単なプログラムでは爆発しません。どうか今のうちに、たくさんコードを壊して、たくさん「赤いエラー」を出して実験してください。
3. 【メンター・講師の皆さんへ】「人」を変えるより「環境」を変える
一方で、教える側の私たちも「最近の若手は気合が足りない」「指示待ちだ」と嘆く前に、やるべきことがあります。彼らがエラーを恐れるのは、彼らの性格の問題ではなく、育ってきた時代の環境（OS）が違うからです。
「失敗を恐れるな」という精神論ではなく、彼らが 「自走（試行錯誤）せざるを得ない、かつ安心できる環境」 を技術的に作りましょう。
アプローチ①：主語を「あなた(You)」から「エラー(It)」に変える
「なんでこんな書き方したの？」は、人格否定に聞こえてしまうキラーワードです。
指導する時は受講生と対面するのではなく、隣に座って一緒に画面を見つめましょう。「（このコードは）ここでエラーを吐いてるね」と事実を確認し、
→「私たち（メンター＋新人） vs エラー」 の構図を作ります。
アプローチ②：「質問の型」を強制し、受け身をタスクに変える
「わかりません」という丸投げを防ぐため、質問のテンプレートをルール化します。
1. 実現したいこと
2. 発生している問題（エラーログの1行目をコピペ）
3. 試したこと（System.out.printlnで中身を見た、等）
4. 自分の推測（間違っていてもOK）
これが埋まっていない状態で呼ばれたら、「この4つが整理できたら、もう一度呼んでね」と一度離れます。「間違った推測」は大歓迎です。 大切なのは、技術的な事実に基づいて仮説を立てるという「エンジニアの動作」を環境として強制することです。
アプローチ③：技術的な「命綱」を用意する
「コードを壊すのが怖い」という新人には、Gitなどの概念を早めに教えることも有効です。「コミットしておけば、どれだけめちゃくちゃにしても1秒で元に戻せるよ」と技術的なセーフティネットを張ることで、彼らの実験へのハードルは劇的に下がります。
おわりに
研修の主役はあくまで受講生（新人）であり、メンターは伴走者にすぎません。
- 教わる側は、エラーを恐れず「コンピュータとの対話」を楽しむこと。
- 教える側は、彼らが「自然と実験したくなる土壌」を整えること。
2026年、AIがどれだけ進化しても、最後にシステムを動かすのは「エラーという事実に向き合うエンジニアの泥臭さ」です。お互いの視点の違いを理解し、歩み寄ることで、最高のチームが生まれることを願っています。