解説
問題管理は、ITサービスマネジメントで使われる管理手法の一つで、ITIL 4ではプラクティスの一つに位置づけられています。ITIL 4では、問題を「1つ以上のインシデントの原因、または潜在的な原因」と定義しています。そのうえで、問題管理の目的を、インシデントの実際の原因と潜在的な原因を特定し、回避策と既知のエラーを管理することで、インシデントの発生可能性と影響を減らすこととしています。一方で、インシデント管理の目的は、通常のサービス運用をできるだけ早く回復させることにあります。したがって、問題管理とインシデント管理は、担当も時間軸も分けて考えます。なお、ITIL 4ではプロセスではなくプラクティスという語が使われ、2026年に発表されたITIL(Version 5)でもプラクティスの名称は変わらないと紹介されています。
仕組み
ITIL 4では、問題管理を次の3つの段階で説明しています。
- 問題の特定:インシデントの傾向を分析するなどして、繰り返し起きている問題や潜在的な問題を見つけます。
- 問題のコントロール:問題を分析し、原因を特定または推定するとともに、回避策を用意します。
- エラーのコントロール:原因は分かっているものの解決していない問題を既知のエラーとして管理し、恒久的な解決策を、必要に応じて変更の依頼として提案します。
実務での使われ方
カスタマーサポートでは、問い合わせの件数が、問題の修正の優先度を決める材料になります。同じ用件の問い合わせが繰り返し入っている場合、原因が解消されていない可能性が高いためです。たとえば、タグ付けした応対履歴を集計すれば、どの問題が最も多くの問い合わせを生んでいるかを数値で示せます。「改善してほしい」と伝えるだけでは開発部門が動かない場面でも、月あたりの問い合わせ件数と対応工数を示せば、修正の優先度を上げやすくなります。また、インシデント管理で応急処置として使った回避策は、問題管理の記録に残しておきます。
注意点
サポート部門の役割は、問題管理へ情報を渡すところで終わりません。インシデントが回復した時点で対応を終えると、同じ原因による問い合わせが繰り返し発生するためです。そのため、原因の追跡を誰が引き継ぐかを決め、原因を取り除いて問い合わせそのものを減らすところまでを業務の範囲に含めます。その結果、呼量の削減にもつながります。
該当する用語がありません