インシデント管理: プランの立て方 (+7 件のベストプラクティス)

これまでプロジェクトにおいて作業を中断せざるを得ない事態に見舞われ、その結果プロジェクトに混乱が生じた経験はありますか？残念ながら、多くの人がそんな状況を経験しています。しかし幸いチームの生産性を犠牲にせずにこのような問題をリアルタイムで解決する方法があります。

インシデント管理は、プロジェクトを中断させる事象を出来る限り迅速に分析し、是正するためのプロセスです。つまりインシデント管理をうまく行うことでプロジェクトの完了はもちろん、大事な仕事に費やせる時間を増やすことができます。

この記事では、プロジェクトで今後インシデントが発生した場合に万全な対応ができるように、インシデント管理のプロセスに加え、実際にインシデント管理を導入する際のベストプラクティスを解説します。

インシデント管理とは何か？

インシデント管理とは、インシデントの発生時に、出来る限り迅速にインシデントを検知し、調査し、それに対応するプロセスを指します。インシデント管理は必ずしも恒久的な解決策ではないものの、プロジェクトを期日または期限に出来る限り近い期間内に完了するために重要な役割を果たします。

インシデント管理はどのようなチームにおいても実施可能ですが、IT チームではリリース管理と並行して使用されるため、IT インフラストラクチャライブラリ (ITIL) インシデント管理と呼ばれることがあります。

プロジェクトマネージャーは、プロジェクトの進行中にインシデント管理を行うことでリスク事象によるタスクの中断を防ぎます。インシデント管理は、インシデントを効率的かつ適正に解決するための 5 つのステップから成るプロセスを用いて行われます。

インシデント管理と問題管理の違いについては混乱が生じやすいので、双方を比較し、その相違点を学びましょう。

インシデント対応計画の 5 つのステップ

インシデント対応計画 (インシデント管理計画) は、5 つの重要なステップから成ります。これらのステップから成るインシデント管理のライフサイクルに基づいて、チームはプロジェクトのさまざまなリスク事象を追跡し、それらに対応できます。これは変更管理プロセスと少々似ていますが、変更管理プロセスとの主な違いは対象がプロジェクトの変更ではなく重大なインシデントであるという点にあります。

インシデントの特定から、優先度の設定、その後の対応までの各ステップを実施すれば、インシデントのプロセス全体を通してスムーズに進めることができます。効果的なインシデント対応計画がない場合、プロジェクトが重大な問題に陥るリスクがあります。IT チームや DevOps チームでは、業務が技術的であるために、このリスクが特に問題化しやすくなります。このことはインシデント管理が最も浸透しているのが IT サービス管理部門である一因でもあります。

インシデント対応計画は 5 つのステップから成ります。

1. インシデントを特定する

2. インシデントをカテゴリに分類する

3. インシデントの優先度を設定する

4. インシデント対応を実施する

5. インシデントを完了する

以下に効果的なインシデント管理システムの 5 つのステップ、問題を発生時に発見し、解決する方法、そしてその際にリソースの割り当てを実施する方法について、詳細を解説します。

1. インシデントを特定する

インシデント対応計画の最初のステップは、インシデントを特定することです。プロジェクトの問題は、社内プロジェクト、業者関連のプロジェクト、顧客向けプロジェクトなど、あらゆる種類のプロジェクトのあらゆる段階において発生する可能性があります。特定したインシデントの情報は、後のステップで行うインシデントの優先順位付けに影響する場合があります。

インシデントを特定する際には、以下の情報を含める必要があります。

• 名称または ID 番号

• 内容説明

• 日付

• インシデントマネージャー

上記の各項目は、特に問題管理計画がある場合には、参照用に記載しておけば後で役に立ちます。そうすることで、根本原因を尽き止め、再発を防ぐことができます。

2. インシデントをカテゴリに分類する

インシデントを特定したら、続いてカテゴリに分類します。カテゴリに分類すべき理由には、問題を特定しやすくなること、適切なチームに割り当てられることなど、さまざまなものがあります。インシデントを迅速に特定できれば出来るほど、プロジェクトの作業に早く戻れます。

カテゴリ名には、問題に関連するトピックを大まかに表す言葉や関連キーワードを使いましょう。たとえば、開発の問題に関連するソフトウェアのバグに遭遇した場合には、シンプルに「開発」と分類できます。もっと詳細に分類するために、「開発バグ」などといったサブカテゴリに分類するチームもあります。

インシデント管理のカテゴリについて厳格なルールは特にないので、チームによる問題の特定を簡単にする分類法を考えましょう。

3. インシデントの優先度を設定する

インシデントを特定し、分類したら、続いてインシデントの優先度を設定します。プロジェクトにおけるインシデントを重要度に基づきランク付けする際には、以下の大事なポイントを考慮しましょう。

まず、優先度を設定する上で比較対象となる他のインシデントがあれば、それらも含めて検討する必要があります。その際には、各インシデントの影響を評価します。インシデント管理の主要な目的は問題のすばやい解決であるため、長期的な影響よりも短期的にすぐに効果が得られる問題の解決を重視する必要があります。

また、インシデントの優先度は、プロジェクトにおいて完了を要するタスクと比較した上で設定する必要があります。インシデントが目前の成果物よりも重要か否かを検討しましょう。重要度が劣る場合には、チームメンバーの手が空くまで解決を待つ余裕があるか考えてみましょう。上記の優先度設定要因を両方とも検討し終えたら、まずは優先度の高いインシデントから対応を始めます。

4. インシデントへの対応を実施する

インシデントへの対応時には、問題を診断するために分析を実施した上で、インシデントを解決する段階に移ります。ほとんどの問題は何らかの形で解決する手段がありますが、解決法がない場合には、適切な部門統括者のサポートを得て問題のエスカレーションを行う必要があるかもしれません。そのような場合、インシデントを解決するために、トラブルシューティングや効果的な次善策が必要になることがあります。

インシデントを分析して根本原因を発見したら、対応計画に対してリソースや成果物を割り当て、担当者に委任する段階に移ります。これはインシデント記録やワークマネジメントソフトウェアを用いて行うことができます。どの方法を使う場合にも、インシデント対応計画に参加するメンバーか否かに関わらず、すべての関係者に対して計画に関する報告を行う必要があります。それにより、プロジェクトが可視化され、透明なコミュニケーションを実現できます。

インシデント管理を行えば問題を未然に防げるものの、インシデントの解決を進める最中に問題に直面する場合もあります。そのような場合には、根本原因分析を行いたいという思いにかられるかもしれません。しかし、その原因分析は適切な問題管理計画に基づき実施できるタイミングまで待つ必要があります。これを守れば、インシデントをリアルタイムで出来る限り迅速に是正し、プロジェクトの遂行を再開できます。

5. インシデントを完了する

インシデント記録の最終段階においては、インシデント対応の成果物を完了させます。上記のステップで作成した文書は、今後参照できるよう、すべて共有のワークスペースに保管しましょう。共有のハードドライブやデジタルのプロジェクトフォルダなど、どんな保管形式でも構いません。

情報を保管するほか、インシデント対応の成果物を適切に遂行できたか、未完了のタスクを完了する前に確認する必要があります。チケットシステム、サービスデスク、サービスリクエストなど、その遂行手段に関わらず、未解決の依存関係が残っていないことを確認しておくと安心です。すべてのタスクを完了したら、インシデント対応計画を正式に終えることができます。

プロジェクトを振り返る会議の際には、プロジェクト中に発生したインシデントも振り返るとよいかもしれません。これはプロジェクトの問題管理の段階に移行して根本原因の解決に取り組むよい機会となると同時に、より効果的な会議を促進します。

インシデント管理の 7 つのベストプラクティス

インシデント対応計画の要素を理解したら、次はインシデントの記録を作成しましょう。初めての記録作成は、プロジェクトやチームの種類によっては難しい場合もあります。しかし下記のベストプラクティスとインシデント対応記録例を参考にすれば、インシデント発生時に記録を記録し、適切な対応を行えます。

インシデントの記録を作成する際には、以下の記録例を参考にしてください。

Asana のテンプレートギャラリーにあるテンプレートをお使いいただくか、お好みのプロジェクトを作成してみましょう。

インシデント管理の主要なベストプラクティスの一部には、記録を整理された状態に保ち、チームの研修とコミュニケーションを適切に行い、プロセスを可能な限り自動化することが含まれます。それでは、インシデント管理の 7 つのベストプラクティスの解説に入ります。

1. 早期かつ頻繁に特定する   

インシデントの発生を記録することは、簡単に思えるかもしれませんが、早期に問題を特定することもその要件に含まれます。インシデントの発見は一筋縄ではいかない場合もありますが、早期に診断できれば出来るほど、結果的に対処しやすくなります。

一番よい方法は、プロジェクトの問題を調査する時間を出来る限り頻繁に予定することです。それにより、どのような問題が生じているのか、そして本格的なインシデントに悪化するリスクがあるのはその内のどれかを正確に把握できます。

ヒント: インシデントを特定したら、必ずインシデント記録に記録しましょう。

2. 仕事の整理整頓を心がける

整理整頓はプロジェクト管理のあらゆる段階において不可欠ですが、特に長期的な影響をもたらす問題を記録する場合には特に重要です。そのため、頻繁に情報を整理し、記録は簡潔に留めることがポイントとなります。

インシデント対応記録に情報を追加するためのスペースが足りない場合には、より詳細な対応を記録するための外部スペースに連携することを検討しましょう。また、チームがブレーンストーミングのテクニックを使用して問題の解決策を探る際には、会議の議事録も添付する必要があるかもしれません。

ヒント: 文字数の基準を定めることで記録内容を簡潔に保てます。また、依存関係にあるタスクを完了していくことで、情報が整理された状態を維持できます。

3. チームを教育する 

インシデント管理についてよく知らないチームも多いでしょう。そういった場合はチームにある程度説明する必要があります。

正式なトレーニングは必ずしも必要ありませんが、チームメンバーが関わるインシデント管理体制や問題化する可能性があるリスクの種類について、チームに対し説明しておくことをおすすめします。それにより、チームとしてインシデントを早めに検知し、未然に悪化を食い止められます。

ヒント: インシデント記録やその他必要なツールについてチームに説明する会議を開きましょう。

4. タスクを自動化する

ビジネスプロセスオートメーション (BPA) は効果的な手法なので、可能な限り実施をおすすめします。自動化は導入が難しい場合もありますが、長期的には大幅な時間の節約につながります (もちろんインシデントをより簡単に解決し、チームの負担を減らせるメリットもあります)。

ITSM ツールとも呼ばれる適切な自動化ソフトウェアを使えば、プロジェクトにおけるインシデントに自動的にフラグを立てられます。自動化はあくまでもソリューションの一要素であり、それだけでは解決に至りませんが、見過ごしやすい問題を検知するためには有効です。

ヒント: 自動化したタスクは必ず頻繁にチェックするよう注意してください。設定後チェックせず放置すると、問題を見過ごしてしまう可能性があります。

5. コミュニケーションは 1 つの場所で行う 

コミュニケーションは、分散した状態になる場合があり、特にリモートワークの環境においてはその傾向が増します。実際、最近の調査によると重複作業により勤務時間が 30% 長くなっていることが分かっています。それを防ぐためには、チームのコミュニケーション方法を正式に定めることが非常に重要です。最初のステップとして、まずコラボレーションを行う共有スペースを定める必要があり、これを行うために多くの組織ではソフトウェアツールを活用しています。そうすることにより、チームが長期的に見て時間を節約できるだけでなく、必要に応じて過去のコミュニケーションを参照しやすくなります。

ヒント: インシデント記録やその他必要なツールについてチームに説明する会議を開きましょう。

6. プロジェクト管理ツールを使用する

インシデント対応計画を作成し、管理を維持するために活用できるツールは多数あり、プロジェクト管理ソフトウェアもその一例です。

プロジェクト管理ソフトウェアを使えば、仕事やコミュニケーションの情報を整理できるだけでなく、チームとしてワークフローを構築し、目標をその達成に必要な仕事と連動させられます。これらの機能は、複数のチームが問題解決に共に取り組む必要があるインシデント管理においては、特に重要になります。コミュニケーションやタスクに関する混乱が多ければ多いほど、リアルタイムでインシデントを解決できるまでの時間が長くかかります。

ヒント: プロジェクト管理カレンダーを使用して仕事と期日を 1 つの場所で可視化しましょう。

7. 継続的に改善する   

どのようなプランも、必ず長期的に継続的な改善に注力する必要があります。初めてのインシデント対応計画は試行錯誤を繰り返した後の 100 回目の計画とは異なりますが、時の経過と共に効率を向上させる方法が身に付き、インシデントを未然に発見しやすくなります。

習熟への一番の近道は実践経験を積むことですが、知識を深める方法はその他にも各種あります。たとえば、教育を継続すること、業績評価指標を追跡することによっても知識は深まります。ウェビナーに参加したり、ポッドキャストを聴いたり、ニュースレターを読んだりすることは、すべてチームと共有できる新しいアイデアの発見につながります。加えて、プロジェクトを追跡し、KPI を分析すれば、チームとしてミスから学んだことを成功につなげられます。

ヒント: 知識を深める次のステップとしてリソース管理計画を作成する方法を学びましょう。

問題管理とインシデント管理の違い

問題管理とインシデント管理を区別する要素はいくつかありますが、その中でも際立つ重要な違いが 1 つあります。それは、問題管理がプロジェクトにおけるリスクの根本原因を是正するプロセスであることに対し、インシデント管理ではプロジェクトを中断する要因を緊急措置で是正することです。

この違いは、次のシンプルな例えでイメージしやすくなります。インシデント管理が傷口に貼るばんそうこうであれば、問題管理はそこに塗る軟膏です。双方とも傷口を保護するために大事な役割を果たしますが、その目的は異なります。

両方のシステムが必要ですが、それらの効果は異なり、プロジェクトのライフサイクルの異なる時点で実施されます。インシデント管理はインシデントの発生時に実施するのに対し、問題管理ではその再発を防ぐために事後に根本原因の解消を図ります。

インシデント管理とは何か？

インシデントの定義は「混乱の原因となる単一の事象」です。そういった場合には、その事象が問題化する前にインシデントを管理するための緊急対策が必要になります。

以下にインシデントを見分けるための主要な特徴をいくつか紹介します。

• インシデントは偶発的な単一の事象です。

• インシデントは、予定外の中断を生じさせる事象です。

• インシデントはリアルタイムで迅速に解決されます。

簡単にいえば、インシデントは迅速に解決される単一の事象です。

問題管理とは何か？

問題の定義は「1 つ以上のインシデントを引き起こす要因」です。その根本原因を解決するための分析は一定の期間をかけて行われます。

問題の主要な特徴を以下に一部紹介します。

• 問題は複数の類似する事象の結果として発生します。

• 問題は会社の業務を中断させます。

• 問題は一定期間を経て根本原因を解消することを通じて解決されます。

簡単にいえば、問題は複数の事象の結果として発生するもので、一定期間を経て解決されます。

インシデント管理は成り行き任せでは成り立ちません

以上の方法を活用してインシデント管理プロセスを作成すれば、実際のプロジェクトにおけるインシデントにも円滑に対処できます。上記で解説した 7 つのベストプラクティスを実践すれば、最大限に効果的なインシデント対応計画を立て、時間とお金の両方を節約できます。

チームのワークフローを向上させる新しい方法をお探しですか？プロジェクト管理の 5 つのフェーズに関する記事をご覧ください。