インストラクター：このレッスンでは､
トラブルシューティングの方法論のステップ3､ 理論をテストすることについてお話しします｡
さて､ CompTIAはこれを､
原因を特定するために理論をテストすると書いている｡
その理論が確認されたら､ 問題を解決するための次のステップを決定する｡
理論が確認されない場合は､
新しい理論を再構築するか､ エスカレートさせる｡
ステップ1では､ 問題を特定した｡
ステップ2では､ その問題の原因として考えられるものを考えた｡
そしてステップ3では､
私たちの理論が正しかったかどうかを検証する｡
さて､ ここまでのところ､ 私たちはこの問題を考えるために多くの作業を行ってきたが､
その問題を解決しようとするためにシステムに何らかの設定や変更を行ったわけではない｡
そして､ ステップ3に入った今､ ようやくそれができるようになった｡
例えば､ 電源が入らないシステムがあったとしよう｡
電源が入らないシステムには様々な問題があるが､ 私たちはこのコンピュータがコンセントに接続されていないことが問題だと考えた｡
これは実に簡単な理論だ｡
タワーの背面からコンセントにつながるケーブルをたどって､
プラグが差し込まれているかどうかを確認すればいい｡
プラグを差し込み､ コンピューターの電源を入れて､
起動するかどうか見てみよう｡
もしそうなら､ それが問題だった｡
今､ 私たちはそれを確認し､
私たちの理論が問題を解決した｡
しかし､ そこに着いてケーブルが壁に差し込まれていなかったとしよう｡
ケーブルを壁に差し込み､
電源ボタンを押しても何も起こらない｡
コンピュータの電源はまだ入らない｡
これで､ プラグが抜かれていることが根本的な原因だという私たちの仮説は成り立たなくなった｡
だから､ 私たちは今､ 私たちが経験したさまざまな症状に基づき､
観察したことに基づき､ これまでやってきたことに基づき､ 新たな理論を構築する必要がある｡
だから私たちは､ 次に試みる理論や正当な理由が何なのかを見極める必要がある｡
この場合､ 私はコンセントが十分な電力を供給していないと言うかもしれない｡
そこで､ ステップ2に戻って新しい仮説を立て､
コンセントが問題だと思う､ と言う｡
今､ 私はステップ3に戻っている｡
その理論を検証する必要がある｡
そこでボルトメーターを手に取り､ 壁に差し込んでテストしてみると､
AC120ボルトが出ていることがわかった｡
そして､ 私はここアメリカにいるので､
それはまったく問題ない｡
だから､ それは僕の問題じゃない｡
だから､ 別の仮説を立てて､ もう一度やってみる必要がある｡
だから､ たぶん電源自体が問題なんだと思う｡
そして今､ 私はそれを新しい理論として使い､ それを確認するためにそれに向かって働き始めることができる｡
その理論を検証して､ もしそれが原因ではないとわかったら､
新しい理論を見つけなければならない｡
理論を検証し､ その理論が確認されれば､
次のステップは長期的な問題解決となる｡
つまり､ この時点で電源をテストし､
それが故障していることが判明すれば､
我々の理論が確定したことになり､ この時点で､
この問題を解決するための次のステップを決定する必要がある｡
電源の修理､ 電源の交換､
あるいはコンピューター全体の交換など､
その機器の年式や企業の方針によってさまざまだ｡
ステップ3で､ 原因を特定するために理論を検証する際に留意すべきもう一つの点は､
実際には4つの可能性があるということだ｡
一つ目は､ あなたの理論が確認され､ この場合はそれを修正するための措置を講じるということだ｡
もうひとつは､ あなたの理論が確証を得ていないので､ 新しい理論を考え出し､
その理論を検証してみる必要があるということだ｡
それを見つけたら､ 修正するんだ｡
3つ目は､ 問題を特定し､ 理論を検証し､
何が問題かを突き止めたが､
その問題を解決するスキルも権限もない場合だ｡
例えば､ この特定の修理には1万ドルの部品が必要で､
そのシステムでその部品を交換する権限がないことを確認したとする｡
この場合は､ そのサーバーや機器の担当チームにエスカレーションして､
その部品を交換するか､ その部品の交換を承認してもらうことになる｡
もう一つの側面は､ あなたにはまだそれを修理する技術がないということかもしれない｡
もしかしたら､ サポートしている複数のシステムで起きている問題を見つけたかもしれない｡
その結果､ 問題はWindowsサーバーからプッシュされたグループポリシーに関係していることがわかった｡
そこで､ この問題をWindowsサーバーグループにエスカレーションし､
そのチームがドメイン全体の全システムにプッシュしているポリシーと設定を変更して､
この大きな問題を解決できるようにする必要がある｡
もうひとつの問題は､ この問題をエスカレートさせ､
外部のサポートを導入しなければならない場合だ｡
もしかしたら､ このシステムが正常に動作しない理由は､
マルウェアに感染しているか､ システムに攻撃者がいて､
その攻撃者がシステムをコントロールしているからだとわかったかもしれない｡
その場合､ 技術者としては､
おそらくそれを修理するのではなく､ サイバーセキュリティの専門家を呼ぶことになるだろう｡
繰り返しになるが､ その多くは､ あなたの組織､ その組織がさまざまなレベルの技術者に与えている方針､
手順､ 権限に依存することになる｡
しかし､ 問題が起きたときにエスカレートさせるのも一つの手だということを覚えておいてほしい｡
さて､ 4つ目の可能性は､ 自分の理論を検証し､
たくさんの理論を考え出し､ 行き詰まることだ｡
何が正しい答えなのか分かっていない｡
あなたはこの問題を解決する方法を知らない｡
そのような場合は､ また次のレベルにエスカレーションする必要がある｡
ほとんどの組織では､ ティア1､ ティア2､ ティア3のサポート技術者からなる階層的なサポート構造をとっている｡
ティア1は最も基本的な問題をすべて解決する｡
時間が経つにつれて､ より多くのスキルを身につけ､
より高度な問題を解けるようになる｡
第3階層になると､
システム管理者､
サーバー管理者､ 暗号やサイバーセキュリティの専門家など､
専門分野のエキスパートを扱うようになる｡
時が経てば､ そのようなポジションに移ることもあるだろうが､
現在では､ 最初のスタート時点では､
おそらくティア1かティア2だろう｡
だから､ どう見極めればいいのか､
どう修正すればいいのかわからないこともあるだろう｡
そのような場合､ 若いユーザーのために問題を解決できるよう､
追加支援のためにチケットを第2層または第3層にエスカレーションすることになります｡