5.1トラブルシュート方法論とヘルプデスク

ネットワークのサポートで最も差が出るのは、知識量よりも進め方（手順）です。同じ「つながらない」という訴えでも、いきなりケーブルを抜き差ししたりルータを再起動したりと当てずっぽうで動くと、原因が分からないまま状況を悪化させかねません。この節では、症状を確認して情報を集め、原因を切り分け、対処し、直ったかを検証するというトラブルシュート方法論の型と、対応をチケットとして残す文書化、複数の依頼を影響の大きさで優先順位付けする考え方という、ヘルプデスクの基本作法を学びます。

5.1.1体系立てたトラブルシュートの手順

• 方法論（methodology）＝当てずっぽうではなく決まった順序で進めること。基本形は「症状の確認→情報収集→原因の切り分け（仮説と検証）→対処→直ったかの検証と記録」。手順に沿うと、原因の見落としや手戻りが減る。
• 情報収集が起点：いつから・誰が・どの範囲で・何をすると起きるかを聞き取る。「1台だけか、フロア全体か」「有線か無線か」「最近変更したことはあるか」といった質問が、原因を絞る材料になる。
• 一度に一つずつ変えるのが鉄則。複数箇所を同時にいじると、直っても悪化してもどれが効いたのか分からなくなる。変更したら必ず検証し、効果がなければ元に戻してから次を試す。

5.1.2チケットと文書化・優先順位付け

• チケット＝1件の問い合わせや障害を管理する記録。受付日時・依頼者・症状・実施した対応・結果を残し、担当交代や再発時に過去の経緯をたどれるようにする。口頭だけの対応は次の人に引き継げない。
• 正確で完全な文書化が価値の源泉。「再起動したら直った」だけでは再発時に役立たない。何を確認し、何を変え、なぜそう判断したかまで書くと、同じ問題が来たとき短時間で解決でき、チーム全体の知識になる。
• 優先順位付け＝複数案件を影響の大きさで並べること。「全社の基幹サーバが停止」は「1人のプリンタ不調」より優先。人数・業務への影響・緊急度で判断し、緊急案件を待たせないようにする。