インシデント管理とは？その具体的な実施手順や関連事項について解説

ITサービス管理のためのテンプレート、ITIL (Information Technology Infrastructure Library)。 
そこで定義されるプロセスの中に「インシデント管理」という言葉があります。 

​​例えば「Webサイトが接続できない」などのトラブルが起きた時、短時間でサイトへの接続が復旧しているのは「インシデント管理」をしているからです。 ​ 

​​この記事では、インシデント管理とはなんなのか、具体的にどんな方法で管理しているのかを解説します。

また、企業のセキュリティインシデント対応のご担当者様へ。セキュリティインシデント発生時の対応を効率化できる「インシデント管理台帳」を無料で配布しています。ぜひご活用ください。

インシデント管理とは

「インシデント管理」とは、ITシステムの正常な利用を妨げる「インシデント（問題）」の対応管理です。 

ITILにおけるインシデント管理の目的は「業務の復旧」で、インシデントが与える業務への影響を最小限に抑える事を第一として考えられています。 

例えば、「サーバーが落ちて、見たいデータにアクセスできない」というトラブルが発生した際、「コピーしてある同じデータを閲覧できるようにする」「別のサーバーに切り替えてアクセスを可能にする」など「データを見たい」といった要望に即座に応えられるようにすることです。 

インシデント管理は、根本的な原因を解決するのではなく、「即座に目的を達成する」ことに重きを置いた、応急処置というようなイメージに近いでしょう。 

ITの運用管理においてシステムの可用性（システムが継続して稼働できる度合いや能力）を維持する一つの手段として用いられています。 
高いサービス品質を維持するには、トラブルへの対処も効率的にしなくてはならないため、インシデント管理の業務が必要とされています。

そもそもインシデントとは

インシデントとは、直訳すると「出来事」「（小さな）事件」という意味です。 

「重大事件に発展する可能性のある異変」というような、被害が拡大せぬよう迅速な対処が求められます。 
たとえば、組織のIT全般を扱うサポートデスクなら、「システム障害」「サービスレベルの低下」「セキュリティ事案」など守備範囲が広くなりますが、特定の業務に特化した機器やシステムのヘルプデスクであれば、「仕様照会」や「操作案内」などの利用サポートが含まれるケースも。 

このように、IT分野においては「システム異常」を指すことが多いですが、対応チームや担当範囲によって、対応するインシデント内容は変わります。

インシデント管理と問題管理の違い

インシデント管理には再発防止や改善策の実施が含まれると思う方もいるかもしれません。 

ですが、それは「問題管理」という別の業務になります。 
インシデント管理の対応とその知見から一歩進んで、「IT管理をブラッシュアップする」のが問題管理です。 
問題管理はインシデントから問題を抽出・発見して、根本原因の特定と対策を実施し、同様なインシデントの再発防止、またサービス品質の安定や改良につなげます。 

インシデント管理は起こったトラブルをひとまず解消して、ユーザーの利用継続をかなえる応急処置であり、それ以上踏み込むことはありません。 
プリンタが故障したら代替手段を用意し、ユーザーの業務を滞らせないのがインシデント管理、故障の原因特定と再発防止策によりサービス品質を揺るぎないものにするのが問題解決です。 

インシデント管理のフロー

インシデント管理のフローはおおむね以下のとおりです。

それぞれについて、次に詳しく説明します。

インシデントの検出・受付・起票

インシデント管理の開始は、ユーザーの利用を妨げる事象の検出です。
主に以下により認識されます。

システム利用を妨げる何らかの事象がユーザーから寄せられたら受付します。 
その次に、今後の対応に活用したり、問題管理の資料とするため、直ちに記録を開始します。

インシデントの分類と対応策の決定

対応方針を決めるため、起こったインシデントを分類し、具体的な対応にあたって、対応優先度を設定して、適切な担当に対応を割り当てます。 

インシデントの分類は以下に基づいて行われることが多いです。

インシデントの種類は「障害回復要求」「サービス要求」の2つに大別されます。
前者で代表的なのはシステムトラブル、後者はパスワード再発行などです。
インシデントの現状と影響を把握し、緊急度を決定、対応方法の決定に移ります。

具体的な対応にあたり、次を決定します。

インシデントに対し、ナレッジの事例を参照して、容易に解決策が見つかる場合もあるでしょう。 
高度な専門対応が必要とされる場合はベンダーやSEにエスカレーションし、調整や進捗管理を行います。 

インシデント解消と進捗管理

インシデント対応は、ユーザーからの連絡や、検知による通知を受けた部署で対処することもあれば、適切な対処ができる組織に対応を依頼する場合もあります。 

具体的な対応として 

の3つがあります。 それぞれ具体的に見てみましょう。

サポート部門で対応

照会や問い合わせなど対応手順の決まっているもの、インシデント内容から容易に解決可能なものは一次対応チームで対処します。 

過去に発生が確認された既知の問題ならば、ナレッジベースを活用し、早期解決に努めます。

エスカレーション

エスカレーションは「上司に相談して判断を仰ぐ」という意味です。 

解決に高度な専門性が必要とするものや、サービスレベルの基準を大きく逸脱するインシデントの際、一次対応チームから担当エンジニアやベンダー、管理責任者に引き継いだり、連携しつつ対応します。 

クローズ　

インシデントが解決したら、ユーザーや関係者にすみやかに報告します。 
解決後の経過観察や追加フォローが必要な場合、完了するまで対応を継続します。 
そして、これまでの経過と対応履歴を記録にとどめ、必要であればナレッジベース等に追加し、今後の業務に活用できるようにしましょう。 

インシデントを無事解決し、事象の再発や対応再開の必要もなくなればクローズとなり記録も終了となります。 
その後、再発防止策や本質的な解決策の策定が必要とされる場合、別途問題管理のプロセスに引き継いで提供品質の向上に努めましょう。 

​​ISMS準拠の「インシデント管理台帳」で適切なインシデント対応をしましょう。​ 

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

インシデント管理を適切に行うことで、ユーザーサポート担当、マネージャー、ユーザーのそれぞれにメリットが生まれます。これらのメリットを生かすためには、トラブル対応など属人化していた知見やノウハウを整理して適切に管理しておくことが重要です。

ユーザーサポート担当のメリット

ユーザーサポート担当者が得た知見をデータベースとして管理することで、効率的にインシデント管理できます。これにより、ユーザーが使用しているシステムを迅速かつ正確に把握できるため、サポート業務の顧客満足度の向上が実現できます。

マネージャーのメリット

​​インシデント管理を行うことで、マネージャーは日常的な業務をユーザーサポート担当者に任せられるようになり、より重要なインシデントの分析や対応に時間を費やせるようになります。重要なインシデントへの対応を強化することで、システムやサービス全体の品質向上に貢献できるようになります。​ 

ユーザーのメリット

適切なインシデント管理により、ユーザーはトラブル発生時において素早い対応を受けることが可能となり、安心して業務を再開できます。

インシデント管理の注意点

運用管理の効率化のためにも、インシデント管理の業務プロセスを設定することが望ましいですが、次の注意点もあります。

インシデント管理を効率化するにはナレッジベースの整備と適切な運用が必須です。
システム規模やユーザー数、ニーズにより、サポート担当は専任でも他業務との兼任でもかまいません。

しかし、管理ツールを単なる記録ツールとして扱うと有用なナレッジとならず、インシデント対応が後手に回りかねません。
効率的な運用のためにも、対応方法や結果を適切に記録し、情報共有・参照しやすいナレッジを整備していきましょう。

インシデント管理は可用性の維持を至上命題としているので、一時的なその場しのぎの解決策でも良しとされます。
そのため、同じ事象の発生が何度も繰り返される可能性があります。

インシデント管理で解決して終わりではなく、真の効率化のため、サービス品質向上のために定期的な分析と問題管理が必要です。

インシデント管理の後続のプロセス

ITILにおけるインシデント管理とは「早急な復旧対応」であり、根本原因の特定は求められません。 
そのため、同じインシデントが発生する可能性は残ってしまいます。 

本来であれば容易に対応できる問い合わせまで、エスカレーションして専門の人材が対応するとなれば、特定の部署や人物に負荷かかり、重要なインシデントの早期解決や、対応の品質維持に悪影響をおよぼしてしまいます。 

それを解消するには、インシデント管理の後続のプロセス（過程）が重要になります。

ナレッジベース（知識ベース）の作成

一次対応の効率化、対応における個人差の解消をするために、ノウハウを蓄積して一次対応担当者向けのナレッジベースを作成する事が必要です。 

これにより、容易な問題によるエスカレーションを防ぎ、属人化の防止に繋がります。 

オペレーションルールを定義しておく

一次対応で解決できないインシデントの場合は、エスカレーションを行ないますが、その際、提供しているサービス内容が多岐にわたる場合は、複数存在する部署の中から適切な部門へ引き継がなければなりません。 

スムーズな対応ができなければ、大幅な時間ロス、サービス品質の低下、顧客離れなどの損失が発生するリスクがあります。 
このような事態を防ぐためにも、オペレーションルールの周知を徹底しましょう。 

問題管理と変更管理を実施

「問題管理」とは、繰り返しになりますが「インシデント」の原因を分析して突き止め、再発を防止するプロセスです。 

「変更管理」とは、変更によるサービスの中断を最小限に抑えながら、変更をスムーズに実施できるよう管理することです。 

どちらも、ユーザーにとって信頼できるサービスを提供するにあたり、非常に重要な取り組みと言えるでしょう。 インシデント管理で不足する要素は問題管理で補いつつ、それにともなう影響を変更管理で制御しましょう。

インシデント管理の事例

ここまで、インシデント管理のフローやメリット・デメリットや注意点について見てきました。ここでは実際のインシデント管理の具体的な事例について、ITシステムの運用におけるインシデントを想定してお話しします。​ 

たとえば、ある企業において利用している経理システムで、通常の操作をしたにもかかわらず、正常な画面遷移が実行されないというトラブルが発生したとします。

経理担当者は社内のヘルプデスク部門に問い合わせました。ヘルプデスク部門の担当者は個別対として、まずは一時的な回避策としてサービスの復旧を優先させ、原因究明や再発防止といったことは後回しにしてしまいます。

インシデント管理では、業務への影響をなるべく最小限に抑えるというのも重要ですので、こういった対応になってしまうのも人情です。

しかし、これでは、同様のトラブルが繰り返し発生する、トラブル対応の進捗状況が明瞭にならない、社内ヘルプデスク部門内での情報共有が不十分、といった課題の可能性をはらんでいます。

このようなインシデント管理の課題というのはしばしば発生しますが、これは、適切なインシデント管理フローの運用や専用ツールの導入で解決することが可能です。

​​具体的な流れは以下の通りです。​ 

こちらのインシデント管理台帳を使うと、適切なフローでインシデント対応を実施できます。ぜひご活用ください。

まとめ

インシデント管理は、システムトラブルを解消しユーザーの業務継続を支援する業務です。 

効率的なインシデント対応にはナレッジの整備と運用、技術者やベンダーとの連携がカギになるので、問題管理と変更管理も忘れずにあわせて実施しましょう。