「社内情報システム部門のお仕事 」にも書きましたが、私の所属する情報システム部の仕事の中に、ヘルプデスク業務と言うものがあります。
社員の方が利用されているPCのトラブル対応や、情報システム部が運用しているシステムの利用方法や利用の過程で起こった問題の解決、問合せ者が業務で悩んでいる問題を解決するためのツールの選定など、IT全般の問い合わせ全てが対象といっても過言ではない業務です。
そういったものの対応を行う際の心構えを自分の経験則から述べてみたいと思います。
1. 焦らない事
問合せ者の役職によっては、緊張する場面も出てくるのですが、焦りというのは的確な判断ができなくなるので、冷静で入れるようにすることが大事です。
焦らないための考え方の一つとして、「こちら側は悪くない」と思っていることです。
ヘルプデスクに問合せが来る場合の多くは、相手側の何らかの操作などにより問題が引き起こされた可能性が高いです。
何かの質問をしてくる場合も、基本お願いベースになりますので、こちら側は堂々と対応すればよいでしょう。（でもそれで横柄な態度になるのは避けましょう）
2. 問題を解決する事を優先する
エンジニアの性か、問題が発生するとその原因を突き止めようとしてしまいがちです。
ですが、原因の究明と言うのはそれなりに時間がかかるものです。
（システムのバグだったりした場合はなお更です）
その間に問合せした人はずっと待ちぼうけていなければなりません。
問合せ者は、問題が解決すればよいと一番に考えているので、それをまず解消する事に専念すべきです。
問題が解消できた後に起こった原因の究明を行いましょう。
3. 代替案を提示する
問題を解決することを優先とした場合に、完全に解決できない場合もあります。
その際は、何らかの代替案を提示するようにしましょう。
例えば、あるシステムで決まった操作をすると問題が出るバグがあった場合に、その操作の順番を変える事で解決できる場合もあります。
あるソフトウェアが操作不能になった場合に、別のソフトウェアを利用してもらう事で解決できる場合もあります。
問合せ者が最終的に何をしたいのかを理解し、その為にその問題を解決する以外に方法が無いのかも考えてみる事が大事です。
4. 何でもかんでも解決しようとしない
ヘルプデスクへ問い合わせてくる人の中には、自分の業務の効率化を図るために色々質問をしてくる人もいます。
ですが、その解決のために費やす時間とその解決によって出る効果を見定める必要があります。
例えば、その問題を解決する事によって問合せした人の業務が1時間短縮されたとしても、その解決のためにあなたが2時間費やしたら何の意味もありません。
定常的な業務の場合は、効果があるかもしれませんが、1度きりの効率化のために何かしてあげるより時には人海戦術で取り組んだ方が手っ取り早い場合もあります。
5. 啓蒙活動を怠らない
問題が解決して、原因がわかったら問合せ者にフィードバックしてあげましょう。
ヘルプデスクの対象は「人」です。
人は理解してくれます。（中には・・・ですが）
問合せ者に理解させる事で繰り返しの問合せをなくし、またその人の周りにいる人へもその問題への解決方法を波及させれば、ヘルプデスク業務自体が楽になります。
6. 問合せ者のレベルを量る
問合せしてきた人がどういったITスキルを持っているのかを確認する事も大事な事です。
そのITスキルに応じて、どういった説明をしなくてはならないのか、相手から問題が起きた情報を引き出すためにどういった質問をすればよいのかが変わってきます。
先に書いた啓蒙活動でも、その人にとってちんぷんかんぷんな事を伝えても意味がありません。
また、原因を伝えるにあたってもその人にとってそのレベルの事を伝えるべきかどうか考えなくてはいけません。
7. わからない場合は持ち帰る
幾らヘルプデスクの達人でも、世の中に星の数ほどシステムやソフトウェアが存在する限り万能に対応できる人などいません。
自分がわからないことも多々ある事と思います。
そういった場合は、一旦その問題を持ち帰り周りの仲間に聞いてみたり、溜め込んだナレッジのデータベースからやインターネットから解決方法を探してみたりしましょう。
その場で、試行錯誤していると問合せ者の業務を止めてしまい、問合せ者はその間は何もできなくなってしまい、時には不満を持つようになります。
一旦その問題について、検証等を行う旨とその間の注意点を伝え、支障のない範囲で業務を継続してもらう事で問合せ者を安心させる事ができます。
8. エスカレーション
問題を持ち帰った時など、自分で問題が解決できなかった場合は、他の識者にエスカレーションする必要があります。
その際に、起こった事象等を性格に伝達しなくてはいけません。
伝達する際は、よくある5W1Hの形式で伝えるようにしましょう。
[ When ]
何時問題が起きたのか
その時間帯特有の現象だった可能性があります（システムがトラぶっていたなど）
[ Where ]
どこで問題が起きたのか
その場所特有の現象の可能性があります（ネットワークがつながらなかったなど）
[ What ]
何で問題が起きたのか
H/W、S/W、システム、情報機器など問題が起きた対象
[ Who ]
問題が起きたのは誰か
単なる個人を特定すると言うわけでなく、その人のシステム上の情報（アカウントなど）に問題がある可能性があります
[ Why ]
何故問題が起きたのか
エスカレーションするからには、何故問題が起きたのか解らない場合がありますがそれまでの検証した結果や、問合せ者が何故その操作をしたのかなどを伝達する必要があります。
[ How ]
どのようにして問題が起きたのか
操作、手順など
9. 仲間にもフィードバック
ある問題を解決したとして、そのソリューションを自分ひとりが持っていてもヘルプデスク全体の業務から言えばあまり意味がない事になります。
その解決方法、原因を同じ業務を行う仲間にもフィードバックし、同様の問合せを効率よく対応してもらうようにします。
この方法としては、ナレッジマネジメントなどの大規模なものから、単純にメール（またはそれを溜め込んだメールアーカイブ）やMtgの場で共有したりもできますが、方法論については割愛します。
10. サービスメニューにしたがって対応する
いくらヘルプデスクと言う窓口を設けておいても、それに何でもかんでも問合せがきたのであれば人が幾らいても足りませんし、対応する人のスキルも幅が広がりすぎてそういった人を確保する事が難しくなります。
ですので、ヘルプデスク業務とは何をするものか、その対象のソフトウェアや機器、対応時間帯などサービスメニューを明確化しておく必要があります。
対応する側は、そのサービスメニューの範囲で対応するようにします。
そこからはみ出して対応する（中には致し方ない場合もあるのですが・・・）場合は、イレギュラーの対応であることを問合せ者・対応者ともに認識の上で対応するようにします。
でないと、「あの時はやってくれたのに」とクレームにも発展する可能性がありますし、他の対応者にも迷惑がかかる事にもなります。
上記では、主に対応する際の心構えを書きました。
もちろんこれ以外にも、ヘルプデスクを如何にマネジメントするかと言う観点で、先ほど書いた対応者同士の情報共有方法や、対応者のモチベーションを保つための評価制度など、トラブルを未然に防ぐためのクライアント管理、
資産管理など色々な観点・手法が必要になってきます。
