「トラブルシューティング」の版間の差分

削除された内容 追加された内容
編集の要約なし
編集の要約なし
3行目:
 
== 概要 ==
問題を解決するためには、正確な事実を状況把握し問題の根源を論理的・体系的に探る必要があり、順を追って解決してゆくのが一般的である。トラブルシューティングは、問題の原因を識別するために用いられる。原因として考えられる最も可能性の高いものを[[消去法]]で見出し、それを取り除き正常な状態に戻すための方法である。あらかじめ想定されたトラブルについて、解決方法がマニュアル化されたものを指すことが多い<ref>[http://www.sophia-it.com/content/%E3%83%88%E3%83%A9%E3%83%96%E3%83%AB%E3%82%B7%E3%83%A5%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0 トラブルシューティング] IT用語辞典</ref>。
 
例えば、それまで動いていたものが突然停止してしまった問題について考えてみよう。この場合、まず第一に、動いていた時と停止した時とで何が変わったのかに注目しなければならない。しかし、何か変化があったとしても、そこに[[因果関係]]があると早合点してはいけない。一般に[[相関|相関関係]]と因果関係は同じではない。
13行目:
その他手法として一旦正常な状態に戻す。例えば、
 
* コンピューターの[[ブート|リブート]]やバックアップからリストアをして正常に起動出来るかを試す。
* 機器に対して正しい結線や使用環境、操作を実施し動作を確認する(電源を入れる)。
*コンピューターの[[ブート|リブート]]や[[バックアップ]]から[[レストア|リストア]]をして正常に起動出来るかを試す。
* 機器の動作に必要な最低限の機器のみを接続させて動作を確認する([[最小構成]])。
*ソフトウェアの設定内容を把握している場合、設定を一旦[[デフォルト (コンピュータ)|デフォルト]]に戻したり[[再インストール]]を試す。
 
などが考えられる。
 
しかし利用状況次第ではすぐに問題解決のための手法は実行出来ない場合があり、なるべくリスクを追わない具体的な策が要求される事がある。(ネットワーク機器、サーバー等)<ref>{{Cite journal|date=2018-06-17|title=Downtime|url=https://en.wikipedia.org/w/index.php?title=Downtime&oldid=846220618|journal=Wikipedia|language=en}}</ref>
問題の原因としてよくあるものは[[設計]]の不備である。例えば、機器を逆に接続してしまったり、カードを逆に挿入したりといった問題では、間違いを起こしにくくする[[人間工学]]設計が不足していると考えられる。また、カタカナ英語に溢れたマニュアルは読みにくく理解しにくく覚えにくいので、大半の日本人が一度もマニュアル読まずに機器を使っていることも問題の大きな原因となっている。他の原因としては自然故障もある。
 
問題の原因としてよくあるものは[[設計]]の不備である。例えば、機器を逆に接続してしまったり、カードを逆に挿入したりといった問題では、間違いを起こしにくくする[[人間工学]]設計が不足していると考えられる。また、カタカナ英語に溢れたマニュアルは読みにくく理解しにくく覚えにくいので、大半の日本人が一度もマニュアル読まずに機器を使っていることも問題の大きな原因となっている。他の原因としては自然障害による不具合や故障もある。<ref>{{Cite journal|date=2017-05-02|title=故障|url=https://ja.wikipedia.org/w/index.php?title=%E6%95%85%E9%9A%9C&oldid=63963739|journal=Wikipedia|language=ja}}</ref>
 
トラブルシューティングでは、体系的な[[チェックリスト]]、手順、[[フローチャート]]や表が事前に用意され、使われることもある。トラブルシューティングの手順開発を事前に行っておくことで、効率的な問題への対処が可能となる。
35 ⟶ 38行目:
* [[フローチャート]]
*[[PD思考法]]
*[[:en:Downtime|ダウンタイム]]
 
== 外部リンク ==