システム運用のインシデント管理の説明です。
インシデント管理に限らず管理全般に言えることですが、何の目的で管理するのかを明確にすることが重要です。管理のための管理になってしまうと、管理される側のモチベーションが下がり、形骸化してしまいます。
１．インシデント管理の管理対象
インシデント管理は、通常、インシデント管理表と呼ばれるものを用いて管理をします。インシデント管理表に事象と対応内容を記載することで、次に同様のインシデントが発生した場合、速やかに同じ対応を実施することができるようになります。
例えば、ログにエラーメッセージが出た場合、インシデント管理表で該当のエラーメッセージを検索し、過去の対応内容を参照して同じ対応を実施する、といった感じです。
インシデント管理表には、「発生日／発見日」「発生時刻／発見時刻」「発見者」「分類」「インシデント内容」「業務影響」「対応状況」「対応者」「対応内容」「対応時間」「完了日時」といった項目があります。
ここで悩むのが「分類」、つまりインシデント管理の対象です。
インシデントとは、ユーザがITサービスを使えるべき時間に使えない状態のことをいいます。解決したい事象全てがインシデントとなるため、システムの停止やサービス品質の低下といった障害以外にも、パスワード忘れなどのユーザーに起因するものも、インシデントとなります。
つまり問合せも、インシデント管理の対象となるのです。
２．問合せをインシデント管理の対象とするか？
問合せは、問合せ管理表で管理することが多いかと思います。
インシデント管理表にも問合せを記載すると、二重管理となってしまいます。
教科書的には、問合せはインシデント管理の対象となりますが、実際の業務では対象とするべきでしょうか？
問合せをインシデント管理の対象とするかどうかは、インシデント管理の目的によります。
例えば全てのインシデントをヘルプデスクのような部署で一括で受付するような場合、インシデントの数と平均の対応時間等で、ヘルプデスクの人数を決めていくことになります。その場合、インシデントの内容が問合せであっても障害であっても、受付としては中身は関係なく、件数と対応時間、さらには応答率が重要になってきます。
このようにヘルプデスクのサービスレベルの向上（応答率の向上、対応時間の短縮等）を図るような場合、問合せだけ別の管理表にあるよりも、インシデント管理表に受付たすべてのインシデントが記載されている方が管理がしやすいです。
その場合でも問合せ管理表や問題管理表は必要となるので、インシデント管理からそれらの管理表に管理を移していくことになります。
逆に、ユーザー系IT企業でよくあるように、開発部門が保守も兼ねて問合せを受けているような場合、前述のような管理は行わないため、インシデント管理には問合せを含めません。ただし「問合せだと思っていたら障害事象だった」とか「障害だと思っていたら、ただのユーザーの操作ミス（問合せ扱い）だった」といったことがあるので、インシデント管理表と問合せ管理表は、多少、重複するものも出てきます。
このように、インシデント管理の対象を何にするかは、管理の目的によって異なるため、目的を明確にして管理することが無駄な作業をしないためにも重要となります。
３．インシデント管理と問題管理の違い
問題管理は、発生したインシデントの根本原因を解決するための管理です。
インシデントの根本原因を究明し、問題を解消することでインシデントの発生が無くなります。
それに対してインシデント管理の対象は、発生した個々のインシデントの一次対応までです。
例えば、サーバーがメモリー不足でスローダウンするインシデントが発生したとします。
サーバーを再起動してスローダウンが解消すれば、インシデント管理としてはクローズですが、同様のインシデントが再発する可能性は残っています。
メモリー不足の原因を究明し、原因を解消すれば問題管理もクローズとなり、同様のインシデントは発生しなくなります。
インシデント管理は、インシデント発生の都度、記録をしていきます。同一事象であっても１００回発生すれば、１００件のインシデントとなります。
発生の都度、記録をする目的は、一次対応を漏れなく行うことと、対応の優先順位を決める判断材料とするためです。様々なインシデントが発生する場合、優先度の高いものから根本原因を究明し解決していくことになりますが、多発しているインシデントは対応の優先度が高くなります。
４．インシデント管理表は必要か？
これまでインシデント管理表の説明をしておきながら、必要か？は無いかもしれませんが、実はインシデント管理表は必ずしも必要なわけではありません。
インシデント管理表と問題管理表は重複する項目が多いためです。
インシデントの種類が多く（つまり問題管理の数が多い場合）、発生頻度も多い場合、インシデント管理表と問題管理表を分けて管理した方が管理がしやすいです。
でもインシデントの種類が少ない場合、分けて管理するメリットはありません。
問題管理表の中に、インシデント管理の要素を盛り込むことで、不必要な二重管理がなくなり効率的にインシデントと問題の管理が可能となります。
このように管理表というものは、管理する対象の種類や量によって、適切に表を分けたり統合したりすることが重要です。
【振り返り】
インシデント管理の説明は以上で終了となります。次回は問題管理の説明をしていきたいと思います。
①インシデント管理
②問題管理
③構成管理
④変更管理
⑤リリース管理
⑥サービスデスク
⑦サービスレベル管理
⑧キャパシティ管理
⑨可用性管理
⑩ITサービス財務管理
⑪ITサービス継続性管理
