ITIL問題管理（ITIL Problem Management）

ITサービスデスクのプロフェッショナルとして、私たちはユーザーに卓越したサービス体験を提供し、支援したいと考えています。インシデント管理プロセスを活用することで、インシデントに対応し、できる限り迅速にサービスを復旧することができます。しかし、究極の目標はインシデントをゼロにすることです。そこで、皆様と組織がこれらの成果を達成するためのProblem Managementをご紹介します。

Problem Managementの主な目標は、インシデントの発生を防ぐこと、そしてインシデントが発生した場合には再発を防ぐことです。同じインシデントが繰り返され、根本的に解決されないまま対応し続けるだけのサービスプロバイダーを想像してみてください。そのような状況が「通常業務」となり、同じインシデントを何度も何度も解決し続けることになったとしたら、どうなるでしょうか。時間の経過とともに、インシデントの件数は増加し、インシデント管理コストは増大し、顧客とユーザーの満足度は急落し、サービスデスクの評判は低下し、シャドーITの取り組みが常態化し、その結果として事業遂行能力に深刻なダメージを与えることになります。

多くの組織は、効果的なProblem Managementプロセスを持っていないために、不必要な苦労を重ねています。多くの場合、これはITチームがProblem ManagementをIncident Managementと混同し、Change Managementとの関係性を十分に理解していないことが原因です。これらのプロセスは密接に連携して機能しますが、Problem Managementの目標は、Change Managementプロセスを活用することで、そもそもインシデントが発生しないようIncident Managementを支援することにあります——Change Managementプロセスの活用を通じて。

このガイドのコンテンツをお読みいただく際には、組織にとって本質的なことを実践し、人材・プロセス・テクノロジー・サプライヤーを活用して目標を達成することの、ビジネスへの価値を念頭に置いてください。サービスエクセレンスとは終わりのない旅であり、継続的に実践し続ける必要があります。そして何より、サービス提供全体に改善が見られたときは、その成功を称えてください。

ITIL Problem Managementとは何か？

Problem Managementは、根本的な「Problems（問題）」のライフサイクルを管理するITサービス管理プロセスです。Problemsを迅速に検出し、解決策またはワークアラウンドを提供することで、組織への影響を最小限に抑え、再発を防止することで成果が達成されます。Problem Managementはまた、問題を引き起こし、ユーザーが経験するIncidentsの原因となっているITインフラストラクチャ内のエラーを特定しようとします。IT Infrastructure Library（ITIL）は、このプロセス内で使用される以下の定義を提供しています：

• Problem：「1件以上のIncidentの原因。Problem Recordが作成された時点では、通常その原因は不明である」
• Error：「1件以上のITサービスまたはその他の構成アイテムの障害を引き起こす設計上の欠陥または誤動作」
• Known Error：「文書化された根本原因とワークアラウンドを持つProblem」
• Root Cause：「インシデントまたは問題の根本的または元の原因」

プロアクティブとリアクティブのProblem Management

Problem Managementは、リアクティブまたはプロアクティブのいずれかになります。

• リアクティブProblem Managementは、1件以上のIncidentが発生した際に行われる問題解決への対応です。
• プロアクティブProblem Managementは、Incidentが発生する前に問題を特定し解決することを扱います。このアクティビティはContinual Service Improvement（CSI）と関連しています。

ビジネスにおけるProblem Managementの価値

Problem Managementプロセスは、IncidentおよびChange Managementと連携して、さまざまな形でビジネスに価値を提供します。Problem Managementの主な目標は、Problemsがビジネスに与える影響を最小限に抑え、再発を防ぐことです。これが成功すれば、ダウンタイムと業務の中断が削減されます。その他の主な効果には以下が挙げられます：

• サービス可用性の向上
• サービス品質の改善
• Problem解決時間の短縮
• Incidentの件数削減
• 生産性の向上
• コストの削減
• 顧客満足度の向上

ITILのプロセスとテクノロジーを採用・実装することで、急速に変化するテクノロジー環境の中でIT組織が直面しうる混乱を最小化できます。Problem Managementは独立したプロセスですが、効果的なIncident Managementプロセスと適切なツールに依存しています。そのツールとは、共通のインターフェース、利用可能なナレッジへのアクセス、構成管理情報、および関連するその他のITILプロセスとの連携を含むものです。これにより、Problemsが迅速に特定され、関連する詳細情報を含んだ状態で対処されることが保証されます。ITILはProblem Managementの採用方法を組織に対して厳密に規定するものではなく、個々のビジネスニーズと制約に合わせて調整が必要な構造化されたフレームワークを提供します。これらの社内ITILプロセスへの継続的な調整は、最終的にアジリティを支援し、ビジネス価値を実証し、組織が市場での競争力を高めることに貢献します。

Problem Managementプロセスフロー

Problem Managementはどのように機能するのでしょうか。ITIL Problem Managementは、単にIncidentsを解決するだけでなく、Problemのライフサイクル全体を考慮します。Problem Managementライフサイクルのプロセスフローは、ユーザーやサービスデスク担当者がセルフサービスポータル、電話、メール、対面などを通じてIncidentとして報告したProblemを管理するために、またはIncidentが発生する前にITSMの担当者やテクノロジーによって自動検出された潜在的なProblemを管理するために構成できます。Problem Managementプロセスフローのスコープには以下が含まれます：

1) Problem検出

Problemは、Incidentレポートの結果、継続的なIncident分析、イベント管理ツールによる自動検出、またはサプライヤーからの通知など、さまざまな方法で検出されます。Problemは、サービスデスクに報告された1件以上のIncidentの原因が不明な場合に検出されることが一般的です。サービスデスクがIncidentを解決したものの再発の可能性があり、根本原因が不明なためProblemレコードを作成するケースもあります。また、報告されたIncidentが既存のProblemに関連していることが明らかな場合もあります。そのProblemがすでに記録されている場合——Known Problem——Incidentは既存のProblemレコードに紐付けることができます。Problemが記録されていない場合は、サービスパフォーマンスを確保するためにすぐにProblemレコードを作成する必要があります。

2) Problemのログ記録

完全な履歴記録を維持するために、特定・報告の方法に関わらず、すべてのProblemは日時、ユーザー情報、説明、CMDBからの関連Configuration Item、関連するIncidents、解決の詳細、クローズ情報を含むすべての関連詳細とともにログに記録する必要があります。

• カテゴリー分類 - ログ記録後、適切な割り当て、エスカレーション、頻度とProblemトレンドの監視を適切に行うために、すべての適切なカテゴリーを選択する必要があります
• 優先度設定 - 優先度の割り当ては、スタッフがProblemをどのように、いつ対処するかを決定する上で非常に重要です。優先度は、影響度——影響を受けたユーザー数やビジネスへの影響を把握できる関連Incidentsの件数——によって決定されます。加えて、Problemの緊急度——どれだけ迅速な解決が必要か——も優先度の定義に考慮されます

3) 調査と診断

対象となるProblemの影響度、深刻度、緊急度に基づいて、Problemの根本原因に関する調査が行われます。一般的な調査手法には、一致するProblemと解決策を見つけるためのKnown Error Database（KEDB）のレビュー、および/または原因を特定するための障害の再現などが含まれます。

4) ワークアラウンド

状況によっては、Problemに関連するIncidentを経験しているユーザーに対して、一時的な修正またはワークアラウンドを提供できる場合があります。ただし、Problem Managementによって検出された根本的なエラーに対する恒久的な変更解決策を追求することが重要です。

5) Known Errorレコードの作成

調査と診断が完了したら、Known Errorレコードを作成することが重要です。将来的にIncidentsやProblemsが発生した場合、調査担当のサービスデスク技術者はKnown Error Database（KEDB）と関連するワークアラウンドを活用して、より迅速に解決策を特定・提供できます。

6) 解決

解決後、標準的な変更手順を用いてソリューションを実装し、サービスの回復を確認するためのテストを行うことができます。ただし、通常の変更が必要な場合は、Problemに解決策が適用される前に、関連する変更要求（RFC）が提起・承認される必要があります。

7) クローズ

Errorが解決されたことが確認された後、Problemおよび関連するすべてのIncidentsをクローズすることができます。サービスデスク技術者は、将来の参照およびレポートのために、初期の分類詳細が正確であることを確認する必要があります。

• Major Problemレビュー - Major Problemは、対応と優先度（Problemの影響度、緊急度、深刻度）を決定するために、組織のビジネス影響度分析（BIA）とリスク評価（RA）によって定義されます。Major Problemレビューの目標は、主要なビジネス課題への対応におけるProblem Managementプロセスを継続的に改善することです。レビュープロセスでは、正しく実施されたこと、誤って実施されたこと、改善できること、追加のリスク、再発防止策、および第三者の責任の性質などを特定できます。このレビューは独立して行うべきではなく、トレーニングや意識向上セッションの一環としてチームメンバーと共有される必要があります。
• Problem ControlとError Control – 状況によっては、Problem ManagementライフサイクルにおいてProblem ControlおよびError Controlという用語が使用される場合があります。Problem Controlは、問題の根本原因を見つけてKnown Errorに転換することを目標として、調査フェーズに組み込むことができます。これにより、サービスデスク技術者はユーザーに一時的なワークアラウンドを提供できます。一方、Error ControlはKnown Errorをソリューションに転換し、必要に応じてKnown Error Database（KEDB）から削除することを目標とした解決フェーズの一部です。

相互に関連するITILプロセス：Incident ManagementとChange Management

ITILプロセスは、サービスデリバリーのライフサイクル全体を通じて相互に連携しています。Problem ManagementとIncident ManagementはProblem Managementと密接に関連していますが、同一のものではありません。これらはいずれもIT部門が実施するプロセスですが、それぞれ異なる目標を持っています。Problem Managementは、根本原因を特定することで、1件以上のIncidentsの影響を防止または最小化することに焦点を当てています。Incident Managementは、Incidentを迅速に解決し、適切なタイミングでユーザーへのサービスを復旧することを目的としています。Incident Managementにおけるサービスの復旧は、必ずしもIncidentが再発しないことを意味するわけではありません。Problemsの大半は1件以上のIncidentsへの対応として発生しますが、状況によっては、テスターがリリースのテストを行う際（例：Service Validation and Testingプロセスを使用する場合）や、サプライヤーが自社の製品やサービスに欠陥を発見した際にProblemが作成されることもあります。

Service Operationは安定性の実現を目指していますが、変更が必要な場合もあります。そのため、Change ManagementもProblem Managementと密接に関連しています。変更は事前承認される場合もあれば、承認が必要な場合もあります。いずれの場合も、必要な変更を文書化するためにRFCが作成されます。変更要求（RFC）は、Problemを解決するために新規・強化・アップグレードされたハードウェア、ソフトウェア、プロセス、またはインフラストラクチャが必要な場合、Problem Managementライフサイクルの中でしばしば発生します。

その他の主要なITILプロセスの関係：

• Configuration Management
• Service Level Management
• Availability Management
• Capacity Management
• Event Management
• Service Validation and Testing

Problem Managementの役割と責任

明確に定義された役割と責任は、Problem Managementプロセスを効果的に実行するために不可欠です。Problem Managementチームは以下のメンバーで構成されています：

1) Problem Manager

Problem Managerは、他の組織的役割を担う場合もあれば担わない場合もある、指定された担当者です。Problem Managementプロセスのオーナーとして、以下を含むすべての調整業務を担います：

• Problem解決を担当する担当者との連絡窓口としての役割
• ProblemがSLA内で解決されることの確認
• Known Error Database（KEDB）のオーナーシップと管理
• Problemのクローズ
• Major Problemレビューの調整

注記：Problem ManagerとIncident Managerは、実行上の焦点において潜在的な利益相反が生じる可能性があるため、同一人物が担当すべきではありません。

2) 問題解決チーム

Problemの解決は、社内の技術サポートチームメンバー、または外部のサプライヤーやベンダーが担当する場合があります。深刻なまたは重大なProblemが発生した場合、Problem Managerは特定の専門知識を持つリソースで構成された専任のProblem Managementチームを編成することがあります。

Problem Management ソフトウェアの機能チェックリスト

Problem Management機能を備えたProblem Managementソフトウェアおよび/またはITサービス管理スイートを評価しているIT組織にとって、以下の機能は主要なプロセスを効果的にサポートするうえで重要、あるいは不可欠です。

最低限、Problem Managementソフトウェアは管理者が以下を実行できるようにする必要があります：

• 問題プロセスの設定
• Incidentカテゴリー分類の設定
• Problemレコードの作成、変更、解決、クローズ
• ITILまたはその他の業界ベストプラクティスフレームワークの実装+
• Problem更新/クローズ時に関連するすべてのIncidentsのステータスを自動更新またはクローズ
• ProblemをCI、Incidents、および変更要求に紐付け
• Problemへの影響度と緊急度の割り当て
• ProblemとKnown Errorの区別
• 個人またはチームへのタスクの自動または手動割り当て
• 監査ログへの履歴データの自動記録
• 各Problemレコードに関連付けられた一意のレコード番号の生成
• Incident、Change、Configuration、ナレッジ管理との統合
• ビジネスルールとSLAに基づくProblem作成の自動化
• ProblemsおよびKnown Errorsに関連するナレッジ資産の文書化と管理
• Problemレコード内から影響を受けるCIの表示
• 作業時間のトラッキング
• サードパーティのナレッジベースとの連携
• フリーテキスト、ドロップダウン、日時、添付ファイル、スクリーンキャプチャを含む柔軟なフィールド設定の使用
• 繰り返し発生するProblemのテンプレート作成
• 解決策、ワークアラウンド、Known Errorの検索
• 根本原因分析の文書化
• Problem検索およびレポート機能