問題管理（problem management）

• マネジメント系
• サービスマネジメント
• ITパスポート
• 基本情報
• 応用情報
• 重要度 ★★★★☆

下書き：本文は書き終えていますが、運営者の確認待ちのため未公開です。 検索エンジンには noindex を返しています。

もう少し詳しい説明

問題管理は、インシデントの裏にある原因を突き止め、同じことが二度と起きないようにする活動です。

インシデント管理との分担

インシデント管理は「症状」を、問題管理は「病気」を相手にしています。

同じ障害が何度も起きるとき、インシデント管理だけでは毎回同じ手当てを繰り返すことになります。それを止めるのが問題管理です。

「問題」とは何か

ITILでいう**問題（Problem）**は、1つ以上のインシデントを引き起こしている、まだ分かっていない原因を指します。日常語の「問題」より狭い意味なので、ここは意識して覚えてください。

• インシデント … 「今朝からメールが送れない」（起きた出来事）
• 問題 … 「なぜ送れなくなったのか、まだ分かっていない」（その原因）

既知のエラー

原因が突き止められると、その時点で**既知のエラー（Known Error）**として記録されます。

「原因は分かったが、まだ直っていない」という途中の状態に名前が付いているのが、この仕組みの実用的なところです。回避策とあわせて記録しておけば、次に同じインシデントが来たとき、調査をやり直さずにすぐ手当てできます。

恒久対策は、勝手には実施できない

ここは見落とされがちです。

問題管理が「この設定を変えれば直る」と突き止めても、問題管理の担当が勝手に本番環境を変えることはできません。変更には影響があり、別の障害を生むかもしれないからです。

対策案は、変更管理に回して承認を得てから実施します。 4つの管理がつながっているのは、このためです。

先回りする問題管理

インシデントが起きてから動くだけではありません。

能動的なほうが望ましいとされますが、記録が溜まっていなければできません。インシデント管理で記録を残すことが、ここで効いてきます。

覚え方：火災調査

インシデント管理を消防にたとえるなら、問題管理は火災調査です。

• 消火が終わったあとに現場へ入る
• なぜ燃えたのかを調べる
• 「この配線が原因だった」と分かれば、それが既知のエラー
• 配線を取り替える工事は、別途許可を取って行う（＝変更管理）

火を消している最中に調査はしない。 順番が決まっているのは、そのためです。

試験ではこう出る

科目A（旧・午前）のサービスマネジメント分野で出ます。多いのは、問題管理の目的を選ばせる問題と、インシデント管理との違いを問う問題です。既知のエラーの意味も問われます。応用情報では、4つの管理をつないだ流れの中でどこに位置するかを答えさせる形になります。

判断の軸は1つです。問題管理は「原因」と「再発防止」の担当。 選択肢に「早期に復旧させる」とあればインシデント管理、「実施してよいかを承認する」とあれば変更管理です。もう1つ、問題管理が自分で本番環境を変更するわけではないという点を押さえておくと、引っかけを避けられます。

関連する用語

インシデント管理

止まったサービスを早く元に戻す活動。問題管理はそのあとを引き継ぐ

変更管理

変更の影響を評価し、実施してよいかを判断する活動。恒久対策はここを通してから実施する

既知のエラー

原因は判明したが、恒久対策がまだ取られていない状態。回避策とあわせて記録しておく

ITIL

ITサービスの運用でうまくいったやり方をまとめた手引書の集まり

SLA

サービスの品質水準を数値で取り決めた合意。再発が続けば、この水準を守れなくなる

ミニクイズ

最終更新：2026-09-25