[インストラクター] このレッスンでは､ CompTIAのトラブルシューティング方法のステップ2についてお話します｡
これは6つのステップのうちのステップ2であり､
ステップ2では､ 正当な理由の理論を確立し､
明白な疑問を呈したい｡
また､ 必要に応じて､ 観察している症状に基づいて外部調査や内部調査を行うことになる｡
つまり､ 推定原因説を確立するということは､
ここまで観察してきたすべての症状に基づいて､
何が問題なのかを推測しようということなんだ｡
エンドユーザーからの最初の質問で良い答えが得られたなら､
どれだけの人が影響を受けているのか､ どの程度ひどいのか､ といった問題の深刻度を判断するのに役立つだろうし､
これはハードウェアの問題なのか､ といった調査すべきことの大まかなアイデアも得られるだろう｡
ソフトウェアの問題ですか？
OSの問題なのか､ アプリケーションの問題なのか､
あるいはドライバーの問題なのか｡
これらのことはすべて､ 私たちが解明しなければならないことであり､
最初の質問をすべてやり返し､ 問題を特定することによって､ 私たちは今､
ケースを構築し､ 物事を解決するために次に何を試みるかについて､ 私たちの理論がどのようなものであるかを考え始めるための多くのデータを手に入れることができるはずだ｡
さて､ 正当な理由の立証について話すときには､
正当な理由とは何かについて話さなければならない｡
考えられる原因というのは､
起こりうるさまざまな原因について話すことだが､
最も可能性が高いのはどれだろう？
例えば､ 宇宙人がやってきて､ あなたのコンピュータの断片をスクランブルした可能性はあるが､
おそらく可能性は低いだろう｡
だから､ 可能性としては非常に低いかもしれないが､
それが私の考えられる原因だとは思わない｡
だから､ そのことを覚えておいてほしい｡
正当な理由を考えるときには､
何が最もありそうなことなのかを考える必要がある｡
というのも､ おそらく考えられることは3つか4つあるだろうから､
可能性の高いものを選びたいと思うはずだ｡
まずそれを試して､ 問題を解決し､ もしそれで問題が解決しないようなら､ 後でもう一度戻ってきて､
何が問題だったのかを正確に特定するまで､ 2番､ 3番､ 4番を試すことになる｡
ここでは､ 可能な限り効率的かつ効果的な方法で物事を進めながら､
可能性のある問題を見落とさないよう､
体系的な方法で行うことを忘れてはならない｡
例えば､ Netflixでビデオを見ていたユーザーが突然動かなくなったとする｡
テレビが消されていたり､ 電気代が支払われていなかったり､
インターネットのサービスが停止していたり｡
ネットフリックスがダウンしている可能性もあるし､ ネットフリックスを視聴しているテレビとインターネットに接続するためのワイヤレスネットワークが送信不能になり､
リンク切れを起こしている可能性もある｡
これがアイデアだ｡
問題はたくさんあるが､ 今はその中から最も可能性が高いと思われるものを1つ選び､
それが我々が追い求める推定原因だ｡
ここでも､ 私は常に明白なことを疑うことを忘れないようにしたい｡
Netflixのようなものを考えているなら､
彼らは本当に大きな会社で､ ほとんど常にサーバーを稼働させておくという本当に良い仕事をしている｡
つまり､ システムやインターネット接続に問題があるというよりも､
ネットフリックスがダウンしている可能性の方が低いだろう｡
だから､ Netflixやそのサーバーを非難する前に､
まずそれらをチェックしたほうがいいかもしれない｡
理論を確立し､ 考えられる原因を選ぶことに加えて､
私たちは目にした症状に基づいて内部または外部の調査を行う｡
例えば､ ネットフリックスの例で､ 私の問題なのかネットフリックスの問題なのかを確認する最も簡単な方法のひとつは､
オンラインでDowndetectorのようなサイトにアクセスし､
netflixと入力することだ｡
comに移籍した｡
そのウェブサイトは､ さまざまなウェブサイトが稼働している､ あるいはダウンしているという他のユーザーを追跡し､
報告している｡
Netflixがダウンしていると思ったら､ Downdetectorをチェックし､
他の人が同じ問題を抱えているかどうかを確認することができる｡
これもまた､ 推定される原因が本当の原因なのか､
それとも別の推定される原因を見つける必要があるのかを確認するのに役立つだろう｡
それに加えて､ 技術者としてすべてを知っているわけではないが､
少なくとも調べたり答えを見つけたりする方法を把握することはできるはずだ｡
例えば､ 私はこの仕事を20年以上やっているが､
いまだに彼らについて知り尽くしていないと言える｡
とはいえ､ 私はリサーチのやり方を知っているので､
どんな問題でも解決できる｡
誰かがこの問題や症状､ エラーコードがあると言えば､
Googleや他の検索エンジンがあなたの一番の味方になってくれるから､ 私はそれらを調べることができる｡
あなたが日常的に行っていることの多くは､
Googleで回答することができ､ 適切に検索すれば､
通常はGoogleの1番目､ 2番目､
または3番目の結果になるはずです｡
だから､ あなたが観察している症状に基づいて調査することを恐れないでほしい｡
また､ 自分の理論を確立し､ 検証するために､
そのマシンを見て､ 物理的な検査をしたい｡
例えば､ マシンの前に行くと､ それを見て､
耳を傾けることになる｡
ファンが回る音がする？
ハードディスクのクリック音や研磨音が聞こえますか？
何か焦げ臭いにおいはしないか？
これらのどれもが症状であり､ そのシステムの何が問題なのかを知る手がかりとなる｡
例えば､ 焦げたような臭いがする場合､ プロセッサやマザーボード上のコンポーネントのいずれかが損傷している可能性があります｡
カチカチ､ ガリガリという音が聞こえたら､ ハードディスク・ドライブに異常があると考えられます｡
そのシステムで従来の機械式ハードディスク・ドライブを使用している場合｡
ファンが回転していないと聞いたら､
それは電源の問題か､ ファンの故障の可能性があります｡
これらはすべて､ 現地を視察すればわかることだ｡
もうひとつ覚えておいてほしいのは､
システムを修理しようとしたときに､
もともとあった症状がなくなっていることがある｡
大組織のヘルプデスクやサポートシステムで働くと､
このようなことがよく起こる｡
たとえば､ 私が働いていたある組織では､ 技術者をデスクに派遣してコンピュータを修理するのに通常1～2日かかった｡
だから､ もし今日､ プログラムがクラッシュするなどの問題があったとしても､
2日間､ ただそこに座って仕事をしないわけにはいかない｡
その代わりに､ おそらくマシンを再起動し､
回避策を試し､ 根本原因として抱えている問題を誰かが直してくれるのを待っている間に､
できるところから仕事を再開することになるだろう｡
その間､ あなたは他のことをしていて､
他の症状が出てくるかもしれない｡
もしあなたがサポート技術者として働いていて､
誰かの問題を解決するために1日前か2日前にチケットを入れたとする｡
だから､ 彼らが最初に抱えていた問題を再現してみて､
エラーメッセージが再び表示されるか､
あるいはその他の症状が起こるかどうかを確認することになる｡
いくつかの問題は断続的に発生するが､
ほとんどの問題は再現できる｡
もし再現することができれば､
より多くの情報を得ることができ､
解決しようとしている原因が正しいかどうかを見極める助けになるだろう｡
もうひとつ､ リサーチをする際に考えておかなければならないのは､
ネット上だけでなく､ システム自体でもリサーチを利用できるということだ｡
各システムにはそれぞれのシステム・ドキュメントがある｡
インストールログやイベントログがあり､
何がうまくいっていて何がうまくいっていないのかを把握するための診断ツールもある｡
そして､ これらのことはすべて､ システムについての詳細を知り､
特定の故障や問題の原因と思われるものを知るための内部調査の一部である｡
そして最後に､ もし他の誰かがすでにそのシステムに取り組んでいるのであれば､
彼らに話を聞き､ 彼らが何をしたのかを把握したい｡
もしあなたが中小企業で働いていて､
技術者があなただけなら､ 機械を修理しているのはおそらくあなただけでしょう｡
しかし､ もしあなたが大きな組織で働いているのであれば､
20人､ 30人､ あるいは数百人の他の人たちがこれらのチケットを扱っているかもしれない｡
彼らはすでに何に触れているのか？
あるいは､ その人が「このコンピューターにはいろいろ問題があるんだ｡
この4カ月で3人目の技術者が修理に来たのか？
では､
他の技術者たちにも話を聞きに行き､ 彼らが何をしたのかを把握しよう｡
彼らは何が問題だと考え､ それを解決するために何をしようとしたのか？
というのも､ まったく同じことをやっても､
おそらく直らないからだ｡ 過去2､
3回は直らなかったのだから｡
先週や先月､ 他の人がやったのと同じことをして時間を無駄にしていると感じ､ 顧客を怒らせるだけだ｡
つまり､ ステップ2の目標は､
正当な理由を立証することである｡
答えがわからなければ､ インターネットなどの外部文書や､
システム本体､ 診断ツール､ システムのログなどの内部調査を使って､ いつでも遠慮なく調べてください｡