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

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

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

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

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

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

ある朝、ヘルプデスクに同時に2件が入ったとします。1件目は「経理部の1人がプリンタに印刷できない」、2件目は「営業部フロア全員がファイルサーバに一切アクセスできない」。ここで受付順に1件目から手を付けるのは、良い判断ではありません。優先順位付けの考え方では、影響範囲の広い2件目（フロア全員・基幹サーバ）を先に着手すべきだからです。次に2件目に取りかかるとき、いきなりサーバを再起動するのではなく、方法論に沿って情報を集めます。「全員なのか一部か」「昨日までは使えていたか」「最近ネットワークに変更はあったか」を聞くと、たとえば「昨夜スイッチの入れ替え作業があった」と分かるかもしれません。ここで原因の当たりが付き、変更箇所を一つずつ確認していきます。仮にケーブルの挿し間違いを直して復旧したら、必ず実際に印刷やアクセスができるか検証し、その一部始終をチケットに「原因：夜間作業でのポート挿し間違い／対処：正しいポートへ接続／検証：全席からアクセス確認」と正確に文書化します。こう書き残しておけば、次に似た症状が出たとき、担当が誰であっても同じ結論に短時間でたどり着けます。入門段階で身につけるべきは、難しい技術よりまず、当てずっぽうを避け、優先度を付け、手順に沿い、記録を残すというこの型そのものです。

5.1.3この節のまとめ

• トラブルシュート方法論は「症状確認→情報収集→切り分け→対処→検証」。当てずっぽうを避け、変更は一度に一つ
• 対応はチケットとして正確で完全に文書化し、原因・対処・結果を残してチームの知識にする
• 複数案件は優先順位付けし、影響範囲の大きい（人数・業務影響・緊急度が高い）ものから着手する