インシデントとその管理の必要性
IT・WEBのサービスサポートにおいて、問い合わせや問題発生の連絡が起きた場合、これをインシデントとして管理します。
incident（インシデント）とは、英語で出来事やちょっとした事件を表す単語です。
大きな問題になるかもしれない発端という意味合いも持っています。
些細な問い合わせでも、将来的なトラブルの種となる可能性を考慮し、そのすべてを台帳等に書き記し記録／管理します。
また、サポートチームと運営部門が別れている場合などは複数のチームにまたがり共有することが必要となります。
このインシデント管理は書き記し、記録したら終わりではありません。
インシデントの管理者は、それぞれの問い合わせやトラブルについてステータスを管理し、課題が解決されるまでフォローする必要があります。
新たなインシデントが発生する度に内容の記載だけでなく、一時対応の目安日時や最終的な対応日時までの予定を設定し、きちんと対応が完了するよう手立てを打っていかなければなりません。
また、サポート対象のシステム範囲が広い場合、インシデントは複数の関係者にまたがり解決を図らなくてはならない場合もあります。
管理者は適宜状況の共有、アナウンスにも努める必要が発生します。
インシデント管理における滞留案件とは
このインシデントですが、対応に時間がかかる場合があります。
例えば、問題の切り分けに時間がかかったり、プラットフォームのサポート窓口に問い合わせが必要だったり、関連システムが多く連携に膨大な手間がかかったりする場合などです。
時として対応予定日時に間に合わない事態もあり得ます。
そういった場合はインシデントの管理者は関係各所に連絡を行い、対応中であることと新たな対応目処を伝えておかなければなりません。
インシデント対応についてもリスケジュールを行い、課題の解決に努めるのです。
そうしてインシデントの対応を行っていくうち、再現性が低い、原因の疑いがある対象が幅広い場合など、長期に渡りインシデントとして残り続けるものが出ることがあります。
長期滞留案件と呼ばれるものです。
これら長期滞留案件は、適宜再確認して対応が止まっていないかを注視しなくてはなりません。
可能であれば定期的に見直しをかける（＝棚卸）、定例会などの場を設けると良いでしょう。
インシデントの棚卸を定期的に行いたい理由
インシデントの棚卸の機会ですが、上司や顧客キーマンが参加可能であれば定例会等の会議体として定期的に管理することが望ましいです。
その理由は３つ挙げられます。
一つ目は先ほどもあげた定期的な見直しの場の確保です。
少ない人数でインシデントを見ていると、見馴れてしまいインシデントに対する危機感、対応スピードを失ってしまいがちです。
二つ目は案件そのものを再確認できることです。
同じ人が見続けていても出ない発想や切り口がもたらされることも少なくはありません。
また、インシデント管理者だけでは判断しきれない重要度、優先度という物差しも他の目線で見てもらい、判断してもらった方が良い場合が多々あります。
三つ目の理由として、インシデントの管理者がインシデントを抱え込みすぎないため、ということが挙げられます。
責任を持って自分の課題に対応する姿勢はどんな仕事でも大切なものです。
しかし、課題を抱え込むことは過度なストレスとの隣り合わせでもあるのです。
他の立場を持つ人と定例会等を行い、インシデントも共有の情報とすることで心理的負荷を下げることが出来ます。
また、一人でインシデントを抱え込み続けると、インシデントは隠ぺいされたと疑われ、時として大事にもなってしまいます。
これも他人と共有することで防ぐことが出来るのです。
まとめ
サポートビジネスにおいてインシデント管理は大きな比重を占める業務です。
ただ発生した事象を記録しておくだけでなく、課題の共有、プロセス改善に向けての分析など重要な役割があります。
インシデント管理の運用を一度見直し、最適化することでサポートの充実を図りましょう。
