解決までの時間を明確化させる方法（第7回）

いつ問題が解決するのかは、システムを預かる管理者にとって非常に重要な問題である。上司への報告にも、これを盛り込む必要がある。しかし、一般的に問題がいつ解決するかを明確にするのは難しく、調査を進めてみないとわからないのが現状である。ユーザーも、そもそも解決までの時間がコミットできるとは思っていないかもしれない。だが問題が実際の運用上、あるいはビジネスに重大な影響を与えるものである場合には、ユーザーは一刻も早い解決を望む。そのため、管理者はどうしても解決までの時間を明確にしたいと考えるだろう。上司への説明などが必要なため、解決までの時間もある程度明確にしたいはずだ。ここでは、解決までの時間はどの程度明確化できるのかを検討し、明確化できない場合の対処方法についても述べていく。

解決までの時間を考える前に、まず、テクニカルサポートが問い合わせへの回答までの時間や解決までの時間といった時間的な内容をどう定義しているかについて述べる。テクニカルサポートが定義しているのは、一次回答までの時間や定期的な回答までにかかる時間であり、解決までの時間ではない。テクニカルサポートは、第4回で説明したシビラティ（重大度や深刻度といった意味。Severityの日本語表現）に基づいて回答までにかかる時間を定義している。具体例を以下に示す。なお、以下はあくまで一例であり、実際の回答までの時間がシビラティ別にどう定義されているかは、メーカーのWebサイトなどで確認してほしい。

1. シビラティ1： テクニカルサポートが問い合わせを受けてから1時間以内に一次回答を行う
2. シビラティ2： テクニカルサポートが問い合わせを受けてから2時間以内に一次回答を行う
3. シビラティ3： テクニカルサポートが問い合わせを受けてから1営業日以内に一次回答を行う
4. シビラティ4： 一次回答までの時間は規定しない

上記の定義では、一次回答（ユーザーからの最初の問い合わせに対するテクニカルサポートからの最初の連絡）までの時間は定義しているものの、その後の回答までの時間は明確にしていない。一次回答のあとの回答は、あくまでユーザーとの間のSLA（サービスレベルアグリーメント）などで定義するものだからだ。定期的な回答までの時間を公開している会社も当然あるということを付け加えておく。

上記の定義のように一次回答までの時間だけを明記している場合でも、テクニカルサポートはユーザーへの定期的な回答までの時間を内部的に定めているのが普通である。特に、CRMを利用した問い合わせ管理システムでは、一定時間経過すると「ユーザーへの連絡を取るように」というアラートを発する仕組みを備えている。そのため、テクニカルサポートは事実上一次回答までの時間とその後の定期的な連絡にかかる時間までは決めているのが一般的である。しかし解決までの時間は保障しないというのが、テクニカルサポートの基本スタンスのようだ。確かに、調査してみないとどのように解決できるのかはわからない。したがって、解決までの時間を保証するかわりに、解決までの時間の目安を明確にしていくことを考えるとよい。解決までの時間の目安を明確にするためには、解決までの調査手順をある程度明確にすることが有効になる。

それでは、まず解決までの調査手順を明確にできない理由を考えてみる。理由は大きく以下の2点になるだろう。

1. トライ&エラー的なアプローチ

   一番大きな要因は、テクニカルサポートでの解決までのアプローチが「トライ＆エラー」的になってしまっている場合である。

   テクニカルサポートは、調査に必要となるログなどの情報をユーザーに提供してもらう。だがその情報で調査や解析がどこまでできるかがあいまいな場合、次から次へとユーザーに情報の提供を依頼し、どこまで進んでいるかが一向にわからない、という状況になる。ユーザーにログを送ってもらって解析したものの、原因がわからずにまた別のログを送ってもらう、ということが何度もくり返され、いわゆるトライ＆エラーに陥ってしまうのだ。

   こうなると、ユーザーはどこまで調査や解析が進んでいるかや、あとどのくらいの調査や解析が必要なのかわからず、解決までの目安すらわからなくなる。

2. テクニカルサポートのレイヤーごとの対応方法や優先順位の違い

   第4回と第6回で述べたように、テクニカルサポート（Tier1-3）や開発部門（サステイニング、コア開発）のレイヤーが変わると、対応方法や優先順位に違いが発生する。レイヤーごとの調査や解析の仕方の違いによって必要となる情報が異なる場合、ユーザーに新たな情報の提供を求めることになる。さらに、第4回で述べたシビラティと優先順位の関係にも影響がある。テクニカルサポートは各レイヤーでさまざまな問い合わせを抱えているため、同じシビラティであってもレイヤー間で異なった優先順位で扱う場合がある。レイヤーが変わるたびに対応状況が変わってくるため、ユーザーからみると調査や解析がどの程度進んでいるのかがわからなくなる。

これらの要因はテクニカルサポート側の問題であり、ユーザー側で改善することは難しい。

最後に、解決までの時間の目安を明確にするにはどうすればよいかを考えてみたい。これまで述べてきたように、目安を明確にできないのは、テクニカルサポート側に大きな要因がある。そこで、ユーザー側がこれらの要因に陥らないようにテクニカルサポートを誘導することで、目安をある程度明確化できるはずだ。

トライ&エラー的なアプローチに陥らないためにはどうすればよいか。まず第一に、テクニカルサポートからログなどの情報提供を求められたときには、情報の取得目的やそれにより何がわかるのか、次のステップはどうなるのかを明確にしてもらうことだ。問題の切り分けの手順やそれぞれの段階において必要となる情報を、可能な限り最初の段階で提示してもらうのが望ましい。それが難しい場合には、何のために情報を取得するのか、次はどうなるのかを最低限明確にした上で進めるようにしたい。

次に、定期的に進捗を報告してもらうことである。これにより、テクニカルサポートのレイヤーごとの対応状況に変化が生じた場合でも、進捗状況が明確になるため、今後の対応を明確にできる。なお、メーカーによっては、シビラティに応じた定期的な連絡時間を規定しているため、特に注意しなくても定期的に進捗を連絡しているはずだ。だが一次回答までの時間のみを規定している場合は、次に進捗の連絡を受ける日時を必ず確認しておきたい。

進捗の連絡を受ける際には、仮に具体的な進展や解決のメドがつかない場合でも、どのような調査方法で問題点を絞込んでいるかなどの手順をできるだけ詳細に説明してもらうようにする。次の連絡時までにどのようなことをするかを確認しておくと良い。

以上のように、解決までの時間を明確化することは難しいが、解決に向けたアプローチ方法やその時点での調査・解析の状況を逐次把握するようにしていくことで、ある程度解決までの目安が見えてくるだろう。今回の目的である「解決までの時間を明確化させる」という点に関しては、期待を裏切る内容となってしまったかもしれない。しかし、トライ＆エラー的なアプローチになりがちなテクニカルサポートの対応を、きちんとした道筋に従った対応に誘導していくことは意義がある。これができるようになれば、ユーザーとテクニカルサポートの信頼関係も向上していくだろう。