障害対応で新人がやりがちなミス15選|正しい初動・切り分け・報告方法を解説
結論から言うと、障害対応で新人が最もやりがちなミスは、状況を十分に確認せずに設定変更や再起動を行ってしまうことです。
障害対応では、すぐに直すことよりも、発生状況を正確に把握し、影響範囲を確認して、決められた手順で対応することが重要です。
新人のうちは原因を特定できなくても問題ありません。事実を記録し、適切なタイミングで上司や二次対応担当者へエスカレーションできれば、十分に良い対応です。
障害対応とは
障害対応とは、パソコンやサーバー、ネットワーク、業務システムなどで問題が発生した際に、状況確認、原因の切り分け、復旧、報告を行う業務です。
IT現場では、次のようなトラブルが障害として扱われます。
- パソコンにログインできない
- インターネットにつながらない
- 共有フォルダへアクセスできない
- メールを送受信できない
- 業務システムが起動しない
- プリンターから印刷できない
- サーバーへ接続できない
障害対応で新人がやりがちなミス
1.エラーメッセージを記録せずに閉じる
新人が特にやりがちなミスが、表示されたエラー画面をすぐに閉じてしまうことです。
エラーメッセージには、原因を特定するための重要な情報が含まれています。
閉じる前に、次の内容を記録しましょう。
- エラーメッセージの全文
- エラーコード
- 表示された日時
- 発生した操作
- 画面のスクリーンショット
Windowsでは、Windowsキー+Shift+Sを押すと、画面の一部を簡単に保存できます。
2.利用者の話だけで原因を決めつける
利用者から「ネットワーク障害です」「サーバーが落ちています」と言われても、その情報だけで判断してはいけません。
実際には、LANケーブルが抜けていたり、パスワードを間違えていたり、特定のアプリだけが停止していたりすることがあります。
利用者の説明は参考情報として聞き、事実は自分で確認することが大切です。
3.影響範囲を確認しない
障害対応では、問題が一人だけに発生しているのか、部署全体や全社で発生しているのかを最初に確認します。
| 影響範囲 | 考えられる原因 |
|---|---|
| 一人だけ | 端末設定、ユーザー権限、アカウント |
| 同じ部署の複数人 | ネットワーク機器、共有プリンター、アクセス権 |
| 全社 | サーバー、ネットワーク、認証基盤、外部サービス |
影響範囲が広いほど、重大な障害である可能性が高くなります。
4.すぐに再起動する
再起動は有効な解決方法ですが、最初に実施すると原因調査に必要な情報が消えることがあります。
特にサーバーやネットワーク機器は、許可なく再起動してはいけません。
再起動前に次の内容を確認します。
- エラー画面
- 発生時刻
- イベントログ
- 実行中の処理
- 他の利用者への影響
5.許可なく設定を変更する
原因が分からないまま、ネットワーク設定やレジストリ、サービス、アクセス権を変更するのは危険です。
変更によって障害が悪化し、元の状態に戻せなくなる場合があります。
設定変更が必要なときは、次の内容を記録してから実施します。
- 変更前の値
- 変更する理由
- 作業日時
- 作業者
- 元に戻す手順
6.確認した内容を記録しない
口頭だけで対応を進めると、何を確認したのか分からなくなります。
二次対応担当者が同じ確認を繰り返すことになり、復旧までの時間も長くなります。
チケットや作業メモには、次のように記録しましょう。
- 10時15分:利用者から受付
- 10時20分:端末再現確認
- 10時25分:他の利用者では正常
- 10時30分:ping疎通正常
- 10時35分:アクセス権確認を二次対応へ依頼
7.確認結果を書かず、実施内容だけ報告する
「pingを実行しました」「再起動しました」だけでは、結果が分かりません。
報告では、実施内容と結果をセットで伝えます。
悪い例:pingを確認しました。
良い例:ファイルサーバーへpingを実行し、応答があることを確認しました。通信遅延とパケット損失はありませんでした。
8.一つの原因にこだわりすぎる
障害には複数の原因が考えられます。
共有フォルダへ接続できない場合でも、原因はアクセス権だけとは限りません。
- ネットワーク接続
- DNSの名前解決
- ファイルサーバーの停止
- Active Directoryのアカウント
- 共有フォルダの権限
- Windowsファイアウォール
思い込みを避け、順番に可能性を消していくことが重要です。
9.正常な端末と比較しない
障害が発生している端末だけを見ても、異常箇所が分からないことがあります。
正常に動作している端末と比較すると、設定の違いを見つけやすくなります。
- IPアドレス
- DNSサーバー
- Windowsのバージョン
- ログインユーザー
- アプリケーションのバージョン
- アクセス権
10.ユーザー側とサーバー側を切り分けない
最初に、問題が利用者の端末にあるのか、サーバーやネットワークにあるのかを考えます。
他の端末では正常なら、ユーザー側や端末側の問題である可能性が高くなります。
複数端末で同じ問題が発生している場合は、サーバー側やネットワーク側を疑います。
11.コマンドの結果を理解せずに使う
コマンドは実行するだけでは意味がありません。結果を読めることが重要です。
| コマンド | 確認できる内容 |
|---|---|
| ipconfig /all | IPアドレス、DNS、DHCPの設定 |
| ping | 通信相手へ到達できるか |
| nslookup | DNSで名前解決できるか |
| hostname | 端末名 |
| whoami | 現在のログインユーザー |
pingに成功しても、業務システムが正常とは限りません。通信経路の一部が確認できただけと考えましょう。
12.イベントビューアーを確認しない
Windowsの障害では、イベントビューアーに原因の手掛かりが記録されている場合があります。
- Windowsキー+Xを押す
- 「イベントビューアー」を選択する
- 「Windowsログ」を開く
- 「システム」または「アプリケーション」を選ぶ
- 障害発生時刻付近のエラーと警告を確認する
イベントID、ソース、発生時刻、メッセージを記録すると、二次対応へ引き継ぎやすくなります。
13.関係者への連絡が遅れる
原因調査に集中しすぎて、上司や利用者への報告を忘れるケースがあります。
障害が長引く場合は、原因が判明していなくても状況を共有しましょう。
- 現在発生している事象
- 影響範囲
- 調査中の項目
- 回避策の有無
- 次回報告の条件
14.自分だけで抱え込む
新人が一人で長時間悩み続けると、障害の復旧が遅れます。
マニュアルの範囲を超えている、権限が足りない、影響範囲が広いといった場合は、早めにエスカレーションしましょう。
エスカレーションは失敗ではありません。適切に相談することも障害対応の一部です。
15.復旧した時点で対応を終える
一時的に直っただけでは、障害対応は完了していません。
復旧後は次の内容を確認します。
- 利用者が正常に操作できるか
- 他の端末でも問題がないか
- エラーが再発していないか
- 監視アラートが正常に戻ったか
- 原因と対応内容を記録したか
障害対応で最初に確認する順番
- 何が起きているか確認する
- いつから発生しているか調べる
- 影響を受けている利用者を確認する
- エラーメッセージを記録する
- 直前の変更作業を確認する
- 正常な端末と比較する
- ユーザー側、ネットワーク側、サーバー側を切り分ける
- マニュアルの範囲内で一次対応を行う
- 必要に応じてエスカレーションする
GUIで確認する方法
GUI(Graphical User Interface)とは、画面上のボタンやメニューを操作する方法です。
- 設定画面でネットワーク状態を確認する
- タスクマネージャーでCPUやメモリを確認する
- イベントビューアーでログを確認する
- サービス画面でサービスの状態を確認する
- エクスプローラーで共有フォルダへの接続を確認する
タスクマネージャーは、Ctrl+Shift+Escで起動できます。
CUIで確認する方法
CUI(Character User Interface)とは、コマンドを入力して確認や操作を行う方法です。
コマンドプロンプトは、Windowsキーを押して「cmd」と入力すると起動できます。
- ipconfig /all:ネットワーク設定の確認
- ping サーバー名:通信確認
- nslookup サーバー名:DNS確認
- whoami:ログインユーザーの確認
- systeminfo:Windowsや端末情報の確認
PowerShellで確認できる内容
- Get-NetIPAddress:IPアドレスの確認
- Test-NetConnection:通信先とポートの確認
- Get-Service:Windowsサービスの状態確認
- Get-WinEvent:イベントログの確認
コマンドの実行結果はコピーして、チケットや作業記録へ保存しましょう。
上司へ報告するポイント
障害報告では、推測よりも確認できた事実を優先します。
| 報告項目 | 内容 |
|---|---|
| 発生日時 | いつ障害を確認したか |
| 事象 | 何ができないのか |
| 影響範囲 | 誰にどの程度影響しているか |
| 確認内容 | 何を調べたか |
| 確認結果 | 正常だったか異常だったか |
| 実施した対応 | どの作業を行ったか |
| 現在の状態 | 未復旧、一部復旧、復旧済み |
エスカレーションするタイミング
- 業務停止が発生している
- 複数の利用者に影響がある
- サーバーやネットワーク機器に異常がある
- 管理者権限が必要
- マニュアルの範囲を超えている
- 原因不明のまま同じ障害が再発している
- 情報漏えいやウイルス感染の可能性がある
セキュリティに関係する障害は、自分で調査を続けず、社内ルールに従って速やかに報告してください。
筆者が新人時代に経験した失敗
筆者が新人の頃、業務アプリが起動しないという問い合わせを受け、十分な確認をせずにアプリを再インストールしたことがあります。
しかし、本当の原因は利用者のアカウント権限でした。再インストールでは改善せず、設定も初期化されたため、復旧作業を増やしてしまいました。
この経験から、作業前に影響範囲、正常端末との差、ログインユーザー、エラーメッセージを確認する重要性を学びました。
現場で評価される障害対応
現場で評価されるのは、すべての障害を一人で解決できる人ではありません。
決められた順番で確認し、作業結果を記録し、適切に報告できる人が信頼されます。
- 事実と推測を分ける
- 影響範囲を最初に確認する
- 作業前後の状態を記録する
- 勝手な設定変更を行わない
- 早めに相談する
よくある質問(FAQ)
障害が発生したら最初に再起動してもよいですか?
利用者のパソコンで、社内手順として認められている場合は有効です。ただし、先にエラー内容や発生時刻を記録してください。サーバーやネットワーク機器は許可なく再起動してはいけません。
原因が分からなくても報告してよいですか?
問題ありません。原因が分からない場合でも、発生事象、影響範囲、確認した内容、確認結果を報告すれば、次の担当者が調査できます。
どのくらい調査してからエスカレーションすべきですか?
社内の対応手順や目標時間に従います。業務停止や複数人への影響がある場合は、時間をかけず早めに報告しましょう。
障害対応で最も大切なことは何ですか?
影響を広げないことです。原因が分からない状態で設定を変更せず、状況を記録して関係者へ共有することが重要です。
まとめ
- エラーメッセージと発生時刻を必ず記録する
- 一人だけか全体か、影響範囲を最初に確認する
- 利用者の説明だけで原因を決めつけない
- 許可なく再起動や設定変更を行わない
- 実施内容と確認結果をセットで記録する
- 原因が分からない場合は早めにエスカレーションする
- 復旧後も動作確認と記録を行う
新人の障害対応では、知識の多さよりも確認手順と報告の正確さが重要です。焦って直そうとせず、事実を一つずつ確認する習慣を身につけましょう。

コメント