なにかトラブルが発生したとき、解決できるのはその分野にくわしい人だけとおもってませんか？
詳しくなくとも、どこの何が悪いのか、特定することはできます。
どこが悪いのか分かれば、かんたんなものなら自分で治せます。
または使い方を工夫して問題がおこらないようにすることもできます。
人に相談することもできますし、修理を依頼することも出来る。何でもできちゃいます。
この記事では、私がやってるやり方をご紹介します。
今の状態を確認しよう
どこが悪いのかを見つけるのに専門スキルは必要ないと思います。もちろんあったほうがいいですが。
ただ事実をみつけて掘り下げていくだけです。
やり方を先に書いてしまうと、以下の４ステップです。
- メッセージやログファイルになんと表示されているかをみる
- ユーザーガイドなどのマニュアルをさがす
- Google 検索する
- あれこれ操作してみて動作を確認する
順に説明していきます。
① エラーメッセージやログファイルを確認する
最初にエラーメッセージやログファイルに何が出力されているかを確認します。
何が起こったかはエラーメッセージや、エラーコード（E01 など）を見ないとわかりません。
家電などは液晶やディスプレイにエラーコードが表示されます。
ソフトウェアではリターンコードやログファイルを確認します。
大量のログファイルの中からエラーを探すときは grep コマンドをつかう
サーバー・プログラムなどは大量のログファイルやトレースファイルにエラーが記録されてます。
エラー内容を見るには grep コマンドで検索します。
Error や fail, exception などのエラーメッセージにありそうな言葉で検索します。すると大抵何かが見つかります。
テキストビューワーやエディターで探すと、見落としがちです。
とくに最近の Apache や Docker 関係のサーバープログラムには複数のログファイルにまたがって記録されていることも多いので、一気に検索するには grep コマンドを使ったほうが速いのです。
そういうわけで最近は grep コマンドを重宝しています。
● 参照リンク：grep – パターンにマッチする行を表示 – Linuxコマンド
このとき日付に注意します。昔発生したエラーをみつけて見当違いな調査をしても時間の無駄になりますので。（それが原因の場合もありますが・・・）
(スポンサーリンク)
② ユーザーガイドなどのマニュアルをさがす
ログやエラーコードを確認できたら、次にやることはユーザーズガイドなどのマニュアルを確認することです。
大抵のことはマニュアルに対応方法が書いてます。マニュアルがないときは、メーカーのサイトからダウンロードします。
電化製品では製品番号がシールで貼られていますので、google でメーカー名と製品番号を入力して検索をかけるとたいてい見つかります。
ソフトウェアだと、製品番号の代わりにソフトウェア名とバージョン番号で検索します。
③ Google で検索すると、だれかが対応方法を書いている
ソフトウェアのトラブルについては大抵インターネットで探すと対処方法が見つかります。
その時は上で調べたログファイルのエラーメッセージや出力、エラーコードを入力します。
このとき、検索エンジンのキーワード（コマンド）を知っていると便利です。
google だと “site:” や “- （マイナス)” などです。下記のリンクで Google のコマンドを確認できますので確認してみてください。(google のサイトにジャンプします）
最近は Twitter も使うときがありますが、Twitter にも “from:” などがあります。下のリンクで Twitter の検索コマンドを確認できます。（別サイトにジャンプします）
● 参照リンク：Twitter（ツイッター）の検索コマンド全22選 日付やアカウントを指定して探す
検索では広告サイトや似たような企業サイトばかり検索にかかることもあるので、そういうのを検索結果から除外したり、決まったサイトだけ検索するなど、で検索効率をあげます。
この辺は検索のスキルが物を言うので、日頃から検索エンジンは使っているといいです。
④ あれこれ操作してみて動作を確認する
故障かな？と思ったときはいろいろと操作してみるといいです。私も大抵そうします。
「動かない」と思ってたけど、実は反応が悪いだけ、とか
他のやり方だとうまくいくけど、特定の方法だとうごかない、とか
こういう発見があり、何が発生しているのかが、より正確にわかるからです。
ただの電池切れかもしれないし、どこかが断線してるだけかもしれません。そういうときはサポートに電話しなくても、すぐもとに戻せます。
後でサポートに電話するにしても、より正確に症状を説明できるのでサポートする方も助かります。
いつからトラブルが発生しているのかの確認も大事
時間軸にそって確認することも大事です。
以前は動いていたのなら、いつから発生してるのか
その直前になにか発生してなかったか、なにか操作しなかったか
時間軸に沿って、何でもいいから思い出すようにします。
これは KT法の問題分析 (PA) の手法です。
いきなり KT法が出てきて、頭が痛くなったかもしれませんが・・・（笑）
いつから発生しているのかわかれば、基本的にその前の状態に戻せばいいのです。
どこをどう操作してそうなってしまったのかわかれば、戻せますよね。
もともと KT法の問題分析って、こういう使い方をします。
ヘルプデスクに連絡して、なおしてもらう
もうどうしようもなくなったら、最後の手段でヘルプデスクに連絡して来てもらうようにします。
その時、それまでやった調査結果が役に立ちます。
調査結果について具体的に話すことができれば、相手もよく理解してくれるでしょう。
トラブルが長引く原因の多くはコミュニケーションの仕方が悪いことなので、そういうことを避けるためにも説明は具体的にします。
最後までよんでいただいてありがとうございました。
論理的思考の参考書は以下の記事に書かれています。
KT法については以下の記事に詳しいです。
