はじめに
エンジニアにとってエラーをどう解消するか、についての問題は永遠の課題と言えるでしょう。
普段は「なんとなく流れで」やっている方も多いかもしれませんが、その「なんとなく」を言語化した上で、フローチャート形式で見ていくことで
そのフローチャートに沿ってやるだけで「自然とエラーを解決できる」方法を体系化したいという思いでこの記事を作成しました。
駆け出しエンジニアによくある「エラーばかりでよく分からない…」状態を、「なぜエラーが起きているのか」「原因はなんなのか」「どう解決していくのか」を言語化して説明していきます。
これを実践していくことでエラーが発生しても、自力でエラーを解決できる「自走できるエンジニア」になりましょう。
考え方の基本
では方法論を説明する前に、大前提となる考え方の基本をおさえていきましょう。
1.まずは冷静になる
動くと思って書いたコードを実行したら急にエラーが出て焦ってしまう…。
そんな経験は誰しもあると思います。
しかし、エラー解決に最も重要なことは「冷静な頭で考える」ことです。
予想していないエラーに焦る気持ちはわかりますが、焦ってしまうとかえって簡単なミスに気づかずに、余計に時間がかかってさらにテンパるという悪循環になります。
特にいろんな方法を試してダメだった時などはイライラしてしまいがちですが、「この方法だと上手くいかないことがわかった」という発想を持ち、論理的に淡々と情報を整理していくことが重要です。
2.エラーログの重要性
初心者あるあるだと思うんですが、エラーが出た瞬間にアレルギー反応が発症してしまう…なんてことがよくあると思います。
私もそうでした。しかしよく考えてみてください。
エラーログはあなたに意地悪をしようと思ってエラーを吐いているのではなく、むしろ「ここが原因で動いてないよー」というのを教えてくれているのです。
よくエラーを吐かれた後、よくわからないからと言ってたいしてエラーを読まずに、実装コードを数分間眺めてみる…みたいなことしてる過去の自分がいましたが…
ああいうのは本当の時間の無駄なので辞めましょうね(戒め)
実際、エラーログほど重要な情報はありません。
ぶっちゃけそこに全てが書いてあるからです。
最初の方はどこを読めばいいのかや、どんなふうに読み解いていくのかや、そもそも英語が読めない…と思うかもしれません。
どこをどう言うふうに読み解いていくのかと言うお話はこの記事でしっかり解説していますので、これを読めば完全に理解できるでしょう。
そもそも英語が読めない…に関しては、今とても恵まれた環境を先人の方達が作ってくださっております。
Google翻訳を使えばページ全体を一瞬で日本語に翻訳してくれますし、Deeplを使えばもっと自然な日本語で翻訳してくれます。
これらのツールは積極的に使っていきましょう！！
ちなみに、私はDeeplが好きなので多用してます。
Googleの拡張機能でDeeplを入れると、わざわざ英文をコピーして…それをDeeplに貼りに行って…みたいな謎の往復をしなくていいのでおすすめです。
詳しくは下記記事を参考にしてみてください！Deepl最高！！
DeepL翻訳をChrome拡張でもっと便利に使う方法
3.公式ドキュメントの重要性
「Qiitaとかで解説してくれてる記事の方がわかりやすいじゃ〜ん」と思ってる方も多いでしょう。
私もその一人でした。
では何故この考え方だけではダメなのか、考えていきましょう。
ここで大事なのは、Qiitaなどの解説記事はあくまで二次情報。
公式ドキュメントは一次情報である、という点です。
一次情報とは、オリジナルな情報、つまり著者本人が直接的に体験から得た情報、考察、本人が行った調査や実験の結果などです。一次情報の作成・収集には手間（＋資金）と時間を要することから、情報としての価値は高くなります。
QiitaやZennなどの二次情報には
もしかしたら誤った内容が書かれているかもしれないし、情報が古くなっているかもしれない。また、詳細なAPIの仕様だったり、各バージョンの変更点などを探すのは難しいでしょう。
いつまでも二次情報に頼っていたら一人前のエンジニアにはなれません。実装で困った時、自分の力で必要な情報にたどり着けるように、公式ドキュメントを読む必要があるのです。
エンジニアとして、一次情報を確認する習慣をつけていきましょう。
ちなみにですが、公式ドキュメントの読み方がわからない方は下記記事おすすめです。
実践！フローチャート
0.エラーログを読む
では考え方を理解した上で、早速実際のフローチャートを見ていきましょう。
もう当たり前すぎて言う必要もないないですが、あえて言います。エラーログはしっかり読みましょう。
これは新人あるあるだと思うんですが、「エラーログが出てきすぎてよくわからないから、なんとなくしか読まない」ことです。
そしてよく分かっていないままエラーログを残して、とりあえずエラー文をそのままGoogle検索をするのです。
たしかに簡単なエラーなどは、これですんなり解決する場合もあるでしょう。
しかしこれでは「なぜエラーが起きていたのか」、そして「なぜエラーが治ったのか」。
これが理解できないまま先に進むことになってしまいます。
この記事では、(私も含めて)誰しもがやってしまいがちなその「悪習」を断ち切ることを目的としているので、エラーログをしっかり読むことを習慣化しましょう。
1.現象を特定する
当たり前のことですが、いつどこでどのようなバグが起きているのか発見するには、そのエラーとなる挙動を見つけないといけません。
「〇〇するとこのエラーを吐く」などのエラーが発生する特定の現象を突き止めましょう。
例）
「フォームの送信ボタンを押すと、エラーが出る」
「ページを更新するとエラーが出る」などですね。
2.原因を特定する
現象の特定ができたら、次はそのエラーの原因を特定します。
ここがよく分かっていないのに、なんとなくで先に進もうとしてはダメです。
この工程をしっかり踏むことで、後の「解決方法を試すフェーズ」でやることが明確になります。
原因を特定するのにも、さまざまな方法があるので一つずつ見ていきましょう。
①どの行でのエラーなのか
広い部分を指しているエラー文の場合はどの行でのエラーかが分かりづらい場合もありますが、ほとんどの場合はどの行でエラーが起こっているのかがログに書かれている場合が多いです。
どんなにログが多くても、どこの行を指しているのかをしっかり読み解きましょう。
②コメントアウトしながら切り分ける
上記の説明でログにエラーの箇所が書いてあると言いましたが、よくよく探ってみると違っていることも多々あります。
広い部分のエラーを指している場合も、ログだけで見つけるのは困難でしょう。
そんな時にはコメントアウトしながら該当のコードを切り分けるのもおすすめです。
この行をコメントアウトしてもエラーが消えないが、この行をコメントアウトするとエラーが消える、と言った具合にエラーの該当箇所を探すことができます。
③debbugerなどのデバッグツールを使う
ちゃんと意図した値が渡されているかを確認するときなどに利用されるdebbugerですね。
debuggerを仕込むと、いわゆるブレークポイントの設定のようなものが使用できます。
ブレークポイントを利用すると、プログラムの実行を任意の場所で一時停止し、停止した場所の変数の状態やコールスタック（関数の呼び出し経路）を確認したり、停止した場所からコードの実行を一つ一つ自分で進めることができます。
言語によってやり方やツールなどは異なりますが、自分の使ってる言語でのデバッグ方法は確認しておきましょう。
3.解決策と思われるものを試す
いよいよここからGoogle先生の登場です。
エラーの現象を特定した後に、原因も特定する。それらをして初めてGoogle先生に聞くことができるのです。
なぜ先の工程をすっ飛ばしてはいけないかというと、「原因がなんなのか分かっていないエラー解決は不毛だから」です。
とは言っても、エラーログをそのままGoogle検索すれば原因もなんなのかを解説してくれている優しい記事もあるでしょう。
ですが、それはたまたまその人が先にそのエラーに遭遇して、その解決方法を記してくれているだけにすぎません。
毎回のエラーでそういう人たちがいてくれるわけがないのです。もっと言うと、本当にエラーの原因が解説通りなのかのは怪しい場合も多いです。
だから自分の頭で考え、エラーの原因を探り、公式ドキュメントなどの信頼できる情報も参照するのが重要になるわけです。
もっと言うと、駆け出しエンジニアは特にこの癖をつけるべきと言うのがこの記事の意図です。
さて。少し本題と外れてしまいましたが、ここでは解決策をどのように探すのかも含めて解説していきましょう。
①公式ドキュメントでエラー文の動詞前後で検索する
そもそもの公式ドキュメントの必要性については、「考え方」の時に解説したので理解できたかと思います。
ではその上で、ベテランエンジニアさんがよく言う「エラーが起きたらまずはドキュメント見る」という言葉、聞いたことないですか？
あれを聞いて「なるほど」と思うと同時に、「何をどうやって見てるの？」という疑問でいっぱいになりました。
たしかに公式ドキュメントは見たことあるけど、エラー解決時に見たことはありませんでした。
なので一口に「エラーが起きたらまずはドキュメント見よう」と言われても、どう見ていくのが正しいのかが分からなかったのです。
そんな私と同じように悩める子羊たちに、どうやって見ていくのが正しいのか一緒に考えていきましょう。
先に結論から言うと
「今やっている実装が正しいのか確認」
「エラー文の動詞前後で検索する」
の２つを行いましょう。
まず「今やっている実装が正しいのか確認」について。
そもそも論として、使い方が間違っていたらそれは動くものも動かないでしょう。
今一度、自分の行なっている実装が正しいのかを公式ドキュメントで確認しましょう。
また、公式ドキュメントを確認している中で意外と知らなかった情報がある場合も多いです。
情報量が多いドキュメントなんかは読んでいるだけでも勉強になります。
「今自分が実装している部分」と「公式の正しい文法」を確認していきましょう。
次に「エラー文の動詞前後で検索する」について。
これはそのままの意味です。
エラーログを読む際に、重要なワードが出てくるのが動詞前後です。なので、その動詞前後を公式ドキュメント内で検索することで、エラーについての対処法や原因が隠れている場合がよくあります。
駆け出しエンジニアの方は、慣れるまではこの２つの方法を意識的に試して見てください。
💡 一次情報をもっと深掘りたい方
補足となりますが、一次情報をもっと深掘りたい方については
・公式ドキュメントの「Q&A」や「Frequently Asked Questions」
・公式リポジトリのREADME
・公式リポジトリのWiki
・公式リポジトリ内のexampleなど
・公式リポジトリのissue
あたりを参照してみると、信頼性の高い情報をさらに深掘りできるかもしれません。
興味ある方は探して見てください。
参照ー最初に読むべきはQiitaではなく公式ドキュメントである
②エラー文をGoogle検索する
上記の公式ドキュメントを確認しても、直接エラーを解消できるような情報がなかったとします。
その場合もよくあります。
ここでやっとエラー文をGoogle検索していきます。みなさんがよく使っている方法ですね。
-
エラーメッセージをそのまま入れる
まずは、エラーメッセージをそのまま入れてググりましょう。そのとき、エラーメッセージの前に、言語名やライブラリ・フレームワーク名を入れるとなおよいでしょう。
「ずばり」な回答が得られることがあるので、まずは最初にエラーメッセージでググりましょう。 -
固有名詞とエラー番号を入れる
エラーメッセージでググっても原因がわからないことはよくあります。その場合は、次にエラー番号が表示されている場合は、言語名やライブラリ・フレームワーク名とエラー番号を入れるといいでしょう。 -
行番号やバージョンを入れずにググる
結構重要なのが、行番号やバージョンを入れずにググることです。
エラー情報を見ると、バージョン情報や xxx.rb(26)のようにソースコードの行番号が書かれていることがあります。ググるときは、これらの情報はなるべく外した方がいいでしょう。ライブラリやフレームワークのバージョンが違うことで、これらの数字が変わってくるからです。
③英語で検索
ぶっちゃけこれ、めちゃくちゃ重要です。
英語での検索結果しか出てこなった時、ため息をつきたくなる時があるかもしれませんが
プログラミングに限らず、英語の情報量はネット上で60%を占めているのに対して、日本語は2%ほどしかないため約30倍の差があるそうです。
つまり、今のうちに英語で検索する術を身につけておけば
日本語しか検索できない人に比べて情報力に約30倍の差がつくと言うわけです。
というかつよつよエンジニアになりたいのであれば、英語検索力は必須といってもいいのでしっかり身につけていきましょう。
英語での検索方法については
ググり力、それはエンジニアには必須の能力である を参考にしてみてください。
これ本当にめちゃくちゃ勉強になりました。
紹介記事まで読む時間がない！と言う方のために
以下、実践で役に立つなと思ったものを抜粋して書かせていただきます。
英語に絞って検索する方法
検索したいURLに「&lr=-lang_ja」のクエリパラメータを追加することで日本語以外のサイトを対象に検索することができます。
クエリパラメータを打つのが面倒臭いという方は
Chrome で Google の検索結果を英語のみにする方法 の「検索しやすいように検索エンジンを設定する方法」を試すとショートカットで英語検索をできるようになりますので試して見てください。
検索から語句を除外する方法
ある特定のワードを外して検索したいときはよくあると思います。
そんなときは、-（ハイフン）を使用することで特定の語句を除外することができます。
よくある状況としては、違うプログラミング言語の情報も出てきてしまう場合です。
PHPの情報が欲しいのに、Rubyの情報が出てきてしまってはノイズになってしまいます。
完全一致で検索する方法
""（ダブルクォーテーション）を使用することで完全一致で検索されるようになります。
この方法で検索すると、エラーの文言と一言一句違わぬものが表示されるので
ありきたりな単語の羅列の時は一部かすっていて、検索にヒットしてしまう時には、完全一致検索が活躍するでしょう。
特定のサイトから検索する方法
Stack OverflowやQiitaなどの特定のサイトのみの情報を閲覧したい場合も多いと思います。
site: を使用することで特定のサイト内で検索することができるようになります。
エラーの検索時のコツ
補足的になりますが、
ググり力、それはエンジニアには必須の能力である でエラーが発生したときの問題の見方として「自分のプロダクトだけの問題」なのかそれとも「ライブラリ」や「言語特有」の問題なのかを見極める方法が紹介されていたので引用させていただきます。
表示されたエラーをそのまま検索し、 結果がかなりの数ヒットされた時 は、それはライブラリ、言語特有のエラーだと推測 されます。また 結果がほとんど出てこない場合 は 自分のプロダクトだけの問題の可能性が高い です。
検索結果数が多いということは世界中でハマったことのある人が多いということです。逆に検索結果数が少ない場合はそのエラーでハマっている人が少ないということです。つまり自分のプロダクトの処理でエラー文を生成して表示していたりなどが考えられるため、むしろそういう場合は プロダクトコード内から検索したほうが有用な情報を得られるケースが多い かと思います。
とのことで、その考え方はなかったなと大変勉強になりました。
みなさんも、１つの指標として頭に入れておくと今後役に立つかもしれません。
4.解決しない場合
メモに残す
基本的には「現象を特定」して「原因を特定」したら、３番の「解決策と思われるものを試す」をひたすら行なっていくことになります。
ただし、ここで重要なのが「そのプロセスを文字に残しておく」ことが大事ということです。
ツボにハマる要因として、色々調べて手当たり次第にやってみたけど、もう何をやったかわからなくなった。てゆうか今自分が何をしているのかわからなくなった…！！！そんな経験ありませんか？
そうならないために一つ一つ順序立てて、プロセスを残しておくことで「この方法はもうやったので別の方法」と言うふうに論理的に解決へ導くことができるのです。
そこで、個人的に利用しているおすすめのテンプレートを紹介します。
これを上から順に埋めていくだけで、エラー解決にどんどん近づいていくと言う魔法のテンプレートです(自称)
このテンプレートのいいところは、こう言うふうに記録を文字で残しておくことで、自分が今何をやっているかが明確になるのはもちろんですが
最終的に先輩に質問する場合などに、これをのまま伝えればいいだけになります。
一石二鳥ですね。
【実現したいこと】
- 例：TypeScriptでジェネリクスを記述しようとしたらエラーが出た
[実際のコード]
【エラーメッセージ】
[実際のエラーメッセージ]
【調査】
[参考になったサイトのURLなど]
【公式】
[公式ドキュメントに記述されていた場合]
【原因】
[考えられる原因を端的に]
【試して見たこと】
[実際に試したことを残しておく]
【解決方法】
- hogeをfooすることで解決できた
[解決後のコード]
さらに、このエラーが解決した場合もこのようにメモを取って、自分のnotionなりにメモしておくことで、次に同じようなエラーに遭遇した時に秒で解決できるようになります。
結構、同じエラー文を１ヶ月後とかに検索してしまっている自分がいるので、この方法は本当に有用です。
未来の自分のためにも、しっかり記録を残しておきましょう。
それでもわからない場合は先輩に聞く
いや「自走できるエンジニアを目指す」って言っておきながら、結局聞くんかい！！！と思われるかもしれませんが
正直、上記のことを試した上で分からないのであれば、2時間悩もうが10時間悩もうが多分解決できません。
と言うか、一つのエラーで10時間も一人で悩み続けるのは流石に時間の無駄が過ぎます。
その間にもプロジェクトは進行していき、消化すべきタスクも溜まっているということを自覚しましょう。
チームにとっての最大のリスクはプロジェクト全体が遅れてしまうことです。
ちなみに漠然と「ここが分かりません。どうしたらいいですか」と聞くのは論外としても
上記の方法でしっかり「現象を特定」と「原因を特定」を探して、試したことをちゃんとメモしている状況であれば
先輩も「ここまで調べているのであれば、あとはやってないこととしてこれとかやってみるといいんじゃない？」と提示してくれる場合が多いです。
こうすれば大切な先輩の時間も使わずに、タスクも進められることができるので最高ですね。
質問に関してはこちらの記事おすすめです。
本題とはずれてしまいますが、その日はエラーの原因が全くわからない状態で数時間溶かしてしまったけど
次の日の朝にやってみたら5分で解決できた、みたいな謎現象がエンジニアの間ではあるあるとしてよく経験します。。笑
あの謎現象にそろそろ名前をつけたいですね。
フローチャートまとめ
かなり内容がボリューミーになってしまったので、最後にフローチャートを簡潔にまとめて終わりにします。
駆け出しエンジニアの皆さんは、このフローチャートをしっかり実践して、「脱・駆け出しエンジニア」になりましょう！
①エラーログを読む
②現象を特定する
③原因を特定する
④解決策と思われるものを試す(ドキュメント参照、エラー分をググる、英語でググる、除外検索や完全一致検索などを活用)
⑤メモをとる
⑥ここまでして解決しなければ先輩に聞く
終わりに
私が普段業務をする中で「なんとなくエラーを調べちゃってる」という状況は良くないなと思ったのがこの記事を書くきっかけとなりました。
ただエラー解決方法を言語化するのではなく、方法論として体系化したかったので
少しでも、私と同じように悩んでいる駆け出しエンジニアさんの助けになれば幸いです。
参考