エラーが出たらとりあえずググれ！なんて言われますが、ググり方にもコツがあるのをご存知ですか？
また、わけわかんないエラーに出会ったとき、どれだけ自分で調べてから人に聞くべきでしょうか？
そんな疑問に答えるべく、エラー解決のフローを作成しました。多少亜種はあるかと思いますし、無意識的にやってる方もいらっしゃるかと思いますが、エンジニアは皆さんだいたいこの手順で問題解決しています。
この順に進めていけば、「あああああ、こんなことだったのか！時間を無駄にした！」と感じたり、質問した時に「もっと早く質問しなよ」と言われたり、逆に「これくらいは自分で調べておけよ」なんて言われることもなくなるでしょう！！
慣れないうちは、このフローの順に丁寧に進めていきましょう。そのうち、無意識にこの順を踏めるようになると思います。エラー解決手順を自分のものにして、開発に集中できるようになりましょう！！
１．エラー文を出す（デバッグ）
エラーが出てきて、エラー解決がスタートするなら問題ないのですが、そのエラーがすごく曖昧なものだったり、そもそもエラーが出ない場合もあります。
そんなときは、「エラーを出す」「ログを見る」などのひと手間が発生します。エラー文が見えずに悶々としていたけどエラー文が見えたら一発で解決した、なんてことはよくあります。
では、パターン別にどうぞ。
エラー文は出ているんだけど曖昧
「このサイトにアクセスできません」などそもそもページが開かない場合など、エラー画面は一応出ているものの、それを見ても何も情報が得られないケースが多いです。
例えば下記のケース
このケースでは２番目にかかれていることを試したら結果良かったわけですが、もし１番目の理由だったら「接続を確認って何？」となるわけです。
そんなケースでは、まずはより細かいエラーメッセージを出すことを目指しましょう！
エラー文が出ている箇所がわかりにくい場合
例えば、Javascriptのコードが誤っている場合などは、画面に直接エラーメッセージが出ません。では、エラーメッセージが出ていないのかと言われるとそうではありません。ログやブラウザのコンソールを見にいけば、エラー文はちゃんと出ています。それを見にいく必要があるわけです。Google chromeを使っている場合は、ディベロッパーツールのコンソールを覗けば、エラー文を見ることが出来ます。最初それを知らずにJSを触っていたので、サイドミラーもバックミラーも使わずに車を運転しているような感じですごく不自由でした・・・。
Mailerを使っている場合も、エラーが直接出てくるわけではありません。この場合は、ログを見るか、デバッガーを使っても無理やり見れます。
エラー文が出ない場合
もちろん、エラーが出ない場合もあります。実現したい挙動と実際の挙動が異なる場合がこのケースに当たります。CSSが効かない！などが典型例でしょうか。あとはJSが読み込まれていなくて反応しない、とか。読み込まれていないとエラーメッセージすら出ません。CSSの場合はディベロッパーツールを使いこなすことである程度原因を見ることができますが、多くの場合は、「２．エラー分を読む」と「４エラー文で検索」のステップを踏めないため、少々面倒になります。が、そういうケースもある、と知っておくと気が楽です。エラーが出ないなら出ないと割り切って進められるので。その場合のググり方もありますし、５「問題を切り分ける」に時間を使いましょう。
２．エラー文を読む（５秒〜30秒）
無事にエラー文が出せたら、エラー文を読んで意味を理解しましょう。
「え、何を当たり前のことを」と思うかもしれませんが、意外とすっ飛ばす人がいるんですよ（う、今ブーメランの刺さった感触が・・・）。
プログラミングのエラー文は英語で出るので、英語が不自由な人はなおさら、よくわからないからといきなりステップ４「エラー文で検索」をしてしまいがちです。ステップ２「エラー文を読む」と３「一瞬で確認できることをチェック」を真面目にやれば１分で解決できたことが、いきなりググって自分とは異なるケースの記事を参考にしてしまい解決まで時間がかかることがあります（はい、経験談です）。
何より、これをしないと成長しません。同じエラー文が出てきても、意味がわかってないと記憶に定着しにくいし覚えていなければまた検索しないといけません。
したがって、英語が読めなかったら、翻訳を活用しましょう。お気に入りの翻訳サイトをお気に入り登録しておいて、いつでもどこでも出せるようにしておきます。特に拘りがないならGoogle翻訳で良いのでは。
慣れたら半分はここで解決できます。
例えば、Ruby on Railsに取り組んでいる人は
NoMethodError
undefined method '◯◯' for nil:NilClassとか頻繁にお目にかかるかと思います。これは「nilに対してそのメソッドは定義されてない（＝使えない）よ！」という意味なので、そこで指摘されているメソッドが参照している変数にnilが入っていることがまずいんだとわかります。こうやって、意味がわかっていれば応用が効き、所謂センスが磨かれます。エラー文の意味がわかった上で、もし何か閃いてそれが簡単に試せるなら、試してみれば良いのです。再三になりますが、慣れたら半分はここで解決できます。
ただし、試してみて外れた場合、元に戻しておくことを忘れずに。（初心者の閃きは、新しいエラーやバグを生む可能性があります）
ここまでで、ようやく「エラー解決の道」のスタートラインに立てたと言っていいでしょう。スタートラインに立つことの重要性はわかっていただけたでしょうか？なにしろ、ここまでで半分のエラーは解決するわけですから。それに割り込みは事故の元です。なんかモヤモヤしてうまくいかないけど人に説明するのが難しいな・・・という時は、ぜひ、この１「エラー文を出す」と２「エラー文を読む」を飛ばしていないか？疑ってみてください。
では、ここまでで解決できなかった残りの半分は、「エラー解決の道」に入って行きましょう。
３．一瞬で確認できることをチェック（10秒〜1分）
トラブルシューティングの基本に忠実にいきましょう。まずは簡単に確認できること試せることからチェックします。家電で言ったら「コンセントはささっていますか？」「電源は入っていますか？」レベルの確認です。具体的には、次の５点です。
- タイポなど誤字脱字はない？（コピペやエディタの補完機能を活用しよう！）
- 全角が混ざっていないか？（コードで全角を使うのは日本語の文字列を扱う時のみ！）
- タブは合っているか？（yamlやslimなどは特に繊細！）
- コードは保存されているか？（頻発する人は自動保存に）
- サーバーやエディタ、ブラウザの再起動は必要ないか？
最初はしらみつぶしで確認する必要はなくて、エラー文の該当箇所の周辺だけチェックすればOK。全部確認するのは最終手段。ここは一度確認しようと思ったらいくらでも時間をかけられるところなので、この時点ではせいぜい１分で確認できる範囲で構いません。再起動とかしたら１分超えてしまうかもしれませんが、長くかかってもそれくらいで良いです。それで意味あるのか？と感じる方もいるかもしれませんが、意味はあります。これは、いきなり４「エラー文で検索」以降に進んで泥沼にハマっていき、「あれ、そういえばこのスペル合ってる？」みたいなオチにならないようにするためなので。この１分をかけるかどうかで全然違います。もし、見つけにくいタイポだったら、それはそれで仕方がないですから。
誤字脱字・全角・タブ・保存・再起動
パッと見でそういったミスがないようなら、ようやく、４「エラー文で検索」に進みましょう！
４．エラー文で検索（1分〜3分）
ここは説明不要かもしれませんね。エラー文を完全コピペで、Google検索しましょう。それでOKです。ほとんどの場合、それらしい記事がヒットします。なんか違うなと思ったら、
- (エラー文) ＋ エラー
- (エラー文) ＋ error
- (エラー文) ＋ (言語やフレームワーク)
などで調べるよ良いでしょう。先ほどのRuby on Railsでのエラーなら「NoMethodError rails」みたいな感じです。
エラー文がない場合は、まずは思いついたままの文章でググりましょう。例えば
- 「モーダル 開かない 対処法」
- 「JS click 何度も実行される」
などです。８割のエラーはここまでで解決できます。
それでも残りの２割は、ピントの外れた記事しか出てこなかったり、「既にそれは修正済みなんだけどなあ」みたいな記事しかなかったり、ということがあり得ます。そういう時は、それ以上ググっても仕方がないので、一度コードに戻りましょう。５分以上ググってもたどり着かない場合は、そもそもその情報だけでは足りないという場合が多いです。次のステップ５「問題の切り分け」に進んでください。
ちなみに、特に初心者のうちは、解決法が共有されていないエラーなんてものはほぼないと思っていただいて差し支えありません。未修正のバグなんてもってのほかです。検索の仕方を変えるだけで、解決につながる記事を見つけることができると考えましょう。しかし、闇雲に検索ワードを変えても、下手な鉄砲数撃ちゃ当たるかもしれませんが、効率が悪すぎます。目をつぶっても乱射したら的に当たるのは映画の世界だけです。せめて的を目で見てその方向に打つようにしましょ？その精度を上げるために、次の５「問題の切り分け」が重要になってくるのです。
５．【重要！】問題を切り分る（5~10分）
自学自習する場合、自力解決が求められる場合は特に、ここがキモです。エラー文でググっても答えが得られないということは、根本的な原因がそこではない、あるいはエラーの範囲が広すぎて原因の特定に繋がっていないということが多いからです。そういったケースでは、「これこそが本質的な原因だ！」というのを突き止める必要があります。少なくとも、エラーが出ている可能性を絞る必要があります。
例えば、「AをしたらGになるはずなのにエラーが出る」という場合は、A→B→C→D→E→F→Gのどこからどこまでは想定通り動いていて、どこで初めてエラーが出るのか（想定と違う挙動をしているのか）を確かめていく必要があるということです。
ここでは、デバッガーを活用しましょう。最初はDあたりにデバッガーをはさんで、正常に（こちらの想定通りに）動いているか確認します。もし想定どおりであれば、本質的な原因はその後（EFGのどこか）にあるわけですし、そこですでにおかしいなら、その前（BCDのどこか）に原因が眠っているとわかります。
そうして、
A→Gでエラーが出る
とざっくりとしたことしかわからない状態から、
E→Fでエラーが出る
とピンポイントでわかるようになると、解決の道を大きく前進することができます。
これがほぼ答えになる場合も多いです。
あとは、絶対にうまくいくはずのG'(Gダッシュ)があるなら、
A→G’
と
A→G
を比較して、差分を見る方法もあります。「これだとうまくいくんだけど、これだとうまくいかない」というやつです。その差分を埋めてあげれば良いわけですからね。この過程で、足りない自分の知識が明確になることも多いです。実はここの情報の受け渡しの理解が曖昧だった、とか、このメソッドの挙動を勘違いしていた、など。それがわかれば、それを次の６「切り分け後のキーワードで調査・学習」でググればよいのです。
６．切り分け後のキーワードで調査・学習（1分〜3分）
問題の切り分けができていれば、何をググればいいかは自ずとわかると思います。逆に、何でググればいいのかわからないのは、知識が足りていないというよりも、問題の切り分けがまだ甘いことが多いです。ですからその場合は５「問題を切り分ける」が不十分なのでは？と疑ってみましょう。問題の切り分けができて、それを元に調査すれば、95%のエラーは解決できます。
ただ、もし、
- 問題の切り分けは十分（＝明確に具体的に「ここでこうなるはずなのにこうなってしまう！おかしい！」と言える状態）なのに解決に至らない
- そもそも問題の切り分け自体が難しい（所謂ちんぷんかんぷんな状態）
そんな場合に当たったら、次の７「質問する」に進みましょう。そこを質問すると良いです。
目安として、エラー文を出してからここまで15分以内に解決できないようなら、それが今のあなたの実力と割り切って、次の７「質問する」へいきましょう。残りの５％の当たったのです。（私はなかなかこれが難しく、ググり続けたり問題の切り分けをダラダラと続けてしまいます・・・）
７．質問する（人に相談する）
15分以内にひとつのエラーを解決できなかった場合は、１〜６を踏まえた上で質問しましょう。１〜６を経てから質問するのが望ましいですが、１「エラー文を出す」や５「問題を切り分ける」で詰まることもあると思いますので、その場合は気にせず15分の目安の方を優先してください。
隣に先輩エンジニアがいる場合はそのまま聞けばよいですが、込み入ったエラーの場合はslackや質問サイトなどで質問する時と同様、一度文章にする方がよいでしょう。つまり、まずすべきは質問文の作成（＝エラー内容の整理）です。
中には、質問文を書いているときに解決することもあります。質問文を書きながら、上記１〜６で足りないところを発見し、それを詰めていったら解決に繋がった、というケースが少なからずあるのです。あれは不思議な感覚ですね。なんでもっと早く気づかなかったんだろうという感じです。そんなこともあるので、15分悩んだら質問文を書き始めることをオススメします。
残念ながら(？)、解決せずに質問文を書きあげてしまったら、大人しくそのまま質問すれば良いのです。１〜６のステップで練り上げられた質問ですから、恥ずかしいことはありません。
質問できる場がない人は、オンラインコミュニティやQ&Aサイトを活用してください。もしそれに多少のコストがかかるとしても、その方が圧倒的に速く、何より質の高い学びが得られます。例えば、
月2,980円で質問し放題：
サブスク型プログラミングスクール「SAMURAI ENGINEER Plus+」
無料が良ければこちら：
ITエンジニア特化型Q&Aサイト「teratail」
個人的には、30分で現場のエンジニアから回答がもらえるのであれば、月３千円くらいであれば自己投資としては安いので入っておいて損はないと思います。私も、プログラミングスクールに入って一番良かったことは、質問し放題の環境や先輩エンジニアとのつながりでした。サブスク型なら、気に入らなければいつでも辞められますし。
なお、「どんな質問文を書くか？」を含む「質問の仕方」は重要です。超重要である故に、これに関しては色んな本やサイトで既に述べられていることなので本記事では割愛します。例えば手始めに下記のような記事を参照していくと良いでしょう。
【もっと自分で考えたら？と言われる前に】思考を深めるのに必要な思考法（IQAサイクル）
何かより良い解が見つかったら記事にしますね。然るべき人に、然るべき「質問の仕方」で相談すれば、99%のエラーは解決するでしょう。え、残りの1%は何かって？それは次のステップで解説します。
８．諦める
質問したけど、解決できない、残りの1%のエラーに当たることがあるかもしれません。自分自身の実力や質問の仕方、質問に回答する方の実力や状況によりますが、もちろんそういったこともあるのです。
そんな時に何時間も「エラー解決」に時間を注ぐのは賢くありません。多くの人が陥りがちな罠ですが、本質的に達成したいことは「エラー解決」ではないからです。改めて状況を整理すれば、「◯◯しようとしたらエラーが出た」あるいは「エラーを解決して◯◯できれば良い」という状況のはずです。ですから、要するに最終的な目的はその「◯◯すること」なのです。問題の解決と、目的の達成は似て非なるものです。手段を目的化しないようにしましょう。つまり、原因究明＆問題解決は諦めて、「エラーを解決しなくても済む道＝代替案」を模索しましょう。
例えば、
- やり直せるならやり直す（git reset –hardなど）
- 別の手法で代替できないか検討
などです。先輩に相談した結果、すぐにこちらに導かれることもままあります。仕事の出来るエンジニアほど、「やり直し」「代替案」を常に意識しながら相談に乗ってくれているような気がします。
やり直す方面では、こちらめっちゃお世話になってます。
正面からエラーと向き合い、きちんと原因を究明して、きれいに問題を解決して次に進みたい気持ちはよーくわかります。その方が勉強になりますし、何より気持ち良いですからね。しかし、時は金なり。趣味でプログラミングそれ自体（or 知的好奇心の充足）を目的としているならそれでいいかもしれませんが、何か別の目的（プログラマーになりたい、あるサービスを開発したい、この仕事を達成したい、など）のためにプログラミングをしているなら、生産性は常に意識しないといけません。その結果、エラーから逃げる形になったとしても、それは詮無いことです。その分の時間でより多くのコードを書き、より多くのエラーを経験しましょう。短期的な利益より、長期的な利益です。その方がトータルで勉強になり、実力も上がり、幸せな生活が送れることでしょう。私はそう信じて割り切っています。
まとめ
エラー解決手順を再掲します。
- エラー文を出す
- エラー文を読む
- タイポや保存などチェック
- エラー文を検索
- 問題を切り分ける
- 調査・学習 （ここまで15分以内に）
- 質問する
- やり直す or 代替案模索
１〜２はエラー解決の準備、７〜８は自分で解決できなかった場合の話なので、実質的には３〜６の４ステップを覚えておけばOKです。ポイントは、
- きちんとエラー文を出してきちんとエラーの意図を理解すること。
- 一度簡単に確認できることをチェックしてからエラー文でググること
- ダラダラとググり続けずにデバッグして問題を切り分けること
- 15分以内に解決出来なければ質問する準備に移ること
を押さえておくことです。
ところで、なぜ15分なのか、という疑問を覚える方もいるかと思いますので、最後に、Google人工知能チームの「15分ルール」をご紹介します。この記事は、このルールと、その他で得た知識、私の体験がベースとなっています。
15 min rule: when stuck, you HAVE to try on your own for 15 min; after 15 min, you HAVE to ask for help.
問題が起きた時は
【1】最初の15分は自分自身で解決を試みる
【2】15分後も解決していなかったら必ず人に聞く
前者を守らないと他人の時間を無駄にし、後者を守らないと自分の時間を無駄にする。
Rachel Thomas氏のtwieetより
自分の時間も他人の時間も、人類にとっては大切なリソースです。どちらも大事にしつつ、快適なプログラミングライフを送りましょう！
質問する場所がない人は、まずはその場を確保！！
サブスク型プログラミングスクール「SAMURAI ENGINEER Plus+」
注：文中の「ここまでで◯%のエラーは解決できる」は私の所感です。個人差もあります。理論や統計に基づくものではありませんので、ご留意ください。
最後まで読んでくださってありがとうございました！
画像提供：Gerd AltmannによるPixabayからの画像
コメント