Aインシデント管理
サービスの中断や品質低下を最小限に抑え、迅速にサービスを通常状態へ復旧させることを目的とするプロセス。原因究明より復旧優先で、暫定的な回避策（ワークアラウンド）でも受け入れます。サービスデスクが一次窓口となり、優先度に応じてエスカレーションする運用フローが典型的です。
迅速な復旧が最優先
回避策（ワークアラウンド）も受け入れる
サービスデスクが起点
KPIは平均復旧時間（MTTR）など
違いシリーズ一覧に戻る
マネジメント系
インシデント管理と問題管理の違い
ITILで定義されるITサービスマネジメントの2大プロセス。インシデント管理はサービス停止・劣化を「迅速に復旧」させること、問題管理は「根本原因を究明し再発防止」することが目的です。両者は連携しながら役割を分担します。応用情報試験で頻出の論点です。
比較表で見る違い
| 観点 | インシデント管理 | 問題管理 |
|---|---|---|
| 目的 | サービスの早期復旧 | 根本原因の究明と再発防止 |
| 対応の優先度 | 緊急対応・回避策が優先 | 時間をかけて恒久対策を立案 |
| 対応期間 | 短期（数分〜数時間） | 中長期（数日〜数週間） |
| 対応の終了 | サービス復旧 | 恒久対策の実施 |
| 記録対象 | インシデントレコード | 問題レコード・既知のエラー |
| 担当者 | サービスデスク・運用担当 | 問題管理担当・専門技術者 |
| KPI例 | 平均復旧時間（MTTR）、解決率 | 再発率、既知エラー登録数 |
それぞれの詳しい解説
B問題管理
インシデントの根本原因を究明し、再発防止のための恒久的対策を講じるプロセス。時間をかけて分析し、対策が確立したものは「既知のエラー」として登録し再発時の対応を効率化します。インシデント管理と密に連携し、繰り返し発生するインシデントを問題として切り出すのが典型的な流れです。
根本原因究明と再発防止が目的
既知のエラーDBに登録
中長期の取り組み
KPIは再発率・既知エラー登録数など
試験対策のポイント
「インシデント=早期復旧・回避策OK、問題=根本原因・恒久対策」で整理。両者は連携する別プロセス。
理解度チェック（2問）
Q1. インシデント管理の目的として、適切なものはどれか。
- 1インシデントの根本原因を究明し、再発防止策を講じる
- 2中断したサービスを可能な限り迅速に復旧する
- 3将来発生しうる障害を予測し予防する
- 4システムの変更を安全に展開する
解答・解説を見る
正解：2. 中断したサービスを可能な限り迅速に復旧する
インシデント管理の目的はサービスの早期復旧。根本原因究明は問題管理、変更展開は変更管理、予防活動は問題管理に含まれる予防的問題管理の役割。
Q2. 問題管理に関する記述として、適切なものはどれか。
- 1サービスデスクが一次窓口として対応する
- 2回避策で復旧したら対応終了とする
- 3根本原因を究明し、既知のエラーとして登録する
- 4主なKPIは平均復旧時間（MTTR）である
解答・解説を見る
正解：3. 根本原因を究明し、既知のエラーとして登録する
問題管理は根本原因を究明し既知のエラーとして登録するプロセス。サービスデスク起点・回避策・MTTRはいずれもインシデント管理に関する記述。