インシデント管理: プランの立て方 (+7 件のベストプラクティス)
これまでプロジェクトにおいて作業を中断せざるを得ない事態に見舞われ、その結果プロジェクトに混乱が生じた経験はありますか？残念ながら、多くの人がそんな状況を経験しています。しかし幸いチームの生産性を犠牲にせずにこのような問題をリアルタイムで解決する方法があります。
インシデント管理は、プロジェクトを中断させる事象をできる限り迅速に分析し、是正するためのプロセスです。つまりインシデント管理をうまく行うことでプロジェクトの完了はもちろん、大事な仕事に費やせる時間を増やすことができます。
この記事では、プロジェクトで今後インシデントが発生した場合に万全な対応ができるように、インシデント管理のプロセスに加え、実際にインシデント管理を導入する際のベストプラクティスを解説します。
インシデントとは
インシデント (Incident) とは、業務やサービスの正常な運用を妨げる、または妨げる可能性のある予期しない事象を指します。IT サービスマネジメントの領域では、システムの停止、サービス品質の低下、セキュリティ上の脅威など、ユーザーの業務継続に悪影響を及ぼすできごとを広くインシデントと呼びます。
IT 運用におけるインシデントの具体例
IT システム運用の現場では、以下のような事象がインシデントに該当します。
社内システムのフリーズや応答遅延
ネットワーク接続の中断
業務アプリケーションへのログイン不能
メールの送受信停止
ライセンスエラーによるソフトウェアの使用不可
セキュリティインシデントの例
情報セキュリティの観点では、以下のような事象もインシデントとして管理する必要があります。
不正アクセスの検知
マルウェア感染
個人情報や機密データの漏洩
フィッシングメールの受信
USB メモリなど記録媒体の紛失
インシデントを放置すると、業務の長期停止、顧客からの信頼喪失、損害賠償の発生など、ビジネスに深刻な影響を及ぼす可能性があります。そのため、インシデントを早期に検知し、迅速に対処するための仕組みが不可欠です。
インシデント管理とは何か？
インシデント管理とは、インシデントの発生時に、できる限り迅速にインシデントを検知し、調査し、それに対応するプロセスを指します。インシデント管理は必ずしも恒久的な解決策ではないものの、プロジェクトを期日または期限にできる限り近い期間内に完了するために重要な役割を果たします。
インシデント管理はどのようなチームにおいても実施可能ですが、IT チームではリリース管理と並行して使用されるため、IT インフラストラクチャライブラリ (ITIL) インシデント管理と呼ばれることがあります。
プロジェクトマネージャーは、プロジェクトの進行中にインシデント管理を行うことでリスク事象によるタスクの中断を防ぎます。インシデント管理は、インシデントを効率的かつ適正に解決するための 5 つのステップから成るプロセスを用いて行われます。
インシデント管理と問題管理の違いについては混乱が生じやすいので、双方を比較し、その相違点を学びましょう。
問題管理とインシデント管理の違い
問題管理とインシデント管理を区別する要素はいくつかありますが、その中でも際立つ重要な違いが 1 つあります。それは、問題管理がプロジェクトにおけるリスクの根本原因を是正するプロセスであることに対し、インシデント管理ではプロジェクトを中断する要因を緊急措置で是正することです。
この違いは、次のシンプルな例えでイメージしやすくなります。インシデント管理が傷口に貼るばんそうこうであれば、問題管理はそこに塗る軟膏です。双方とも傷口を保護するために大事な役割を果たしますが、その目的は異なります。
両方のシステムが必要ですが、それらの効果は異なり、プロジェクトのライフサイクルの異なる時点で実施されます。インシデント管理はインシデントの発生時に実施するのに対し、問題管理ではその再発を防ぐために事後に根本原因の解消を図ります。
インシデント管理とは何か？
インシデントの定義は「混乱の原因となる単一の事象」です。そういった場合には、その事象が問題化する前にインシデントを管理するための緊急対策が必要になります。
以下にインシデントを見分けるための主要な特徴をいくつか紹介します。
インシデントは偶発的な単一の事象です。
インシデントは、予定外の中断を生じさせる事象です。
インシデントはリアルタイムで迅速に解決されます。
簡単にいえば、インシデントは迅速に解決される単一の事象です。
問題管理とは何か？
問題の定義は「1 つ以上のインシデントを引き起こす要因」です。その根本原因を解決するための分析は一定の期間をかけて行われます。
問題の主要な特徴を以下に一部紹介します。
問題は複数の類似する事象の結果として発生します。
問題は会社の業務を中断させます。
問題は一定期間を経て根本原因を解消することを通じて解決されます。
簡単にいえば、問題は複数の事象の結果として発生するもので、一定期間を経て解決されます。
インシデント管理が必要な理由とメリット
インシデント管理を体系的に実施することで、組織は以下のメリットを得られます。
業務影響の最小化
インシデント発生時に迅速な初動対応ができれば、サービス停止時間を短縮し、業務への影響を最小限に抑えられます。対応が遅れるほど影響範囲は広がり、復旧コストも増大します。
対応の標準化と属人化の防止
対応手順を明文化し、エスカレーション基準を定めることで、担当者によって対応品質にばらつきが出ることを防げます。誰が対応しても一定の水準を保てる体制は、チームの安定した運用に直結します。
顧客信頼の維持
迅速かつ誠実なインシデント対応は、顧客満足度の維持やブランド価値の保護につながります。対応の遅れや不透明さは、顧客離れや社会的信用の失墜を招きかねません。
再発防止とナレッジの蓄積
インシデント対応の記録を蓄積し、振り返りを行うことで、同様の事象の再発を防ぎ、組織全体の対応力を継続的に向上させられます。
ITIL におけるインシデント管理
ITIL (Information Technology Infrastructure Library) は、IT サービスマネジメントのベストプラクティスを体系化したフレームワークです。ITIL では、インシデント管理を「IT サービスの中断による影響を最小限に抑え、可能な限り迅速に通常の運用状態へ復旧させるプロセス」と定義しています。
ITIL に基づくインシデント管理プロセスは、以下の 7 つのステップで構成されます。
インシデントの識別: ユーザーからの報告や監視システムによる検出
インシデントの記録: すべてのインシデントを記録し、追跡可能にする
分類と優先度設定: 種類や影響度に基づき分類し、対応の優先順位を決定
初期診断: サービスデスクによる初期対応と問題の特定
エスカレーション: 必要に応じて上位サポートや専門チームへ引き継ぐ
解決と復旧: 問題の解決とサービスの正常化
インシデントのクローズ: ユーザー確認後、インシデントを正式に終了
IT 環境が複雑化する現在、ITIL に基づくインシデント管理は、組織の IT 運用の安定性を確保する上で重要な指針となっています。
インシデント対応計画の 5 つのステップ
インシデント対応計画 (インシデント管理計画) は、5 つの重要なステップから成ります。これらのステップから成るインシデント管理のライフサイクルに基づいて、チームはプロジェクトのさまざまなリスク事象を追跡し、それらに対応できます。これは変更管理プロセスと少々似ていますが、変更管理プロセスとの主な違いは対象がプロジェクトの変更ではなく重大なインシデントであるという点にあります。
インシデントの特定から、優先度の設定、その後の対応までの各ステップを実施すれば、インシデントのプロセス全体を通してスムーズに進めることができます。効果的なインシデント対応計画がない場合、プロジェクトが重大な問題に陥るリスクがあります。
IT チームや DevOps チームでは、業務が技術的であるために、このリスクが特に問題化しやすくなります。このことはインシデント管理が最も浸透しているのが IT サービス管理部門である一因でもあります。
インシデント対応計画は 5 つのステップから成ります。
インシデントを特定する
インシデントをカテゴリに分類する
インシデントの優先度を設定する
インシデント対応を実施する
インシデントを完了する
以下に効果的なインシデント管理システムの 5 つのステップ、問題を発生時に発見し、解決する方法、そしてその際にリソースの割り当てを実施する方法について、詳細を解説します。
1. インシデントを特定する
インシデント対応計画の最初のステップは、インシデントを特定することです。プロジェクトの問題は、社内プロジェクト、業者関連のプロジェクト、顧客向けプロジェクトなど、あらゆる種類のプロジェクトのあらゆる段階において発生する可能性があります。特定したインシデントの情報は、後のステップで行うインシデントの優先順位付けに影響する場合があります。
インシデントを特定する際には、以下の情報を含める必要があります。
名称または ID 番号
内容説明
日付
インシデントマネージャー
上記の各項目は、特に問題管理計画がある場合には、参照用に記載しておけば後で役に立ちます。そうすることで、根本原因を突き止め、再発を防ぐことができます。
2. インシデントをカテゴリに分類する
インシデントを特定したら、続いてカテゴリに分類します。カテゴリに分類すべき理由には、問題を特定しやすくなること、適切なチームに割り当てられることなど、さまざまなものがあります。インシデントを迅速に特定できればできるほど、プロジェクトの作業に早く戻れます。
カテゴリ名には、問題に関連するトピックを大まかに表す言葉や関連キーワードを使いましょう。たとえば、開発の問題に関連するソフトウェアのバグに遭遇した場合には、シンプルに「開発」と分類できます。もっと詳細に分類するために、「開発バグ」などといったサブカテゴリに分類するチームもあります。
インシデント管理のカテゴリについて厳格なルールは特にないので、チームによる問題の特定を簡単にする分類法を考えましょう。
3. インシデントの優先度を設定する
インシデントを特定し、分類したら、続いてインシデントの優先度を設定します。プロジェクトにおけるインシデントを重要度に基づきランク付けする際には、以下の大事なポイントを考慮しましょう。
まず、優先度を設定する上で比較対象となる他のインシデントがあれば、それらも含めて検討する必要があります。その際には、各インシデントの影響を評価します。インシデント管理の主要な目的は問題のすばやい解決であるため、長期的な影響よりも短期的にすぐに効果が得られる問題の解決を重視する必要があります。
また、インシデントの優先度は、プロジェクトにおいて完了を要するタスクと比較した上で設定する必要があります。インシデントが目前の成果物よりも重要か否かを検討しましょう。重要度が劣る場合には、チームメンバーの手が空くまで解決を待つ余裕があるか考えてみましょう。上記の優先度設定要因を両方とも検討し終えたら、まずは優先度の高いインシデントから対応を始めます。
4. インシデントへの対応を実施する
インシデントへの対応時には、問題を診断するために分析を実施した上で、インシデントを解決する段階に移ります。ほとんどの問題は何らかの形で解決する手段がありますが、解決法がない場合には、適切な部門統括者のサポートを得て問題のエスカレーションを行う必要があるかもしれません。そのような場合、インシデントを解決するために、トラブルシューティングや効果的な次善策が必要になることがあります。
インシデントを分析して根本原因を発見したら、対応計画に対してリソースや成果物を割り当て、担当者に委任する段階に移ります。これはインシデント記録やワークマネジメントソフトウェアを用いて行うことができます。どの方法を使う場合にも、インシデント対応計画に参加するメンバーか否かに関わらず、すべての関係者に対して計画に関する報告を行う必要があります。それにより、プロジェクトが可視化され、透明なコミュニケーションを実現できます。
インシデント管理を行えば問題を未然に防げるものの、インシデントの解決を進める最中に問題に直面する場合もあります。そのような場合には、根本原因分析を行いたいという思いにかられるかもしれません。しかし、その原因分析は適切な問題管理計画に基づき実施できるタイミングまで待つ必要があります。これを守れば、インシデントをリアルタイムでできる限り迅速に是正し、プロジェクトの遂行を再開できます。
5. インシデントを完了する
インシデント記録の最終段階においては、インシデント対応の成果物を完了させます。上記のステップで作成した文書は、今後参照できるよう、すべて共有のワークスペースに保管しましょう。共有のハードドライブやデジタルのプロジェクトフォルダなど、どんな保管形式でも構いません。
情報を保管するほか、インシデント対応の成果物を適切に遂行できたか、未完了のタスクを完了する前に確認する必要があります。チケットシステム、サービスデスク、サービスリクエストなど、その遂行手段に関わらず、未解決の依存関係が残っていないことを確認しておくと安心です。すべてのタスクを完了したら、インシデント対応計画を正式に終えることができます。
プロジェクトを振り返る会議の際には、プロジェクト中に発生したインシデントも振り返るとよいかもしれません。これはプロジェクトの問題管理の段階に移行して根本原因の解決に取り組むよい機会となると同時に、より効果的な会議を促進します。
インシデント管理の 7 つのベストプラクティス
インシデント対応計画の要素を理解したら、次はインシデントの記録を作成しましょう。初めての記録作成は、プロジェクトやチームの種類によっては難しい場合もあります。しかし下記のベストプラクティスとインシデント対応記録例を参考にすれば、インシデント発生時に記録を記録し、適切な対応を行えます。
インシデントの記録を作成する際には、以下の記録例を参考にしてください。
インシデント管理の主要なベストプラクティスの一部には、記録を整理された状態に保ち、チームの研修とコミュニケーションを適切に行い、プロセスを可能な限り自動化することが含まれます。それでは、インシデント管理の 7 つのベストプラクティスの解説に入ります。
1. 早期かつ頻繁に特定する
インシデントの発生を記録することは、簡単に思えるかもしれませんが、早期に問題を特定することもその要件に含まれます。インシデントの発見は一筋縄ではいかない場合もありますが、早期に診断できればできるほど、結果的に対処しやすくなります。
一番よい方法は、プロジェクトの問題を調査する時間をできる限り頻繁に予定することです。それにより、どのような問題が生じているのか、そして本格的なインシデントに悪化するリスクがあるのはその内のどれかを正確に把握できます。
ヒント*: インシデントを特定したら、必ずインシデント記録に記録しましょう。*
2. 仕事の整理整頓を心がける
整理整頓はプロジェクト管理のあらゆる段階において不可欠ですが、特に長期的な影響をもたらす問題を記録する場合には特に重要です。そのため、頻繁に情報を整理し、記録は簡潔に留めることがポイントとなります。
インシデント対応記録に情報を追加するためのスペースが足りない場合には、より詳細な対応を記録するための外部スペースに連携することを検討しましょう。また、チームがブレーンストーミングのテクニックを使用して問題の解決策を探る際には、会議の議事録も添付する必要があるかもしれません。
ヒント*: 文字数の基準を定めることで記録内容を簡潔に保てます。また、依存関係にあるタスクを完了していくことで、情報が整理された状態を維持できます。*
3. チームを教育する
インシデント管理についてよく知らないチームも多いでしょう。そういった場合はチームにある程度説明する必要があります。
正式なトレーニングは必ずしも必要ありませんが、チームメンバーが関わるインシデント管理体制や問題化する可能性があるリスクの種類について、チームに対し説明しておくことをおすすめします。それにより、チームとしてインシデントを早めに検知し、未然に悪化を食い止められます。
ヒント: インシデント記録やその他必要なツールについてチームに説明する会議を開きましょう。
4. タスクを自動化する
ビジネスプロセスオートメーション (BPA) は効果的な手法なので、可能な限り実施をおすすめします。自動化は導入が難しい場合もありますが、長期的には大幅な時間の節約につながります (もちろんインシデントをより簡単に解決し、チームの負担を減らせるメリットもあります)。
ITSM ツールとも呼ばれる適切な自動化ソフトウェアを使えば、プロジェクトにおけるインシデントに自動的にフラグを立てられます。自動化はあくまでもソリューションの一要素であり、それだけでは解決に至りませんが、見過ごしやすい問題を検知するためには有効です。
ヒント*: 自動化したタスクは必ず頻繁にチェックするよう注意してください。設定後チェックせず放置すると、問題を見過ごしてしまう可能性があります。*
5. コミュニケーションは 1 つの場所で行う
コミュニケーションは、分散した状態になる場合があり、特にリモートワークの環境においてはその傾向が増します。実際、最近の調査によると重複作業により勤務時間が 30% 長くなっていることが分かっています。それを防ぐためには、チームのコミュニケーション方法を正式に定めることが非常に重要です。
最初のステップとして、まずコラボレーションを行う共有スペースを定める必要があります。多くの組織ではソフトウェアツールを活用しており、チームが長期的に時間を節約できるだけでなく、必要に応じて過去のコミュニケーションを参照しやすくなります。
ヒント: チームが使用するコミュニケーションチャネルを一つ決め、全員が同じ場所で情報を共有できるようにしましょう。
6. プロジェクト管理ツールを使用する
インシデント対応計画を作成し、管理を維持するために活用できるツールは多数あり、プロジェクト管理ソフトウェアもその一例です。
プロジェクト管理ソフトウェアを使えば、仕事やコミュニケーションの情報を整理できるだけでなく、チームとしてワークフローを構築し、目標をその達成に必要な仕事と連動させられます。これらの機能は、複数のチームが問題解決に共に取り組む必要があるインシデント管理においては、特に重要になります。コミュニケーションやタスクに関する混乱が多ければ多いほど、リアルタイムでインシデントを解決できるまでの時間が長くかかります。
ヒント: プロジェクト管理カレンダーを使用して仕事と期日を 1 つの場所で可視化しましょう。
7. 継続的に改善する
どのようなプランも、必ず長期的に継続的な改善に注力する必要があります。初めてのインシデント対応計画は試行錯誤を繰り返した後の 100 回目の計画とは異なりますが、時の経過と共に効率を向上させる方法が身に付き、インシデントを未然に発見しやすくなります。
習熟への一番の近道は実践経験を積むことですが、知識を深める方法はその他にも各種あります。たとえば、教育を継続すること、業績評価指標を追跡することによっても知識は深まります。ウェビナーに参加したり、ポッドキャストを聴いたり、ニュースレターを読んだりすることは、すべてチームと共有できる新しいアイデアの発見につながります。加えて、プロジェクトを追跡し、KPI を分析すれば、チームとしてミスから学んだことを成功につなげられます。
ヒント: 知識を深める次のステップとしてリソース管理計画を作成する方法を学びましょう。
インシデント管理のよくある課題と対策
インシデント管理を導入・運用する際に、多くの組織が直面する課題とその対策を紹介します。
対応の属人化
特定の担当者に知識や対応スキルが集中すると、その担当者が不在のときにインシデント対応が停滞します。対策として、対応手順のドキュメント化やナレッジベースの整備が有効です。
エスカレーション基準の不明確さ
いつ、誰にエスカレーションすべきかが明確でないと、対応が遅延し、影響が拡大します。インシデントの重大度に応じたエスカレーションフローを事前に定義しておくことが重要です。
対応記録の不備
インシデント対応の記録が不十分だと、事後の振り返りや再発防止策の立案に支障をきたします。対応の開始から終了まで、各ステップの記録を徹底することが求められます。
ツール間の情報分散
メール、チャット、スプレッドシートなど複数のツールで情報を管理していると、対応状況の把握が困難になります。一元的に管理できるツールの導入を検討しましょう。
インシデント対応後の振り返りと再発防止
インシデントの解決後に行う振り返り (ポストモーテム) は、同様の事象の再発を防ぎ、組織の対応力を高めるために不可欠なプロセスです。
ポストモーテムの実施
インシデントの発生原因、対応の経緯、影響範囲を整理し、チーム全体で共有します。責任追及ではなく、プロセスの改善に焦点を当てることが重要です。
ナレッジベースの構築
過去のインシデント対応事例を体系的に蓄積し、検索可能な形で整備します。これにより、類似のインシデントが再発した際に、担当者が迅速に過去の対応策を参照できます。
改善サイクルの確立
振り返りで得られた教訓をもとに、対応手順やエスカレーションルールを継続的に更新します。定期的な見直しを組み込むことで、インシデント管理プロセスの成熟度を段階的に高められます。
導入事例: インシデント管理の実践
実際の組織では、インシデント管理をどのように実践しているのでしょうか。ここでは、セキュリティインシデント対応と製造業でのリスク管理について、 2 つの事例を紹介します。
Asana のセキュリティチームでは、インシデント対応における役割分担、緊急緩和策の追跡、ステークホルダーからの質問管理、承認フローを体系的に運用しています。対応プロセスを標準化することで、チーム全体が一貫した手順でインシデントに対処できる体制を実現しました。詳細は Asana セキュリティインシデント対応事例をご覧ください。
フジテック社は、 100 以上のプロジェクトを俯瞰管理する中で、リスク管理の属人化という課題を抱えていました。ワークマネジメントツールの導入により、年間 3,200 時間の会議時間を削減し、各メンバーが自律的にリスクを把握してプロジェクトを推進できる体制を構築しました。詳細は フジテック導入事例をご覧ください。
インシデント管理の無料テンプレート
インシデント管理プロセスをチームに導入する際には、テンプレートを活用するとスムーズです。対応フローや記録フォーマットがあらかじめ用意されていれば、担当者は手順に迷うことなく、検知から復旧までを一貫して進められます。
以下のテンプレートを活用して、インシデント管理の仕組みを素早く構築しましょう。
仕事リクエスト用テンプレート: インシデント報告の受付と対応依頼を一元管理
テンプレートギャラリー: プロジェクト管理やワークフロー構築に活用できるテンプレート一覧
インシデント管理をワークマネジメントで効率化
インシデント管理の各プロセスを効果的に運用するには、チーム全体でタスクの進捗、担当者、期日を一元的に把握できる仕組みが必要です。
ワークマネジメントツールを活用すれば、インシデントの検知から対応完了までのフローを可視化し、エスカレーションの判断やチーム間の連携をスムーズに進められます。対応記録の蓄積やナレッジの共有も、一つのプラットフォーム上で完結できます。
Asana のワークマネジメント機能を活用して、インシデント管理の効率化を始めてみませんか。
Asana を無料で試す
