【仕事・IT業務】質問を受ける側の考え、質問するために考える相手のことについて

Business work


サポート業務をこなしていると、質問が来るのはお客様だけに限らず、同僚からくるケースも多い。

自分の場合、大体8割は同僚から。そしてその質問の大半は検索すれば分かったりする程度の疑問だったりする。
自分で調べれるように調べ方をアドバイスしても2日後には元に戻ってるケースがほとんど。
そんな他力本願さんに向けて。


質問を受けても鵜呑みにしない

日常会話では相手が言ったことには深く考えないかもしれない。
しかし、ビジネスの現場ではそうはいかない。
特にサポート業務などは相手の質問に答える必要があります。相手が望んでいなかったり的外れの回答を出すわけにはいかないのです。

ならば、相手の言葉や文章をよく聞きよく読み、相手にどうなりたいの?それはなぜ?と問いかけるクセを持った方が良いです。


背景を確認しよう

現場でトラブルが起きて、それを解決するにあたってある程度背景を明確にする必要がある。それは仮説を立てるのに必要あるから。
どんな現象でも必ずそれを起こした背景がある。それはそもそもやってはいけないことをやったからなのか、設定に関する人的ミスをしていたからなのか、またはソフトの障害に関する対処をしてなかったからなのか。

仮説立案のためにも最低限以下のプロセスがあることを頭に入れてほしい。

何が問題なのか、解決するべき課題を特定する    (what)
どこが問題なのか、重要な問題個所を特定する    (where)
なぜそうなったのか、根本的な原因を特定する    (why)
対処方法は何か、課題を解決する具体的な対策を考える(how)

基本的には、whyの後にwhatに戻り最後の最後にhowにたどり着く。

文字だと分かりにくいかもしれないが、プログラム作ってるとよくあるのではなかろうか。

簡単には以下のような場面。

エラーメッセージが発生した。  (what)
とある機能が出力しているようだ。(where)
その機能に関する設定に不備がある(why)
設定を直そう。         (how)


相手にとって何が必要かを考えよう

サポートの世界では、問題解決が出来たとして、それで満足いく結果になるかと言ったらそうとは限らない。

動作の確認など、仮説検証中に発生した「エラーメッセージ」をサポートに問い合わせて解決して、いざ検証を続けてみても、そもそも最初のやりたいことが出来ないものだったりする。プログラマーあるあるだと思います。

そしてお客様はこう言うでしょう「なんであの時言ってくれなかったんだ、これやりたいからこう設定したって説明したでしょ!」と。

理不尽と思われるかもしれないが、相手が最終的にやりたいことをあらかじめ確認して調べてアドバイス出来たなかった時点で、サポート側の落ち度だと私は思います。


総じて

IT業務に限らず、相手の置かれている状況を理解して、相手に提供できるものが何か、自分の頭で考えるクセを持ちましょう。そして調べましょう。



以上。

コメント

タイトルとURLをコピーしました