目次

インシデント管理の問題点

担当者の問題

仕組みの問題

継続させるための課題

データ活用の問題

ITILは絶対ではない

インシデント管理のメリット

今回は前回に引き続き、インシデント管理についてご紹介いたします。

インシデント管理の問題点

インシデント管理プロセスを実装していく上での問題点を、過去の経験等も踏まえて、いくつかご紹介します。

担当者の問題

最も大きな問題点はインシデント管理を行う人材かもしれません。
インシデント管理は、ITサービスをユーザに対して提供するために、非常に重要な職務です。
ITILでは、発生したすべてのインシデントを記録することが求められています。
前回も述べましたが、これは、すべてのインシデントを管理、分析、過去履歴を活用することにより、できるだけ短時間でユーザの不具合を解決、または回避策（ワークアラウンド）を提供することにより「ITサービス」によってエンドユーザが業務をスムーズに行うことを実現するためです。システム運用担当者は、コンピュータの管理が業務ではなく、エンドユーザへ「ITサービスを提供している」という意識が重要なのです。
担当者がこのことを理解していないと、すべてのインシデントを記録しなかったり、分類が不適切であったり、必要事項が十分に記録されていないなどの問題が発生します。この場合、類似インシデント情報を参照したときに、情報が不十分なため、役に立たないということになりかねず、本来のインシデント管理の実現はできません。
インシデント管理における最も重要な課題は、そこで実際に作業にあたる担当者のスキルだけでなく、モラル、モチベーションをいかに高めることであると考えます。このことは、ITサービスマネジメントにおける「人」の要素が非常に大きいことが実証されることになります。
この課題を解決し、高品質なITサービスを提供するためには、現場担当者、管理者、ユーザなどの関係者間で、どのようにしてITサービスを利用してビジネスを行うかを考え、改善活動を継続的に行っていく必要があります。
その際には、担当者のキャリアパスや、あるべき姿を考えた成長も必要であり、昨今話題のITSSを利用したりする方法も有効となります。

仕組みの問題

すべてのインシデントを記録するためには、作業ルール・プロセスは必須ですが、何らかの仕組みを構築することも検討すべきといえます。
もちろん、件数が少なければ、手書きやEXCELでも管理可能ですが、将来におけるインシデント・データの活用や、情報の共有を前提として考えると、インシデントをデータベース化することが必要といえます。
インシデントのデータを入力する場合、できるだけ容易に入力する方法を確立できないと、継続することが困難になります。

仕組みの構築にあたってのポイント

少ない工数、キータッチでデータを入力可能なこと。できれば項目の選択式が望ましい。
情報共有が容易なこと。
インシデント・データのトレーサビリティが確保されること。できればリアルタイムの把握。
エスカレーション等が明確に管理できること　　など

継続させるための課題

システム運用改善におけるひとつに、「継続した活動」があげられるかと思います。
PDCAサイクルが重要とわかっていても、気がつけばやらなくなっている業務は案外多いものです。
推進者が異動、退職などでいなくなった、担当者が勝手に業務をやめてしまう、引継ぎがない、といった要因で改善活動が頓挫することが往々にして見受けられます。
システム運用のように定常的、かつ恒久的な業務（サービス）の場合、特に重要なことは継続した改善活動です。
ITILの各プロセスにおいても継続性が重要であることは、CSIP（Continuity Service Improvement Program）継続的改善活動として記述されています。
インシデント管理においても、インシデント発生件数など、数値の把握だけでなく、サービスレベルの維持・改善に向けて、「継続的に」活動を行わなければなりません。継続することにより、インシデントの削減や解決時間の短縮などを測定し、さらなる、サービスの向上を図ることが必要です。
システム運用部門だけでなく、エンドユーザとの定例会の設置や、QC活動といった品質向上のため継続的な取り組みのひとつと捉えて活動することが大切です。

データ活用の問題

インシデント管理の事例として、インシデント・データは蓄えてみたものの、活用していないという話をよく耳にします。
これは、インシデント・データを後にどのように活用するかを考えて蓄積することが解決策といえます。つまり、ただ蓄積しただけでは、データの有効活用は望めないということです。
インシデントを記録する際に、分析する項目をある程度想定して、初期分類を行うことで、後にデータを有効に活かすことができます。

インシデントの分類　　　原因の分類、インフラ、人的、原因別状況の把握
インシデント件数　　　発生件数の増減
対応状況策の分析　　　傾向分析、対応時間の分析
発生から解決までの時間　　　サービスレベル管理との連携
本来、サービスカタログとして、サービスの内容をITサービスの提供側とエンドユーザ側で定めたサービスレベルを評価し、よりよいサービスに結びつけるためのプロセスですから、インシデント管理単体ではなく、ITサービス提供のための一連の流れの中のひとつの要素として捉える必要があります。

ITILは絶対ではない

ITILはベスト・プラクティスであり、すべてにおいて準拠する必要はないと考えています。
たとえば、ITILではすべてのインシデントを記録することを要求していますが、過去のデータを分析し、あきらかに不要なインシデント（たとえば監視ツールから出力される対応不要なメッセージ）などは記録する必要はないと判断することも可能です。インシデントの発生件数は把握しておくにしても、毎回分類したり、詳細に記録しておく必要はないという判断です。
ITILはあくまでもITサービスの提供におけるベストプラクティスですから、盲目的に信奉し、すべてITILに記述されている通りにすることが正しいことだと思う必要はないのです。
現状のプロセスを分析し、もっとも正しい方法だと判断したのであれば、それがITILの記述と多少違っても、変更する必要はありません。
ただし、過去の経験上、問題分析を行い、解決策を検討し、改善活動を実施していく過程の中で、いつしか、ITILの考え方に類似してくることが多々あります。これはITILがベストプラクティスと呼ばれる所以でもあります。

→今後も問題点とその対策について機会を見てご紹介していきたいと思います。

インシデント管理のメリット

ITILを活用して運用改善を実施する場合、インシデント管理から取り組む場合が多く見受けられます。
実際に、インシデント管理から取り組むべきというセオリーが広く知られています。海外のホームページの記載にもありますし、数多くの事例もあります。
その理由は、インシデント管理は他のITILプロセスに比較して、効果が出しやすいからと考えられます。確かに分析する項目も容易に思いつきますし、現場も理解しやすいことが考えられます。
実際にインシデント件数を削減し、インシデントの内容を分析、対策を講じることで、ユーザからの評判がよくなるといったメリットを得ることができます。
しかし、システム運用におけるインシデント管理は理論（ITILの記述）通りにはいきません。上記に記載した問題点を抱える場合も多々あります。これらを解決し、ITをサービスとして提供していく体制を構築することが重要です。

インシデント管理を実施し、かつ、その成功により、ユーザやシステム運用の現場が「成功体験」を得ることによって、さらなる改善活動へつながることが本当のメリットといえるのではないでしょうか。

次回はシステム運用とエンドユーザをつなぐ単一窓口、「サービスデスク」への取り組みについてご紹介します。