Loading article…
トラブルシューティングは問題解決の一形態であり、機械やシステムの故障した製品やプロセスを修復するためによく用いられます。これは、問題を解決して製品やプロセスを再び稼働させるために、問題の原因を論理的かつ体系的に探す作業です。トラブルシューティングは症状を特定するために必要です。最も可能性の高い原因を特定するには、潜在的な問題を体系的に排除する消去法を用いることがよくあります。最後に、トラブルシューティングでは、解決策によって製品やプロセスが正常な状態に戻ることを確認する必要があります。戦略とは、目標を達成するための妥当な方法を表す、組織化された一連の活動です。戦略は、解決策に至るまで柔軟性のないアルゴリズムとして捉えるべきではありません。問題解決者は機会主義的に行動し、戦略内の活動を調整し、情報やアイデアに応じて戦略や戦術を変更します。
一般的に、トラブルシューティングとは、何らかの障害によってシステム管理フローに生じた「トラブル」を特定または診断することです。問題は当初、機能不全の症状として説明され、トラブルシューティングとは、これらの症状の原因を特定し、解決するプロセスです。
システムは、期待される動作、望ましい動作、または意図された動作（人工システムの場合は通常、その目的）によって説明できます。システムへのイベントまたは入力は、特定の結果または出力を生成することが期待されます（たとえば、さまざまなコンピュータアプリケーションで「印刷」オプションを選択すると、特定のデバイスからハードコピーが出力されることが意図されています）。予期しない動作や望ましくない動作は症状です。トラブルシューティングとは、症状の具体的な原因を特定するプロセスです。多くの場合、症状は製品またはプロセスが結果を生成しないことです（たとえば、何も印刷されなかった）。その後、同様の種類の障害が再発しないように是正措置を講じることができます。
フォレンジックエンジニアリングの手法は、製品やプロセスにおける問題点の特定に有効であり、特定の故障の原因を突き止めるための幅広い分析技術が利用可能です。その後、同様の故障の再発を防ぐための是正措置を講じることができます。本格的な生産開始前に、故障モード影響解析（FMEA）やフォールトツリー解析（FTA）を用いて予防措置を講じることが可能であり、これらの手法は故障解析にも利用できます。
トラブルシューティング診断を行うために必要な主要な要素は 2 つあります。それは、事前のドメイン知識と検索戦略です。[ 1 ]これらは相互に依存しており、ここで根本的に 2 種類の異なる問題と、それに対応する診断アプローチを特定できます。Rasmussen [ 2 ]は、デバイスの正常な機能の特性によって導かれる戦略 (地形的戦略) と、異常な機能の特性によって導かれる戦略 (症状的戦略) があると提案しました。後者は実際には「何が問題なのか？」と尋ねており、前者は「何が起こっているのか？」と尋ねています。
戦略とは、目標を達成するための妥当な方法を示す、組織化された一連の活動である。戦略は、解決策に至るまで融通の利かないアルゴリズムとして捉えるべきではない。問題解決者は機会主義的に行動し、戦略内の活動を調整し、情報やアイデアに応じて戦略や戦術を変更する。[ 3 ]
症状に基づく戦略（事例に基づく推論、または浅い推論とも呼ばれる）では、症状と原因の関連性を確立した過去の経験から得られる事前のドメイン知識が必要です。この知識は、浅い知識、コンパイルされた知識、証拠に基づく知識、履歴に基づく知識、および事例に基づく知識と呼ばれます。これは、専門家による診断に最も関連付けられている戦略です。問題の診断は、症状が適切な状況カテゴリを喚起する迅速な認識プロセスとして発生します。[ 4 ]専門家は、以前に同様のケースに遭遇したことにより原因を知っています。事例に基づく推論は最も強力な戦略であり、最も一般的に使用されています。ただし、この戦略は、真に新しい問題や、何が起こっているのかをより深く理解しようとする場合には、単独では機能しません。地形的戦略は、深い推論のカテゴリに分類されます。深い推論では、システムの深い知識が使用されます。この文脈での地形とは、構造化されたエンティティの説明または分析であり、その要素間の関係を示します。[ 5 ] 第一原理からの推論とも呼ばれる[ 6 ]深層推論は、経験に基づくアプローチが有効でない場合に、新しい障害に適用されます。したがって、地形的戦略は、おそらく第一原理の知識を使用して、システムのより根本的な理解から開発された事前のドメイン知識と結び付けられています。このような知識は、深層知識、因果知識、またはモデルベースの知識と呼ばれます。[ 7 ]
Hoc [ 8 ]は、症状は多様な用語で定義できるため、症状アプローチは地形的アプローチによって補完される必要があるかもしれないと指摘した。逆もまた真であり、地形的探索では、浅い推論をアブダクション的に用いて因果仮説を生成し、演繹的にそれらの仮説を評価することができる。
通常、トラブルシューティングは、突然動作しなくなったものに対して行われます。なぜなら、それまで正常に動作していた状態が、その後の動作に関する期待を形成するからです。そのため、最初の焦点は、システムまたはシステムが存在する環境への最近の変更に置かれることがよくあります（例えば、「あちらに差し込んだときは正常に動作していた」プリンターなど）。しかし、相関関係は因果関係を意味しないというよく知られた原則があります（例えば、デバイスを別のコンセントに差し込んだ直後に故障したとしても、必ずしもそれらの事象が関連しているとは限りません。故障は単なる偶然である可能性もあります）。したがって、トラブルシューティングには、魔法のような思考ではなく、批判的思考が求められます。
電球に関する一般的な経験を振り返ってみると良いでしょう。電球は多かれ少なかれランダムに「切れる」ものです。フィラメントの加熱と冷却の繰り返し、そして供給される電力の変動によって、フィラメントにひびが入ったり、蒸発したりします。この原理は他のほとんどの電子機器にも当てはまり、機械装置にも同様の原理が当てはまります。故障の中には、システム内の部品の通常の摩耗によるものもあります。
トラブルシューティングにおける第一の基本原則は、問題をいつでも再現できることです。第二の基本原則は、問題が再現できる最も単純な形にシステムを縮小することです。第三の基本原則は、「何を探しているのかを知る」ことです。つまり、システムがどのように動作するべきかを完全に理解し、エラーが発生したときにそれを「見つける」ことができるようにすることです。
トラブルシューターは、システム内の各コンポーネントを一つずつ点検し、疑わしいコンポーネントを正常なコンポーネントと交換していくことができます。しかし、コンポーネントの故障が診断された症状を引き起こす可能性に関する仮説を考慮せずにコンポーネントを交換する場合、この「逐次交換」プロセスは劣化していると考えられます。
単純なシステムや中程度のシステムは、構成要素やサブシステム間の依存関係をリストやツリー構造で示すのが特徴です。より複雑なシステムには、循環的な依存関係や相互作用（フィードバックループ）が含まれます。このようなシステムは、「二分法」によるトラブルシューティング手法には適していません。
コンピュータの再起動などの方法により、システムを既知の機能状態に戻すことができます。その手法には、認知ウォークスルーなどがあります。テクニカルライターが作成する包括的なドキュメントは、デバイスまたはシステムの動作原理を提供します。
問題の一般的な原因は、設計不良、例えば、適切な強制機能（動作形成制約）の欠如や、エラー耐性設計の欠如により、デバイスが逆向きや上下逆さまに挿入されてしまうような、人間工学的に不適切な設計です。特に、慣れが伴う場合は問題です。慣れとは、ユーザーが誤った使用方法に気づかなくなることであり、例えば、2つの部品が異なる機能を持ちながら共通のケースを使用しているため、ざっと見ただけではどちらの部品が使用されているのかが分からない場合などがこれに該当します。
トラブルシューティングは、問題が発生する前に作成される体系的なチェックリスト、トラブルシューティング手順、フローチャート、または表の形式をとることもできます。トラブルシューティング手順を事前に作成することで、トラブルシューティングの際に取るべき手順について十分に検討し、最も効率的なトラブルシューティングプロセスに整理することができます。トラブルシューティング表は、ユーザーにとってより効率的に使用できるよう、コンピュータ化することも可能です。
コンピュータによるトラブルシューティング サービスの中には (Primary など、後に Manesar と改名)、根本的な問題を解決する可能性が最も高い上位 10 個の解決策を即座に表示するものがあります。技術者は、トラブルシューティング 手順を進めるために追加の質問に答えて解決策のリストを絞り込むか、問題を解決すると思われる解決策をすぐに実行することができます。これらのサービスでは、技術者が問題解決後にさらに手順を踏むと、実際に問題を解決した解決策を報告することで割引が受けられます。コンピュータはこれらの報告を使用して、特定の症状セットを解決する可能性が最も高い解決策の推定値を更新します。[ 9 ] [ 10 ]
効率的かつ体系的なトラブルシューティングは、システムの想定される動作と観察されている症状を明確に理解することから始まります。そこから、トラブルシューターは潜在的な原因について仮説を立て、これらの可能性のある原因を排除するためのテストを考案（または標準化されたチェックリストを参照）します。このアプローチはしばしば「分割統治」と呼ばれます。
トラブルシューターがよく使う2つの戦略は、まず頻繁に遭遇する、または簡単にテストできる状態を確認することです（たとえば、プリンターのランプが点灯していること、ケーブルの両端がしっかりと接続されていることを確認するなど）。これはしばしば「フロントパネルを徹底的に調べる」と呼ばれます。[ 11 ]
次に、システムを「二分」します（たとえば、ネットワーク印刷システムでは、ジョブがサーバーに到達したかどうかを確認し、問題がユーザー側またはデバイス側のサブシステムに存在するかどうかを判断します）。
この後者の手法は、コンポーネント間の直列化された依存関係や相互作用の長い連鎖を持つシステムで特に効率的です。これは、依存関係の範囲全体にわたってバイナリサーチを適用するだけのもので、「ハーフスプリッティング」と呼ばれることがよくあります。 [ 12 ]これは「 20の質問」ゲームに似ています。誰でも、選択肢のセットを20回半分に分割することで、100万の中から1つの選択肢を分離できます（2^10 = 1024、2^20 = 1,048,576のため）。
トラブルシューティングにおいては、再現性のある問題を特定し、解決することが重要です。再現性とは、報告された症状を引き起こす手順を特定することを意味します。
トラブルシューティングで最も難しい問題のいくつかは、断続的に発生する症状に関するものです。電子機器においては、これは多くの場合、熱に敏感な部品が原因です（回路の抵抗は導体の温度によって変化するため）。圧縮空気を使って回路基板上の特定の箇所を冷却したり、ヒートガンを使って温度を上げたりすることができます。そのため、電子システムのトラブルシューティングでは、これらのツールを使って問題を再現することが頻繁に必要になります。
コンピュータプログラミングにおいて、競合状態は再現が非常に困難な断続的な症状を引き起こすことがよくあります。様々な手法を用いて、特定の関数やモジュールを通常の動作時よりも高速に呼び出すように強制することができます（ハードウェア回路のコンポーネントを「加熱」するのと同様）。また、他の手法を用いて、他のモジュールや相互作用するプロセスに大きな遅延を導入したり、同期を強制したりすることもできます。
断続的な問題は、以下のように定義できます。
断続的な問題とは、その症状を常に再現できる既知の手順が存在しない問題のことである。
—スティーブン・リット、[ 13 ]
特に彼は、問題の発生頻度と「一貫して問題を再現するための既知の手順」との間には区別があると主張している。例えば、断続的な問題が特定の刺激や出来事から「 1時間以内に」発生することがわかっているが、それが5分で発生することもあれば、1時間近くかかることもある場合、その刺激によって症状の観察可能な発現頻度が増加するとしても、「既知の手順」には当たらない。
しかしながら、問題解決担当者は統計的手法に頼らざるを得ない場合があり、症状の発生頻度を連続置換などの手法が実行可能なレベルまで高める手順しか見つけられないことがあります。このような場合、症状が著しく長期間消失したように見えても、根本原因が特定され、問題が真に解決されたという確信は低いと言えます。
また、特定のコンポーネントに負荷をかけるテストを実行して、それらのコンポーネントが故障したかどうかを判断することもあります。[ 14 ]
再現性のある症状を引き起こす単一部品の故障を特定することは比較的容易である。
しかし、多くの問題は複数の障害やエラーが重なった結果としてのみ発生します。これは特にフォールトトレラントシステム、つまり冗長性を組み込んだシステムに当てはまります。システムに冗長性、障害検出、フェイルオーバー機能を追加する機能も故障する可能性があり、どのようなシステムでも、複数の異なるコンポーネントが同時に故障すると、システムはダウンしてしまいます。
単純なシステムであっても、トラブルシューターは常に複数の障害が存在する可能性を考慮しなければなりません。（各コンポーネントを順番に交換し、症状が改善しない場合は新しいコンポーネントを古いコンポーネントに戻すという手順では、このようなケースは解決しない可能性があります。さらに重要なのは、いずれかのコンポーネントを欠陥のあるコンポーネントに交換すると、問題が解消されるどころか、かえって問題の数が増える可能性があるということです。）
なお、「部品交換」という言葉を使う場合、多くの問題は「交換」ではなく調整やチューニングで解決します。例えば、導線の断線や「汚れた接点や緩んだ接点」などは、単に清掃や締め付けで済む場合もあります。「交換」という言葉を使う場合は、すべて「交換、調整、またはその他の変更」を意味するものと解釈してください。
{{cite news}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)