はじめまして。株式会社PRUMでエンジニアをしている、すもも🍑です
日々、プログラミング学習や実務の中で、つまずきやすいポイントや
考え方を整理して発信しています。

PRUMについて気になった方は、コーポレートサイトもぜひご覧ください。
▶コーポレートサイト

エラー対応理由考えてる？コピペしてAIに聞いてるでしょ！

エラーが出るたびに、メッセージをちゃんと読まずに、AIに「このエラーの原因は？」と聞いて、出てきた答えをそのままコピペしていないでしょうか。

「AIに聞けば早いし、別にいいでしょ？」

新人のころ、私も同じでした。読んでもピンとこないので、AIや検索に頼って、それっぽい答えをそのまま試すことばかりしていました。

職場で許可されているなら、エラーの原因を調べるためにAIを活用すること自体は悪いことではありません。

ただ、毎回それだけで済ませていると非効率ですし、AIが原因を間違えることもあります。最低限、自分でエラーメッセージを読み解く基礎的な読解力は身につけておいた方がいいと思います。

実は、IT業界で求められる「読解力」は特殊

そもそも、エラーメッセージが読みにくいのは、読解力がないからではありません。

英語で書かれている上に、プログラミング言語特有の言い回しが混ざり、半角と全角、シングルクォートとダブルクォートのような、普段の生活ではまず気にしない細部まで見なければならない。これは、一般的な「読解力」とは種類が違うスキルです。


普段どれだけ本を読んでいる人でも、この特殊な読み方に最初から慣れている人はいません。

具体的に何を見ればいいのか

エラーメッセージを読むときに、まず拾いたい手がかりは次の3つです。

• エラーの種類（SyntaxErrorなのか、TypeErrorなのか）
• どのファイルの何行目で起きているか
• 何が期待されていて、実際には何が渡されたか

たとえば「cannot read property 'x' of undefined」というメッセージなら、「undefinedに対してxを読み込もうとしている」という手がかりだけは、専門知識がなくても拾えます。

半角と全角、クォートの種類のような細かい違いも、最初は「そんなところまで見るの？」と思うかもしれませんが、これも慣れれば自然と目が止まるようになる部分です。

だから鍛えたいのは「AIに聞く前に、手がかりを拾う」習慣

「まず自分で考えて仮説を立てる」というのは、実はハードルが高い言い方です。仕様の知識がまだない状態で、読むだけで仮説が浮かんでくるわけではないからです。

そうではなく、まずエラーメッセージの中から具体的な手がかりを拾ってからAIに聞いたり検索したりする、という順番が現実的だと思います。

手がかりを拾ってから聞くと、質問や検索の精度そのものが上がります。「このエラー直して」ではなく、「TypeErrorでcannot read property of undefinedと出た、原因は？」のように、拾った手がかりで聞けるようになるからです。

そしてこの、手がかりを拾う作業を繰り返しているうちに、仕様の知識そのものも後から自然に身についていきます。読解力があるから仕様が分かるのではなく、手がかりを拾う習慣が、結果的に仕様の理解につながるという順番です。

これはIT業界に限った話ではありません。

• 料理で「なぜか焦げた」「なぜか膨らまなかった」という結果を都度観察していくうちに、火加減や分量の感覚が自然と身についていく
• 語学学習で、聞き取れなかった言い回しをその都度調べて覚えていくうちに、文法を意識しなくても自然に使えるようになる
• スポーツで、フォームのどこがズレているかという指摘を繰り返し拾っていくうちに、正しい動きの感覚が体に染み付いていく

エラーメッセージも同じです。「なぜこの手がかりが出たのか」を拾い続けることが、結果的に仕様を理解する"感覚"につながっていきます。

まとめ

エラーメッセージが読みにくいのは、読解力の問題ではなく、そもそも特殊な読み方が必要なだけです。

AIに聞くこと自体は悪いことではありません。ただ、聞く前に一度、エラーメッセージの中の手がかりを拾ってみる。その一手間が、次第に仕様を理解する力につながっていきます。

その上で、エラーメッセージは、読めないから怖いものではなく、手がかりを拾えば少しずつ読めるようになるものだと思います。

---

PRUMのエンジニアの多くは未経験からの採用です。
よければコーポレートサイトにも遊びに来てください。
▶ PRUM採用ページ

エンジニアの方に役立つ記事をまとめたサイトも運営しています。もしご興味あれば覗いてみてくださいね。
▶ エンジニアに役立つ記事サイト