「障害の復旧」と「問題解決」を勘違いする人たち：失敗しない「外資系」パッケージソフトとの付き合い方（2/3 ページ）

[吉丸新一郎（日本ヒューレット・パッカード），ITmedia]

あなたはちゃんと「ITIL」を理解していますか？

　2人の会話の内容を見ると、運用担当者は障害の「原因」を追究する方向に向かっているのに対し、サポート担当者は障害の「復旧」を念頭に置いて、その方法を案内しています。どちらが正しい考え方なのでしょうか。

　ここで少し、運用管理の原則についてお話ししたいと思います。IT運用管理の業界標準、またはベストプラクティスと言うと、多くの方がITIL（Information Technology Infrastructure Library）を思い付くのではないかと思います。

　IT運用管理はITILで扱う領域の一部ですが、ITILを参考にして社内の運用管理プロセスや機能、役割を整理している会社も多く、運用管理の話をするときの共通の土台となっている場合も多いでしょう。ITILが公表されたのは1980年代ですから、ブラッシュアップされているとはいえ、今の時代に合わせにくい部分もあるかとは思います。しかし、他の管理手法と比較しても、その歴史の長さと普及度合いから、ITILは今でもIT運用管理の“お手本”と言えます。

ITIL v3の概要図

　今回のケースにおける、障害対応の管理プロセスは、ITILでは「インシデント管理」プロセスとして扱われます。ある事象が障害として認識されると、それはインシデントの単位で管理システムに登録され、その障害（＝インシデント）がクローズされるまで管理されます。障害がクローズするのは、その障害が沈静化する、または何らかの代替案（ワークアラウンド）で回避できる場合です。

　先ほどの会話例では、ソフトウェアが「動作が不安定で、応答がない状態」「業務に一部影響が出ている」ことが解決すべき事象で、「動作が安定する」「業務影響がない」、もしくはそれに代わる代替案が提示された状態でクローズできることになります。

　もちろん、国内の企業でも、このようなプロセスでIT運用にまつわるインシデントを管理しているところは多いと思いますが、そこそこの規模以上の外資系IT企業では、まず間違いなく、このプロセスをインシデント管理に採用していると言っていいでしょう。