インシデント解決までの時間を短縮する6つの重要ステップ

2022.10.06更新

解決までの時間とは

解決までの時間（TTR）または平均解決時間（MTTR）とは、カスタマーサービスの事例やチケットが作成されてから、解決するまでに要する平均時間のことです。お客様やユーザーがサービスに問題を感じてチームに連絡してきた場合、ダウンタイムを最小限に抑えて可能な限り最高の経験を保証するためには、MTTRを最短にすることが重要です。例えば、お客様から電話で製品に関する問題の報告があったとします。TTRはこのやりとりが行われると同時に開始となり、解決に至ると停止します。
TTRは、従業員別やインシデントのカテゴリー別に計算することで、傾向や改善すべきあらゆる領域を明らかにすることができます。お客様ができるだけ中断を受けずにサービスを適切に利用できるように、問題の解決に要する時間を最小限に抑えることを常に目標とすべきです。

「インシデント解決までの時間を短縮するにはどうすればいいんだ？MTTRの数値が足を引っ張っている！」

もしあなたが、この疑問を空に向かって叫んでいるとしても、それはあなただけの問題ではありません。これは慢性的なサポートの問題なのです。インシデント解決までの時間を短縮するにはどうすればいいのでしょうか？結論から言うと、非常に効果的で実用的な方法がいくつかあります。この記事では、その方法をご紹介いたします。

指標、指標、指標

何よりもまず、インシデント解決を評価するために使用される指標について理解し、その指標のどの側面が重要かを決定することが大切です。

解決までの時間にとって最も重要な指標は、もちろん、MTTR（平均解決時間）です。この指標は、分かりやすい簡潔な数値にすべてを凝縮したものであるため、経営陣が好む指標のひとつです。しかし残念なことに、そうした数値は単純すぎて、重要な情報が排除されており、ほぼ無意味な平均値でしかないことがあります。

全体的なMTTR（すべてのインシデントを対象としたもの）は、データに影響を与える異常値がそれほど多くなく、釣鐘曲線の下にうまく収まる広範囲のインシデントに基づいているのであれば、信頼できる指標になります。しかし、２つの異なるインシデントが存在し、それぞれの解決時間が大きく異なっているとしたら、そのMTTRに基づいた判断は誤っている可能性があります。広範囲の釣鐘曲線は異常値を含むことが多いため、システム全体のMTTRは良い指標ではないかもしれません。

指標を選べるとしたら、全体的なMTTRの代わりとなるものは何でしょうか？次にいくつかご紹介します。

インシデントクラスごとにMTTRを区別：
インシデントを特定のクラスに分類できる場合、各クラスに別々のMTTRを使用することができます。これは、関係するインシデントを無理なく異なるクラスに分けられる場合にとても有益です。しかし、次の会議で良いMTTRの数字を見せたいがために、人為的にインシデントのクラス分けをしないようにしましょう。
解決された割合：
目標時間内に解決された割合や、制限時間後も未解決になっている割合を調べることもできます。これにより、目標に対する解決時間が測定できるため、目標達成に向けたインシデント管理の手法を調整することができます。
インシデント総数と累積インシデントタイム：
しかし、MTTRや目標解決時間の数値を意味あるものにするには、一定期間のインシデント総数と累積インシデントタイムを考慮する必要があります。なぜでしょうか？以下の表Aをご覧ください。２つの異なるIT部門が、同じ方法でインシデントのモニタリングと測定を行っています。インシデントが目標時間を超過した割合とMTTRだけを見れば、明らかにIT部門Bが勝者です。実際のインシデント総数と累積時間を考慮しない場合、結局は役に立たない統計の比較になってしまいます。

表A：インシデントマネジメントおよびMTTR

ID部門	1ヶ月のインシデント数	目標時間を超過したインシデント数	累積インシデント時間	目標時間を超過したインシデントの割合	MTTR
A	3	1	4.5時間	33.33%	1.5時間
B	35	10	26.25時間	28.57%	0.75時間

数値を低く抑制

しかし、解決時間を測定しても、数字を低く抑える必要性（たいてい経営陣からの圧力を伴う）に変わりはありません。どうすればいいのでしょうか？

取るべきいくつかのステップがありますが、それらを一緒に取り組むことで、ポジティブな成果を得ることができます。以下は、今すぐ始めるべき6つの重要なステップです。

迅速で正確なインシデントマネジメントシステムの利用
レスポンスは、インシデントマネジメントシステムから始まります。レスポンスチームはどのようにアラートを受け取っていますか？勤務時間内にエンドユーザーから電話やメールでメッセージを受け取っていますか？このようなシステムは優先度の低い問題や機能変更リクエストには適しています。インシデントが検出または報告されたとき、直ちにマルチチャネルのグローバル通信オプション（電話、SMS、メール、その他のクイックレスポンス通信システム）を使用して、適切なレスポンスチームのリーダーに通知する自動インシデントシステムが必要です。インシデントは、インシデントへの対応に誰が責任を持つのかという混乱や誤解を避けるため、適切なチームリーダーへ報告されるべきです。
アラートノイズの削減と非アラートのフィルタリング
最初からアラートノイズをフィルタリングして制限することで、レスポンスチームは優先度の低いインシデントや、ディスパッチされる前にフィルタリングされていない非インシデントというさらに避けたいケースに拘束されることがなくなります。これらの機能はアラートやディスパッチシステムに組み込まれるべきで、大部分は自動化することができます。
インシデント承認時間を短縮
これには、アラートシステムとレスポンスチームの両方が関わってきます。設定された（非常に短い）時間を過ぎてもインシデントの承認がない場合、インシデントは自動的にチーム内の2番目のメンバーへ、それから3番目のメンバーへといった具合に引き継がれます。チームの誰もインシデントを承認しない場合は、2番目のチーム（またはIT管理者）に引き継がれることになります。インシデントを承認せずに、いつまでも放置してはなりません。
初めから優先順位を設定
インシデントの重大度や範囲、影響を受けるシステム、会社の業務への影響などに基づいて、明確な優先順位を設定します。これはMTTRにさまざまな影響を与えるかもしれません。しかし、どのインシデントに最も注意すべきなのか、そしてどれは待てるのかを明確に理解してから開始すれば、無駄な時間を減らして、最終的に解決時間を短縮できます。
リアルタイムコラボレーションの活用
インシデント解決の対応中は、必要に応じて、専門チームやサポートリソースに協力を求めましょう。適切なメディア（VPN、ライブビデオ、テキスト、音声などが含まれます）を使用したリアルタイムコラボレーションは、翌営業日のメールメッセージを待つこととは違い、迅速かつその場での解決を意味します。
明確なルールを持つレスポンスチームの構築
インシデント対応は決して場当たり的であってはなりません。各チームにはリーダーを置き、チームメンバー全員がお互いの責任を明確にしておく必要があります。チーム内とチーム外のステークホルダーの両方に対して、コミュニケーションは明確かつオープンであるべきです。

レスポンスタイムを短縮するために実行できるステップは他にもたくさんあります。例えば、大企業にとっては、インシデントドリルを用いた組織的なコマンドシステムが適切かもしれません。しかし、上記のガイドラインに従うことで、ITチームのMTTR数値を、空に向かって叫びたくはならない程度に下げられるはずです。

公式資料
「デジタルオペレーションの現状」独自調査レポート

エンジニアの燃え尽きを防ぐ秘訣とは？
一段と信頼性の高いシステムを顧客が求めるようになり、勤務時間外や夜間の対応など、技術チームへの要求も増しています。本レポートでは、19,000 社以上、100 万人を超えるユーザーで構成されるPagerDutyプラットフォームから収集したデータを基にしたシステム運用の”今”を解説！→ PagerDutyの資料をみる（無料）

無料ダウンロード >