ITサービス管理（ITSM）の現場では、「インシデント管理」と「問題管理」という2つのプロセスが密接に関連しながら運用されています。
しかし両者の違いを正確に理解していないと、対応すべき事象に対して適切なプロセスを適用できず、根本的な問題解決が遅れることがあります。
本記事では、インシデント管理と問題管理の違い・役割・連携方法・ITILにおける位置づけについて詳しく解説していきます。
インシデント管理と問題管理の根本的な違い
それではまず、インシデント管理と問題管理の根本的な違いについて解説していきます。
インシデント管理と問題管理の最も本質的な違いは、「対応の目的と時間軸」にあります。
インシデント管理と問題管理の違いを一言で表すと：
・インシデント管理 → 「今すぐ火を消す（対症療法）」が目的
・問題管理 → 「なぜ火が起きたかを調べ、再発を防ぐ（根本対策）」が目的
同じ障害に対しても、短期的な復旧対応と根本原因の究明・恒久対策という異なるアプローチが必要です。
インシデント管理の定義と役割
インシデント管理はITサービスの通常運用への影響を最小化し、できるだけ迅速にサービスを復旧させることを目的とするプロセスです。
対応の時間軸は「今すぐ」であり、根本原因の究明よりもサービスの一時的な回復（ワークアラウンド・暫定対応）を優先します。
例えばデータベースサーバーが高負荷でサービスが停止した場合、インシデント管理では「サーバーを再起動してサービスを復旧させる」というアクションが取られます。
なぜ高負荷になったかという根本原因の調査は、問題管理が担当するでしょう。
問題管理の定義と役割
問題管理はインシデントの根本原因（Problem）を特定し、恒久的な解決策を実施してインシデントの再発を防ぐことを目的とするプロセスです。
問題管理における「問題（Problem）」とは、1つ以上のインシデントの根本原因であるまだ解明されていない原因を指します。
問題管理の対応は週・月単位の時間軸で行われることが多く、根本原因分析（RCA：Root Cause Analysis）・恒久対策の立案・実施・効果検証という長いサイクルで進めます。
| 比較項目 | インシデント管理 | 問題管理 |
|---|---|---|
| 目的 | サービスの迅速な復旧 | 根本原因の特定と再発防止 |
| 対応の性質 | 対症療法・暫定対応 | 根本対策・恒久解決 |
| 時間軸 | 即時（分〜時間単位） | 中長期（日〜週単位） |
| 優先事項 | 速さ | 正確さ・完全性 |
| 成果物 | サービス復旧・ナレッジ記事 | 根本原因レポート・恒久対策 |
既知エラー（Known Error）という概念
問題管理の重要な概念として既知エラー（Known Error）があります。
既知エラーとは、根本原因が特定された問題であり、恒久的な解決策がまだ実施されていない状態のものを指します。
既知エラーに対してはワークアラウンド（一時的な回避策）が定義されており、同じインシデントが発生した際に迅速に対応できるようにナレッジベースに記録されます。
既知エラーデータベース（KEDB）はインシデント管理と問題管理を橋渡しする重要な情報資産となるでしょう。
インシデント管理と問題管理の連携方法
続いては、インシデント管理と問題管理の連携方法を確認していきます。
両プロセスが効果的に連携することで、ITサービス全体の品質向上が実現します。
インシデントから問題への移行
インシデント管理から問題管理へのトリガーとなる主なケースを理解しておくことが重要です。
同じインシデントが繰り返し発生している場合・重大なインシデント（Major Incident）が発生した場合・根本原因が未解明のまま暫定対応でサービスを復旧させた場合などが、問題管理を開始する典型的なトリガーとなります。
インシデントチケットに「問題管理に引き継ぐ」フラグを立てる運用を定着させることで、インシデント対応の知見を問題管理に確実に引き継ぐ仕組みが整うでしょう。
根本原因分析（RCA）のプロセス
問題管理の核心となる根本原因分析（RCA：Root Cause Analysis）には、いくつかの代表的な手法があります。
「なぜなぜ分析（5 Whys）」は問題に対して「なぜ」を5回繰り返すことで根本原因にたどり着く手法であり、シンプルで実践しやすいというメリットがあります。
「魚の骨図（Fishbone Diagram）」は原因をカテゴリ別に整理して可視化するツールであり、複雑な問題の構造を把握するのに役立つでしょう。
なぜなぜ分析の例：
インシデント：Webサービスがダウンした
なぜ①：データベースサーバーがフルロードになった
なぜ②：定期バッチ処理が異常終了し再実行が重複した
なぜ③：バッチの異常終了検知処理にバグがあった
なぜ④：テストで異常終了パターンが考慮されていなかった
なぜ⑤：テスト設計のレビュープロセスが不十分だった
→ 根本原因：テスト設計のレビュープロセスの不備
ITILにおける両プロセスの関係性
ITIL（IT Infrastructure Library）フレームワークでは、インシデント管理と問題管理はともにサービス運用（Service Operation）のプロセスとして定義されており、密接に連携しながら機能します。
インシデント管理のデータ（発生頻度・影響度・対応時間等）は問題管理の優先順位付けに活用され、問題管理の成果（既知エラー・ワークアラウンド）はインシデント管理の効率化に貢献します。
この相互連携によって「インシデントを速く解決しながら、根本原因を特定して再発防止を図る」という両プロセスの目的が同時に達成されるでしょう。
効果的な運用体制の構築
続いては、効果的な運用体制の構築を確認していきます。
インシデント管理と問題管理を組織の中で効果的に機能させるための運用体制のポイントを説明します。
役割と責任の明確化
インシデント管理と問題管理を効果的に運用するためには、各プロセスにおける役割と責任を明確に定義することが重要です。
インシデントマネージャー（インシデントの優先順位付け・エスカレーション判断）・問題マネージャー（問題の特定・RCAの主導・恒久対策の管理）・サービスデスク（ユーザーからのインシデント受付・初期診断）という役割の分担が基本的な体制となります。
大規模な組織では各役割を専任担当者が担い、小規模な組織では兼任で対応するという現実的な運用体制が採られることが多いでしょう。
ナレッジマネジメントとの統合
インシデント管理と問題管理の効果を最大化するためには、ナレッジマネジメント（知識管理）との統合が重要です。
インシデントの解決策・既知エラーのワークアラウンド・問題の根本原因分析結果を体系的にナレッジベースに蓄積することで、将来の類似インシデントへの対応時間を大幅に短縮できます。
「解決したインシデントのナレッジ記事作成を義務化する」運用ルールの徹底が、ナレッジベースの充実と継続的な品質向上のサイクルを生み出すでしょう。
定期的なレビューと改善
インシデント管理と問題管理プロセスは定期的なレビューと改善を繰り返すことで成熟していきます。
月次・四半期ごとのインシデントレビューミーティングでは、発生したインシデントの傾向分析・SLA達成率の評価・問題管理の進捗確認・プロセス改善事項の討議を実施することが推奨されます。
継続的な改善サイクルを組織文化として定着させることが、長期的なITサービス品質の向上につながるでしょう。
まとめ
本記事では、インシデント管理と問題管理の違い・役割・連携方法・効果的な運用体制について詳しく解説しました。
インシデント管理は「迅速なサービス復旧（対症療法）」、問題管理は「根本原因の特定と再発防止（根本対策）」という異なる目的を持ちますが、互いに連携して機能することでITサービスの品質向上が実現します。
役割の明確化・ナレッジマネジメントとの統合・定期的なレビューによる継続的改善が、両プロセスを組織で効果的に機能させる鍵となるでしょう。
インシデント管理と問題管理の違いを正確に理解し適切に運用することが、安定したITサービスの維持と顧客満足度の向上につながります。
