ITILの問題管理（Problem Management）は、インシデントを「直して終わり」にせず、根本原因を特定して恒久対策につなげることで、再発を防ぐための重要なプラクティスです。
現場では復旧を急ぐあまり暫定対応が積み重なり、同じ障害が繰り返されがちです。問題管理は、その繰り返しを構造的に断ち切る仕組みです。
本記事では「問題」の定義、インシデント管理との違い、導入メリット、プロセス全体像と6ステップ、運用定着のポイントを整理します。

結論（要点）

ITILにおける「問題」と問題管理の定義

問題管理を正しく運用するには、まずITIL/ITSMにおける「問題（Problem）」が何を指し、問題管理が何を達成する活動なのかを共通認識として揃えることが出発点になります。

問題管理は障害対応の単なる「後工程」ではなく、再発防止を実現するための継続的な業務です。定義が曖昧だと、インシデントの延長として扱われて分析が浅くなったり、逆に何でも問題化してバックログが崩壊したりします。

• インシデント：利用者が感じる症状やサービス影響
• 問題：それを起こす原因や潜在原因

この区別ができると、復旧スピードを落とさずに原因除去へ投資する判断がしやすくなります。問題管理はリアクティブ（起きたインシデントを受けて分析）だけでなく、プロアクティブ（傾向や弱点を見つけて未然防止）も含み、成熟するほど後者の比率が高まります。

ITSM（ITサービスマネジメント）における「問題」の定義

ITILでは「問題」を「1つ以上のインシデントの原因、または潜在的な原因」と定義します。すでに起きた障害の背後にある原因だけでなく、まだ顕在化していない原因候補も含みます。
例えば「プリンターが印刷できない」はインシデントですが、調査で判明した「メインボード破損」は問題に該当します。
問題は複数インシデントの背後にあることが多いですが、単発でも重大影響なら問題化します。再発時の損失が大きいものは原因除去まで追う価値があります。

• 基幹決済が停止した
• 情報漏えいにつながる恐れがある
• 復旧にロールバックを要した

プロアクティブの例として、次のような兆候からインシデント前に問題を起票し対策することもあります。

• 監視でエラー率がじわじわ上がる
• ログに同一警告が増えている
• 特定CI（構成品目）の障害が季節性で増える

問題管理の目的と期待される成果物

問題管理の目的は、根本原因を特定して再発を防ぎ、発生時の影響も最小化することです。恒久対策の完了に時間がかかる場合も、分析と並行して回避策を整備すれば、次のインシデントの被害をすぐに減らせます。
代表的な成果物は問題レコードです。関連インシデント、症状、影響範囲、暫定対応、仮説、担当、期限、意思決定の履歴を一元化し、組織の記録として残します。
根本原因分析（RCA）の結果はRCA報告としてまとめ、再発防止策の根拠にします。同時に、暫定的に有効な回避策はワークアラウンドとして整理し、現場がすぐ使える形にします。
原因が特定され回避策が確立した段階で、既知エラー（Known Error）として登録し、既知エラーデータベース（KEDB：Known Error Database）やナレッジベースに蓄積します。恒久対策が必要な場合は改善アクションとしてタスク化し、変更要求（RFC）として変更管理につなげます。

インシデント管理と問題管理の違い

インシデント管理は迅速復旧、問題管理は原因除去と再発防止が主眼です。両者の違いをKPIや成果物レベルまで落として理解すると、現場連携がスムーズになります。

インシデント管理は利用者影響を最短で取り除くことがゴールで、「いま直るか」に判断軸が寄ります。問題管理は背後にある原因を潰すことがゴールで、後回しにすると同じ障害が繰り返され復旧対応の総工数が膨らみます。
両者は対立ではなく役割分担です。インシデントの現場情報が問題分析の材料になり、問題管理で作られた既知エラーやワークアラウンドが次回のインシデント対応を高速化します。

目的・成果物・KPIの違い

目的・成果物・代表的なKPIは下表のとおり明確に異なります。インシデント管理はサービスの迅速復旧と影響最小化が目的で、問題管理は根本原因の排除と再発防止、将来影響の予防が目的です。KPIを分けて設計しないと、誤った最適化を招きます。

実務での連携とエスカレーション

インシデントから問題へ移行する条件を決めておくと、現場の迷いが減ります。典型例は次のとおりです。

• 同種インシデントの頻発
• 重大影響
• 原因不明で切り分けが進まない
• 暫定対応の限界が見えている
• セキュリティ上の懸念がある

連携の起点はサービスデスクになりやすく、関連インシデントを問題レコードにリンクし発生条件・時系列・対応履歴を揃えることで、調査チームが再現と検証を行いやすくなります。エスカレーション先はProblem Manager（問題管理責任者）や担当技術チームで、「調査する人」と「進行管理する人」を分けることが重要です。恒久対策の実装は変更管理・リリース管理と連携し、リスク評価や承認を経て実施することで、新たなインシデントを生まないよう統制します。

問題管理を導入するメリット

問題管理は“その場しのぎ”を減らし、障害対応の生産性とサービス品質を継続的に引き上げます。導入効果を、現場が実感しやすい観点で分解します。

再発防止の仕組みがない組織では、同じ種類の障害に何度も時間を吸い取られ、改善の時間が確保できません。分析だけで終わらせず、回避策の整備と恒久対策まで一連で回すことで、短期的な復旧効率と中長期的な品質向上の両方を実現できます。
「再発件数の減少」「深夜休日対応の減少」「一次対応の標準化」など、現場の痛みに直結する指標で効果を示すと社内合意を取りやすく、継続しやすくなります。

ダウンタイム短縮と復旧速度の改善

問題管理が進むと既知エラーとワークアラウンドが蓄積され、類似インシデントの初動が速くなります。原因が未解明でも過去の知見から暫定復旧の型が使え、切り分け時間を短縮できます。
結果として業務停止時間が短くなり、顧客影響や売上影響を抑えられます。24時間稼働のサービスでは、恒久対策完了までの間にワークアラウンドの整備が実務上の価値になります。

再発防止によるITコスト削減

同じインシデントを繰り返し対応するコストは、見えにくいですが確実に積み上がります。一次対応、エスカレーション、状況共有、復旧確認など、1回の障害でも関係者の時間が広く消費されます。

ナレッジ資産化と属人化防止

障害対応が属人化すると、担当者が不在のときに復旧が遅れ、判断の再現性も失われます。問題管理は、RCA結果や回避策だけでなく、調査過程で得た判断基準もナレッジとして残す点に価値があります。

• 症状
• 原因候補
• 確認手順
• 回避策
• 恒久対策状況

これらをKEDBやナレッジベースに揃えて登録すると、サービスデスクや一次対応者でも同品質の初動が取れ、一次解決率の向上につながります。ナレッジが溜まるほど新人教育や引き継ぎも短縮されます。

ITILの問題管理プロセス全体像

問題管理は単発の分析ではなく、継続的改善として回し続けるプロセスです。全体像を押さえることで、各ステップの意味とつながりが理解できます。

起票して分析して終わりでは成果が出ません。リアクティブに起票される問題と、傾向分析で見つかるプロアクティブな問題を同じ枠組みで管理し、バックログとして見える化する必要があります。変更管理・ナレッジ管理・構成管理とつながって初めて効果が最大化します。

PDCAサイクルで捉える問題管理

問題管理はPDCAで整理すると理解しやすくなります。下表のように、各フェーズで何をすべきかを押さえておくと、調査が断片的になったり結論が出ないまま停滞したりすることを防げます。

役割と責任（Problem Managerなど）

役割分担が曖昧だと停滞します。下表のとおり、Problem Managerは解決まで運ぶ責任者、調査担当は技術チーム、サービスデスクは検知・記録の要、変更管理は恒久対策の実装統制を担います。

問題管理の6ステップ

ここでは実務で使いやすい形で、問題管理を6つのステップに分解します。各ステップで“何を入力し、何を出力するか”を意識すると運用が安定します。

形骸化する典型パターンは、調査が個人作業になり記録が薄く、クローズ基準が曖昧なまま終わることです。すべての問題で完璧なRCAを目指さず、影響と再発確率に応じて深さを変えるのが現実的です。インシデントとのリンクと意思決定の記録が、一貫して大事なポイントです。

1. 問題の特定と記録

問題化のトリガーを決めます。代表例は次のとおりで、トリガーがないと起票が人の感覚に依存し、重要な問題が漏れたり増えすぎたりします。

• 同種インシデントの繰り返し
• 重大なサービス影響
• 原因不明で復旧が不安定
• 監視や傾向分析で兆候を検知した

問題レコードには関連インシデント番号、症状、発生条件、影響範囲、担当、期限、次アクションを記録します。原因の断定ではなく調査可能な状態にすることがポイントで、入力の最低要件をテンプレート化すると運用が安定します。

2. 分類と優先順位付け

アプリ、インフラ、ネットワーク、認証、バッチ、外部サービスなど、運用実態に合ったカテゴリ体系を用意し、選択式で揺れを減らします。優先順位は影響度×緊急度を基本に、サービス重要度や再発頻度、セキュリティ観点を加味してルール化します。
バックログは溜まりやすいため、週次や隔週のレビューで優先度の見直しや担当の再調整を行い、停滞を見える化します。優先度は技術的な難しさではなく、ビジネスの損失期待値で決めることが本質です。

3. 調査と根本原因分析（RCA）

RCAは手法よりも進め方が重要です。次のような手法を使い分け、事実に基づいて仮説を検証します。

• 5Why
• 特性要因図
• イベント相関
• ログやメトリクス分析
• 再現試験

重要なのはブレームレスで進めることです。個人のミスに帰着させると報告が萎縮し、根本原因の特定に必要な情報が集まらなくなります。原因は複合になり得るため、単一原因に絞るより再発防止に効く要因を優先して潰すほうが実務的です。分析のアウトプットは、原因の記述だけでなく再発条件と検知条件まで落とすことが重要です。

4. 回避策と恒久対策の特定

回避策（ワークアラウンド）は原因を除去しなくても影響を抑える暫定手段です。恒久対策は根本原因を取り除く施策で、次のようなものが該当します。

• 設計変更
• 設定修正
• コード修正
• 運用手順の改定
• 監視追加

原因候補が絞れ、有効な回避策がある段階で既知エラーとして登録すると、次回インシデント時にサービスデスクが即座に回避策を提示できます。対策案は効果だけでなくリスク・コスト・実装容易性で比較し、恒久対策の実装は変更管理（RFC）へつなげ、承認や検証を経ずに本番投入しないよう統制します。

5. 解決策の実施とクローズ

解決策の実施は変更またはリリースとして計画し、影響範囲の確認、実施手順、ロールバック、検証観点、監視強化をセットで用意します。実施後は症状が消えたかだけでなく、再発条件が取り除けたか、監視で検知できるようになったかを確認します。
クローズ判定の基準は次のとおりです。

• 再発が一定期間ない
• 影響が解消した
• 関連ドキュメントとナレッジが更新された
• 関係者が合意した
• 未完タスクの扱いが決まった

クローズ後の振り返りで、分析の不足やプロセス上の改善点が見つかることもあります。

6. ナレッジ共有と継続的改善

KEDBやナレッジベースに、症状から回避策にたどり着ける導線で情報を整理し、サービスデスクが検索しやすい形に整えます。再発監視は待つだけでなく、アラート条件を見直し兆候を早期に検知できる状態を作ることが大切です。
定例の問題レビューでバックログを見直し、傾向分析からプロアクティブな問題提起につなげます。KPIをモニタリングし改善アクションに落として回すことで、問題管理が継続的サービス改善（CSI）として定着します。

問題管理を成功させるポイントとツール選び

問題管理は“プロセスを作る”だけでは成果が出ません。評価ルール、データの一元化、継続的改善を回す仕組みまで含めて設計することが成功の鍵です。

現場が迷わず判断できる基準と、負担を増やさずに記録と連携が回る仕掛けが必要です。複数チームにまたがるため調整コストが成果を食いがちで、ルールを明文化しツールで関連付けと可視化を自動化すると、人が議論すべき論点が減ります。

評価基準・優先ルールの明確化

問題化基準を明文化します。次の項目で起票の入口を揃えるとブレが減ります。

• 頻発回数
• 影響の大きさ
• 原因不明の期間
• 暫定対応の限界
• セキュリティ懸念

優先度算定とエスカレーション条件も定義し、例外や期限延長の扱いを決めます。重大インシデント後のポストモーテムを問題管理と接続し、再発防止策のオーナーと期限を必ず設定し、完了まで追跡することが再発防止の要になります。

ツールでの一元管理とCMDB連携

インシデント・問題・変更が分断されると、原因究明と対策実装が途切れます。ツール上で相互に関連付けできることは必須要件で、ワークフロー・通知・承認・ダッシュボードが整っているとProblem Managerが停滞を早期に発見できます。
構成管理データベース（CMDB）と連携すると、影響範囲（どのCIがどのサービスに効いているか）を可視化でき、優先度判断や恒久対策のリスク評価の精度が増します。

継続的改善を運用に定着させる

定例のProblem Reviewを運用のリズムとして固定し、トップ優先問題の進捗や既知エラーの解消計画などに議題を絞ります。KPIは現場が行動に変えられるものを選びます。

• 再発件数
• 滞留期間
• 既知エラーの参照数
• 恒久対策完了率

教育とテンプレ整備で記録の品質を平準化し、傾向分析や監視データのレビューを定例に組み込むと、問題管理が「起きた後の後始末」から「起きる前の予防」へ移行していきます。

まとめ：ITILの問題管理で再発防止を仕組み化する

問題管理は、インシデント対応を“復旧で終わらせない”ための仕組みです。定義の統一、プロセス設計、役割分担、ツール活用を揃えることで、再発防止とサービス品質向上を継続的に実現できます。

ITILの問題管理は「問題＝原因（または潜在原因）」として捉え、インシデントの背後にある根本原因を継続的に取り除くための実践です。インシデント管理とは補完関係にあり、既知エラーやワークアラウンドの活用によって次回以降の復旧も速められます。
導入メリットは、ダウンタイム短縮、コスト削減、属人化防止として現れます。ポイントは分析だけで終わらせず、変更管理に接続して恒久対策を確実に実装することです。6ステップで入出力を揃え、Problem Managerを中心に役割を明確化し、ツールで一元管理とCMDB連携を進めると運用が安定します。定例レビューとKPIで継続的改善を回すことで、再発防止が「組織の仕組み」になります。

WebSAM Cloudでインシデント対応の初動を仕組み化する

ここまで解説した問題管理は、日々のインシデント対応（アラート受信から一次対応までの初動）が仕組み化されていて初めて機能します。
WebSAM Cloudは、ITIL準拠のITサービスマネジメント機能を搭載しており、問題の調査・原因特定・再発防止策の実施までの一連の流れを標準化して運用できます。問題管理機能はBusinessプランよりご利用いただけますので、まずは1か月間の無料トライアルで、運用がどう変わるかをお試しください。

WebSAM Cloudの機能や導入効果について、より詳しくお知りになりたい方は、以下よりお気軽にお問い合わせ・資料請求ください。

サービス紹介資料のダウンロード

WebSAM Cloudの機能、活用シーン、導入効果を1つにまとめた紹介資料を無料で配布しています。
社内検討や上長への説明資料としてもご活用いただけます。

まずはFreeプランから

WebSAM Cloudはアラートメールのフィルタリング、自動通報（メール／電話）を無料で体験いただけます。

個別相談・お問い合わせ

「自社の運用に合うか相談したい」「料金プランや構成管理機能の詳細を聞きたい」といったご要望には、専門担当者が個別にお応えします。