問題管理とは

問題管理とインシデント管理の比較

ITIL は、問題を 1 つ以上のインシデントの原因、または潜在的な原因と定義しています。効果的なインシデント管理と効果的な問題管理の背景にある行動は、多くの場合、類似しており重複していますが、重要な違いがあります。たとえば、最近のデプロイをロール バックすると、サービスが再稼働してインシデントが終了することがありますが、根本的な問題は残ります。

当社はそのため、問題管理とインシデント管理のプラクティスの関連性がますます深くなっていると考えています。インシデント間の時間に、IT チームは改善とサービス品質の向上につながる問題の調査に集中できます。このようにして、問題管理が組織にとって非常に重要になります。

問題管理と変更管理

変更管理とは、サービスの中断やダウンタイムなしに変更を計画、追跡、リリースするプロセスです。

変更によって中断またはダウンタイムが発生した場合、その変更はインシデント管理および問題管理のプロセス中に分析されます。

問題管理とナレッジ マネジメント

ナレッジ マネジメントは、ソリューションと一般的な手順やインシデントの回避策のドキュメントのリポジトリを作成します。適切なナレッジ マネジメント プラクティスを併用することで、インシデントの解決を迅速化してインシデントを減らせます。

問題管理とサービス リクエスト管理

サービス リクエスト管理は、アプリケーション、ソフトウェアの拡張、情報へのアクセスなど、提供されるものについてのユーザーからの要求を処理する手法です。サービス リクエストとインシデントは、区別することが困難な場合があります。実際、2007 年に ITIL V3 がリリースされるまでは区別されず、「インシデント」のカテゴリにまとめられていました。ITIL では、インシデントを「IT サービスの予期しない中断または IT サービスの質の低下」と定義しています。そこでは、サービス リクエストは、「情報または助言の要求、パスワードのリセットの要求、新しいユーザー用のワークステーションのインストールの要求など、ユーザーからの正式な要求」と定義されています。

事後的な根本原因分析に頼るのを避ける

インシデントや問題が 1 つの根本原因から発生していることは稀です。最良のチームは、すべての潜在的な要因を総合的に考慮し、誰も責めることのない分析を実践します。

問題が共有されるオープンな環境作りを推進する

問題分析とインシデント分析は、チーム メンバーが罰や報復を恐れることなく、事実を共有することが推奨されているオープンな対話でなければなりません。

重要なサービスに集中する

組織に最大の価値を提供するサービスに影響する問題への対処を優先します。

質問する際に「5 つの Why」を使う

多くのチームが、トヨタ生産システムの考案者である大野耐一氏による「5 つの Why」という技法を駆使することで、成功を収めています。詳しくは、Atlassian Team Playbook をご覧ください。

ナレッジを広める

オープンなチームは、同僚や隣接するチームの学びのためのナレッジと知見を共有します。

学習する組織になる

効果的な問題管理に終わりはありません。最もパフォーマンスの高い組織でさえ、インシデントが発生します。真の世界クラスのチームとは、プロセスを常に繰り返して改善し、同僚や顧客に対する問題の影響を軽減するチームです。

フォローアップを追跡する

フォローアップ行動を適切に把握するために、明確で標準化された方法を開発することが重要です。常に問題管理を実践する必要があるため、ITSM ソフトウェアを使用することが重要です。これによって、チームはタスクの優先順位を決めて進捗を追跡し、インシデントの課題と問題を関連付けられます。