そろそろ話をしよう...Time to ResolveとMTTRについての話だ！Time to Resolveは、私が物心ついた頃からある指標です。解決までの時間は、私が覚えている限り、ずっと前からある指標です。解決までの時間(またはMTTR)は新しいものではありませんが、そろそろ解決までの時間が本当に意味するものを詳しく見て、解き明かす時期が来ていると思います。
なぜ今なのか？なぜなら、解決までの時間はとても重要だからです。解決までの時間は、ユーザビリティとユーザーエクスペリエンスの指標です。また、解決までの時間は、非常に誤解され、誤った解釈をされる指標のひとつでもあります。では、さっそく検証してみましょう。
このTime to Resolveガイドでは
Time to Resolveとは？
解決までの時間」とはどういう意味ですか？
MTTR（Time To Resolve）は、停電や問題解決のシナリオの中で、同じ症状のケースやインシデントが解決されるまでの平均時間を示しています。
Time To Resolve = 障害発生から障害発生までの時間
要するに、解決までの時間とは、特定のエラーに対してユーザーがどれくらいの時間待っているかを示す指標です。人々が同じ問題を抱えているか、別の問題を経験しているかは重要ではなく、以前に同じようなことに遭遇したかどうか、そして解決策を見つけることによって立ち直るまでにどれくらいの時間がかかるかが重要なのです。
MTTDとMTTR：何が違うのか？
MTTDとMTTRは同じ生地から作られています。しかし、同じではありません。MTTRはシステムを復旧させるのにかかる時間を示し、MTTDはインシデントが発生してから解決されるまでの時間を示します。この記事では、わかりやすくするために、解決までの時間に焦点を当てますが、MTTDとMTTRのわずかな違いについて知っておいてほしいと思います。
MTTDとは、事故発生から解決までの時間です。
MTTRとは、インシデントが発生してから解決するまでの時間のことです。
例 発生時刻(TOI)と解決時刻(TOR)
MTTRはこんな風に考えるのが便利です。 時間Xに問題が発生し、ユーザーAが解決策を見つけるまでに平均してYの時間がかかり、時間Zに問題が解決される。
また、MTTDはインシデントが発生してから解決するまでの時間を意味し、MTTRは問題が発生してから解決するまでの時間を意味することも覚えておいてください。これは些細なことに思えるかもしれませんが、このような混乱に何度も遭遇していると思うので、はっきりと確認しておきたいと思います。
Time to Resolveはいつ測定すればいいのか？
Time To Resolveは、繰り返し発生するエラー（類似の症状を持つエラー）のユーザー満足度を理解する必要がある場合に、優れたデータを提供します。例えば
- なぜまた私のサイトがダウンしたのですか？先週も起こったばかりなのに！？何度も何度もこんなことが起こるなんて......。
- ブラウザをアップデートした後、このメッセージがずっと表示されます。誰かに見てもらうことはできないでしょうか？
- 送っていただいた説明書が分かりにくかったです。どなたかもう一度見ていただけませんか？
解決までの時間が測定できるものであれば（解決までの時間は誰にでも可能）、解決までの時間は、障害が発生した後にユーザーが作業を再開するまでにかかる時間を理解するのに役立ちます。基本的には、問題を経験した後、ユーザーが再び仕事をこなせるようになるまでにどれくらいの時間がかかったか？
なんといっても「時間」は「お金」なのですでは、解決するための時間を常に使えるようにするにはどうしたらいいのか・・・。
Over time to resolveでは、ユーザーが問題解決を待っている時間を計算できます。そして、そのデータを時系列で、異なるチーム間で比較することができます。この分野で問題があるかどうかを判断するために使用される重要業績評価指標（KPI）が他にもいくつかありますが、解決までの時間はそのうちの1つです。
Resolveまでの時間はどのように計測するのですか？
まず、time To Resolveを利用するためには、測定する必要があります。Time To Resolutionは、（1）インシデントから解決までの時間（2）停電の間の時間（3）インシデントからクローズ時間までの時間、の3つの方法のいずれかで測定することができます。それぞれの方法にはメリットとデメリットがあり、またどのように報告されるかもしれないので、チームに合った方法を選ぶ際には、それらのことに留意してください。以下、この3つを見てみましょう。
1.)インシデントが発生してから解決するまでの時間。これは、障害発生後すぐにデータを引き出すことができるため、迅速な対応を望むチームには最適な指標です。デメリットとしては、72時間以内に解決されない場合、過去のデータが失われることが挙げられますが（かつてはグッドプラクティスとされていました）、これは報告までの時間を短縮するのに役立ちます。障害発生時の解決までの時間は、最も人気のある指標の1つです。
2.)インシデントからクローズ時間までの時間。問題が発生してから、このチケットのユーザが復旧するまでの時間が100分であることがわかります。この方法は、障害発生直後にデータを収集するよりも時間がかかりますが、より長い期間の履歴データを得ることができます。このデータは、異なるチーム間で分析することで、何が最も長く続いたのか（そしてその理由）を掘り下げることができます。
3.)問題発見からクロージングまでの時間。問題発見から解決までの時間の例をもうひとつ示します。今回は、ユーザーが問題を解決するのに50分かかっていることがわかります。また、今回は1日前ではなく、数日前のデータを引き出していることも明らかです。課題はワークフローの進行に伴って更新される傾向があるため、他の方法よりもデータを取得するのが困難です。したがって、解決までの時間データを取得するためには、更新の間に少なくとも24時間必要なことを覚えておいてください。
一般的にTime To Resolution（測定）は、これら3つのカテゴリーのいずれかに分類されます。
- 停止時間中（データ収集時間には、停止時間およびスタッフが問題に対処するまでの時間が含まれます。）
- 停電時間後（データ収集時間から数日または数週間後）
- 待ち行列の時間（システム内の開始時間からシステム内のクローズ時間まで）。
ユーザーは待っている、どうする？
ここで厄介なのが、解決までの時間です。時間」はお金です。ですから、データを解決するために時間をかけ、それを何か役に立つものに変えることが重要なのです。以下のような質問をすることもできます。
- この問題は、実際にはどの程度の大きさなのでしょうか？
- この問題は、時系列で見るとどのように見えますか？ 何か傾向はありますか？
- 私のチームは、問題を迅速に解決する能力が向上しているのか、それとも低下しているのか？
解決までの時間データを有用なものにするのは難しいものです。チームは多くの情報を持っていますが、解決までの時間データがなければ変更できないとわかっている場合もあります。解決までの時間データを収集することで、同業他社との比較だけでなく、この分野でどれだけ効率的に時間を使っているかを確認することができます。
解決までの時間やMTTRを短縮するためのヒント
解決までの時間とは何か、それをどのように測定し追跡するかはおわかりいただけたと思います。では、この重要な指標を減らすにはどうすればいいのでしょうか。私たちのお気に入りのヒントがここにあります。
- 時間がかかっても、重要でないことをやめることを恐れないでください。もし、時間を費やすだけで、付加価値のないことに時間を費やしているのなら、それらの活動を見直す時期かもしれません。
- 現在インシデントを追跡している方法であれば、電子メールやスプレッドシートとは対照的に、エラーの余地が少ないDesk.comのような観察可能プラットフォームやインシデント管理システムの使用を開始する（または継続する）。電子メールは紛失したり忘れられたりする可能性があり、スプレッドシートは乱雑で混乱し、最終的には問題を解決するために行ったり来たりしているうちに時間が過ぎてしまいます。
- 常に仕事に優先順位をつける - 最も時間がかかるので、まず最も重要な仕事から始め、時間節約のために仕事を完了するまでの時間を優先させる。
- 解決までの時間を改善する他の方法としては、フォローしやすい明確なプロセスを持つこと、チームがすべてのレベルで適切なトレーニングを受けていることを確認すること、キューにあるチケットを常に把握すること（これにより、どれだけのユーザーがあなたを待っているかを正確に把握することができます）などがあります。
解決までの時間とMTTRの最終的な考察
Time To Resolutionは、IT作業の品質を示す優れた指標です。これは、問題が正しく解決されているか、時間管理を念頭に置いているかを示す指標として使用されます。解決までの時間が効率的であるということは、チームが問題に対処するのに十分なほど迅速に問題が解決されていることを意味しますが、問題の根本原因の分析に深く入り込むことなく、「消火活動」とみなされるほど迅速すぎるわけではありません。優れた解決までの時間KPIは、チームが顧客サービス、効率、タスクに費やした時間などに関する質問に答えるのに役立ちます。したがって、解決までの時間に「注目」するだけでなく、それがチームにとって何を意味するかを理解することが重要です。
