問題管理プロセス 根本原因

問題管理プロセス 根本原因

問題管理とは何ですか?具体的にどのようなプロセスがありますか?

問題管理プロセス 根本原因

問題管理とは?

システムの現場における「問題管理」とは、予期せぬ自体「インシデント」の原因となる要素を突き止め、分析を行ない、再発防止を試みるプロセスを指します。ユーザーにとって信頼できるサービスを提供し、品質を維持するためには非常に重要な取り組みです。

インシデントに対応する「インシデント管理」とはしばしば混同されますが、本来は分離して考えるべきものです。インシデント管理はトラブル発生の都度に行う「応急処置」、問題管理はインシデントそのものを避けるための「恒久対策」に当たります。

ユーザーがサービスを利用できる状態に普及した時点でインシデント管理はクローズしますが、問題管理はその後も原因を究明・是正するまで続きます。インシデント発生時はユーザーに配慮し、インシデント管理を有線して行うことになります。このように、インシデント管理と問題管理を分離して考えることが重要です。

問題管理が動き始めるきっかけは?

問題管理はサービス・システム運用において定型的に発生する業務ではありません。きっかけとなる事象として、大きく分けて3つ存在します。それぞれについて詳しくお話しましょう。

・未経験のインシデント発生時

過去に起こったことのないインシデントは、最もたる問題管理の対象です。同様のインシデント再発を防ぐため、根本的な原因の究明に注力する必要があります。問題管理では、最もスタンダードなケースと言えるでしょう。

・解決済みのインシデント発生時

解決済みと思われていた過去の例と同じ、もしくは類似したインシデントが再度発生した場合、過去の問題管理が根本原因の是正にいたっていなかったことを意味します。その場合は、再度原因究明・解決に向けた取り組みが必要です。

・過去の分析結果から何らかの傾向がわかった場合

集積されたインシデントのデータには、問題管理のきっかけとなる何らかの傾向が秘められていることがあります。インシデント自体がきっかけとなる上述した2つのケースに対し、こちらは能動的な分析がきっかけです。

問題管理における解決までの3つのプロセス

問題管理は一般的に、以下の3つのプロセスで進行します。

・インシデントの記録・分類

問題管理において「問題」として認識されるのは、インシデントを引き起こした原因を特定不能な場合です。この認識後、対応漏れを防ぐ意味を込めて、発生日時やインシデント内容の報告者について詳細に記録しておきます。

・インシデント内容の調査・分析

「問題」の認識後は、問題管理の本筋である原因を究明するフェーズです。問題が単独の場合は、すぐに原因究明に取り組めますが、複数発生している場合はあらかじめ分類し、優先順位にもとづいて着手する必要があります。

・解決策実施

根本的な解決策が見つかり次第、適応します。また、問題管理の性質上、同様のインシデントと防ぐために発生経緯や解決までの道のりをナレッジとしてまとめておくことが大切です。ナレッジの記録までを終えて、はじめてひとつの問題管理がクローズしたことになります。

問題管理は「再発防止」が重要

インシデント管理がユーザーの目線にたち、サービス・システムの迅速な復旧を目指すのに対し、問題管理において重要視されるのはインシデントの「再発防止」です。その都度の原因究明、解決はあくまで前提と言えます。

インシデントの再発防止を実現するためには、発生時から解決までの詳細な情報をログとして残しておくことが重要です。過去の問題管理のデータが、新たな問題解決に役立つケースもあります。

問題管理のデータベースは「問題管理台帳」と呼ばれており、情報が一元管理できるかたちでまとめられています。また、問題管理担当に問題の削減目標を数値で求める取り組みも一般的なようです。

まとめ

問題管理、またインシデント管理への理解を深めていただけたのではないでしょうか。システムをインシデントがまったくない状態で維持することは困難ですが、問題管理によって限りなくインシデントの数をゼロに近づけることはできます。

また、ユーザーへとシステムを利用できる状態で速やかに戻すためにも、インシデント管理と問題管理を混同せず、分離して考えることは重要です。問題管理では、その場の原因究明・問題解決策の実施異常に、その後の再発防止を目的として情報の記録が求められます。社内利用システムにおいても、インシデントがもたらすビジネスへの悪影響を最小化するため、インシデント管理と問題管理に注力することが大切です。

問題管理プロセス 根本原因

システム運用担当者さま必見!お役立ち資料

今の運用現場には、多くの悩みを生む「負のスパイラル」があります
「システム運用、負のスパイラルから脱却するには」
システムの維持保守をするだけで手一杯なのに要求は増えるばかり。でもコスト削減で体制は増強できないから改善が進まない。そんな負のスパイラルから抜け出すヒントをまとめた資料です。

問題管理プロセス 根本原因

【このコラムの著者】

ReSM(リズム)サービス担当

ReSMサービスはシステム運用の「 {re} design 」をコンセプトに、 「最適な運用」を「最適な価格」でご提供するマネージド・サービス・プロバイダーです。 クラウドの導入支援から安心の運用監視・保守までをトータルでご提案できます。
>>ReSMのサービス内容はこちら

関連サービス

  • 問題管理プロセス 根本原因

    システム運用監視サービス

    24×365の障害対応を最適なコストで。運用整理から任せて安心の運用代行サービス

  • 問題管理プロセス 根本原因

    クラウド導入支援

    AWS・Azure環境の導入をフルサポート。ハイブリッドクラウドにも対応!

インシデントの根本原因を突き止める

問題管理プロセス 根本原因

今回はITILのサービスサポートにおける6つの運用プロセスの3つ目、「問題管理」をご紹介します。
問題管理はインシデント管理と混同されることもありますが、問題管理はあくまで原因究明を目的としたプロセスで、ITサービスをいかに迅速に復旧させるかを目的としたインシデント管理とは異なります。インシデントの根本原因を突き止め、再発を完全に防止するのが、問題管理の役割なのです。

問題管理にはある程度時間がかかります。再発防止策を施すためですが、するとインシデントを素早く解決し業務を続行することを支援するインシデント管理とは利害が対立する可能性があることがわかりますね。ITILの目的はサービスマネジメントを最適化することですから、ビジネスに対する影響を最小限に抑えることが必要です。このため、問題管理とインシデント管理の担当者は別に配置し、うまくバランスを取っていくことが重要だと言われています。

問題管理の4つのプロセス

問題管理プロセスの主要な活動は4つあります。

  1. 問題の記録・分類
  2. 問題の調査・診断
  3. エラー制御
  4. 問題のクローズ

インシデントの発生をもたらした根本原因が不明な場合は、インシデントが解決されたとしても「問題」として認識されることになります。問題が認識されたら、発見された問題を放置しないために発見者や関連するインシデントの情報などを記録・分類しておくことが必要です。

分類においてはビジネスに対するインパクトと緊急度などを要素として考え、優先度を決定します。これは、対応が必要なものが複数ある場合に備えるためです。より優先度の高い問題から調査を開始し、根本原因を究明します。根本原因が判明した問題は「既知のエラー」として識別されます。

既知のエラーも記録しておき、恒久的な解決策を施し、再発防止を目指します。この時、恒久的な解決策も記録しておきます。問題の発生経緯なども含め、基本的な事項を詳細に記録しておくことで、次に同じようなインシデントが再び発生したとしても、迅速な解決が可能になります。既知のエラーが完全に解決されたことを確認したら、問題をクローズします。

問題管理はすでに発生したインシデントへの対策ですから、基本的に受身な活動です。しかし、ベンダーが提供する情報を基にしたり、インシデントのトレンド分析を行うなど、将来発生するであろうインシデントを予防する活動をしておくと、インシデントそのものの数を減らすことができます。そのため、「積極的な問題管理」こそが問題管理の真髄とも言えるでしょう。

問題管理の業務

問題管理の業務は以下の4つに分類されます

  • 問題の識別と記録
  • 問題の分類と優先度付け
  • 問題の調査と解決
  • 既知のエラーに関する記録の作成

① 問題の識別と記録

まずは、組織が抱える「問題」を洗い出し、記録・管理します。

ヘルプデスクに寄せられるサービス要求やインシデントのなかには、頻発しているインシデントや業務に重要な影響を与える可能性のあるインシデントもあります。

再発を防ぐために、これらを解決すべき「問題」として扱い、順次対処するために記録していく業務です。

② 問題の分類と優先度付け

全ての問題を一度に解決することは困難なため、内容をもとに問題を分類し、業務に与える影響や緊急度を考慮して優先度を決定します。

③ 問題の調査と解決

優先度の高い問題から調査を開始し、根本原因を特定後、問題解決のための適切な対応を決定します。

問題解決のプロセスには、コストや解決までの時間を考慮して、一時的な回避策をとる場合と、恒久的な解決策をとる場合があります。

④ 既知のエラーに関する記録の作成

ITILにおいて「既知のエラー」とは、「根本原因と回避策・解決策が文書化された問題」を指します。

解決された問題の根本原因と回避策・解決策を、既知のエラーとして記録しておくことで、問題が再発して再度インシデントを引き起こした場合でも、対応までの時間を大幅に削減できます。

問題管理プロセスの目的は?

問題管理プロセスは、インシデントの根本原因を特定し、インシデント及び問題の影響を最小化又は回避することを目的とするプロセスです。

サービスマネジメントにおける問題管理プロセスの目的はどれか。?

問題管理プロセスは、インシデントや障害発生の根本原因を突き止め、インシデントの再発防止のための恒久的な解決策を提示することを目的とするプロセスです。

問題管理の目的は?

インシデントを起こした原因を管理する「問題管理問題管理は発生したインシデントの根本原因(問題)を究明し、恒久的な対応策を実施することを目的としています。 この活動により、既知の問題に起因するインシデントの再発を防止するとともに、予防に限界があるインシデントによる悪影響を最小限に抑えます。

問題管理のメリットは?

問題管理のメリットとは.
解決までの時間を短縮 現在のインシデントの背後にある問題を明らかにするチームは、将来的にインシデントにより上手く対応できるでしょう。 ... .
コストのかかるインシデントを回避 ... .
生産性の向上 ... .
チームによる根本的な原因の特定と学習を実現 ... .
継続的なサービス改善を促進 ... .
顧客満足度を改善.