03-5946-8400
HOME
目次
属人化を防ぎ、場当たり的な障害対応から脱却するための運用プロセス
問題管理とは、 ITIL に基づき、障害やトラブルの根本原因を特定し、恒久的な対策を講じるプロセスの一つです。
システムの高度化・複雑化や IT 人材不足が進むなか、属人的・場当たり的な障害対応だけでは安定運用が難しくなっています。そのため、標準モデルに基づいた運用体制の構築が重要です。
本記事では、問題管理の概要、インシデント管理との違い、実務に活かすためのプロセスや運用ポイントを解説します。
1. 問題管理とは何か？
問題管理とは、 ITIL （ Information Technology Infrastructure Library ）で定義されているプロセスの一つで、障害やトラブルといったインシデントの根本原因（ Root Cause ）を特定し、再発防止のための恒久的な対策を講じることです。
単なる障害対応にとどまらず、過去のインシデントを分析して潜在的な問題を洗い出し、本質的な原因を除去します。問題解決により障害の再発を防ぎ、システムの安定性と品質を継続的に向上させることができます。
2. 問題管理とインシデント管理の違い
問題管理と混同されやすいプロセスにインシデント管理があります。インシデント管理が障害からの迅速な解決を目指すのに対し、問題管理ではインシデントの根本解決を目的とする点が大きな違いです。両者の違いを以下の表にまとめました。
| 観点 | インシデント管理 | 問題管理 |
|---|---|---|
| 目的 | サービスの中断や品質低下をできるだけ早く復旧させ、業務影響を最小限に抑える | インシデントの根本原因を特定し、再発を防止する |
| 対応スピード | 暫定対応であっても、迅速な復旧を優先する | 即時性よりも恒久性を重視する |
| 原因究明 | 根本原因を特定せず、ワークアラウンドで対応を進める | 原因究明のために分析を徹底的に行う |
| 対応方法 | 再起動、切り戻し、代替手段の提供など応急、回避対応を実施する | 恒久対策の立案、変更、プロセス改善など根本対策を行う |
| 実施タイミング | インシデント発生直後から対応する | インシデント収束後、または繰り返し発生する事象を対象に実施する |
| ゴール | サービスを通常の状態に戻す | インシデントが再発しない状態にする |
3. 問題管理の6つのプロセス
ここでは、問題管理を実施するうえでの 6 つのプロセスを解説します。
1. 問題の記録
インシデントや障害に起因する問題を登録します。発生したインシデントの概要や影響範囲、発生日、発生頻度、関連インシデント番号の紐付けを行います。その際、単発の障害であっても再発リスクがあれば問題として扱うとともに、客観的な事実に基づいて正確に記録することが重要です。
2. 問題の分類と優先順位付け
記録した問題を整理し、どの問題から対応すべきかを明確にします。具体的には、アプリケーション、インフラ、ネットワークといったカテゴリ分類に加え、業務への影響度やユーザー数、緊急度をもとに優先度を決定します。判断にあたっては、影響度と緊急度に加え、再発リスクの高さも考慮することが重要です。
3. 問題の調査と分析
優先順位の高いものから順に、問題の根本原因を特定します。ログや監視データの分析だけでなく、関係者へのヒアリングを通じて多角的な視点から分析を行うことが重要です。その際は、まず「いつ」「どこで」「誰が」「何を」「なぜ」「どのように」といった 5W1H で状況と事実関係を整理したうえで、原因を深掘りします。
表面的な事象で終わらせず、本質的な原因まで掘り下げ、分析経過や結果を詳細に記録しておくことが、後のナレッジ共有にもつながります。
4. 問題の解決
問題の調査と分析によって特定した根本原因に対して、恒久的な対策を実施します。具体的には、対策の検討と決定、システム改修、設定変更、運用ルールの見直しなどが挙げられます。システムに変更を加える際は、変更管理やリリース管理で具体化して実行しましょう。その際、回避策（ワークアラウンド）と恒久対策を区別し、特に影響の大きい変更については十分な検証と承認を行うことが不可欠です。
5. 問題のクローズ
根本的な原因が解消され、再発防止策が有効であることを確認したうえで、問題をクローズします。ステータスを更新する前には、対策実施の効果と関連インシデントの収束を確認しましょう。単に対応しただけでなく、二度と同じ事象が発生しないことを担保するために、クローズ条件を明確にしておくことが重要です。
6. ナレッジの共有と継続改善
問題をクローズしたあとは、得られた知見を組織全体で共有し、同様の問題を未然に防ぐ体制を整えます。根本原因と対策をナレッジベースとして登録するほか、運用手順書や設計書の更新、問題管理プロセス自体の見直しも並行して行いましょう。ナレッジの共有によって属人化を防ぐとともに、問題管理そのものの妥当性を定期的に振り返り、運用の質を高めていく必要があります。
4. 問題管理を運用として継続させるための4つのポイント
問題管理を運用として継続させるためには、 4 つの重要なポイントがあります。
①評価基準と優先ルールの明確化
問題管理を継続的に運用するためには、優先順位の判断基準を組織内で統一しておく必要があります。担当者ごとに判断が異なると、対応の遅れや重要な問題の見落としを招くおそれがあるためです。
「業務への影響が大きい障害や、単一障害点（ SPOF ）となっている箇所は最優先で対応する」など、影響度や緊急度、再発リスクといった評価基準を明文化しましょう。運用ルールとして共有することで、安定した問題管理体制を維持しやすくなります。
②体制と役割分担の整備
調査・対応・承認といった責任範囲を明確にした運用体制が不可欠です。例えば、共通の問題管理表を作成し、個々の問題の進捗と担当者を常に紐付けて管理します。あわせて管理責任者を定め、定期的に更新状況を確認することで、運用の形骸化を防ぎやすくなります。
また、対策の実施や変更における承認プロセスもあらかじめ定義しておきましょう。インシデント管理や変更管理、リリース管理と連携し、全体プロセスを俯瞰した運用ルールを整備することで、再現性のある運用体制を構築できます。
③根本原因の体系的な分析
一時的な対処で終わらせず、再発防止を実現するためには、根本原因を体系的に分析することが重要です。
5W1H に加えて、特性要因図やなぜなぜ分析（ 5 Whys ）などの手法を用いることで、技術的な要因だけでなく、運用プロセスや体制面の課題も洗い出せます。経験や感覚といった主観に頼らず、事実とデータに基づいた分析を行うことが、精度の高い効果的な恒久対策につながります。
④運用観点での再発防止の徹底
問題の解決は、システム改修や設定変更だけで終わりがちです。しかし、それらが運用手順や対応フローに正しく反映されて初めて、恒久的な対策として機能します。
例えば、設定漏れの原因が設計書と実機構成の不整合にある場合、設計書を最新の構成に合わせて更新するとともに、実機変更時の更新手順を標準フローに組み込むことが重要です。このように、技術面と運用面の両輪で対策を定着させることで、再発しにくい安定した運用体制が整います。
5. まとめ
問題管理は障害の根本原因を分析し、再発防止に向けた恒久的な対策を講じるプロセスを指します。
問題管理には、問題の記録、優先順位付け、根本原因の分析、問題への対応、問題のクローズ、ナレッジの共有と改善の 6 ステップがあります。これらを形骸化させずに運用するためには、客観的な評価基準の策定や体制の整備、継続的な改善活動に取り組むことが重要です。
Rworks は、 ITIL に基づく運用設計と24時間365日の監視・障害対応を含むフルマネージドサービスにより、システムの安定稼働と継続的な改善を支援しています。自社での運用体制に課題を感じている場合は、ぜひお気軽にご相談ください。
Contactお問い合わせ
お見積もり・ご相談など、お気軽にお問い合わせください。