WEBVTT 00:00.000 --> 00:05.130 [インストラクター] このレッスンでは､ CompTIAのトラブルシューティング方法のステップ2についてお話します｡ 00:05.130 --> 00:06.870 これは6つのステップのうちのステップ2であり､ 00:06.870 --> 00:09.600 ステップ2では､ 正当な理由の理論を確立し､ 00:09.600 --> 00:12.630 明白な疑問を呈したい｡ 00:12.630 --> 00:18.930 また､ 必要に応じて､ 観察している症状に基づいて外部調査や内部調査を行うことになる｡ 00:18.930 --> 00:21.180 つまり､ 推定原因説を確立するということは､ 00:21.180 --> 00:24.150 ここまで観察してきたすべての症状に基づいて､ 00:24.150 --> 00:27.900 何が問題なのかを推測しようということなんだ｡ 00:27.900 --> 00:30.300 エンドユーザーからの最初の質問で良い答えが得られたなら､ 00:30.300 --> 00:35.820 どれだけの人が影響を受けているのか､ どの程度ひどいのか､ といった問題の深刻度を判断するのに役立つだろうし､ 00:35.820 --> 00:41.730 これはハードウェアの問題なのか､ といった調査すべきことの大まかなアイデアも得られるだろう｡ 00:41.730 --> 00:43.020 ソフトウェアの問題ですか？ 00:43.020 --> 00:45.180 OSの問題なのか､ アプリケーションの問題なのか､ 00:45.180 --> 00:47.100 あるいはドライバーの問題なのか｡ 00:47.100 --> 00:49.110 これらのことはすべて､ 私たちが解明しなければならないことであり､ 00:49.110 --> 00:52.500 最初の質問をすべてやり返し､ 問題を特定することによって､ 私たちは今､ 00:52.500 --> 01:01.710 ケースを構築し､ 物事を解決するために次に何を試みるかについて､ 私たちの理論がどのようなものであるかを考え始めるための多くのデータを手に入れることができるはずだ｡ 01:01.710 --> 01:03.810 さて､ 正当な理由の立証について話すときには､ 01:03.810 --> 01:08.070 正当な理由とは何かについて話さなければならない｡ 01:08.070 --> 01:09.840 考えられる原因というのは､ 01:09.840 --> 01:12.330 起こりうるさまざまな原因について話すことだが､ 01:12.330 --> 01:16.050 最も可能性が高いのはどれだろう？ 01:16.050 --> 01:21.960 例えば､ 宇宙人がやってきて､ あなたのコンピュータの断片をスクランブルした可能性はあるが､ 01:21.960 --> 01:24.000 おそらく可能性は低いだろう｡ 01:24.000 --> 01:26.190 だから､ 可能性としては非常に低いかもしれないが､ 01:26.190 --> 01:29.970 それが私の考えられる原因だとは思わない｡ 01:29.970 --> 01:31.350 だから､ そのことを覚えておいてほしい｡ 01:31.350 --> 01:33.060 正当な理由を考えるときには､ 01:33.060 --> 01:36.420 何が最もありそうなことなのかを考える必要がある｡ 01:36.420 --> 01:38.460 というのも､ おそらく考えられることは3つか4つあるだろうから､ 01:38.460 --> 01:40.320 可能性の高いものを選びたいと思うはずだ｡ 01:40.320 --> 01:45.660 まずそれを試して､ 問題を解決し､ もしそれで問題が解決しないようなら､ 後でもう一度戻ってきて､ 01:45.660 --> 01:52.350 何が問題だったのかを正確に特定するまで､ 2番､ 3番､ 4番を試すことになる｡ 01:52.350 --> 01:55.440 ここでは､ 可能な限り効率的かつ効果的な方法で物事を進めながら､ 01:55.440 --> 01:57.660 可能性のある問題を見落とさないよう､ 01:57.660 --> 02:01.320 体系的な方法で行うことを忘れてはならない｡ 02:01.320 --> 02:09.870 例えば､ Netflixでビデオを見ていたユーザーが突然動かなくなったとする｡ 02:09.870 --> 02:12.030 テレビが消されていたり､ 電気代が支払われていなかったり､ 02:12.030 --> 02:15.330 インターネットのサービスが停止していたり｡ 02:15.330 --> 02:23.790 ネットフリックスがダウンしている可能性もあるし､ ネットフリックスを視聴しているテレビとインターネットに接続するためのワイヤレスネットワークが送信不能になり､ 02:23.790 --> 02:26.970 リンク切れを起こしている可能性もある｡ 02:26.970 --> 02:27.803 これがアイデアだ｡ 02:27.803 --> 02:32.520 問題はたくさんあるが､ 今はその中から最も可能性が高いと思われるものを1つ選び､ 02:32.520 --> 02:35.400 それが我々が追い求める推定原因だ｡ 02:35.400 --> 02:38.940 ここでも､ 私は常に明白なことを疑うことを忘れないようにしたい｡ 02:38.940 --> 02:40.890 Netflixのようなものを考えているなら､ 02:40.890 --> 02:47.250 彼らは本当に大きな会社で､ ほとんど常にサーバーを稼働させておくという本当に良い仕事をしている｡ 02:47.250 --> 02:50.130 つまり､ システムやインターネット接続に問題があるというよりも､ 02:50.130 --> 02:53.700 ネットフリックスがダウンしている可能性の方が低いだろう｡ 02:53.700 --> 02:55.650 だから､ Netflixやそのサーバーを非難する前に､ 02:55.650 --> 02:58.500 まずそれらをチェックしたほうがいいかもしれない｡ 02:58.500 --> 03:00.960 理論を確立し､ 考えられる原因を選ぶことに加えて､ 03:00.960 --> 03:07.590 私たちは目にした症状に基づいて内部または外部の調査を行う｡ 03:07.590 --> 03:12.330 例えば､ ネットフリックスの例で､ 私の問題なのかネットフリックスの問題なのかを確認する最も簡単な方法のひとつは､ 03:12.330 --> 03:14.700 オンラインでDowndetectorのようなサイトにアクセスし､ 03:14.700 --> 03:19.170 netflixと入力することだ｡ 03:19.170 --> 03:19.170 comに移籍した｡ 03:19.170 --> 03:22.380 そのウェブサイトは､ さまざまなウェブサイトが稼働している､ あるいはダウンしているという他のユーザーを追跡し､ 03:22.380 --> 03:24.270 報告している｡ 03:24.270 --> 03:26.250 Netflixがダウンしていると思ったら､ Downdetectorをチェックし､ 03:26.250 --> 03:30.270 他の人が同じ問題を抱えているかどうかを確認することができる｡ 03:30.270 --> 03:32.310 これもまた､ 推定される原因が本当の原因なのか､ 03:32.310 --> 03:37.680 それとも別の推定される原因を見つける必要があるのかを確認するのに役立つだろう｡ 03:37.680 --> 03:40.290 それに加えて､ 技術者としてすべてを知っているわけではないが､ 03:40.290 --> 03:45.420 少なくとも調べたり答えを見つけたりする方法を把握することはできるはずだ｡ 03:45.420 --> 03:48.390 例えば､ 私はこの仕事を20年以上やっているが､ 03:48.390 --> 03:51.960 いまだに彼らについて知り尽くしていないと言える｡ 03:51.960 --> 03:54.570 とはいえ､ 私はリサーチのやり方を知っているので､ 03:54.570 --> 03:58.020 どんな問題でも解決できる｡ 03:58.020 --> 03:59.640 誰かがこの問題や症状､ エラーコードがあると言えば､ 03:59.640 --> 04:06.750 Googleや他の検索エンジンがあなたの一番の味方になってくれるから､ 私はそれらを調べることができる｡ 04:06.750 --> 04:08.910 あなたが日常的に行っていることの多くは､ 04:08.910 --> 04:11.490 Googleで回答することができ､ 適切に検索すれば､ 04:11.490 --> 04:13.590 通常はGoogleの1番目､ 2番目､ 04:13.590 --> 04:16.530 または3番目の結果になるはずです｡ 04:16.530 --> 04:20.520 だから､ あなたが観察している症状に基づいて調査することを恐れないでほしい｡ 04:20.520 --> 04:22.650 また､ 自分の理論を確立し､ 検証するために､ 04:22.650 --> 04:27.060 そのマシンを見て､ 物理的な検査をしたい｡ 04:27.060 --> 04:29.340 例えば､ マシンの前に行くと､ それを見て､ 04:29.340 --> 04:31.470 耳を傾けることになる｡ 04:31.470 --> 04:32.940 ファンが回る音がする？ 04:32.940 --> 04:36.810 ハードディスクのクリック音や研磨音が聞こえますか？ 04:36.810 --> 04:38.970 何か焦げ臭いにおいはしないか？ 04:38.970 --> 04:43.500 これらのどれもが症状であり､ そのシステムの何が問題なのかを知る手がかりとなる｡ 04:43.500 --> 04:49.650 例えば､ 焦げたような臭いがする場合､ プロセッサやマザーボード上のコンポーネントのいずれかが損傷している可能性があります｡ 04:49.650 --> 04:54.150 カチカチ､ ガリガリという音が聞こえたら､ ハードディスク・ドライブに異常があると考えられます｡ 04:54.150 --> 04:57.720 そのシステムで従来の機械式ハードディスク・ドライブを使用している場合｡ 04:57.720 --> 04:59.580 ファンが回転していないと聞いたら､ 04:59.580 --> 05:03.330 それは電源の問題か､ ファンの故障の可能性があります｡ 05:03.330 --> 05:07.080 これらはすべて､ 現地を視察すればわかることだ｡ 05:07.080 --> 05:08.250 もうひとつ覚えておいてほしいのは､ 05:08.250 --> 05:10.950 システムを修理しようとしたときに､ 05:10.950 --> 05:16.620 もともとあった症状がなくなっていることがある｡ 05:16.620 --> 05:18.561 大組織のヘルプデスクやサポートシステムで働くと､ 05:18.561 --> 05:21.960 このようなことがよく起こる｡ 05:21.960 --> 05:29.610 たとえば､ 私が働いていたある組織では､ 技術者をデスクに派遣してコンピュータを修理するのに通常1～2日かかった｡ 05:29.610 --> 05:32.910 だから､ もし今日､ プログラムがクラッシュするなどの問題があったとしても､ 05:32.910 --> 05:35.760 2日間､ ただそこに座って仕事をしないわけにはいかない｡ 05:35.760 --> 05:37.980 その代わりに､ おそらくマシンを再起動し､ 05:37.980 --> 05:41.280 回避策を試し､ 根本原因として抱えている問題を誰かが直してくれるのを待っている間に､ 05:41.280 --> 05:45.600 できるところから仕事を再開することになるだろう｡ 05:45.600 --> 05:47.700 その間､ あなたは他のことをしていて､ 05:47.700 --> 05:52.020 他の症状が出てくるかもしれない｡ 05:52.020 --> 05:55.680 もしあなたがサポート技術者として働いていて､ 05:55.680 --> 06:01.980 誰かの問題を解決するために1日前か2日前にチケットを入れたとする｡ 06:01.980 --> 06:04.050 だから､ 彼らが最初に抱えていた問題を再現してみて､ 06:04.050 --> 06:05.220 エラーメッセージが再び表示されるか､ 06:05.220 --> 06:08.880 あるいはその他の症状が起こるかどうかを確認することになる｡ 06:08.880 --> 06:11.010 いくつかの問題は断続的に発生するが､ 06:11.010 --> 06:13.020 ほとんどの問題は再現できる｡ 06:13.020 --> 06:14.610 もし再現することができれば､ 06:14.610 --> 06:16.380 より多くの情報を得ることができ､ 06:16.380 --> 06:20.880 解決しようとしている原因が正しいかどうかを見極める助けになるだろう｡ 06:20.880 --> 06:23.250 もうひとつ､ リサーチをする際に考えておかなければならないのは､ 06:23.250 --> 06:27.390 ネット上だけでなく､ システム自体でもリサーチを利用できるということだ｡ 06:27.390 --> 06:29.820 各システムにはそれぞれのシステム・ドキュメントがある｡ 06:29.820 --> 06:31.530 インストールログやイベントログがあり､ 06:31.530 --> 06:35.760 何がうまくいっていて何がうまくいっていないのかを把握するための診断ツールもある｡ 06:35.760 --> 06:38.610 そして､ これらのことはすべて､ システムについての詳細を知り､ 06:38.610 --> 06:44.010 特定の故障や問題の原因と思われるものを知るための内部調査の一部である｡ 06:44.010 --> 06:46.380 そして最後に､ もし他の誰かがすでにそのシステムに取り組んでいるのであれば､ 06:46.380 --> 06:50.010 彼らに話を聞き､ 彼らが何をしたのかを把握したい｡ 06:50.010 --> 06:51.510 もしあなたが中小企業で働いていて､ 06:51.510 --> 06:55.530 技術者があなただけなら､ 機械を修理しているのはおそらくあなただけでしょう｡ 06:55.530 --> 06:57.720 しかし､ もしあなたが大きな組織で働いているのであれば､ 06:57.720 --> 07:09.720 20人､ 30人､ あるいは数百人の他の人たちがこれらのチケットを扱っているかもしれない｡ 07:09.720 --> 07:10.890 彼らはすでに何に触れているのか？ 07:10.890 --> 07:14.760 あるいは､ その人が「このコンピューターにはいろいろ問題があるんだ｡ 07:14.760 --> 07:17.970 この4カ月で3人目の技術者が修理に来たのか？ 07:17.970 --> 07:17.970 では､ 07:17.970 --> 07:20.340 他の技術者たちにも話を聞きに行き､ 彼らが何をしたのかを把握しよう｡ 07:20.340 --> 07:22.950 彼らは何が問題だと考え､ それを解決するために何をしようとしたのか？ 07:22.950 --> 07:24.480 というのも､ まったく同じことをやっても､ 07:24.480 --> 07:26.640 おそらく直らないからだ｡ 過去2､ 07:26.640 --> 07:28.230 3回は直らなかったのだから｡ 07:28.230 --> 07:36.150 先週や先月､ 他の人がやったのと同じことをして時間を無駄にしていると感じ､ 顧客を怒らせるだけだ｡ 07:36.150 --> 07:37.803 つまり､ ステップ2の目標は､ 07:38.670 --> 07:47.430 正当な理由を立証することである｡ 07:47.430 --> 07:50.670 答えがわからなければ､ インターネットなどの外部文書や､ 07:50.670 --> 07:57.510 システム本体､ 診断ツール､ システムのログなどの内部調査を使って､ いつでも遠慮なく調べてください｡