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

削除された内容 追加された内容
編集の要約なし
編集の要約なし
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>。
 
例えば、それまで動いていたものが突然停止してしまった問題について考えてみよう。この場合、まず第一に、動いていた時と停止した時とで何が変わったのかに注目しなければならない。しかし、何か変化があったとしても、そこに[[因果関係]]があると早合点してはいけない。一般に[[相関|相関関係]]と因果関係は同じではない。
 
問題解決の基本原則は、最も単純で[[確率]]の高い原因から検討開始するというものである。これは「足跡を見つけたら、まずシマウマではなく馬を探せ」という格言や[[KISS原則]]で表される。この原則の結果として、解決手順(ヘルプデスクやマニュアル)で最初に「電源は入っていますか?」と聞かれることになるのだが、これは侮辱ではなく、現状の把握と単に考えられる可能性を排除していくための手続きの一部(問題の切り分け)である。
 
次に、構成体の要素を1つずつ調べていき、疑わしいものがあればその部品を置き換えていく。また、一旦正常な状態に戻すという手もある(例えば、コンピューターの[[ブート|リブート]]など)。[[認知ウォークスルー]]も試す価値のある手法である。また、特定の機器やシステムについて詳しく記載された文書があれば、非常に役立つだろう。
 
その他手法として一旦正常な状態に戻す。例えば、
問題の原因としてよくあるものは[[設計]]の不備である。例えば、機器を逆に接続してしまったり、カードを逆に挿入したりといった問題では、間違いを起こしにくくする[[人間工学]]設計が不足していると考えられる。また、カタカナ英語に溢れたマニュアルは読みにくく理解しにくく覚えにくいので、大半の日本人が一度もマニュアル読まずに機器を使っていることも問題の大きな原因となっている。
 
* コンピューターの[[ブート|リブート]]やバックアップからリストアをして正常に起動出来るかを試す。
* 機器に対して正しい結線や使用環境、操作を実施し動作を確認する(電源を入れる)。
* 機器の動作に必要な最低限の機器のみを接続させて動作を確認する([[最小構成]])。ソフトウェアの設定内容を把握している場合、設定を一旦[[デフォルト (コンピュータ)|デフォルト]]に戻したり[[再インストール]]を試す。
 
などが考えられる。
 
問題の原因としてよくあるものは[[設計]]の不備である。例えば、機器を逆に接続してしまったり、カードを逆に挿入したりといった問題では、間違いを起こしにくくする[[人間工学]]設計が不足していると考えられる。また、カタカナ英語に溢れたマニュアルは読みにくく理解しにくく覚えにくいので、大半の日本人が一度もマニュアル読まずに機器を使っていることも問題の大きな原因となっている。他の原因としては自然故障もある。
 
トラブルシューティングでは、体系的な[[チェックリスト]]、手順、[[フローチャート]]や表が事前に用意され、使われることもある。トラブルシューティングの手順開発を事前に行っておくことで、効率的な問題への対処が可能となる。
26 ⟶ 34行目:
* [[良品返品]](NTF)
* [[フローチャート]]
*[[PD思考法]]
 
== 外部リンク ==