ITIL NaviITガバナンス/運用管理のワンストップ情報コーナー

用語集

インシデント管理

2010年03月20日

インシデント管理とは、ITサービスの利用者(顧客)が”何らかの理由により”業務を遂行できない状態を、いかに早く解決し、業務を続けられるようにするかを支援するIT運用管理プロセスです。この際の”何らかの理由”が、インシデントにあたりますが、一般的には対応方法が手順化されているかどうかによって、大きく以下に示す2つに分類することができます。※1

  1. 障害回復要求 (例:データ閲覧不可、ログインエラーに関する問い合わせ等)
  2. サービス要求 (例:情報の開示要求、登録情報変更依頼、パスワード再発行依頼等)
ちなみに「2. サービス要求」にのみに関わるプロセスを特に「サービスリクエスト管理」と呼ぶ場合があります。

※1. インシデントの定義にサービス要求を含めるかどうかについては、規格やガイドライン、専門家によって異なる場合があります。
【ITIL ver3における定義】
「予定していないITサービスの中断、または、ITサービス品質の低下。ITサービスに影響をもたらす可能性のあるITサービスを構成するコンポーネントの障害(例:ミラーリングしているハードディスクのうちの1台が故障する場合など)」
【ISO20000における定義】
「サービスの標準的な運用に属さないあらゆる事象であって,サービスの中断若しくはサービス品質の低下を引き起こすもの,又は引き起こす可能性があるもの。」 注記:インシデントには、問い合わせ(例えば、”・・・するには、どうすればよいか”)を含む場合がある。

インシデント管理に欠かせない6つの活動

インシデント管理プロセスには、主に以下の6つの活動があります。

1. 受付と記録の実施
顧客からの問い合わせの全ての記録を行います。

2. 分類と優先度付けの実施
インシデントに「誰が対応すべきか」、「どのように対応すべきか」、「どれだけ急いで対応すべきか」、「すぐに解決できそうな問題か」など、対応に必要な基礎情報を特定するため、「インシデントの種類(障害回復要求/サービス要求、情報照会)」、「障害がもたらす影響の対象と範囲」などに基づいて、インシデントの分類を行います。

3.ファーストヘルプラインによる解決
分類結果に基づき、対応が容易なもの(例:単なる情報照会や対応手順が決まっている問い合わせ、過去に発生したことのある事象(既知の問題)など)については、ナレッジベースなどを活用しつつ、ファーストヘルプラインによる解決を試みます。

4. エスカレーションによる解決
ファーストヘルプラインにより解決できなかったインシデントや、あらかじめ定めた基準を超える内容のものについては、サービスレベルアグリーメント(SLA)の制約の範囲内で、適切にエスカレーション(より詳細かつ正確な調査・判断ができるスペシャリストへ依頼する)し、調査し、解決を図ります。

5. インシデントの追跡とライフサイクル管理
インシデントの担当者は、報告を受けたインシデントがクローズされるまでの間「インシデントの報告を受けてからの経過期間」「現在の調査状況」「顧客へのアップデート状況」「次回の進捗報告のタイミング」「解決が長引いている場合のエスカレーションの必要性」などについて管理を行います。

6. クローズ
インシデントが解決された時点で、顧客ならびに関係者に速やかな報告を行います。また、解決にいたった活動について記録を行います。

「インシデント管理」と「問題管理」は似て非なるもの

インシデント管理が、あくまでも顧客へのITサービスをいかに迅速に復旧させるかを目的としているのに対し、「問題管理」は原因究明を目的しています。

以下を例にとり解説します。

【顧客からの報告内容】
「サーバがソフトのバグによりシステムダウンしてしまった」

【IT部門が行った4つの活動内容】
  1. 「サーバの再起動を行ったところ、ソフトが再び稼働した」(回復処置)
  2. 「モジュールにバグを発見したためパッチを作り2日後に適用した」(是正処置)
  3. 「同様のモジュールを使用しているソフトが他にも多数あることが判明したため、後日それらにもパッチを適用した」(予防処置)
  4. 「バグが発生した原因が、開発時のQA(Quality Assurance:品質保証)プロセスのチェックの甘さにあったことがわかり、QAで使うチェックリストの改善を行った」(是正処置)
「IT部門が行った4つの活動内容」のうち、1番にあたるものが「インシデント管理」によるものです。そして、2、3、4番が「問題管理」によるものです。ただし、場合によっては障害復旧のための(インシデント管理における)活動が、イコール、原因究明につながるケース(上記の例で言うところの2番も同時に行える場合)もあります。とは言うものの、問題管理は上記の例で言うと2番だけでなく、3番や4番などに対する管理も行う必要があることから、厳密にはインシデント管理と分けてプロセスを考えることが必要になります。

観点が異なるサービスデスクとインシデント管理

先述したとおり、インシデント管理はIT運用管理プロセスの1つであり、ITサービスの利用者(顧客)が”何らかの理由により”業務を遂行できな状態を、いかに早く解決し、業務を続けられるようにするかを支援することを目的とした活動を指します。

これに対し、サービスデスクは機能の1つであり、顧客とIT部門とを密につなぐことを目的とした活動を行う組織(人の集まり;単一窓口)を指します。なお、顧客とIT部門とを密につなぐことを目的とした活動とは、たとえば、
 
  • インシデント管理における初期サポートやエスカレーションに関わる活動
  • 新しいプログラムリリースについての顧客への案内
  • 顧客満足度調査の実施
  • 傾向分析(合意された期間内に解決したインシデントの割合や放棄呼率※2の分析)結果などからのサービス改善提案の実施

などがあります。サービスデスクは、これらの活動を行う組織全体(”機能”)を指します。
※2. サービスデスクが応答する前に、ユーザが問い合わせを放棄したコールの割合

様々な規格に登場する「インシデント管理」

インシデント管理は、変更管理と同様に「ITガバナンス」、「ITの運用管理」、「情報セキュリティ」のいずれにおいても中核を担うコントロールになります。

以下に、代表的なインシデント管理の位置づけについて挙げておきます。
ISO/IEC ISO27001-1:2005 付属書Aの13「インシデント管理」
ISO/IEC ISO20000-1:2005 8.2「インシデント管理」
ITIL Ver3 サービスオペレーションの主要プロセスの1つとして言及
COBIT4.1 「サービス提供とサポート」におけるDS8にて言及
B25777-1:2008 ICT※3継続 6.6 「ICTインシデント対応」

【おまけ】 インシデントの語源から学ぶ「インシデント管理」のポイント

インシデントという言葉は、非常に抽象的な意味を持つため、対象とする規格・ガイドライン・組織・人によって解釈が異なる可能性が高いものです。実際、インシデントは「出来事」という意味で日本語に訳されます。その語源を見てみても、インシデント(=incident)は"in-cidere"に由来し、これはすなわち"on" + "to fall"であり、「何らかの結果に何とはなしに結びつく事象のこと」と示されます。

このことからも、「インシデント=システム障害」と、必ずしも単一的に結びつくものではないことが分かります。したがって、「インシデント管理」において重要なことは、自分たちの組織に導入しようと考えている管理のプロセスにおける”インシデント”とは何であるのか?ということを真っ先に確認・定義することであると言えます。
※3. ICT:Information and communication technology

(文責:工藤 秀義