インシデントに関連したよくある質問

今回はITILの中でも重要でありながら、「ツボ」を外すとさっぱり脈絡がつかめなくなる重要な用語について説明したいと思います。

ITILが成功した要因のひとつとして、「インシデント管理」と「問題管理」がきちんと決められたことが挙げられることがよくあります。しかし、インシデントという言葉に関してはあまり馴染みがないのが実情だと思います。そこで、これに関連して、インシデント管理のところでよく出てくる質問の、次の代表的な2つを取り上げてみたいと思います。

・「インシデント」と「サービス要求」は何が違うのですか？

・「インシデント」と「問題」の違いは何ですか？

システムやサービスの故障、不具合、機能低下など、顧客やユーザーからサービスデスクへ連絡が入ります。受付登録され、問い合わせ番号が発行されます。このあと、サービス要求として処理されたり、インシデントのままだったり問題になったりしますが、その違いはいったいなんでしょうか。従来の処理の方法と違いがあるので馴染みにくい要因もあるようですが、重要な項目なのでじっくりと違いを把握することにしましょう。

■「インシデント」と「サービス要求」は何が違うの？

インシデントとサービス要求は、インシデント管理のプロセスで取り扱われます。インシデント管理への顧客、ユーザーからの入力であるコールの集合の一部になります。コールは前述の範囲にさらに、不平、不満を含むサービスデスクへの問い合わせを総称しています。

サービス要求の定義とインシデントの定義ならびにアクティビティを見ると、以下のことに分かります。

・インシデントの受付・記録はサービス要求かどうかを判断する以前に行われています

・サービス要求はインシデントの分類されたものです

・すべてのインシデントがITインフラストラクチャの不具合とは限りません

・サービス要求は、処理手順や配布先があらかじめ決められています

・調査・診断が必要で解決・復旧を図らなければならないのはインシデントのまま扱われます

・機器やアプリケーションから出される“ワーニング”“アラート”もインシデントとして扱われます

・サービス要求を処理手順通りに進めると、標準変更となってRFC（変更要求）を起票しなければならないこともあります

ここまで見てくると、広い意味でのインシデントと、狭い意味でのインシデントがあることがわかると思います。

狭い意味でのインシデントとは、サービスで何らかの不具合が起きているか、あるいはパフォーマンスの低下につながるかもしれない事態が発生している状態をさしています。

広い意味でのインシデントとは、受付・記録が行われ、まだ分類が行われていない状態です。サービス要求と狭い意味でのインシデントを含んだものの集合ということができます。まだインシデント・マッチングが行われていないので、ワークアラウンド、問題、既知のエラー、解決、変更要求、サービス要求、標準変更などが特定されていない状態というわけです。広い意味で使う例はあまりないようですが、インシデント管理というプロセス名は広い意味でのインシデントになっています。また、分類が行われるまでのコールのうち、不平・不満を除いたものが広義のインシデントです。

顧客満足という観点からすれば、システムやサービスの機能や性能には影響がなくても、顧客の要求に的確に答えられ迅速に情報を提供することが重要です。インシデントの発生は必ずしもインフラストラクチャにのみ限定されるわけではありません。サービス要求はインシデントのカテゴリのひとつで、「情報の要求・助言の要求・文書に対する要求」や「パスワード忘れ」など処理方法や配布先があらかじめ設定したとおりに処理することが可能な要求です。

■「インシデント」と「問題」の違いは何ですか？

インシデントのうち根本原因が分からないものは、そのままイコール問題となります。インシデントの優先順位付けはインパクトと緊急度で行われます。問題の優先順位付けはインシデントの重要度で判断されます。したがって、インシデントがいつ問題になるかとか、どの程度のインパクトがある場合に問題として扱われるのかということに惑わされがちになりますが、これらの条件は関与しないのです。インシデント・マッチングの結果、解決策が提示されていないし、まだ問題として扱われていないインシデントは、新たに問題として扱われます。ただし、問題として検知され、問題のレコードが記録されるのは、問題として解決されることが保証された段階で作ることが推奨されています。

問題の定義は以下のように記述されています。

「問題とは、共通した兆候を示すいくつかのインシデントを受けてしばしば識別される状態である。原因は不明であるが影響は深刻である、単一のエラーの兆候がある重大なインシデントから複数の問題が識別されることもある。」（ITIL　サービスサポート　P96より抜粋）

・問題管理のプロセスは、問題コントロールとエラーコントロールのサブプロセスに分割されています

・問題ではCIが特定されますが、インシデントは必ずCIと関係するというわけではありません

・問題はインフラストラクチャに関連しています

問題という言葉がITILではこのように定義されているので、私は、「problem」以外の用語に対する訳語としては「問題」と重複しないように「課題」や「設問」という言葉を使うように気をつけています。

■「プロアクティブな問題管理」と「ハインリッヒの法則」の関連

話は変わりますが、皆さんは「ハインリッヒの法則」というのを聞いたことがあると思いますが、いかがですか。

1：29：300の法則とも呼ばれています。米国のハインリッヒ氏が労働災害の発生確率を分析した結果として導き出されました。1件の重大災害の陰には、29件の軽度の災害があります。さらにその奥には実被害はないが「ヒヤリ」「ハッと」とした経験が300件もあるそうです。

これはサービスマネジメントでも同じようなことがいえます。例えば1件の大きなトラブルの陰には29件の顧客・ユーザーからのインシデントが報告されています。そして、その奥に、300件の「まずい」｢大丈夫か｣と思ったが報告されていないとか、実害がなくて見逃されている場合があるということです。よく事例適用されているのを見るのは、「回転ドアの事故」と「列車脱線の事故」です。

ビジネスインパクトと緊急度に応じてプライオリティ付けするのがインシデント管理であり、これに準じてビジネス・ニーズを考慮して分類を行うのが問題管理です。とかく、ビジネスインパクトの大きさが支配的になりますが、その対応はその場しのぎ的で、都度対応が精一杯ということが多いようです。そこで重要視されるのが、プロアクティブな問題管理です。

予防的とか積極的な問題管理と言われますが、インシデントが発生していなくても、インフラストラクチャの構造分析やインシデントの傾向分析などから問題と既知のエラーが識別されることがあります。ついつい見逃してしまうのが、問題の解消方法が提示され、解決の状態になった問題です。類似のインシデントが多く報告される場合は、提示されたエラー以外の根本原因を含んでいることもあるのです。

インシデント、問題のレポートは設定されたKPI（重要業績評価指標）に注目するのは当然ですが、その時点におけるレポートだけでなく、経時変化が見てとれる報告も重要です。そして、それに気付くセンスを研いておくことが何よりも重要です。

・顧客はインシデントを報告してくれます

・報告されない類似のインシデントはその何倍か存在します

・インシデントはワークアラウンドでサービス復旧したままで、エラーが内在していることもあります

・問題として調査・診断が行われ、根本原因が明らかにされます

・既知のエラーに対する解決法が提示されます

・変更要求が提出されます

でもこの背後に、認識できていないエラーが存在しているのです。ある日、予想もしていなかった大事故が・・・ということのないように、プロアクティブな問題管理活動に取り組みましょう。

前田　隆

※このエントリはZDNetブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet編集部の見解・意向を示すものではありません。