ITILの中には「問題管理」という言葉がよく出てきます。日本語であるためなんとなく意味を理解できる人も多いかもしれませんが、そのプロセスなどまで理解しているでしょうか。

今回は問題管理の重要性やそのプロセスなどをご紹介します。問題管理は専用ツールを使うことで効率的かつ効果的に行えるので、問題管理に興味のある方はツールの導入も検討してみましょう。問題管理と混同されがちな「インシデント管理」との違いもご紹介しますので、参考にしてみてください。

ITサービス管理やITILについてより詳しく知りたい方はこちらの関連記事もご覧ください。

問題管理とは

ITILでは「問題」は「インシデントを引き起こす可能性のある未知の根本原因」と定義しています。

例えば営業部から「プリンターが故障して、資料を印刷できない」という問い合わせがあったとします。この場合「資料を印刷できない」という事象がインシデントで、「プリンターが故障している」という未知の根本原因が問題となります。

問題管理とは、インシデントの根本原因を特定して解決策を策定するプロセスをいいます。

例えば上記の例の場合、「別のプリンターで印刷する」という解決策は、インシデントを解決していますが「問題」は解決していないため「インシデント管理」に当たります。問題管理とは二度と同じ問題が起きないように根本原因を究明することなので、プリンターの故障の原因を解明し再発防止策を実施しなければなりません。

インシデント管理も問題管理も重要ですが、緊急性が高くなりがちなインシデント管理は行われても、問題管理は後回しにされることも多いです。しかし、問題管理を行わなければ何度も同じインシデントが発生し、インシデント管理に忙殺されることになります。インシデント管理の業務を減らすためにも問題管理が重要なのです。

問題管理のプロセス

ITILでは、問題管理をどのように行うのかも定められています。

問題管理のプロセスは大きく「問題コントロール」と「エラーコントロール」に分けられます。問題コントロールは主に問題の識別と根本原因の識別を目的としており、「問題の識別と記録」「分類」「調査と診断」の手順で構成されています。

問題の識別と記録

インシデントが明らかに再発する可能性が高い場合や、重大なインシデントが発生した際にはその問題を識別して記録しておきます。できれば、一元的に確認するためにも専用ツールを用いて記録することが望ましいです。

分類

記録された問題を、ビジネスへのインパクトの大きさや緊急度で分類して、着手すべき優先順位を決定します。ビジネスへのインパクトという観点から分類することが重要で、「システムが古い」「時代遅れ」などという観点で分類してはいけません。

調査と診断

優先順位に沿って、分類された問題の根本原因を調査します。必要な場合は専門家チームを結成するといいでしょう。根本原因が判明した問題は既知のエラーと診断されて、エラーコントロールに引き継がれます。

エラーコントロールは既知のエラーに対する根本的な解決策を提供することを目的としており、「エラーの識別と管理」「エラー評価」「エラー解決の記録」のプロセスがあります。

エラーの識別と管理

問題の識別と記録と同じように、エラーと識別されたものを管理・記録していきます。この際も、人的ミスなどを防ぐために専用ツールを使って記録するのがおすすめです。

エラー評価

エラーに対する恒久的な解決策を調査し、必要に応じて専門家チームを結成します。根本的な解決をするのに、IT構成になんらかの変更が必要な場合には、RFC（Request for Comments）を作成するとよいでしょう。RFCとは、なんらかの変更を行う際の要求文書のことを指します。

エラー解決の記録

解決されたエラーは、その詳細を問題レコードとして記録しておきましょう。この情報があれば、将来のインシデントに対して対策できますし、インシデントを回避するための情報として有意義なものになります。RFCが作成されている場合は、このRFCを次のステップである「変更管理」プロセスに渡します。

問題管理が重要になるシーン

ITシステムを運用していく上でインシデントを絶対に起こさないように使い続けるのは困難です。しかし、適切に問題管理をすることで、インシデントが再発する可能性を限りなくゼロに近づけることは可能です。自動化できるシステムを使用し徹底的に効率化させ、ビジネスへの悪影響を最小化させることが可能なのです。ここでは、そのような問題管理が特に重要となるシーン・タイミングをご紹介します。

過去に起きていないインシデントが発生した時

未知のインシデントが起きた時は問題管理の対象となります。問題管理が必要となる、最もよくあるパターンです。同じようなインシデントが2度と発生しないように、根本的な原因究明を行いましょう。

解決済みのはずのインシデントが再発した時

解決済みにしたインシデントが再発することの原因には、2つの可能性が考えられます。

ひとつは残念ながら過去の問題管理の対策が不十分・不適切だったことです。この場合には問題管理のプロセスを見直す必要もあるかもしれません。

もうひとつは過去の時点では有効だった対策が仕様や設定、技術などの変更・更新で無効、または不十分になり、似たようなインシデントが発生した場合です。この場合はインシデントは同じでも、必要な解決策は異なるケースがあります。

過去のインシデント分析から問題の傾向が推測できる場合

上記2つのケースはインシデントが起きてから対処する「リアクティブ（受動的）」なアクションといえます。しかし、インシデントが起きる前に未然に防ぐ「プロアクティブ（能動的）」な分析や対応も必要です。集積されているインシデントの記録から、問題管理のきっかけやヒントになる点を細かく分析して予防に活かしましょう。

Ivanti Software株式会社の問題管理ツール

問題管理においては、問題を記録し問題の傾向から未来のインシデントの傾向を分析するためにも、ツールの活用がおすすめです。問題管理の中でもぜひ検討して頂きたいのがIvanti Software株式会社のITIL管理ソリューションです。ITサービスの管理を最適化するためのツールで、全てクラウドで提供するため、IT部門とユーザーが場所を問わず自動化と効率化のメリットを得られます。

問題管理においては、ツールを使うことで問題が業務にもたらす影響を主体的に修正し、最小限に抑えることが可能です。インシデントの傾向を特定するために既知の問題に目を向け、インシデントや他のデータを分析することで根本的な問題解決に役立たせることができます。サービスデスクが速やかに問題を修正できるように、問題の原因や解決までのプロセスを可視化します。

Ivanti Software株式会社の問題管理についてさらに詳しく知りたい方はこちらをご覧ください。

まとめ

問題管理は業務を効率化するためにも重要なプロセスとなります。一度起きたインシデントを再発させないことは、業務を何倍も効率化させることになるのです。多少のコストをかけても十分な投資になるため、問題管理ツールの導入を検討してみてはいかがでしょうか。