トラブルシュートとは
Return to Macintosh Trouble Shoot Direction
どのような障害（トラブル）も原因があります。どんな分野のトラブルでも達人（エキスパート）と言われる人が触ると、たちどころに直ってしまうと言うのを皆さんも目撃したことがあると思います。
これは、エキスパートがトラブルが発生している物の仕組みや動作原理を理解している為に、問題解決の手順が非常に簡潔であるからです。ビギナーが陥りやすい問題は、動作原理を理解せずに、トラブルシュートに必要な動作原理知識を「勘違い」「誤った理解」「無関心」等による知識で解決しようとするところにあります。
トラブルシュートはパズルをとくような物です。「障害状況把握」「関連症状把握」「動作原理の理解」「試験」など、復旧に至るまでの段階がいくつかあります。
トラブルシュートは想像力を非常に要求されます。障害に関連する他の事柄を適切に思い浮かべることができれば、ほぼトラブルシュートは完了したと思っても構いません。
障害にあった人は、普通こう言います「昨日まではなんともなかったのに、今は調子が悪い」。 それは当然です、こう言う状態を障害というのです。
たとえばなんらかのトラブルが発生した場合、ハードウェアの問題か、ソフトウェアの問題か、人的な問題か見分けがつかないとき、まず初めに通常は人的な問題を追求します。人間は、だれしも自分で考えているよりも失敗を犯しやすい生き物です、尚且つそれを自分では認めたがらないものです。
人間は基本的な本能（直感）により行動を開始し、その後自分でこれまでに得た経験によってその行動を修正します。従って新しいテクノロジーや知らないことについての作業は、まず直感で行われます。
ある機器の動作原理が、人間の直感にそぐわないような設計（アキテクチュア）がされていた場合は障害が頻発します。ここでは作業ミス（オペレーションミス）も障害と考えます。
ハードウェアの問題は意外に人的要因と関係があります。障害がハードウェアの故障であると判断するのは、障害の調査がかなり最終段階に近づいた時点で行われます。
「新規に機器の設置を行った」「新しい機能（ハードウェア）を追加した」等の際に、疑われるのが「作業ミス」です。ハードウェアの故障であるか人的な作業ミスであるかを判断するためには、まず「どのような作業を行ったか？」を記憶のかなたから呼び返さなければなりません。
「どのようなハードウェアを使用するのか？」
「作業環境はどうであったか？」
「予備の機器は存在するか？」
「どのような条件の際障害が発生するか？」
「どのようにすれば障害が発生しないか？」
「動作原理の理解は十分であったか？」
これらの情報から、障害の発生原を突き止めます。
調査の際に予備の機器や測定機関係があれば、非常に容易く障害の原因を追求することができます。機器のパートが別れている場合は予備の機器（パーツという）をそれぞれのパートごとに取り替えていき、どのパーツを交換したときに障害がなくなるかを観察します。
この作業を「障害のきり分け」と言います。
ある特定のパーツを交換したときに障害が出なくなると、そのパーツが壊れていたと判断することができます。ただし、電圧の変動や気温の変化、周囲の状況により障害の内容が変化したり、症状が出たりでなかったりする場合は、注意が必要です。
このような場合には、いくらパーツを交換しても一時期は直ったように見えますが、近い将来同じ症状に悩まされることになります。この場合の調査方法は機器ごと別の環境にもって行き、しばらく観察して症状を確認する必要があります。
動作原理を理解することはトラブルシュートの基本ですが、その機器の動作原理が人間の直感や感性に共鳴するものであれば、さほど動作原理を知らなくてもトラブルシュートを行うことはできます。いわゆるメタファ（比喩）と言われるものは、機器の操作性を高めるために、我々の現実の実世界の実際にあるものを機器上に再現して、利用者（ユーザー）に新しい訓練や知識を要求しないようにするために利用されます。
操作上ユーザーに見える部分は、メタファを多用されますが、機器とメタファを中継している部分の構造については、機器の製作者の設計思想により異なります。
ユーザーが独自にハードウェアの設置変更等の作業を行う場合についても製作者の思想はユーザーに大きく影響をおよぼします。パーツの取付け間違いや接続間違いなど、取り扱い説明書を読めばわかるようなことでも、機器の製作者はユーザーが取り扱い説明書を読むことを期待してはなりませんし、いつまでも取り扱い説明書がユーザーの手元にあることを期待してもなりません。
ソフトウェアの障害とは、機器とユーザーの中継を行うメタファを多用したアプリケーションが、正しく動作しない場合を言い、２つのアプリケーション同士が、お互いに影響しあって障害が起きる場合が大半です。また、ユーザーの操作ミスによって引き起こされる障害も無視できません。操作ミスによって引き起こされる障害は、本来の純粋な意味での障害ではありませんが、ユーザーにとってはアプリケーションが正しく動作しないという結果を伴う点では一致します。
アプリケーションという言葉はコンピュータの世界では頻繁に使用されますが、「機器の運用方法」「応用方法」等と言う意味です。
ユーザーが、機器の設計者の意図としないアプリケーションを入手し使用した場合に、そのアプリケーションが他のアプリケーションと同じ機器の同じ部分にアクセスしようしていた場合、お互いに反発しあって障害が発生します。
また、すべてのアプリケーションには問題（バグ）があると言っても過言ではありません。バグのないアプリケーションは存在しないとする場合の、障害時の対応は ｢諦め」が非常に有効な処置ですが、それでは解決になりませんので、どちらかのアプリケーションを使用を中止するか、アプリケーション同士の互換性がアップされるのを待つ、互換性が良くなったものを使用する、等の方法が考えられます。
バグには通常、障害の再現性があります。ユーザーがアプリケーションに対して操作を行った場合に、ある特定の操作の場合のみに現れる障害があります。