「問題管理」でITサービスの貢献度を向上させる：初心者歓迎！ ITIL連載講座（3/4 ページ）

[谷誠之，ITmedia]

問題管理の活動

　問題管理の活動は「問題コントロール」と「エラーコントロール」に分けられる。

　問題コントロールは問題の識別と根本原因の調査を目的としている。問題コントロールの具体的な活動は、図2の通りである。

図2：問題管理の活動（問題コントロール）

1．問題の識別と記録

　頻繁に発生し、再発が明らかでビジネスに悪影響を与えるインシデントがあったり、体系的な問題解決が必要な重大なインシデントが発生したり、なんらかの活動の中で将来明らかに重大なインシデントに発展する恐れのある問題が見つかったりした場合は、その問題を識別し、問題レコードとして記録する。問題管理に関しても、できれば専用のツールを用いて管理することが望ましい。

2．分類

　記録された問題を、ビジネスへのインパクトや緊急度などを要素として分類し、優先度を決定する。インシデント管理同様、この分類のためには、CMDB上のCI情報を参照する必要がある。分類はあくまでも「ビジネスに対するインパクトと緊急度」という観点から行うこと。単純に時代遅れだからとか、バージョンが古いから、といったIT寄りの考え方で分類してはいけない。

3．調査と診断

　必要に応じて専門家チームを結成し、問題の根本原因を調査する。根本原因が判明した問題は既知のエラーとして識別され、エラーコントロールに引き継がれる。エラーコントロールは、既知のエラーに対する根本的な解決策を提供することを目的とする。エラーコントロールの具体的な活動は、図3の通りである。

図3：問題管理の活動（エラーコントロール）

4．エラーの識別と記録

　既知のエラーと識別されたものを記録する。

5．エラー評価

　必要に応じて専門家チームを結成し、エラーに対する恒久的な解決策を調査する。根本的な解決に対して、IT構成に何らかの変更が必要だと判断された場合はRFCを作成する。

　ユーザがアプリケーションの使い方をよく知らない、ということが根本原因だというような場合もある。そのような場合の恒久的な解決策は「ユーザ教育を行う」ということである。従って、恒久的な解決策が必ずしも変更を伴うとは限らない。

6．エラー解決の記録

　恒久的な解決策は、問題レコードに詳細に記録されるべきである。この情報は、将来のインシデントに対するワークアラウンドや、インシデントを回避するための情報として有意義なものになるかもしれない。RFCが作成されている場合、このRFCを次のステップである「変更管理」プロセスに渡す。

7．クローズ

　変更の実装が成功したり、先のユーザ教育などの解決策が功を奏したりして、既知のエラーが完全に取り除かれたことを確認したら、問題レコードをクローズする（この時点で問題はすでに既知のエラーになっているため、エラーレコードという場合もある）。

　なお、IT構成への変更が必ずしも適用されるとは限らない。変更に多大な費用がかかったり、ITサービスを停止させる時間が長すぎると判断されたり、ワークアラウンドの実施で十分だと判断されたりした場合は、解決策を実施しないでクローズする場合もある。