arrow_backフィールドノートに戻る
SYSTEMS 公開日 7 Aug 2026

IT Support Done Right: A Practical Field Guide

IT サポートチケットをプロのように運用する方法:トリアージ、診断、ドキュメント化、エスカレーションを適切に行い、単に早く閉じるのではなく。

ほとんどの IT サポート業務は速度で判断されていますが、方法なしの速度は同じ問題を別の場所に移すだけです。5 分で閉じたが 3 日後に再開するチケットは、20 分かかっても実際に修正されるチケットより多くのコストがかかります。このガイドでは、チケットを閉じる人と問題を解決する人を分ける習慣を扱います。

推測ではなく、実際のインテークから始める

マシンに触れる前に、ユーザーに自分の言葉で問題を説明させ、その後 3 つのフォローアップを質問してください:いつ始まったのか、最近何が変わったのか、毎回発生するのか、それとも間欠的に発生するのか。「インターネットが遅い」は DNS 解決、Wi-Fi チャネルの飽和、NIC の故障、またはタブが 40 個開いているブラウザーを意味する可能性があります。正確なエラー テキストがある場合は書き留めます。スクリーンショットは説明より常に優れています。ユーザーに何かを試すことを求める前にスクリーンショットを要求してください。

「再起動を試しましたか」にすぐに飛び込む誘惑に抵抗してください。十分な頻度で機能するため、人々がそれにデフォルトしていますが、インテークをスキップすると、パターンを見逃します。同じスイッチ上の 3 人が同じ時間に同じ遅さを報告する場合、それは不良ドライバーを持つ 1 台のラップトップよりも異なるチケットです。

修正する前に再現する

問題を再現できない場合、修正したことを確認できません。ユーザーに画面共有で正確なステップを実行させるか、リモート ツールが許可する場合は自分のマシンで実行してください。Windows で ipconfig /all を確認するか、Linux で ip a を確認してネットワークの基本的な健全性を確認し、Event Viewer (eventvwr.msc) をチェックして報告された時刻の前後のアプリケーションとシステムエラーを確認し、Linux ボックスで journalctl -xe --since "1 hour ago" をチェックして同じウィンドウを確認します。

アプリケーション クラッシュの場合は、正確なビルド番号と OS バージョンを取得します。「クラッシュした」は何も教えてくれません。「Outlook 16.0.17726 は .ics 添付ファイル付きカレンダー招待を開くときにクラッシュする」は、どこを見るかを教えてくれます。ローカルだと仮定する前に、既知の問題についてベンダーのリリースノートと相互参照してください。

最も大きな声を出す人ではなく、影響度でトリアージする

単一ユーザーが電子メールからロックアウトされるのは不便です。40 人の共有ファイル サーバーに到達できないのは停止です。P1 を複数のユーザーまたは重要なシステムに影響する停止、P2 を単一ユーザーのブロッカー、P3 を機能の低下、P4 を外観または利便性のリクエストなど、単純な重大度スケールを構築し、マネージャーから最初に自分のことをしたいというプレッシャーの下でも一貫して適用します。

チケット自体に重大度の判断を記録します。これは後で誰かが P3 が 2 日間放置されている理由を尋ねるときに保護します。一方、3 つの P1 を処理します。

症状ではなく、根本原因を修正する

クラッシュし続けるサービスを再開してもは時間を稼ぐだけで、解決にはなりません。プリント スプーラーが毎日死ぬ場合は、もう一度再開する前に、実際のエラーについて Get-WinEvent -LogName Application -MaxEvents 50 をチェックしてください。ユーザーのパスワードが予期せず有効期限切れになり続ける場合は、リセットして進む代わりに、OU に適用されたグループ ポリシーをチェックしてください。

定期的な修正の個人ログを保持します。同じ PowerShell コマンドまたは同じレジストリ修正を 3 回入力している場合は、頭の中ではなく、スクリプトまたはドキュメント化された runbook に属していることを示しています。

他の誰かが読むようにドキュメント化する

すべてのチケット解決は次に答える必要があります:実際の原因は何であったか、修正は何であったか、このようなことが再度発生した場合、最初に何をチェックしますか。チケット解決ノートとしての「修正」は、次のテック(6 か月後にこのチケットのメモリがない将来のあなたを含む)にとって無価値です。

良い解決ノートは次のようなものです:「根本原因:VLAN 20 の DHCP スコープが枯渇し、新しいデバイスは APIPA アドレスを取得しました。修正:スコープを /24 から /23 に拡張し、プリンター用の予約を追加しました。確認:毎月 DHCP リース数をチェックし、アラート閾値を 90% に設定します。」その 3 番目の文は、ほとんどのテックがスキップするもので、繰り返しチケットを防ぐものです。

単なる転送ではなく、コンテキストを使用してエスカレートする

チケットが層 2 またはベンダーに行く場合は、既にルールアウトしたものを含めてください。「ケーブル接続を確認、ポートを交換、VLAN 構成を確認、リンク ライトなしのまま」は、次の人が最初の 20 分を再実行するのを保存します。「ユーザーは壊れていると言っています、お願いします」のようなあいまいなエスカレーションは、それを削除する代わりに、遅延を移動するだけです。

ユーザーとループを閉じる

ただの「修正」ではなく、平文で何が悪かったかをユーザーに伝えます。人々は何が起きたかを理解したときにサポートをより信頼し、その人が接続されていることに気付かないため、同じ人が次の月に同じチケットをファイルするのを減らします。

これの技術的側面をさらに深く掘り下げたい場合(ネットワーク基礎、Windows イベント ログ、または独自の診断ツールのスクリプト化)、Korra Studio には、ネットワーク、システム、スクリプト作成に取り組む価値があるセグメントがあります。

この記事は AI の支援を受けて執筆し、Korra Studio の Michal Pilch(CISSP)が確認のうえ公開しました。

さらに先へ進む準備はできていますか?

これは Korra Studio ナレッジベースの 1 つのノートです。プラットフォームはすべてのトピックと 1 対 1 メンタリングをペアで提供します。

無料で始めるarrow_forward