「あれ、この症状、前もあったよね？」「ありましたね。どう直したんでしたっけ……」
ITトラブルの現場で、この会話ほど多く繰り返されているものはないでしょう。障害対応の記録が残らない会社では、経験が資産にならず、同じ時間の浪費が静かに繰り返されます。
記録がない会社で起きる3つの悪循環
1. 同じ障害を、毎回ゼロから調べる
前回の原因と対処が残っていなければ、二度目の障害も初見と同じです。「前は再起動で直った気がする」という曖昧な記憶は、かえって判断を迷わせます。その記憶すら一人の頭の中にしかない会社では、その人が休んだ日に、会社ごと初見に戻ります。
2. 外部への説明を、毎回やり直す
ISPや保守業者に相談すると、必ず聞かれます。「いつからですか」「何台に影響していますか」「何を確認されましたか」。記録がなければここで止まり、調査は業者に依頼した時点からではなく、状況説明が終わった時点からしか始まりません。
3. 機器の判断が、勘になる
「このルーター、最近よく調子が悪い気がする」と言われても、気がする、では買い替えの稟議は通りません。障害の頻度と内容の記録だけが、更新投資の客観的な根拠になります。
「報告書」ではなく「調査票」
記録が続かない理由のひとつは、記録を「終わった後に書く報告書」と捉えているからです。障害が終わったころには疲れ果てていて、報告書は要約になり、肝心の途中経過が抜け落ちます。
おすすめは、**対応しながら書き足す「調査票」**という運用です。1件の障害につき1枚。書式は簡単で構いません。
- 件名——「受付プリンタが応答しない」のように症状で
- 発生・検知の日時——「言われた時刻」と「実際に始まった時刻」は別物として
- 影響——誰が・何ができない状態か
- 確認したこと——時刻つきで。pingの結果、機器のランプ、設定画面で見た値
- 対処と結果——やったこと、その後どうなったか
- 確定原因・再発防止——分かった場合のみ。分からなければ「原因未確定」と書く
対応の途中で1行ずつ足していけば、終わったときには記録が完成しています。例に挙げた「受付プリンタが応答しない」なら、到達性とIPの変化をどう確かめたかを、そのまま「確認したこと」の欄へ書き写せます。
最重要ルール——事実と推測を分ける
調査票の書き方でひとつだけルールを挙げるなら、これです。「確認できた事実」と「推測」を分けて書く。
悪い例:「DNSがおかしくなって遅くなった」。これは推測です。次に似た症状が出たとき、読んだ人はDNSだけを疑い、他の原因を見落とします。
良い例:「14:20 社内DNSへの応答が普段より遅いことを確認（事実）。原因はDNSサーバーの負荷と推測（未確認）」。事実と推測が分かれていれば、次の対応者は事実だけを土台に、推測を検証するところから始められます。
原因が分からないまま復旧してしまったら、「原因未確定のまま復旧」と書きます。それは恥ではなく、最も誠実で有用な記録です。
記録の半分を、自動で埋めるという発想
調査票の項目のうち、「発生時刻」「そのときネットワークで何が起きていたか」は、実は人が書くのに最も苦労する部分です。人は障害が始まった瞬間を見ていないからです。
AI情シスは、この部分を観測の仕組みで埋めます。異常を検知すると、発生前後のネットワーク品質・端末の変化・台帳の状態が「証拠」として自動で調査票にまとまり、人はそこに対応の経過・業務影響・確定原因を書き足していきます。AIは観測にもとづく原因候補と「確認できたこと・未確認のこと」を分けて提示し、確定の判断と記録は人が行います。まさに「事実と推測を分ける」を画面の構造にした設計です。復旧も、実際に使えることを人が確かめてから記録します。なぜ確定だけを人に残すのかは、AIに任せてよい範囲の線引きで扱っています。
蓄積された調査票は会社の資産になり、必要なら弊社のエンジニアが同じ調査票を見て対応を引き継ぎます。AI情シスは、企業ごとに個別カスタマイズして提供する製品です。導入はPoCからご相談いただけます。詳しくは障害調査の機能紹介をご覧ください。
まとめ
障害対応の価値は「直したこと」ではなく「次に速く直せるようになったこと」にあります。1障害1票の調査票を、対応しながら書き足す。事実と推測を分ける。原因未確定なら未確定と書く。この3つを守るだけで、トラブルのたびに会社は少しずつ強くなっていきます。