エラーメッセージを読めるエンジニアは何が違うのか
この記事は約 5 分で読めます。
エラーメッセージは「読む」ものである
TypeError: Cannot read properties of undefined (reading 'map') というエラーが出たとき、あなたは何をしますか。エラーメッセージをそのまま Google に貼り付ける人と、メッセージを読んで「配列のはずの値が undefined のまま map を呼ばれている」と読み取り、取得の完了前にレンダリングが走った、プロパティ名を間違えている、想定と違う形の JSON が返ってきた、といった候補まで絞り込める人がいます。
この差は才能ではなく、エラーメッセージを「読む」訓練を重ねてきたかどうかで説明できる部分が大きいです。そして、その訓練の土台になるのが、言語やランタイムの仕組みを解説した本です。
デバッグ力を支える 3 層の知識
第 1 層: 言語の型システムと実行モデル
値の型が想定と違うこと、処理の実行順序が想定と違うことは、エラーの原因として繰り返し現れます。JavaScript なら undefined と null の違い、Python なら AttributeError と TypeError の違い。これらを正確に理解していると、エラーメッセージから原因を逆算できます。
言語の入門書は文法を教えてくれますが、型システムや実行モデルを深く解説している本は少数です。入門書を卒業した後に、言語の内部動作を解説した本を 1 冊読んでおくと、同じメッセージから読み取れる情報が増えます。
第 2 層: フレームワークのライフサイクル
React の useEffect で無限ループが起きる、Rails のコールバックが意図しない順序で実行される。フレームワーク固有のエラーは、そのフレームワークのライフサイクルを理解していないと原因がわかりません。
公式ドキュメントのチュートリアルだけでは、ライフサイクルの全体像は掴めません。フレームワークの設計思想から解説している本を読むと、「なぜこの順序で処理が実行されるのか」が理解でき、エラーの原因を構造的に推論できるようになります。
第 3 層: OS とネットワークの基礎
ECONNREFUSED、ETIMEDOUT、ENOMEM。これらのエラーコードは、OS やネットワークの知識がないと意味がわかりません。アプリケーションコードに問題がないのにエラーが出る場合、原因はインフラ層にあることが多く、この層の知識が欠けていると手も足も出なくなります。
OS やシステムプログラミングの本を 1 冊読んでおくと、インフラ層のエラーに遭遇したときに、まずどこを見ればいいかの当たりがつきます。
エラーメッセージの読み方を鍛える習慣
スタックトレースは「自分のコードが現れる行」から読む
エラーが投げられた最深部の 1 行だけを見て終わりにすると、呼び出し元にある本当の原因を見落とします。探すべきは、自分が書いたコードが現れるフレームです。
ただし、フレームの並ぶ向きは処理系によって逆になります。JavaScript のスタックは新しい呼び出しから古い呼び出しへ向かって並ぶため、自分のコードは下のほうに現れます。一方 Python のトレースバックは冒頭に Traceback (most recent call last) と書かれている通り、最後の行がエラーの発生地点で、呼び出し元はその上に並びます。向きを取り違えると、ライブラリの内部だけを延々と追いかけることになります。
エラーメッセージを英語のまま読む
翻訳されたエラーメッセージは情報が欠落していることがあります。英語のまま読む習慣をつけると、公式ドキュメントや Stack Overflow の情報にも直接アクセスできます。英語が苦手でも、エラーメッセージに現れる語は expected、undefined、permission denied、connection refused のように同じものが繰り返し出てきます。訳さずにそのまま覚えていけば、読める範囲は使っている道具の分だけ広がっていきます。
「なぜこのエラーが出るのか」を言語化する
エラーを解消した後、「なぜこのエラーが出たのか」を 1 文で書き残します。「非同期処理の完了前に state にアクセスしたため」のように、原因を言語化する習慣が、次に同じエラーに遭遇したときの対応速度を上げます。
関連記事
まとめ
エラーメッセージを読めるエンジニアは、言語の型システム、フレームワークのライフサイクル、OS とネットワークの基礎という 3 層の知識を持っています。これらは実務経験だけでは体系的に身につきません。各層について 1 冊ずつ本を読むことで、エラーメッセージが「意味不明な文字列」から「原因を教えてくれるヒント」に変わります。
この記事は役に立ちましたか?
関連用語
関連記事
エラーが出たときこそ本の出番
プログラミング中にエラーが出ると焦りますが、そんなときこそ本が役に立ちます。エラーと本の付き合い方を、初心者向けにやさしく解説します。
スタックオーバーフローのコピペを卒業する日
Stack Overflow からコードをコピペして動かす段階から、自分で設計して書ける段階へ。この成長の壁を越えるために技術書が果たす役割を解説します。
本を読んだらすぐパソコンを開こう
プログラミングの本を読んだら、すぐにパソコンを開いて手を動かしましょう。読むだけでは身につかない理由と、読んだ直後にやるべきことを紹介します。
技術書のサンプルコードが動かないときの対処法
技術書のサンプルコードがエラーで動かない原因と、自力で解決するための具体的な手順を解説します。バージョン違い、環境差異、誤植への対応方法。
プログラマーはなぜ本を読むのか
ネットで何でも調べられる時代に、プログラマーがわざわざ本を読む理由を解説します。検索では手に入らない「つながった知識」が本にはあります。
写経のすすめ - 技術書のコードを手で打ち込む学習効果
技術書のサンプルコードを手で打ち込む「写経」の 3 つのレベルと、写経に向いている本の特徴、効果を最大化するやり方を紹介します。