HP OpenView News 【42-02】
続・アポロ13とITIL -5-

問題管理のプロセスには2つの基本的なサブプロセスがあります。「問題コントロール」と「エラーコントロール」です。

前述した3人の飛行士が亡くなった「アポロ1」の事故を例にしてみましょう。この事故のインシデントを仮に「火災の発生」と言うことに絞るとすると、ここで、何故火災が発生したかを調べるプロセスが「問題コントロール」のプロセスになります。この時、問題の識別と記録、問題の分類（ハードウエア、ソフトウエア、手順や、ビジネスに与えるインパクトの大きさ等）、調査と診断（問題の根本原因は何か）などの活動が行われます。アポロ1号の事故では指令船内の気体が酸素のみであったこと（小さな火花が電極から発生したのも原因かもしれませんが）が根本原因として解明され、この問題は既知のエラーとして登録され、「エラーコントロール」に送られます。「エラーコントロール」では、エラーの識別登録、エラーの評価（解決方法の作成、RFCの作成など）、エラーの解決策の記録、エラーのクローズ（火災に対する問題管理活動の終了）などの活動が行われます。最終的に解決方法が変更を伴うものであれば、変更管理プロセスにのっとって解決策が実装された後、変更後の正常動作確認が出来たところでエラーのクローズとなるわけです。

ただ、ITサービス運用の世界で考えてみると、問題または既知のエラーが存在するからといって、ワークアラウンドが適用されているのにも関わらず、それらが全て解決されるまでITサービスを停止することは現実的には出来ません。「問題コントロール」、「エラーコントロール」と言うサブプロセス活動が行われている間、人命に関わるロケットの発射を全て停止して問題管理プロセスを実行するアポロ計画とは事情が違うことは理解しておく必要があると思います。

また、ここで改めてインシデント管理との違いを確認しておきたいと思います。
アポロ13では酸素タンクが爆発した根本原因を突き止めるアクションを、アポロ13が地球に帰還した後に行っています。根本原因は酸素タンクに使われたコイルの不良だったようです。従って、次々と発生するインシデントに対応して3人の飛行士の安全を確保し、何とか地上に戻す為の一刻を争う対応をインシデント管理が行い、根本原因を突き止める、部品の設計や変更を行うなどの、いわゆる時間のかかる対応は、問題管理と位置付けて実施したと理解できます。インシデント管理と問題管理の最も違う点です。