ちょっと硬派なコンピュータフリークのBlogです。

カスタム検索

2009-12-04

サポートエンジニアが経験から語る、論理的文章によるコミュニケーションのススメ

俺はこれまで一貫してIT業界でエンジニアとしてのキャリアを進んできたのだが、これまでのキャリアでもう一つ一貫していることがある。それは、ずっとサポートエンジニアであるということだ。実はサポート職というのはかなり論理的なコミュニケーションを必要とする職種であり、如何に論理的な文章を上手に書くかということが、如何に良い仕事をするか(短い時間で成果=顧客満足度を得られるか)ということに繋がるという側面がある。(もちろん高い技術力が必要なのは言うまでもないが。)サポートエンジニアはメールや報告書という形で日々論理的な文章を書かなければならないので、サポートの経験を重ねることによって論理的にコミュニケーションをする能力というのは徐々に磨かれよう。しかし、論理的にコミュニケーションをするというのは意外と皆出来ているようで出来ていないし、筋が悪いといつまで経っても身につかないこともあり、上手にお客さんを説得することが出来ずにクレームを受けやすい人が居るのも確かだ。

そこで、今日は漢がサポート職を通じて身につけた「論理的な文章の書き方」ということについて、ポイントを紹介しようと思う。

最も大事なことは、ちゃんと質問に回答すること。

何を今更ワケの分からないことを言ってるんだ?そんなの当たり前じゃないか?と思ってしまうかも知れない。しかし、この基本中の基本とも言えることが実は意外と出来てないことが多いのである。実は質問というのは、内容はバリエーションに富んでいるが、質問の形式というのは種類が決まっている。そして、個々の質問の形式に合った回答をしないと、質問に答えたことにはならないのである。如何に有益な情報を書いて相手にメールを送ったとしても、相手の質問に回答していなければ意味がない。それどころか、お客さんは「ちゃんと俺の質問に答えていない」とイライラを募らせてメールをよこす羽目になってしまうのである。

3つしかない「質問」の形式

形式はたったの3つしかないだと?「ハァ?バカにするなよ!」と思われる方はまず落ち着いて続きを読んで欲しい。それは紛れもない事実なのである。「なんだって?質問だったら何でも聴けるんじゃないのか?」という意見もあるしそれは確かに正しいのだが、質問の内容は千差万別でもその形式にはバリエーションはないのである。3つしかないのだから誰だって覚えられるし対策もできる!というわけで、是非これを読んでいるアナタも試してみて欲しい。その3つの形式とは次の通り。

  1. Yes/Noで回答できる質問
  2. 5W1Hの質問
  3. それ以外の質問

それではこれらについて、順を追って説明していこう。

Yes/Noで回答できる質問

最もシンプルかつ多く見受けられるのが、YesかNoで回答出来る質問だ。最もシンプルな例を挙げると「Is this a pen?」というような質問がこのカテゴリに該当する。YesかNoで回答できる質問(以下Yes/No質問)には、YesかNo以外の回答をしてはいけない。そんなの当たり前じゃないかと思うだろうが、これは実は多くの人が無意識のうちに破ってしまう約束事である。どういう事かというと、相手はYesかNoか?と聞いているのについそれ以外の回答をしてしまうということだ。ちょっと卑近な例として、スーパーの生鮮食品売り場で買い物をするときの例を見てみよう。(ちょっとバカ会話だが。。。)

客:このハマチは日本海側でとれたの?
店員:つやがいいでしょう?たくさん餌を食べた証拠です。ひとつどうですか奥さん。
客:そうねえ、ひとついただこうかしら。

この文章を見ておかしいと思わない人はアウトーーーーッ!!である。「だって普通の日常会話じゃこんなのよくあるだろ?」と思われるかも知れない。確かにその通りなのだが、そもそも日常会話自体が論理的ではない。論理的なコミュニケーションをする上で、日常会話の常識は邪魔なのである。この質問では、お客さんは日本海側で取れたのかどうかということを聞いているのだから、論理的に回答しようとするならばYesかNo、つまり「はい」か「いいえ」以外の答えしかあり得ないのである。サポートの仕事では、この形式の質問として次のようなものを多く見かける。

xxxxxxがxxxxxxという動作をするのは仕様ですか?
xxxxxが起きた原因はxxxxxですか?
xxxxxでxxxxxという操作をすることは可能ですか?

因みに、今話題の仕分け人が放った質問「1位じゃなきゃダメなんですか?」というのもYes/No質問である。

この形式の質問では、まずYesかNoではっきりと回答すること!言い回しは何でもいい(例:おっしゃる通りですetc)のだが、まずはYesかNoの意思表示が重要なのである。

ただし、Yes/No質問には一つ注意しなければいけない罠がある。それは、例えば答えがYesだったとき、「はい」だけ回答しただけではいけないということである。

例えば、

> xxxxxが起きた原因はxxxxxですか?
はい、そうです。

というようなメールを送ったとしたら、相手は「なんて不親切なサポートなんだろう」と思ってしまう。何故ならば、相手は暗黙的にさらにその回答に対してコメントを求めていることが多いからである。上記の「xxxxxが起きた原因はxxxxxですか?」というような質問では、相手はその裏付けとなる根拠を説明して貰いたいと思っている場合がほとんどであり、その暗黙的な質問に対しても回答しなければ相手を満足させることは出来ない。このように、額面の裏に隠された質問を察することが、Yes/No質問では大事なのである。

もう一つ注意点としては、相手の質問に対してYesかNoで答えることが不可能な場合がある。例えば、

MySQLはPostgreSQLよりも高速ですか?

と聞かれてもYesかNoでは答えられないだろう。このような場合には、「一概に言えない」とか「場合による」といった回答が相応しい。ただし、この場合ももちろんその根拠をコメントすることを忘れてはならない。

5W1Hの質問

5W1Hとはつまり、Who(誰が) What(何を) When(いつ) Where(どこで) Why(どうして)How(どのように)したのか、という形式の質問である。勘の良い方なら、5W1Hに対してどのように回答すれば論理的な回答になるかということがおわかりだろう。そう、聞かれたことに回答すれば良いのである。5W1Hを聞かれたら、まずはその対象を答えるべきなのだ。次は夫婦の会話だが、夫はちゃんと妻の質問に答えていない。
妻:今日は何時に帰ってくるの?
夫:ちょっと取引先の人と会ってくるよ。

この場合、夫は帰宅時刻のおおよその見積もり(When)を答えなければならないはずであるが、取引先の人と会うという事柄(What)について述べているのでこれは論理的ではない。「取引先の人と会うから遅くなるということを察しろ」という意見があるかも知れない。それは確かに日常会話ではそれは通じる場合が多いのだが、論理的なコミュニケーションではそのようなやり取りは相応しくないということを理解して貰いたいのである。

サポートで見かける5W1H質問には、例えば次のようなものがある。
xxxxという操作をするためのコマンドは何ですか?(What)
xxxxがクラッシュした原因は何ですか?(Why)
このエラーはいつの時点から発生していたのでしょうか?(When)
この状態から復旧するにはどのようにすれば良いのでしょうか?(How)

ちなみに、WhoやWhereを聞かれることはあまりない。例えば「誰が作業をしたのか?」などという質問をされても、サポートサイドでは回答出来ない(ということをお客さんも当然知っている)からである。

5W1Hの場合は、Yes/No質問のように暗黙的な隠れた質問があることは少ない。質問者はダイレクトに自分の疑問を聞いている場合が多く、聞かれたことを全力で説明すれば良いというわけである。

それ以外の質問

3つのパターンの中で最も答えるのが難しいのが、Yes/Noにも5W1Hにも当てはまらない質問である。漠然としたことについて意見を求めるようなケースである。この手の質問としては、例えば次のようなものがある。

MySQL Clusterについて教えて下さい。
バイナリログの仕組みを教えて下さい。
MySQLをバックアップするにはどうすればいいでしょうか。
データベースのパフォーマンスチューニングはどのようにすれば良いのでしょうか。

このような質問をしてくる背景として、お客さんが何かを知りたいのだがどこから聞いて良いのか掴み切れていないという状況が多い。このような質問をされると、

オーケー。じゃあまず何から話そうか。

ということになってしまう。何を回答するかは回答者次第、言ってみれば自由なのだ。自由だから何でも書いて良いというわけではない。質問者を満足させる回答でなければならないので、正直言ってこれが一番回答に困る質問の形式であると言えよう。だからこそ腕の見せ所であると言える。

ここで注意しなければいけないのは、「マニュアル嫁」という味も糞もミソもカンガルーもない反応をしてしまうことである。確かにそれは真理である場合もあるのだが、そのような回答は英語では「RTFM=Read The F@cking Manual」として揶揄されるよくない対応である。サポートエンジニアたるもの、努々RTFM的な回答をするなかれ。なんたってお金を頂いているわけだから。

ではRTFMの代わりにどのような回答をすれば良いのだろうか。このような質問をしてくる質問者は、たいてい質問している内容についてあまり詳しくない場合が多い。そんな質問者は質問している対象を1〜100まで全部知りたいわけでなく、その概要を知りたがっていると見なすべきである。従って、この手の「漠然とした質問」に対しては一般的な見解をすっきり短くまとめるのが良い。つまり、ここでは「要約して説明する」というスキルが求められるのである。要約した回答を送った上で、質問者がさらに詳しく知りたいと思ったならばさらに質問が送られてくることになるが、追加質問についてもこれまでに紹介した3パターンに当てはめあらた回答すれば良いだろう。

ただ、人に何かを要約して説明するというのは、仕事には欠かせないにも関わらず非常に難しい高度なスキルである。しかもそのスキルの追求には終わりがなく、如何に分かり易い文章を書くかということは文章を書く者全てにとっての永遠のテーマであると言えるだろう。自由なフォーマットで相手に何かを要領よく説明する場合、文章全体の構成をどのようにするか、説明する内容をどこに絞るかということが重要だとよく言われる。つまり、相手が知りたがっている情報を効果的に提供することが大事なのである。

サポートの場合、相手の立場を考えた上で必要な情報を提供するには次のポイントが大事である。

一、ユーザーの運用を理解する。

この手の「一般的な質問」をする場合、質問者は間違いなくその機能が質問者の環境でどのように利用出来るかどうかということを検討していると言って良い。従って、運用者の立場、即ちユーザーの利用シーンを考えることが重要なのである。例えばMySQL Clusterの場合、高可用性や運用方法などが、質問者の目的に合っているかどうかということを判断したいわけだ。

一、技術(製品)についてよく理解する。

回答する対象の技術や製品について詳しく研究しておくことがとても重要である。つまり、ネタ帳の中身が詰まっていないと良いネタが出てこないということである。対象の製品について、日々研究することもやはり大事なのである。

一、よく聞かれる質問についてはテンプレートとしてまとめておく。

毎回同じ文章を書いても良いが、毎回同じ回答になるような質問についてはテンプレート化しておくと便利である。テンプレートを作っておくのは効率が良いし、何よりそのテンプレートを随時更新することによって回答の品質が高まっていくことになるからだ。手間はRTFM的な回答をする場合と比べてそれほど増えないにも関わらず、質問者に対する印象は180℃違うことになるので非常にお得である。

ここではカスタマーサポートにおいて「漠然とした質問」に回答する際に役立つポイントについて紹介したが、この形式の質問に対する回答の質を高めるには、とにかく書いて書いて練習するのが最も重要であるということを付け加えておく。

まとめ

というわけで、質問には3つの形式があって、それぞれの形式に合った方法で回答しなければいけない。その3つの形式とは、
  • Yes/No質問
  • 5W1Hの質問
  • それ以外の(漠然とした)質問
である。それぞれ聞かれたことに対して回答する際の注意点については上で述べた通りである。くれぐれもRTFM的な回答をしてはならない。この法則に当てはめて確認すれば、書いた文章が論理的であるかどうかを判断することが出来るだろう。論理的なコミュニケーションを行うのは易しいことではないが、文章の論理性を高めて建設的な意見交換をする一助になれば幸いである。

0 コメント:

コメントを投稿