コラム

こんにちは、デジタルビジネスのシステム運営に関するコンサルティングを担当している河村です。
前回に続き、インシデント管理プロセスを実施する際のポイントについて書きます。
前編はこちら

重大インシデントと通常インシデントでプロセスフローを分ける：
インシデントには、サービス中断に至るクリティカルなもの（重大なインシデント）もあれば、冗長化しているサーバの一つが壊れただけでサービス品質にあまり影響のないもの（通常のインシデント）もあります。これらの対応に同じプロセスフローを適用すると、重大インシデント発生時のサービスレベル要件に引きずられて非効率になったり、通常インシデント発生時のサービスレベル要件に対応がとどまりユーザーの満足度が下がったり、といった問題が起こります。
重大インシデントと通常インシデントの分類基準を明確化したうえで、これらの対応プロセスフローを分けて標準化することがポイントです。重大インシデント発生時の対応には、通常インシデント発生時の手順に加え、以下を定義するとよいでしょう。

• 影響範囲や復旧時間に関するユーザーアナウンスの手順、頻度、実行責任者、承認者
• 社内関係者への状況報告の実施手順、頻度、範囲
• 事後のお詫び対応の実行有無を判断する手順、実行責任者、承認者

サービスレベル要件との整合性を確保する：
デジタルビジネスのITシステムでは多くの場合、高いサービスレベルが求められます。しかし、本来求められるサービスレベルに対して実態があっておらず、求められるサービスレベルを満たせなかったり、過剰なコストを払っていたり、といったことがよく見られます。以下に、その例を記載します。

• 本来は24時間365日のサポートが求められるにもかかわらず、一部の作業を社員が実施しているため、夜間や休日は十分な対応ができない（ストレスもたまる）
• 本来求められるサービスレベル以上のサポート体制でベンダーと契約しており、過剰なコストを支払い続けている
• 24時間365日のサポート体制でベンダーと契約しているが、休日夜間問わず復旧作業の承認を必ず社員が行う手順になっているため、そこがボトルネックとなり実態はベストエフォート対応にとどまっている

こういったことを起こさないためには、求められるサービスレベル要件を定義したうえで、それに準じた契約をベンダーと結ぶ、社内の体制がボトルネックとならないよう手順化や権限移譲を進める、といった対応を行うことが有効です。

問題管理へのエスカレーション基準を定義する：
インシデント管理だけをいくら頑張っても、品質は上がりません。問題管理へとつなげ、恒久対応・再発防止を徹底しなければ、いつまでたっても楽になりません。担当者の意識に左右されないよう、どういう場合に問題管理へとエスカレーションするのかを明確化したうえで、それが徹底されているかどうかをモニタリングできるようなプロセスフローとツールを整備する必要があります。また、徹底状況を常に確認し、指導や是正処置を推進することに責任を持つ問題管理マネージャーを任命することも有効です。

KPIでパフォーマンスチェック：
定義したプロセスフローや基準が有効的・効率的に機能しているかどうかを評価し、改善を推進することが、継続的なプロセスの強化につながります。例えば以下のKPIを設定し、ツールから実績データをとれるようにするとよいでしょう。

• インシデント発生から初動までのリードタイム（早いほどビジネス影響を小さくできる、ベンダーのパフォーマンス指標の一つ）
• インシデントの一次解決率（同じようなものが何度もエスカレーションされるようなら、ナレッジ共有が不十分）
• 復旧までの時間（短いほど、ビジネス影響を小さくできる）
• 再発インシデント数（再発しているようなら、問題管理が不十分）