インシデント管理のライフサイクルとKPI：初心者歓迎！ ITIL連載講座（1/3 ページ）

今回は「インシデント管理」を扱う。簡単に言えば社内のトラブル対応をまとめたものなのだが、ここにもITILならではの考え方がある。

[谷誠之，ITmedia]

このコンテンツは、オンライン・ムック「運用管理の過去・現在・未来」のコンテンツです。関連する記事はこちらでご覧になれます。

「インシデント／問題／既知のエラー」を理解する

　この3つの用語と考え方を理解することが、ITILのインシデント管理を理解する上での基本となる。筆者は、ITIL最大の発明とも言われている「インシデント」という概念だけは、ITILを導入する予定のない企業でも、ぜひ導入してほしいと考えている。

　筆者は今まで、あえて「トラブル」という言葉を使ってきた。しかしITILにおいては「サービスの標準の運用に属さないイベントであり、サービス品質を阻害、あるいは低下させる、もしくはさせるかもしれないイベント」のことを「インシデント」という。インシデントという言葉そのものは珍しい用語ではない。もともとは「出来事、事件」といった意味の英単語だし、ITの世界でも（ITILでなくても）使用上、あるいは運用上の困った出来事を、インシデントと呼ぶことが多い。

　しかしここで注意したいのは、ITILではインシデントのことを「標準の運用に属さないイベント」であると定義していることである。ここには、通常の業務を遂行できない何らかの状態すべてが含まれる。ネットワークがつながらない、アプリケーションが起動しない、プリンタが動作しない、ウイルスに感染した、といった「障害」と、パスワードを忘れた、アプリケーションの操作方法が分からない、ウイルス対策ソフトのパターンファイルが正しく更新されているかどうか知りたい、といった「サービス要求」が含まれる。

　インシデントはあくまでもイベント（状態）であり、そのインシデントを引き起こす結果となった根本原因を含まない。IITLでは、インシデントを引き起こした原因のことを「問題」と呼んで、インシデントと区別している。さらに「インシデントを発生させる可能性のある未知の原因」のことを「問題」と呼び、原因が特定されたものを「既知のエラー」と呼んで区別している。

　たとえ話で説明しよう。筆者は旅行に出かけるときも、デジカメではなく、ひと昔前の銀塩カメラを持ち歩いている（写真1）。筆者が持っているようなカメラではあり得ないことだが、コンパクトカメラであれば、レンズキャップをしたままカメラのシャッターを押してしまって、現像してみたら写真が真っ黒、ということがよくあった。

写真1：筆者の愛機。レンズキャップつき。なかなかの年代ものだ

　この場合「写真が写っていなかった」というイベント（状態）が「インシデント」である。そしてその原因は「レンズキャップをしたままシャッターを押してしまった」ということにある。しかし写真を撮る時にレンズキャップをはめたままシャッターを押したということには気付いていないため「なぜ、写真が真っ黒なんだろう？」と悩んでいるうちは、その根本原因は未知であり「問題」であるといえる。ある日「なぁんだ、レンズキャップをはめたままだったんだ」と気付けば、その原因は「既知のエラー」と呼ばれることになる。

　ITIL最大の発明とは、この「インシデント」と「問題」を完全に分離したことにある。詳細は後で述べるが、インシデント管理では、そのインシデントが発生した原因を追究しない、ということに大きな特徴があるのだ。