インシデント管理

インシデント管理は、ITILのベストプラクティスの採用を目指す組織が実装または改善の対象として最初に取り上げることが多い、IT Infrastructure Library（ITIL）のプロセスです。その理由はシンプルです。コンシューマライゼーションの向上とサービス価値の実現です。インシデント管理は、サービスデスクやセルフヘルプテクノロジーとの関与を通じて、迅速なサービス復旧を目的として組織が日常的に活用するプロセスです。

このプロセスの高いパフォーマンスは、組織および影響を受けるサービスのユーザーにとって不可欠です。これが欠如すると混乱が生じ、ユーザーのパフォーマンス、組織のパフォーマンス、そしてサービスの顧客と提供者双方にとっての経済的価値全体に悪影響を及ぼします。インシデント管理それ自体はビジネス戦略を支援するものであり、ビジネス戦略はインシデント管理が価値を生み出す形で遂行されるための手段を可能にするものでなければなりません。

このガイドでは、ITILのインシデント管理システムを詳しく解説します。プロセスの定義と目標設定をはじめ、ITILがプロセスフローをどのように定義しているかを確認し、サポートチームが連携してITインシデントを解決する方法を理解するとともに、主要業績評価指標（KPI）を用いてエンタープライズ内のプロセスの成功をどのように測定できるかを学びます。最後に、新しい統合サービス管理ソフトウェアがどのように自動化を促進し、組織が統合サービスデスクを構築してインシデントをより効率的に解決するための支援をどのように行うかを検討します。

インシデント管理とは何ですか？

ITILでは、「インシデント」という用語は、ITサービスの計画外の中断または品質低下を指すために使用されます。これは大規模な組織にとって非常にコストの高い問題となり得ます。インシデント管理プロセスの主な目的は、中断が発生した際に可能な限り迅速にユーザーへのサービスを回復させることです。

基本的なリクエスト履行とともに、インシデント管理はIT組織が日々管理する最も重要なプロセスの一つです。リクエスト履行プロセスがパスワード変更のような標準的なユーザーリクエストへの対応に使用されるのに対し、インシデント管理は実際のサービス障害に対処し、障害を解消して可能な限り迅速にユーザーへのサービスを回復させることを目標としています。

ITILで使用される5段階のサービスライフサイクルモデルにおいて、インシデント管理は「サービスオペレーション」に該当します。これはサービスライフサイクルの第4段階であり、サービスがすでに組織によって運用されている段階です。このプロセスは、パフォーマンス、可用性、およびサービスへのユーザーアクセスを確保するために取り組むことで、組織がサポートするサービスやアプリケーションから最大の価値を引き出せるよう支援します。

インシデント管理のプロセスとワークフローとは何ですか？

インシデント管理は、報告されたインシデントのライフサイクルを管理するためにIT組織が従うプロセスです。このプロセスは、インシデントが適切に解決され記録されることを確保するために実施しなければならない複数のステップ（しばしばサブプロセスと呼ばれます）で構成されています。以下では、各サブプロセスと、それが組織にとって何を実現するかについて説明します。

インシデント管理サポート

インシデント管理サポートの目標は、インシデントを効果的かつ効率的に処理するために必要なツール、プロセス、スキル、およびルールを提供・維持することです。このプロセスは、サービスデスクエージェントや技術者がIT組織内で発生するインシデントに対応・解決するための十分な教育とトレーニングを受けていることを確保するために役立ちます。また、インシデントの処理と解決に関するルールとワークフローを維持し、技術者がインシデント解決に向けた次のステップを常に把握できるようにします。

インシデントのログ記録と分類

このサブプロセスの目的は、迅速かつ効果的な解決を促進するために、インシデント報告を適切な精度で記録し優先順位付けすることです。組織はインシデントやその他のIT問題の解決に利用できるリソースが限られていることが多く、受信したインシデント報告の効果的な優先順位付けは、最優先のインシデントに対して適切に人員を配置するための重要なステップです。IT組織は、報告されたインシデントのスコープと重大度を判断し、それに応じて優先順位を付けることに習熟する必要があります。インシデントのログ記録と分類は、ITオペレーション監視ソリューションがパフォーマンスや可用性イベントの発生に応じてインシデントを生成する場合など、しばしば自動化されています。

1次レベルサポートによる即時インシデント解決

ユーザーが初めてサービスデスクにインシデントを報告する場合、通常は1次レベルのサービス技術者に問題を報告します。理想的な結果は、1次レベルの技術者が初回の問い合わせでインシデントに対処し、IT組織が設定した目標解決時間内にITサービスを復旧させることです。目標時間内にインシデントを解決できない場合、またはインシデントの解決により高度な専門的技術知識が必要な場合は、エスカレーションが発生し、2次レベルのサポート技術者がインシデントを引き継ぐことができます。

2次レベルサポートによるインシデント解決

1次レベルサポートによる初回解決を超えてインシデントがエスカレーションされると、2次レベルのサポート技術者がインシデントを引き継ぎ、できる限り迅速にサービスを復旧させるための回避策を探し始めます。このレベルでは、技術者はインシデントの解決にサポートグループやサードパーティーサプライヤーを関与させる柔軟性を持ちます。例えば、インシデントがアプリケーションの誤動作によるものである場合、2次レベルの技術者はそのアプリケーションを開発した企業に連絡し、インシデント解決に関する追加のガイダンスを求めることがあります。インシデントの根本原因に対処する方法がない場合、2次レベルサポート技術者は問題レコードを作成し、インシデントを問題管理プロセス・チームに移管することができます。

重大インシデントの処理

先述のとおり、リソースを最も効率的に展開するために、緊急度に応じてインシデントを優先順位付けすることの重要性について述べました。重大インシデントは、組織が認識できる最も優先度の高いITインシデントであり、ビジネス活動への深刻な中断や脅威を構成するものであるため、財務的損失やその他の重大な結果を防ぐために最高の緊急度で解決する必要があります。重大インシデントは、1次レベルおよび2次レベルのサポート担当者を通じて迅速にエスカレーションされ、インシデントが迅速に解決されない場合はサードパーティーサプライヤーが関与することもあります。この場合も、根本原因の修正が不可能な場合は、インシデントは問題管理に移管されます。

インシデントの監視とエスカレーション

ITILのベストプラクティスに従うIT組織は、報告された各ITインシデントのステータスとエスカレーションを監視するシステムを構築・維持します。インシデント管理を担当するITマネージャーは、現在報告されているインシデントの数を追跡し、インシデント管理プロセスにおけるそのステータスを確認できる必要があります。インシデント管理チームがインシデントへの対応に時間がかかりすぎると、サービスレベル契約（SLA）の違反が発生し、サービス停止はビジネスの中断につながります。インシデント監視は、インシデント管理チケットがタイムリーに解決され、プロセスを通じて適切に処理されることを確保し、組織のサービスレベルが維持されるために活用されます。

インシデントのクローズと評価

インシデントが効果的に解決された後、インシデントレコードは最終的な品質管理ステップに提出されます。このサブプロセスは、インシデントが解決されたこと、およびインシデントのライフサイクルが十分な詳細をもって文書化されていることを確認します。インシデント報告書からの知見は、ナレッジ管理プロセスへのインプットを含め、組織が将来にわたって活用することができます。インシデントのクローズと評価は、組織がインシデントに関するすべての重要情報を追跡し、解決したインシデントから教訓を得られるようにするために役立ちます。

ユーザーへの積極的な情報提供

インシデント管理レポートは通常、組織内のITリソースに対する単一の窓口として機能するサービスデスクを通じて提出されます。サービスデスクチームはまた、この通信ポータルを活用して、組織内の既知の問題やサービス停止についてユーザーに積極的に情報提供することができます。このサブプロセスは、組織全体に情報を配布し、組織内のサービス停止に関する最新情報を提供することでサービスデスクへのリクエストや問い合わせの件数を削減するために役立ちます。

インシデント管理レポーティング

このサブプロセスは、インシデント管理プロセスから情報を収集し、他のサービス管理プロセスに供給することで、組織が過去のインシデントデータに基づいてパフォーマンスを改善する機会を確保するために機能します。

組織はインシデント管理の成功をどのように測定しますか？

ITILサービスライフサイクル全体にわたるプロセスの成功を測定することは、継続的なサービス改善の鍵となります。組織は各プロセスのパフォーマンス監視に使用するメトリクスを決定し、改善の最良の機会を特定するためにそれらのメトリクスを正確に報告する必要があります。以下では、インシデント管理プロセスが適切に機能していることを確保するために組織が測定できる、最も重要なKPIを5つ挙げています。

インシデントのステータス - 組織はソフトウェアを使用して、インシデント管理プロセスの一環として現在管理されているインシデントのステータスを追跡できます。リアルタイムですべてのオープンインシデントのステータスを確認することで、最大のバックログが発生している箇所や、フローを改善して解決時間を短縮するために組織がリソースを最適に投入できる方法についての情報が明らかになります。例えば、多くのインシデントが2次レベルサポートで解決されないまま滞留している場合、組織は以下のような複数の潜在的な解決策を検討することができます。

1. インシデント処理を迅速化するために2次レベルサポートのスタッフを増員する。
2. インシデント解決の効率を高めるために2次レベルサポートのスタッフのトレーニングを強化する。
3. エスカレーションを削減するために1次レベルサポートのスタッフのトレーニングを強化する。
4. 特定タイプのインシデントのバックログ管理を支援できる3次レベルサポートを活用する（例えば、プリンターの誤動作に関するインシデントのバックログがある場合は、メーカーに連絡して問題の解決を依頼する）。

初回解決率 - 初回解決率は、1次レベルの技術サポートスタッフが初回の問い合わせでインシデントを解決する頻度を示します。タイムリーな解決は、十分な経験を持ち、リソースとナレッジへのアクセスが確保された効果的なトレーニングを受けたスタッフによってもたらされます。

インシデント1件あたりの平均コスト／インシデント解決工数 - 組織は、管理されるインシデント1件あたりの平均コスト、または各インシデントの解決に費やされる平均工数のいずれかを測定することを選択できます。組織はサービスレベル契約と顧客満足度を満たしながら、これらのコストを最小化することを目指します。ビジネスの稼働時間向上につながるIT投資は、プラスの投資対効果（ROI）を生み出すべきです。

平均初回応答時間 - このKPIは、ユーザーがインシデントを報告してからサービスデスクがそのインシデントに応答するまでの平均時間を測定します。サービスデスクがインシデントを迅速に解決できる一方で、応答に3時間かかる場合、組織は1次レベルのサービス技術者を増員して応答時間を短縮し、それに応じてサービス可用性を向上させることを検討すると良いでしょう。

繰り返しインシデントの件数 - 繰り返し発生または再オープンされるインシデントは、組織にとって好ましくない状況です。これは、サポート技術者が問題の根本原因を特定できていないことを意味する場合があり、そのため問題が繰り返し発生し続けます。ITスタッフは問題の解決方法を知っており、ユーザー自身で対処できる場合でも、セルフサービスを促進するためのリソースが利用できないことがあります。繰り返しインシデントは、問題の根本原因を特定し、ユーザーがITに報告せずに問題を解決できるよう積極的にコミュニケーションを図ることで回避できます。

インシデント管理の役割と責任

インシデント管理プロセスを効果的に実行するためには、明確に定義された役割と責任が不可欠です。インシデント管理チームは以下のメンバーで構成されています。

インシデントマネージャー

インシデントマネージャーは、インシデント管理プロセスを推進し継続的に改善する主要な責任を担います。中小規模の組織では、この役割は一般的にサービスデスクマネージャーに割り当てられます。大規模な組織では、独立して定義された役割となる場合があります。主な責任には、チームリーダーシップ、主要業績評価指標（KPI）の経営陣へのレポーティング、1次および2次ラインサポートの直接管理、インシデント管理システムの管理、およびインシデント管理プロセスワークフローの徹底が含まれます。

1次ラインサポート

1次ラインサービスデスク技術者は、情報を求めたりサービス障害を報告したりするエンドユーザーにとっての単一の窓口です。インシデントの初期サポートおよび分類、および障害が発生したサービスをできる限り迅速に復旧させるための即時対応に主な責任を持ちます。インシデントを解決できない場合、1次ラインサービスデスク技術者は適切なサポート担当者にインシデントを転送し、対応状況を監視しながら、インシデントのステータスについてユーザーに最新情報を提供します。

2次レベルサポート

2次レベルサポート技術者は、通常1次ラインサービスデスク技術者よりも高度な知識を持ちます。1次レベルサポートが解決できないインシデントを担当することがあります。これらの技術者は、通常サービスをできる限り迅速に復旧させるために、ソフトウェアまたはハードウェアベンダーのサードパーティー専門家と連携することがあります。

インシデント管理のKPI

測定はITILライフサイクルのすべての段階において重要です。各プロセスには、全体的なパフォーマンスを効果的に評価するために監視・報告すべきメトリクスがあります。継続的サービス改善には、改善が必要な領域を特定するために各プロセスのパフォーマンスを測定することが不可欠です。

一般的なインシデント管理のメトリクスには以下が含まれます。

• 報告されたインシデントの総数（カテゴリー、優先度、担当者、組織単位別など）
• インシデントのステータス
• インシデント作成から解決までの時間
• インシデントとSLA（達成・違反）
• インシデント1件あたりの平均コスト
• 再オープン率
• エスカレーションなしで処理されたインシデント
• 初回解決率
• 繰り返しインシデントが発生している構成アイテム
• 時間帯別インシデント数

KPIは重要成功要因（CSF）に関連付けられるべきであり、CSFは目標に関連付けられるべきです。この関係性は、現状の維持と望ましい状態への改善に向けた意思決定の支援に役立ちます。組織はそれぞれ異なりますが、ユーザー、スタッフ、および経営陣向けの適切なレポートは、プロセスとビジネス全体の両方を改善するために活用できる重要な意思決定を支援します。

インシデント管理実装のベストプラクティス

ビジネスにITILフレームワークを導入することは、困難な作業となる場合があります。あらゆるITILプロセスと同様に、インシデント管理の実装にはビジネス側からのサポートが必要です。特に重要なのは、経営幹部および上層管理職からの賛同を得ることです。導入プロセスを開始する前に、インシデント管理のベストプラクティス遵守に向けたプロジェクト管理と調整全体に専念できる担当者を少なくとも一名確保しておくことが重要です。また、現状のプロセスおよび将来の目標プロセスの両方をサポートするITサービス管理（ITSM）ツールを整備しておくこと、およびIT部門との主要なインターフェースとして機能するサービスデスクを設置しておくことも、非常に有益です。

1）現在のインシデント管理プロセスを理解する

組織によっては、インシデントを処理するための一貫したプロセスが存在しない場合や、より洗練度の低いプロセスが運用されている場合があります。いずれの場合も、既存のサービスデスクプロセスが何を提供しているかを理解するために、既存のプロセスをできる限り詳細にマッピングすることが重要です。

2）インシデント管理プロセスの長期的なビジョンを特定する

組織がインシデント管理プロセスに何を期待しているかを理解することも重要です。その期待は、ITSMツールに含まれる汎用的なインシデント管理テンプレートに基づく場合もあれば、組織固有のニーズに基づくよりカスタマイズされたプロセスとなる場合もあります。

3）ギャップ分析を実施する

次に、組織の現在のインシデント管理プロセスとインシデント管理の長期的なビジョンとの間で調整が必要な点を特定します。これにより、インシデント管理の目標と全体的なサービス目標を達成するために必要な工数、時間、費用、およびリソースに関する有益な情報を得ることができます。

4）実装ロードマップを作成する

ITILプロセスを導入するには開発に時間がかかります。経営陣の期待値を適切に管理するためのロードマップが必要となります。そのロードマップを活用して、実現に必要な活動内容、スケジュール、および工数を明示してください。このロードマップには、短期的な成果（クイックウィン）、ツール実装、プロセス変更、人材・組織の整備、コミュニケーション計画、および全体的なガバナンスの変更を含める必要があります。

5）プロジェクト実装を開始する

いよいよ実装を開始する段階です。すべてのタスクの完了に向けたアクションまたは作業、責任者、およびスケジュールを定義したプロジェクト計画を作成してください。各マイルストーンを達成するたびにその成果を共有し、最終的な実装目標に向けた進捗を示してください。

インシデント管理ソフトウェアの機能チェックリスト

インシデント管理ソフトウェアおよび／またはインシデント管理機能を提供するITサービス管理スイートを評価しているIT組織にとって、主要なプロセスをサポートするために必要な機能の種類を理解することが重要です。インシデント管理ソフトウェアは、最低限以下の機能を提供する必要があります。

• インシデントレコードの作成、変更、解決、およびクローズ
• 各インシデントレコードに関連付けられた固有のレコード番号の生成
• インシデントと問題レコード、ナレッジ記事、既知の回避策、および変更要求のリンク
• 構成管理データのインシデントレコードへのリンク
• 関連する問題が解決された際のインシデントオーナーへの通知
• 監査ログへの履歴データの自動記録
• 設定可能なインシデント分類
• インシデントの検索およびレポーティング機能
• リソースの可用性、タイムゾーン、サイトなどに基づくインシデントのルーティング
• 分類に基づくインシデントの優先順位付け、割り当て、およびエスカレーション。優先度またはその他の分類に基づくエスカレーション
• インシデントの自動作成、更新、およびクローズ機能を持つイベント監視ソリューションとの統合
• フリーテキスト、ドロップダウン、日時、添付ファイル、スクリーンキャプチャを含む柔軟なフィールド設定
• インシデントと顧客データのリンク
• 診断と解決のためのナレッジベースソリューション／スクリプトの活用
• 外部サービスプロバイダーへのインシデントまたは関連タスクの割り当て
• 複数の担当者へのインシデントの割り当て
• インシデントレコードからの問題または変更要求の作成
• 期限、SLA、クローズ、およびその他の活動に基づくインシデントアラートの自動送信（ITスタッフおよび／またはエンドユーザー向け）
• インシデントレコードとSLAのリンク
• 顧客満足度調査によるエンドユーザーからのフィードバック収集
• 他者に代わるインシデントの起票
• インシデントを保留状態にするSLAクロック停止機能
• インシデントとサービスリクエストの区別
• 解決済みインシデントの再アクティブ化
• 影響度と緊急度による優先度の自動決定
• 発信者番号に基づいて顧客情報を自動入力するテレフォニー／ACDシステムとの統合