インシデント管理と問題管理

概要

インシデント管理は、チケット化された単一の事象について、分類、優先順位付け、初回問い合わせ解決率や顧客満足度などの指標を用いながら、できるだけ迅速にサービスを復旧することに重点を置きます。問題管理は、再発するインシデントの根本原因を追究し、専任のオーナーを割り当て、既知のエラーと回避策を文書化し、根本原因の排除と予防的な変更を測定するKPIを追跡します。2つのプロセスを明確に分けることで、コミュニケーションが改善され、繰り返し発生する障害が減少します。また、多くの組織が戦略的価値を認識できずに見送っている問題管理の低い採用率を克服する助けにもなります。

インシデント管理と問題管理の違いはわずかに見えるかもしれませんが、実際には大きな違いがあり、ITの領域において両者を分けるものを認識することが重要です。

問題とインシデントの違いを知ることが重要な理由

一見すると、「インシデント」と「問題」は同じもののように思えるかもしれません。一般的な言い方では、どちらもビジネスに悪影響を及ぼす状況を指し得ます。しかしITでは、この2つの用語は大きく異なり、それぞれ異なる目的を念頭に置いて、適切に対応・管理する必要があります。つまり、インシデント管理と問題管理は同じものではありません。

最も基本的な定義では、インシデントとは単発の独立した事象です。インシデントは、多くの場合、ユーザーがITヘルプデスクにチケットを起票し、ITによる迅速な解決を期待するような事象や課題を指します。問題はインシデントの根本原因であり、問題管理は、繰り返し発生するインシデントを引き起こし得る根本的な理由に対処することで、インシデントの発生を防ごうとするものです。

インシデントと問題の違いを、次のシナリオで考えてみましょう。ある運送会社が車両群を運用しているとします。そのうち1台のトラックがパンクし、早急にタイヤを交換して道路に戻す必要が生じました。この事象は単独で発生し、その1台のトラックにのみ影響するため、インシデントに当たります。この場合、インシデント管理とは、そのトラックをできるだけ早く稼働状態に戻すためにタイヤを交換することです。

パンクが繰り返し発生したり、通常考えられる範囲を超えて発生したりする場合、その事象はインシデントから、問題管理を必要とするものへ移行する可能性があります。この場合、運送会社は過剰なパンクの根本原因を特定するため、さらに調査を行うことになります。

これらのインシデントの根底にある問題は何でしょうか。該当するタイヤがリコール対象になっているのかもしれません。あるいは、タイヤの保守スケジュールが守られておらず、パンクが頻発している可能性もあります。また、ドライバーが工事のがれきなど路面上の危険物があるルートを走行しており、それがパンクの原因になっている場合もあります。

この根本原因を特定することで、会社は将来の関連インシデントを防ぐための対策を実施できます。

課題解決に不可欠な基本原則

ITでは、これらの基本原則を用いてインシデントと問題を適切に見極め、それぞれに適した対応を行います。そのため、IT部門以外のビジネスオーナーや管理者にとっても、インシデントと問題の違い、そしてインシデント管理と問題管理をいつ適用すべきかを理解することが重要です。

これらの用語は互換的に使えるように見えるかもしれませんが、ITサポートの技術的な言葉を用いて明確にコミュニケーションすることで、混乱や不満を減らすことができます。実際にはより広範な問題であるにもかかわらず、ITサポートにインシデントだと伝えてしまうと、根本原因が対処されないまま残り、将来的なトラブルにつながる可能性があります。

違いを理解することで、組織は適切な解決により早く到達できます。

それでは、複数の業界の組織で一般的に使用されているITのインシデント管理と問題管理について、どちらもITILプロセスであることを踏まえ、詳しく見ていきましょう。

インシデント管理とは

インシデント管理と問題管理を区別するにあたり、まずITインシデント管理を見てみましょう。その目的は、サービス運用をできるだけ早く復旧し、停止やサービス品質低下の影響を最小限に抑えることです。実務では、ITサポートデスクが個々のチケットのトラブルシューティングに注力する形でこれが見られます。場合によっては、根本的な修正ではなく回避策で対応することもあります。

インシデント管理に関連する活動は、主にインシデントの詳細を記録し、分類し、調査し、最終的に解決することを扱います。

効果的なインシデント管理を支える戦略とプロセスは、IT以外の多くの場面にも見られます。インシデント管理の仕組みを示す例として、背中の痛みを抱えている状況を想像してみましょう。適切なインシデント管理は、よく運営された診療所のように機能するべきです。

整形外科を初めて受診するとき、私たちは問診票に記入し、健康状態全般の背景情報と症状の詳細を伝えます。医師はその情報に加え、X線検査を用いて診断し、治療計画を処方します。

医師はインシデント（背中の痛み）を詳しく記録し、調査し、問題を迅速かつ効果的に解決するための有効な計画を実施したのです。

企業におけるインシデント管理機能

ビジネス環境では、多くのインシデントがITに関連しています。IT組織がITILに準拠しているかどうかにかかわらず、通常はインシデント管理を担う役割または機能が存在します。それが2人のチームであっても、200人規模であっても同様です。

インシデント管理の目標と主要業績評価指標（KPI）は、比較的明確です。

インシデントをできるだけ迅速に解決する。
インシデントの優先度を意識する。
解決にかかるコストを意識する。
プロセス全体を通じてユーザーの満足度を評価する。
初回問い合わせ解決率、問い合わせ1件あたりのコスト、顧客満足度など、個別の指標で結果を測定する。

インシデントが単発ではないように見える場合、ITチームは問題管理チームへエスカレーションする必要があるかもしれません。

問題管理とは

インシデント管理と問題管理を定義する次のステップとして、問題管理がIT内でどのように機能するかを見ていきます。その目的は、インフラストラクチャ内のエラーによって引き起こされるインシデントや問題の悪影響を最小化し、それらのエラーに関連するインシデントの再発を防ぐことです。

問題管理に関連する活動は、主にインシデントがそもそもなぜ発生したのかを特定し、既知のエラーを特定・文書化することを扱います。

インシデント管理とは異なり、問題管理を担当する役割や機能が存在しないことも少なくありません（これは、インシデント管理に注力するITサポートデスクの範囲を超えるものです）。また、関係する目標や主要業績評価指標が十分に理解されていない場合もあります。

企業は、問題管理を導入し、そのタスクにリソースを割り当て、自社に最も適した期待成果とKPIを定義するために、意識的に一歩踏み込む必要があります。

運用における問題管理

問題管理が適切に実行された場合、包括的な治療のように機能することを理解するため、背中の不調の例に戻ってみましょう。

医師は即時の緩和策（インシデントへの対応）を提供する一方で、治療計画がうまく機能せず、患者が痛みを感じ続ける場合には、より重大な問題が隠れている可能性があると説明するかもしれません。その場合は、MRIとさらなる分析が必要になります。

これは医師の最初の対応を否定するものではありません。医師は即時の根本解決を提供できたわけではなく、過去に同様の訴えを見ていたため、以前に特定・文書化していた回避策（薬と運動、移動の制限）を示したのです。根本原因が判明するまでは費用対効果も適切性もないと理解していたため、初回の受診時に手術を勧めることはありませんでした。

インシデント管理と問題管理の違いを理解することは、あくまで最初の一歩です。診療所の例から、次のことが分かります。

インシデント管理は個別のインシデントにできるだけ迅速に対応します。
問題管理はインシデント（または類似する複数のインシデント）がなぜ発生したのかに対応します。

後者は、根本原因を取り除くか、効果的で容易に展開できる回避策を構築することを目指します。

インシデントを解決するには何が必要か

インシデント管理と問題管理の違いを考える際に次に注目すべきなのは、インシデントと問題を実際に「管理」していくために整備されている構造やプラクティスです。

前述のとおり、すべての組織には、インシデントの管理と解決に専任で取り組む少なくとも数名、またはチーム（おそらくITサポートデスク、またはITサポートチケットを扱うチーム）が必要です。

専任のオーナーがいなければ、インシデントは迅速、効果的、または一貫した形で解決されない可能性があります。チームを配置するだけでなく、特にITや運用に関連するインシデントに対応する場合、インシデント管理を成功させるにはいくつかの重要な要素があります。

インシデント管理を効果的に行うには、次の要件を満たすことが重要です。

問題およびエラー制御の継続的な改善。
チームがTier 1およびTier 2のエスカレーションを理解している、階層型のサポート体制。
組織の目標と目的に整合したKPIを通じて効率性と有効性を測定する継続的サービス改善プログラム。
望ましい成果に関して、IT内の役割と責任が明確に文書化されていること。

さらに、ITは次の機能を含む堅牢なインシデント管理ソフトウェアを利用できる必要があります。

ITサービスデスクソフトウェアとIT資産管理リポジトリの統合。この統合により、ITサポートはユーザーが利用する資産やサービスに関するコンテキストを把握でき、フォームへの入力を不要にできます。
症状の把握を共有、拡張、標準化するのに役立つ、ITSMツール内のナレッジベース。ナレッジベースは、ITサポートがより迅速に作業し、チーム全体で一貫性を維持するのに役立ちます。
ITSMソリューションの構成管理データベース（CMDB）によって提供されるITサービスマップの表示。サービスマップは、ITがサービスレベルで何が起きているかを理解し、可用性やパフォーマンスに影響する問題のある構成アイテムをより適切に切り分けるのに役立ちます。

これらのツールとプロセスにより、ITまたはサービスデスクは、適切なコンテキストを伴って必要な情報を収集し、インシデントとその影響を十分に理解しやすくなります。

これが、インシデント解決の第2段階である分類と優先順位付けにつながります。すべてのインシデントが組織に同じ影響を与えるわけではなく、最も大きな混乱を引き起こすものから先に対応する必要があります（例：社内プリンターが動作しない場合と、会社のサービスレベル契約（SLA）に関連する顧客ポータルへアクセスできない場合の違い）。

問題を解決するには何が必要か

変更、資産、ナレッジの統合は、インシデント管理プロセス、ひいては組織に価値をもたらします。では、問題管理プロセスになると、なぜこれほど大きく取り組みが低下するのでしょうか。

ITSM.toolsによる2022年の調査では、問題管理プロセスを採用していたのはわずか38%の組織であることが分かりました。問題管理の採用率が低い理由の多くは、問題管理が組織にとってなぜ重要なのかについての理解不足にあると言えるでしょう。これが、そのプロセスに関連する役割と責任の整合にも影響します。

また、テクノロジーへの過度な依存も見られます。テクノロジーは問題レコードを作成し、オーナーシップを割り当てることはできますが、それ自体で、根本原因の特定、回避策の特定、解決アプローチの提案を担当者に促すことはできません。

インシデントとその影響を理解することで、ITチームは適切なリソースと優先度を割り当てやすくなります。

ITがインシデントを解決した、または回避策を提供したと判断したら、そのソリューションが意図どおりに機能し、ユーザーのペインポイントが残っていないことを確認するため、エンドユーザーに確認する必要があります。

問題管理における課題

成功する問題管理プロセスを構築するには、ITはまず、そのプロセスが自分たちにとってなぜ重要なのか（将来のインシデントの削減、ダウンタイムの最小化、インフラストラクチャの改善など）を判断し、それに応じて役割とリソースを割り当てる必要があります。

少なくとも、ITリーダーはインシデント管理と同等の厳密さを適用しなければなりません。

問題管理のリーダーは、次の点を確実にする必要があります。

問題とエラーが定期的に（かつ適切に）分類・特定されていること。
回避策が文書化され、インシデント管理機能に共有されていること。
問題管理プロセスに、明確に定義された関連性の高いKPIがあること（組織および問題管理に関する目標に基づいて決定）。
役割と責任が明確で、文書化されていること。

ITはまた、専用の問題管理機能を備えた適切なITSMソリューションを確保し、次の機能を実行できるようにする必要があります。

問題管理担当者が類似した再発インシデントを検出し、切り分けられるようにする、充実したインシデントダッシュボードとフィルタリング可能なインシデントレコードテーブルを提供する。
インシデントの詳細をナレッジベースと既知エラーデータベースの両方と照合し、インシデントレコードを問題レコードに関連付けやすくする。
問題レコードのオーナーシップを個人または機能グループに簡単に割り当てられるようにする。
必要なコンテキストと文書をすべて添えて、問題を変更要求（RFC）へ迅速に昇格できるようにする。
重要な問題管理指標を単一のパネルに直感的に整理する、充実した包括的なダッシュボードを提供する。

問題管理は、リアクティブかつプロアクティブなプロセスです。インシデントアナリストは、再発するインシデントを特定し、リアクティブな対策として問題要求を提出できます。問題管理の真の強みは、問題管理チームが、まだインシデントを引き起こしてはいないものの将来的に発生する可能性が高い潜在的な問題やインフラストラクチャの弱点を、継続的かつ入念に探し出す点にあります。これは真に効果的な問題管理アプローチの重要な要素であり、その実現を支援する方法があります。

問題は、ソリューションが実装された、または十分に文書化・周知された回避策が整備され、インシデントが発生しなくなった時点で解決されたと見なされます。