トラブルシューティングを当たり前のようにやってきた私は、その知識と経験を活かし、トラブルシューティングの概念を整理し、具体例を添えて体系的に書くことにしたことにした。

本記事は、基礎講義のような内容になっており、専門家でない人の問題解決の手助けになると思うのでぜひ読んでみてほしい。

まず、トラブル（不具合事象）について解説する。

基本的に不具合事象の原因とは、次のうちのどれかに当てはまる。

・ハードウェアの不具合
・ソフトウェアの不具合
・設定ミス
・仕様（既知の不具合だが、改修しない。運用で回避する）
・環境要因

トラブルシューティングには、まず、切り分け作業を行う。

切り分けとは、どの範囲で不具合が発生しているかを特定する作業だ。

たとえば、ハードウェアの不具合の場合、不具合が発生しているであろう被疑箇所について、どういう条件下でどのような事象が発生するか、つまり正常動作か異常かをひとつひとつ確認していき、問題となっている部分を特定する。

問題となっている部分が特的できたら、その部分（パーツ）を正常なものと交換し、正常に動作をするか確認するわけだ。

ソフトウェアの不具合の場合は、まず、不具合が発生した際のエラーメッセージを確認するとことから始める。対象が汎用品であれば、Googleなどの検索サイトでそのエラーメッセージを検索してみると良い。

検索するときの注意点としては、エラーメッセージは、完全一致で検索するため、ダブルクォーテーション「“”」で囲むこと。

検索結果に有効な情報がない場合は、不具合が発生しているものの言語設定を英語に変えて、英語でのエラーメッセージで検索してみると良い。

設定ミスの場合は、不具合を特定するのに相当な知識や経験が必要にはなるが、それが無くとも不具合事象が発生する直前に設定の変更がなかったかを確認することで問題となっている部分を特定することができる場合が多い。

仕様の場合については、メーカの技術資料を見ていくしかないが、必ずしも公開されているとは限らない。また、膨大な英語のドキュメントをくまなく読むことが要求されることもある。

仕様を確認して不具合事象の原因を特定するのが難易で高いため、効率的に行うのであれば、不具合事象の発生した時期に OSのアップグレードがなかったかを疑ってみるのも近道かもしれない。

不具合事象をキーワードにインターネットで検索をかけ、同事象の不具合が同時期に確認できた場合は、仕様上の変更がトリガーとなって不具合が生じた可能性が高いと考えていいだろう。

いずれにしても仕様による不具合事象は、運用によって回避するしかない。

先述の例であれば、不具合事象が発生するOSを使用しないために、以前のOSにダウングレードする作業を行うことで不具合事象を回避するのだ。

最後に環境要因だが、これは、個別具体的な周囲の環境の変化を調査することで、不具合事象の発生原因を特定することができる。

射程をどこまで伸ばすかによって調査に掛かるコストは変わってくるが、まずは自身が所属している場所で管理されている機器の構成の変更点を確認してみることから始めよう。
また、物理的な変化だけにとどまらず、月々に利用しているサービスの内容や契約の変更も環境要因として調査してみるとよい。

たとえば、運営しているホームページのドメイン更新忘れがきっかけとなり、ウェブサーバがダウンしていないにもかかわらず、ホームページにアクセスできなくなったというのは、環境要因の例として有名だろう。

以上

さいごに

この記事が役だったと思った方は、以下の [拡散で応援して購入] または [定価で購入] からご購入していただけると大変嬉しく思います。