エラーが出たときに最初に確認する5つのこと

プログラミングをしていると、必ずと言っていいほどエラーに遭遇します。

画面が真っ白になる。

コマンドが動かない。

ボタンを押しても反応しない。

保存したはずなのに変更が反映されない。

こうしたとき、焦ってコードを何度も書き換えてしまう人は少なくありません。

しかし、エラー対応で大切なのは、いきなり修正することではありません。

まずは、今どこで何が起きているのかを整理することです。

今回は、エラーが出たときに最初に確認したい5つのポイントを紹介します。

1. エラーメッセージを最後まで読む

最初に確認するべきなのは、画面に表示されているエラーメッセージです。

英語で書かれていることも多いため、読む前から避けたくなるかもしれません。

ただし、エラーメッセージには原因を特定するための情報が含まれています。

例えば、次のような内容です。

ファイルが見つからない

コマンドが存在しない

文法が間違っている

必要なパッケージが入っていない

指定したポートが使用中

権限が不足している

エラーメッセージを読まずに修正を始めるのは、地図を見ずに迷路を進むようなものです。

すべての英語を理解する必要はありません。

まずは、次の部分を探してみましょう。

Error

Failed

Not found

Cannot

Invalid

Unexpected

Permission denied

また、ファイル名や行番号が表示されている場合は、必ず確認します。

例えば、次のような表示です。

style.scss 32:5

これは、style.scssの32行目付近に問題がある可能性を示しています。

エラーが出たら、まずメッセージを消さずに、そのまま読む習慣をつけることが重要です。

2. 今いるフォルダが正しいか確認する

ターミナルでコマンドを実行するときによくあるのが、作業するフォルダを間違えているケースです。

例えば、次のコマンドを実行したとします。

npm run sass:watch

しかし、現在いるフォルダにpackage.jsonがなければ、正しく実行できません。

同じように、

dotnet run

を実行しても、プロジェクトファイルがない場所では動きません。

現在いる場所は、次のコマンドで確認できます。

pwd

フォルダ内のファイルは、次のコマンドで確認できます。

ls

Windowsの場合は、次のコマンドを使うこともあります。

dir

エラーが出たときは、コードそのものを疑う前に、次の点を確認しましょう。

正しいプロジェクトフォルダにいるか

必要なファイルが存在するか

実行するコマンドが、そのプロジェクト用のものか

意外と多いのが、フォルダを一つ上や下に移動するだけで解決するケースです。

3. ファイル名・パス・スペルが合っているか確認する

プログラムは、人間が考えている以上に文字の違いに厳密です。

例えば、次の2つは別の名前として扱われることがあります。

style.css

Style.css

また、次のような小さな違いでもエラーの原因になります。

images

image

main.js

main.ja

assets/css/style.css

asset/css/style.css

特に確認したいのは、次の項目です。

ファイル名のスペル

フォルダ名のスペル

大文字と小文字

拡張子

相対パス

スラッシュの位置

全角文字や余計な空白

コピーしたコードでも、環境によってフォルダ構成が違えば、そのままでは動きません。

「コードは合っているはず」と思ったときほど、ファイル名やパスを確認するべきです。

見た目では同じように見えても、全角スペースや特殊な引用符が混ざっていることもあります。

例えば、次の引用符は見た目が似ています。

"

”

しかし、プログラム上では別の文字です。

エラーの原因は、難しいロジックではなく、単純な入力ミスであることも少なくありません。

4. 保存されているか・変更が反映されているか確認する

コードを直したのに動かない場合、そもそもファイルが保存されていない可能性があります。

基本的なことですが、実際によく起こります。

まずは、変更したファイルが保存されているか確認しましょう。

また、保存されていても、次のような理由で変更が反映されないことがあります。

ブラウザのキャッシュが残っている

Sassの監視コマンドが止まっている

ビルドを実行していない

開発サーバーを起動していない

別のCSSファイルを読み込んでいる

修正しているファイルと表示中のファイルが違う

本番環境とローカル環境を見間違えている

ブラウザで確認している場合は、スーパーリロードも試します。

Macの場合は、次のキーです。

Command + Shift + R

Windowsの場合は、次のキーです。

Ctrl + F5

また、SassやJavaScriptのビルド環境では、ターミナルにエラーが出て監視処理が停止していることもあります。

画面だけでなく、ターミナル側も確認しましょう。

「修正したのに変わらない」という問題は、コードの内容ではなく、変更が読み込まれていないだけの場合があります。

5. 直前に変更した箇所を戻してみる

エラーが出たときは、直前に何を変更したかを思い出します。

エラーの原因は、最後に触った箇所にある可能性が高いからです。

例えば、次のような変更です。

新しいコードを追加した

ファイル名を変更した

フォルダを移動した

パッケージを追加した

設定ファイルを書き換えた

コマンドを実行した

プラグインを更新した

複数の箇所を一気に変更すると、どこが原因なのか分からなくなります。

そのため、エラー対応では、一度に多くの箇所を直さないことが重要です。

まずは直前の変更を一つ戻し、動くか確認します。

動いた場合は、その変更箇所に原因があると判断できます。

Gitを使っている場合は、変更差分を確認すると原因を探しやすくなります。

git diff

また、変更前に細かくコミットしておけば、正常に動いていた状態と比較できます。

エラーが出たときに困らないためにも、普段から変更を小さく分けることが大切です。

エラーが出たときに、やってはいけないこと

エラーが出たときに避けたいのは、原因が分からないままコードを次々と変更することです。

適当に修正を続けると、最初のエラーに加えて別の問題まで発生します。

また、検索して見つけたコードを、意味を理解せずに貼り付けるのも危険です。

環境やバージョンが違えば、同じ方法では解決しない場合があります。

エラーが出たときは、次の順番で進めるのがおすすめです。

エラーメッセージを読む

現在地とファイルを確認する

ファイル名やパスを確認する

保存・ビルド・反映状況を確認する

直前の変更を戻す

ここまで確認しても解決しない場合に、エラーメッセージを検索したり、詳しい人に質問したりします。

質問するときは状況を整理する

誰かに質問するときに、「動きません」だけでは原因を特定できません。

少なくとも、次の情報を伝える必要があります。

何をしようとしたのか

どのコマンドを実行したのか

どのファイルを編集したのか

どのエラーが表示されたのか

直前に何を変更したのか

本来どう動いてほしかったのか

可能であれば、エラーメッセージは省略せずにそのまま共有します。

スクリーンショットだけでなく、コピーできる文字として送ると、検索や確認がしやすくなります。

質問の仕方を整えることも、エラーを解決するための重要なスキルです。

まとめ

エラーが出ると、自分にはプログラミングが向いていないと感じる人もいます。

しかし、エラーが出ること自体は失敗ではありません。

プログラミングでは、エラーの原因を一つずつ切り分けていく作業が必要です。

最初に確認したいのは、次の5つです。

エラーメッセージを最後まで読む

今いるフォルダが正しいか確認する

ファイル名・パス・スペルを確認する

保存・ビルド・反映状況を確認する

直前に変更した箇所を戻してみる

エラー対応が上手い人は、すべてのエラーを暗記しているわけではありません。

何を確認すれば原因を絞り込めるのかを知っています。

すぐに答えを探すのではなく、まず状況を整理する。

この習慣が身につくと、エラーに対する苦手意識は少しずつ減っていきます。