「エラーが出た。でも何を調べればいいかわからない。」「そもそも自分が何をわかっていないのかもわからない。」文系未経験でエンジニアになった当初、毎日この状態でした。この記事はその実体験をそのまま書きます。同じ状況で詰まっている人に届いてほしい。
文系未経験エンジニアが最初にぶつかる壁は「調べ方がわからない」
プログラミングの勉強を始めると、すぐに「エラー」が出ます。そのとき多くの人は「エラーメッセージをそのままGoogle検索すればいい」とアドバイスをもらいます。でも実際にやってみると、英語のエラーメッセージが出てきて、検索結果もよくわからない。
問題はそれだけじゃありませんでした。「エラーが出ていない状態でも、何がわからないのかがわからない」という状況が同時に存在していました。コードを読んでいても「なぜこう書くのか」が理解できない。でも何を質問すればいいかもわからない。この二重のわからなさが、最初の一番大きな壁でした。
「わからないことがわからない」状態とはどういうことか
文系出身だと、そもそもプログラミングの「概念の地図」がない状態でスタートします。理系・情報系の人はある程度「こういう仕組みで動いている」という地図を持っている。でも文系はその地図がゼロからです。
地図がない状態で迷子になると、「自分がどこにいるのか」もわかりません。何がわかっていて何がわかっていないかを整理するための土台がないので、質問しようとしても言葉にならない。先輩に「何がわからないの？」と聞かれても「全部です」としか言えない状態でした。
これは頭が悪いわけでも、向いていないわけでもありません。地図がない状態で調べようとしているから迷子になるのは当然です。
実際にやっていた「調べ方がわからない」ときの失敗パターン
エラーメッセージをそのままコピペして検索する
最初はこれをやっていました。英語のエラーメッセージをそのままGoogle検索すると、Stack Overflowの英語ページが出てくる。読めない。翻訳する。なんとなくわかった気がする。でも解決しない。この繰り返しでした。
問題は「エラーメッセージの意味がわからないまま検索している」ことでした。エラーメッセージには「何が」「どこで」「なぜ」起きたかが書いてありますが、それを読む訓練ができていなかった。
「なんとなくわかった」で次に進む
コードをコピペして動いた。でもなぜ動いたかわからない。そのまま次に進む。これを繰り返すと、あとで似た問題が出たときに完全にお手上げになります。「なんとなく動いた」の積み重ねは、理解の積み重ねにならない。
調べすぎて時間を溶かす
わからないことを調べていると、関連する別のわからないことが出てきます。それも調べると、また別のわからないことが出てくる。気づいたら2時間経っていて、元の問題は解決していない。これも文系未経験あるあるです。
先輩に聞いて気づいた「調べ方」の正解
行き詰まって先輩に助けを求めたとき、先輩がやっていたことを横で見て気づきました。調べ方が根本的に違った。
エラーメッセージを「読む」のではなく「分解する」
先輩はエラーメッセージを見て、まず「何のエラーか」だけを取り出していました。たとえば「NullPointerException」なら「nullが入ってはいけない場所にnullが入っている」という意味。全文を読もうとするのではなく、エラーの種類と発生箇所だけを最初に確認する。
そのうえで検索するときは「NullPointerException 原因」など、エラーの種類＋知りたいことをセットにして検索していました。エラーメッセージの全文をコピペするより、ずっと精度の高い結果が返ってきます。
「何がわからないか」より「何がしたいか」を先に言語化する
先輩に聞くとき、「〇〇がわかりません」と言っても伝わらないことが多かった。そのかわり「〇〇をしたいんですが、△△のところでエラーが出て止まっています」という形で伝えると、先輩もすぐに状況を把握してくれた。
「何がわからないか」を言語化するのは難しい。でも「何がしたいか」と「どこで詰まっているか」は言語化できる。この2つをセットにして伝えるのが、質問の最低ラインだと学びました。
30分調べてわからなければ聞く
先輩から言われたのが「30分調べてわからなければ聞いて」という言葉でした。最初は「そんなにすぐ聞いていいのか」と思っていましたが、2時間溶かして解決しないより、30分で聞いて5分で解決する方が全員にとってプラスです。
ただし「30分調べた」という事実と「こう調べたけどわからなかった」という情報を一緒に伝えることが条件でした。調べた形跡があると、先輩も答えやすい。
先輩に聞く前にやること：質問の準備が9割
「30分調べてわからなければ聞く」と書きましたが、聞き方にも準備が必要です。何も整理せずに「わかりません」と言いに行くと、先輩も答えにくい。聞く前に以下を自分なりに整理してから質問すると、解決が格段に早くなります。
① 自分が試したことをメモしておく
「〇〇を試した」「△△を検索した」「□□のページを参考にしたけど解決しなかった」という記録を残しておきます。試したことのメモがあると、先輩も「じゃあそれ以外の原因を探せばいい」と絞り込みができます。
② エラーが出た手順を再現できるか確認する
「さっきエラーが出たんですが、今は出なくて…」は先輩にとって一番答えにくいです。再現手順を言語化しようとするだけで、原因に自分で気づくことも多いです。
③「本来どうなってほしいか」を決めておく
「最終的に〇〇という状態にしたい」という一文を決めておくだけで質問の精度が上がります。
④ エラーメッセージと該当コードをコピーしておく
口頭だけで説明しようとすると情報が欠けます。テキストでコピーしてSlackやTeamsで共有できる状態にしておくのが理想です。
質問テンプレート
【やりたいこと】〇〇をしたい
【発生している問題】△△のエラーが出ている（メッセージを貼る）
【試したこと】・〇〇を確認した・△△を参考にしたが解決しなかった
【該当コード】（コードを貼る）
まず調べてから聞きましょう！
文系未経験が調べ方を身につけるためにやること
- エラーメッセージは全文読もうとしない。エラーの種類と発生箇所だけを最初に確認する
- 検索するときは「エラー名＋知りたいこと」でセットにする。全文コピペより精度が上がる
- 「何がわからないか」より「何がしたくて、どこで止まっているか」を言語化する。質問するときもこの形式が伝わりやすい
- 30分調べてわからなければ聞く。時間を溶かすより早く解決する方が全員にとってプラス
- 「なんとなく動いた」で満足しない。なぜ動いたかを1行でいいので確認する習慣をつける
「調べ方がわからない」は慣れで解決する
8年目の今振り返ると、調べ方は技術ではなく「慣れ」だと思っています。エラーメッセージを読む経験を積むと、パターンが見えてくる。検索の精度も、回数をこなすと上がってくる。
最初の数ヶ月は「調べ方がわからない」という状態が続きます。それは普通のことです。文系・理系関係なく、全員が通る道です。ただ、早めに「調べ方の型」を持っておくと、その期間を短くできます。
この記事で紹介したことは、先輩から教わったことと、自分が失敗して気づいたことだけです。難しい方法論ではないので、明日から試してみてください。
よくある質問
Q. 文系未経験でエンジニアになるのは無理ですか？
無理ではありません。自分自身が文系出身でSES会社に転職し、8年続けています。ただし最初の数ヶ月は「わからないことだらけ」の状態が続くので、そこを乗り越える覚悟は必要です。
Q. プログラミングが全くわからない状態から始めてどのくらいで慣れましたか？
「調べ方に慣れた」と感じたのは現場に入って3〜4ヶ月後くらいです。エラーメッセージを見て「あ、これはこういう系のエラーだ」とわかるようになってくると、調べるのが怖くなくなりました。
Q. 先輩に質問するのが怖くてできません。
最初はみんなそうです。「30分調べてわからなければ聞く」という自分ルールを決めると、「調べたのに聞いた」という事実が心理的ハードルを下げます。何も調べずに聞くより、調べた上で聞く方が先輩にとっても答えやすいです。
Q. Google検索で英語の記事しか出てこないときどうすればいいですか？
検索キーワードに「日本語」を追加するか、検索ツールで言語を日本語に絞ると日本語記事が増えます。ただし英語の記事の方が情報が早くて正確なことも多いので、DeepLなどの翻訳ツールを使いながら英語記事を読む習慣もおすすめです。
文系からエンジニアへの転職については、こちらの記事も参考にしてください。→IT Engineer Log トップページ
Oracle公式のJava資格情報はこちら。→Oracle Java SE 17 Developer 認定資格（公式）
コメント