大量のエラーログにフリーズしていた私が「視線の落とし方」を学んで少しずつ向き合えるようになるまで
こんにちは、入社2年目になりました、小林です。
よく「エラーメッセージをよく読んでみよう」と言われますが、当時の自分は正直「画面いっぱいに広がる赤文字英語の一体どこが原因！？！？」という状態でフリーズしていました。
今振り返ると、つまずいていた原因は「英語力」ではありませんでした。エラー文に使われている英語自体（例えば `x is not a function` など）は、よく見るとそこまで難しいことは書いていません。また、出てくる英文も決まっています。 問題だったのは、「一度に出る情報量が多すぎて、どこが重要か、どこから読めばいいかわからない」という、情報の重要度が判断できていないことでした。
今回は、私が躓いた「エラーログとの向き合い方」について、当時の自分に教えるつもりでまとめてみました。
１．大量のエラーログは「3つの要素」に仕分ければ怖くない💡
例えばコンソールにこんな感じで大量の情報が出てくることがあります。
TypeError: Cannot read properties of undefined (reading ‘name’)
at UserProfile (UserProfile.jsx:8:24)
at renderWithHooks (react-dom.development.js:16305:16)
at updateFunctionComponent (react-dom.development.js:19588:15)
at beginWork (react-dom.development.js:21601:16)
at beginWork$1 (react-dom.development.js:27426:14)
at performUnitOfWork (react-dom.development.js:26557:12)
at workLoopSync (react-dom.development.js:26466:5)
at renderRootSync (react-dom.development.js:26434:7)
at recoverFromConcurrentError (react-dom.development.js:25850:20)
at performConcurrentWorkOnRoot (react-dom.development.js:25750:11)
at flushActQueue (react-dom.development.js:26671:24)
at Object.enqueue (react-dom.development.js:13011:15)
最初の頃は、この画面を埋め尽くす大量の英語を仕分けのない1つの塊として捉え、「なんか長くてヤバそうなエラーが出た…」と一括りに見てフリーズしていました。
でも実際には、エラーの画面は以下の「3つの要素」で構成されています。
エラーの種類：
TypeError（型のエラー。今回は「存在しないものを読み込もうとした」という分類）エラーメッセージ：
Cannot read properties of undefined (reading 'name')（何が起きたか）スタックトレース：
at ...がずらりと並ぶ部分（エラーに至るまでのプログラムの実行経路）
新人あるあるだとは思いますが、当時の自分は、この構造（特にスタックトレースという概念）を知りませんでした。そのため、ズラリと並ぶ英語の行がすべて同じ重みの情報に見えてしまい、どこに視線を落とせばいいのか分からずに混乱していました。
実は、先ほどのエラーログを「仕分け」してみると、見るべき場所は一目瞭然です。
【エラーログの仕分け方】
TypeError: Cannot read properties of undefined (reading 'name')➔ 【最重要】何が起きたかat UserProfile (UserProfile.jsx:8:24)➔ ★【ココだけ見る】自分が書いたコード（上から順に探す）at renderWithHooks (react-dom.development.js:16305:16)➔ 【無視してOK】ライブラリの内部処理at updateFunctionComponent (react-dom.development.js:19588:15)➔ 【無視してOK】ライブラリの内部処理（以下、何十行続いてもすべて【無視してOK】なライブラリの内部処理…）
下10行近く並んでいる react-dom.development.js は、Reactやフレームワーク側の内部コードなので、バグを探すときに読む必要は（基本的には）ありません。見るべきは、上から順番に視線を落としていって、最初に見つかる「自分が書いたファイル名（UserProfile.jsx）」の1行だけだったのです。
残りの長いログは、すべて「ライブラリの内部処理なので無視してOK」な情報です。そう考えると、急に怖くなくなってきました！
2. 開発の罠：「React側の原因」なのか「外側の原因」なのかの切り分け💡
さらに難しかったのが、「エラーが出た行＝原因の場所」とは限らないということです。
先ほど例に出した Cannot read properties of undefined (reading 'name') （値が空っぽなのに中身を読み込もうとしたエラー）は、私が開発中によく遭遇するエラーの筆頭です。
以前の私は「エラーが出た場所＝悪者」だと思っていたので、この UserProfile.jsx の8行目（React側）だけを凝視しては、「コンポーネントの書き方は合っているのになぜ原因が分からないんだ…」と泥沼にハマっていました。
しかし、Reactのコンポーネント自体は正しく書けていても、本当の原因は別の場所に隠れていることが多々あります。
前段の処理で、APIからのデータ取得（バックエンド側）に失敗していた
親から値を引き渡す段階で、タイポや渡し忘れがあった
非同期処理のタイミングがズレていて、データが届く前に画面の描画（レンダリング）が走ってしまった
つまり、Reactのコードが出したエラー行は「前の工程で発生したバグの、被害に遭った場所」に過ぎないケースが多いです。「Reactの書き方の問題」なのか、それとも「流れてくるデータや外側の問題」なのかを切り分ける難しさを痛感しました。
3. ヒントは先輩の「独り言」に詰まっている？
こうした「情報整理」や「切り分け」の感覚ですが、近くにいる先輩たちの「独り言」が参考になることもあります。
上手な人が画面に向かって、
「あれ、ここでundefinedになるってことは、API叩けてない？…あ、ネットワークエラー出てるわ」
「Reactの構文は合ってるから、親から渡ってくるときのデータの形が違うな…」
「APIのログを見てみよう」
などと呟いているのを聞いているうちに、彼らの「ログのどこを見て、どう判断しているか」という視線の動かし方が、少しずつ見えてきます。
長文の英語をすべて真面目に読んでいるのではなく、エラーから「必要な情報（エラー名や自分のコードの行）」をサッと拾い上げ、時には通信ログ（ネットワークタブ）なども確認しながら、どこに原因があるかを切り分けていました。
1から10まで教えてもらうわけではなくても、上手な人の視線の落とし方をちょっと参考にしてみるだけで、エラーと向き合うヒントが見つかるのだと気づかされました。
4. まとめ：エラーは怖くない、まずは「分解」と「切り分け」から💡
今の私は、長いエラーが出てもパニックにならず、脳内で次のように仕分ける意識を少しずつ持てるようになってきました。
まず最上部を見る（「何が起きたか」だけを掴む）※言語にもよると思います
スタックトレースを上から見て「自分の書いたファイル名」の行を見つける
その行の書き方が合っているなら、「ここに流れてきているデータはどこから来たか？」と関数を呼んでいる箇所など関連する箇所を見る
正直、まだまだエラーを見てすぐ原因が分かるわけではありませんし、今でも学びの真っ最中です。
でも、「全部一気に理解しなきゃ」と焦るのをやめて、「まず要素を分解して、どこに原因があるか切り分けよう」という姿勢を持てるようになったことで、エラー画面に対する恐怖心が少し薄れました。
もし、かつての私のようにエラー画面の前でフリーズしている方がいたら、まずは「エラーの構造」を意識して、自分のコードの行をピンポイントで見つけることから始めてみてください！
