プラスアルファの情報を引き出す方法（第10回）

「問題が解決しましたので、この問い合わせはクローズとさせていただきます」。よくある、テクニカルサポートの案件対応の終了メッセージである。しかし、もっと建設的な会話ができないものであろうか。実は、テクニカルサポートには製品の使用方法のノウハウや使用上の注意点、利用者にとっての的確な使用方法、今後の製品動向といった“宝の山”、つまりプラスアルファの情報がある。ここでは、プラスアルファの情報をいかに引き出すかに関して述べる。

さて、そもそもなぜこの話題に触れるのかを最初に説明する。テクニカルサポートにおいて、上記のようなプラスアルファ情報は提供されにくい。その理由は、ユーザーからの問い合わせをできるだけ速やかに解決させて終了させたい、という意図があるからである。これは、テクニカルサポートにおける個々のエンジニアに対する評価が、「いかに早く解決できたか」に依存しているところに大きな理由がある。ここでは、まずテクニカルサポートにおけるパフォーマンス評価指標の代表的なものについて述べる。

1. 平均解決時間

   平均解決時間とは、ある期間にクローズした問い合わせに対して、問い合わせを受け付けてからクローズするまでの平均時間のことをいう。この値は、どれだけ短時間で解決に導けたかという指標となる。そのため、この値が小さければ、一般的に問い合わせに対して効率的に処理していることになる。またこの値が小さいエンジニアは、効率的な問い合わせ対応ができているとみなすことができる。

   平均解決時間はエンジニアのパフォーマンスを直接表現するため、エンジニアはこの数値を小さくするように、つまりできるだけ迅速にクローズすることに注力することになる。

2. オープン案件の平均経過時間

   オープン案件の平均経過時間とは、対応中の問い合わせに対して、問い合わせ受付からどれだけの時間が経過しているかを示す数値である。この値が大きい場合には、対応中の問い合わせに時間がかかっていることになる。処理がうまく進んでいるかどうかをモニターできるため、特にマネジャーはこの数値が大きいエンジニアに対して、その理由を求めたり、場合によってはテコ入れをしたりする。

   この数値自体は、エンジニアのパフォーマンスを示しているわけではない。だがエンジニアから見ると、この数値が大きいとマネジャーなどからの注意対象となるため、できるだけ小さくする、つまりなんとかして早くクローズに持っていくことになる。

3. 総クローズ数

   総クローズ数は、ある期間にクローズした問い合わせ数を示す。平均解決時間と同様に、エンジニアのパフォーマンスを直接表している。したがって、できるだけ多くの案件を処理してこの値を大きくできるように、迅速にクローズすることに注力することになる。

4. 残存案件数、バックログ数

   残存案件数、あるいはバックログ数は、どちらもその時点で対応中の案件の数を示す。残存案件数が、単純にその時点でクローズできていない数を示すのに対して、バックログ数は、その時点でクローズできていない問い合わせのうち、一定期間（1週間など）経過しているものの数を示す。特にバックログ数は対応に時間がかかっている問い合わせと言えるため、マネジャーにとって注意が必要なものと判断できる。したがって、この値に関してもできるだけ小さくできるように、つまり迅速にクローズに注力する理由となる。

もちろん、上記4点の指標だけでテクニカルサポートのパフォーマンスがすべて計られるわけではないが、定量的に計ろうとすると上記のような指標になる。これらの値を良くするためには、問い合わせの解決や終了をいかに早くできるか、いかに多くの問い合わせをさばけるかという点に注力せざるをえない。

テクニカルサポートでは、顧客満足度を上げるため、ユーザーに対して付加価値情報を提供したり、親身になって相談に応じる姿勢は見せているものの、上記のような指標があるため、なかなか実行するのが困難なようである。したがって、今回のテーマであるプラスアルファの情報を引き出すためには、ユーザーの方からうまくアプローチすることが重要になる。

それでは、どのような情報をどのようなときに引き出せばよいかについて以下に述べていく。

1. 使用方法や設定方法に関して問い合わせた場合。仮に、テクニカルサポートからの回答が「使用できます」というような内容であったとしても、本来の使用方法や一般的な使用方法を確認する。これにより、より望ましい使用方法を検討できるし、将来における仕様の変更に対してできるだけ安全な方法を取ることができる。
2. バージョンアップ情報として、その時期や新しく追加される機能について確認した場合、あわせて今までの機能との互換性について確認する。互換性に関しては、テクニカルサポートでも出荷直前まで知らされないことが多い。そのため、ユーザーの方から先行して確認を求めることで、テクニカルサポートも開発担当などに確認を取るなどして互換性を明確にできる。早い段階から互換性情報を入手できるため、移行のためのスケジューリングなどを先行して進めることができる。
3. 障害の対応が終了したとき、次回同様の問題が発生したときにも、取得すべきログや確認すべき内容などをまとめて提示してもらえるようにする。これにより、テクニカルサポートに障害を問い合わせる場合に初期対応が非常にスムーズに進み、迅速に解決へと導けるようになる。

以上3点、典型的な例を基に追加情報の引き出し方を示した。様々な問い合わせの状況があると思うので、その都度、テクニカルサポートと先を見据えてやり取りし、できるだけ建設的な関係を築いていただきたい。