問題管理プロセスと原因分析
問題管理は、インシデントの根本原因を調査して特定し、インシデントの発生や再発を防ぐことを目的とするサービスマネジメントのプロセスである。 インシデント管理がサービスを早く通常の状態へ戻すことを主眼とするのに対し、問題管理は「なぜ起きたのか」を突き止めて恒久的な対策につなげる点に特徴がある。
問題管理の基本的な仕組み
問題管理の出発点は、個々のインシデントを処理するだけでなく、インシデントの記録や発生傾向を分析して、複数の事象に共通する原因を見つけることにある。インシデントの傾向を分析すると、まだ認識されていない問題の手掛かりが得られる。 問題管理の中心は根本原因の調査と特定であり、そこから再発防止や影響の軽減へとつなげる。 未知の根本原因を特定できたら、その原因に対する恒久的な解決策を策定することが問題管理の役割になる。
原因を取り除くまでに時間がかかる場合は、判明している原因と回避策を既知の誤りとして記録しておく。こうした記録があれば、同じ事象が発生したときに利用者へ回避策を案内し、復旧を早めることができる。
他のプロセスとの区別
問題管理の活動は、変更管理、サービス要求管理、リリース管理などと混同されやすい。次の表で、それぞれの中心となる役割を整理しておく。
| 管理プロセス | 中心となる役割 |
|---|---|
| インシデント管理 | 影響を受けたサービスをできるだけ早く通常の状態に戻す |
| 問題管理 | 根本原因を特定し、インシデントの発生や再発を防ぐ |
| 変更管理 | 変更の要求を記録し、影響とリスクを評価して管理された手順で実施する |
| サービス要求管理 | 利用者からのサービス要求を受け付け、優先度を付けて処理する |
| リリース管理 | リリースの試験や検証を行い、展開を管理する |
| サービス継続性管理 | 重大な中断に備え、合意した目標を満たせるよう準備する |
変更要求の記録は変更管理の活動であり、問題管理の活動とは区別して理解する必要がある。 同様に、サービス要求の優先度付けはサービス要求管理に、リリースの検証はリリース管理に属する。 利用者からの障害報告を受けて既知の誤りに該当するかを照合する作業は、インシデント管理の初期対応として行われるものであり、問題管理そのものではない。
原因分析の図法と使い分け
原因分析では、目的に応じて図法を使い分ける。次の表は、主な図法と用途の対応を示している。
この節の続き
- 実務での適用
- 試験で問われやすい区別
ここまでが冒頭部分です。ログインすると、無料でも1日2節まで全文をお読みいただけます。
アプリでこの節を読む