なぜインシデント管理と問題管理は分断されてしまうのか？
問題管理が形骸化し、形ばかりの報告書作成に追われて疲弊していることはないでしょうか。また、類似の障害が再発して悪いスパイラルに陥っていないでしょうか。
サービス影響の大きなシステム障害が起きたら、業務を中断し、復旧に取り組むことになります。いち早くサービスを復旧させることが大事だからです。ここでは、このフェーズを「インシデント管理」と呼ぶことにします。
サービスが復旧すると、「ああよかった。では元の業務に戻ろう」と安心して、通常モードに戻ります。さて、それから数ヶ月後、どこかで見たことのある障害が再度発生してしまった、このようなことはないでしょうか。
また、インシデント管理の対応スピードや効率は向上しているにもかかわらず、再発防止という観点では十分な成果が出ていない、そのように感じる現場は多いのではないでしょうか。
これは、ITサービスマネジメント全体における「運用と改善の断絶」とも言えます。
こうした状況に対して、「問題管理を強化しよう」「ポストモーテムを徹底しよう」といった対策が語られます。しかし、それだけで状況が大きく改善することは多くありません。なぜなら、これは単なる努力不足や当事者意識の欠如等によるものではなく、構造に起因しているからです。
このブログ記事では、インシデント管理と問題管理がなぜ分断されてしまうのかを構造的に整理し、そのうえで、現場で実践可能な手法について考えていきます。
インシデント管理と問題管理の前提は大きく異なる
まず押さえておきたいのは、インシデント管理と問題管理は、似ているようでいて、その前提が大きく異なるという点です。
インシデント管理の目的は、「今この瞬間のサービスを復旧すること」です。ユーザーへの影響を最小限に抑えることが最優先であり、時間との戦いになります。そのため、多少不確実な情報であっても、仮説を立てて調査をしたり、迅速に意思決定を行ったりして、暫定的な対応を含めてでも復旧を目指します。
一方で、問題管理の目的は、「なぜその障害が発生したのかを明らかにし、再発を防止すること」です。こちらは中長期的な視点が求められ、仮説ではなく再現性のある原因特定が重視されます。拙速な結論よりも、正確な分析が優先されます。
つまり、両者は単に役割が異なるだけではなく、求められる思考様式や意思決定の基準そのものが異なるのです。
この違いは、現場の行動に直接的な影響を与えます。インシデント管理が「まず止血すること」だとすれば、問題管理は「なぜ出血したのかを突き止めること」です。この2つを同じタイミングで完璧に行うことは、現実的には非常に困難ですし、むしろ、やるべきではないことです。
KPIの違いが行動を分断する
さらに、この分断を強化する要因として、評価指標、すなわちKPIの違いが挙げられます。
インシデント管理では、MTTR（平均復旧時間）やビジネス影響の最小化といった指標が重視されます。いかに早く復旧できたか、ユーザーへの影響をどれだけ抑えられたかが評価の対象になります。
一方、問題管理では、恒久対策の実施状況や、再発率の低減といった指標が重視されます。
このように、評価の軸が異なると、現場の最適化の方向も変わってきます。
インシデント管理の現場では、「とにかく早く復旧すること」が最優先になります。その結果、詳細なログ取得や再現確認といった後工程に必要な情報収集は後回しになりがちです。場合によっては、復旧のために一時的な設定変更や回避策を適用し、そのまま恒久対策に進まずにクローズしてしまうこともあります。
一方で、問題管理の立場から見ると、必要な情報が残されていないために、原因分析が進まないという状況に直面します。「なぜもっとログを取っておかなかったのか」「なぜあの時点で切り分けをしていないのか」といった不満が生じることも少なくありません。
しかし、ここで重要なのは、どちらかが間違っているわけではないということです。両者ともに、それぞれのKPIに基づき合理的に行動した結果なのです。
分断は「失敗」ではなく「合理的な結果」である
ここまで見てきたように、インシデント管理と問題管理の分断は、個人の能力や意識の問題ではなく、構造的な要因によって生じています。
むしろ、一般的な組織構造や評価制度、時間的制約のもとでは、この分断は自然で、避け難い合理的な結果だといえます。
インシデント管理にリソースを集中すれば、問題管理は後回しになります。逆に、問題管理に十分な時間をかけようとすれば、日々の運用対応に支障が出る可能性があります。このトレードオフは、多くの現場で避けがたい現実です。
そのため、「インシデント管理も問題管理もどちらも完璧にやろう」というアプローチは、結果的に現場に過剰な負荷をかけるだけで終わってしまうことが少なくありません。
必要なのは、分断そのものを否定することではなく、分断を前提として、どのように接続するかを設計することです。
接続の第一歩は「問題管理を重くしすぎないこと」
では、どのようにしてインシデント管理と問題管理を接続すればよいのでしょうか。
その第一歩は、問題管理を過度に重くしないことです。
多くの組織では、問題管理というと「徹底的な真因分析」「網羅的な対策検討」といった、非常に重厚なプロセスを想定しています。しかし、すべてのインシデントに対してこれを適用しようとすると、確実にリソースが不足し、形骸化してしまいます。
重要なのは、対象を適切にコントロールすることです。具体的には、どこまでやるかを意図的に線引きすることです。
例えば、影響の小さいインシデントについては、簡易な振り返りにとどめ、レビューもチーム内で済ませる。一方で、重大なインシデントや再発リスクの高いものについては、時間をかけて詳細な分析を行い、適切な場で共有し、承認を得る。このように、メリハリをつけることが重要です。
このとき、前提として、何をもって影響が大きいとするのか、重大度を判定する仕組みが整っていることが求められます。その上で、組織内で「どのレベルのインシデントを詳細な振り返り対象とするのか」について合意が取れている必要があります。
また、インシデントの発生段階で、「後から分析すべきポイント」を意識的に残しておくことも有効です。すべてをその場で解決しようとするのではなく、「ここは後で深掘りする」と切り分けることで、初動対応のスピードと問題管理の質の両立が可能になります。
ある現場の例を紹介します。「復旧優先で！」と指示したら、原因特定が一切できなくなる対応が実行されてしまったことがあります。「この手段をとれば、追加で5分かかるが、後から分析することができます。どちらをとるべきですか」といった会話と判断がされるべきです。
フィードバックループを設計する
もう一つ重要な観点は、問題管理の成果をインシデント管理に確実にフィードバックする仕組みを持つことです。
問題管理で得られた知見が現場に還元されなければ、同じような障害が繰り返されます。分析結果が報告書にまとめられるだけで終わってしまっては、意味がありません。
具体的には、以下のような取り組みが考えられます。
- 頻出する障害パターンをナレッジとして蓄積する
- 新規着任者のオンボーディングでナレッジを紹介する
- 初動対応の手順や判断基準に反映する
- 監視項目やアラート設計を見直す
- 運用手順そのものを改善する
これらを通じて、次のインシデントへ向けて対応力を高めることが重要です。
このようなフィードバックループが機能し始めると、インシデント管理と問題管理は単なる直列のプロセスではなく、相互に影響し合う循環的な関係になります。
分断を前提に設計するという発想
最後に、再度強調したいのは、「分断をなくす」ことを目指す必要はないという点です。
インシデント管理と問題管理は、その性質上、完全に一体化することはありません。むしろ、それぞれが異なる役割を担うからこそ、全体としてのバランスが保たれます。
重要なのは、分断を否定し、無くそうとするのではなく、分断を前提に「どこで接続するか」の設計を行うことです。
どのタイミングで問題管理に引き渡すのか。
どのレベルのインシデントを詳細分析の対象とするのか。
どのように分析結果を現場に還元するのか。
これらを明示的に定義し、プロセスとして組み込むことで、初めて実効性のある仕組みが構築されます。
組織役割を分けることも有効
組織の機能分化が進んでいる場合は、インシデント管理は事業部に近いIT組織が行い、問題管理は横断組織が行う、といった役割分担をしているところもあるでしょう。組織として分けずとも、問題管理担当として任命するケースもありえます。
これは、まさに分断を前提にした設計だと言えます。
インシデント管理は、主にシステム障害対応となりますが、豊富なシステム知識と業務知識をもとに、熟練の技が求められます。
問題管理は、大きく2つの側面があります。
まず1つ目は、インシデント管理で発生した障害記録に対して、どこまで対応できているのかを進行管理し、再発防止の完了までフォローしてクローズすること。これは、機能として切り出すことができます。つまり、システム知識と業務知識は必ずしも豊富である必要はなく、別組織や別担当が主導することもできるわけです。
2つ目が、問題管理の本質である、真因分析と再発防止です。これは、豊富なシステム知識と業務知識はあるに越したことはありませんが、どちらかといえば論理思考力がものを言う世界です。もちろん、真因分析と再発防止策を持ち込むのは、実際にインシデントへの対応を行った組織になることが多いですが、問題管理はインシデント管理と比べると、このような機能的な側面があるわけです。
以上のことから、問題管理がうまくいかない、徹底されない場合は、機能として別組織または別担当に切り出し、それぞれで専門性を磨くアプローチも有効です。そして、事業部やプロダクトを横断して問題管理した結果、データ分析して傾向から示唆を出したり、標準化したりする役割も担えるでしょう。
おわりに
インシデント管理と問題管理の分断は、多くの現場で見られる普遍的な課題です。しかし、それは決して「うまくいっていない」ことを意味するわけではありません。むしろ、現場がそれぞれの役割に対して最適化した結果として生じているものです。
だからこそ、必要なのは構造に対するアプローチです。
自組織のプロセスを振り返り、どこまでがインシデント管理で、どこから問題管理が始まっているのか。その間にどのような断絶があるのか。そして、それをどのように接続できるのか。
こうした視点で見直していくことで、単なる「対応の繰り返し」から、「学習する組織」へと一歩踏み出すことができるはずです。結果として、現場が安心して、目の前の復旧に集中できる文化が育てていくことができます。
インシデント管理の高度化だけでも、問題管理の強化だけでも、不十分です。
両者の“あいだ”にこそ、本質的な改善の余地があります。
まずは、自組織におけるその「あいだ」を見つめ直すことから始めてみてください。