SEと営業のためのヒアリング講座。モデレータのヒアリングテクニックから学ぶ(前編)

2015年3月11日

数カ月前のことですが、次のような依頼をいただいたことがありました。「新野さんのモデレータとしてパネリストから発言を引き出す能力を生かして、SEや営業がお客様の要望をうまくヒアリングできる技術が身につくような講座をお願いできないだろうか」と。

SEの仕事としてお客様の要望を聞き出す、いわゆる要求開発の重要さが増してきている一方で、SEやエンジニアの研修は技術中心でヒアリングを上達させるようなものはなく、なんとかそういった研修ができそうな人を探しているとのことでした。

超大手SIerからヒアリング講座の依頼が

僕は仕事としてほとんど毎月のようにパネルディスカッションのモデレータをしています。今年に入っても、インフォテリアの「ASTERIA Cloud Conference 2015」、F5の「F5 Agility Tokyo 2015」でモデレータを行い、今週金曜日にはCloud Days Tokyo 2015の「Cisco Cloud Solution Day」に登壇予定です。おそらく過去10年以上、IT分野でもっとも多くモデレータを経験している人間であることは間違いないと思います。

前述の依頼をいただいた会社(国内の超大手SIerさんです)でも、依頼をいただく数カ月前に同社内の大きな勉強会でディスカッションのモデレータをさせていただきました。そのときにも壇上のパネリストから適切な発言をうまく引き出せたようで、それが社内研修の担当の方に見込まれて、ヒアリング講座の依頼につながったのです。

パネルディスカッションのモデレータのテクニックは、2012年に2本の記事としてまとめたことがあります。

ただ、SEや営業向けのヒアリング講習というのは当然ながら専門外です。一方で、モデレータのテクニックとしてはまだ書いていない、モデレータの対話術のようなものをここでまとめておくのもいい機会だと思い、挑戦する気持ちも半分込めてお受けすることにしました。

そんなわけで、これからご紹介するのはモデレータとしてのヒアリングテクニックを基に作成した「SEと営業のためのヒアリング講座」です。特に、ヒアリングも営業も習ったことがほとんど無いSEの方を想定して作られていますので基本的な内容を心がけました(講習は自由参加だったために実際には営業の方も多数受講されました)。

そしてこの講座は昨秋と今春の2回、実際にご依頼いただいた超大手SIerにおいてロールプレイなども交えて行い、ひとまずご好評をいただいたものです。その内容は読者の方の参考にもなるのではと思ったので、ここでその概要を共有したいと思います。

質問するのは難しい

質問するのって、難しいですよね。ビジネスの現場でも、知りたいことはたくさんあると思います。お客様の困っていることは何なのか知りたい、お客様の本当の要望が知りたい。競合はどれだけ食い込んでいるのか、案件の予算が実際にはどれくらいあるのか知りたい。などなど。

でも、その知りたいことをそのまま聞けば、ちゃんと答えが返ってくるかというと、実際にはそうでない、ということは多くの方が経験していると思います。

fig

お客様が何に困ってるか知りたい。だからといって「何に困ってますか?」と単純に質問をすれば知りたいことをぺらぺらしゃべってくれる、などという都合のいいお客様というのは現実にはまず存在しません。

ならば、答えてもらえそうな具体的な質問を矢継ぎ早に繰り出したらどうか。それで答えは引き出せるかもしれませんが、質問ばかりでは相手にうんざりされてしまいます。

fig

質問しなければ答えは得られません。でも単純な質問では答えが得られない。どうすればいいのでしょうか。

文脈を共有しよう

僕がモデレータとして発言を引き出しやすい環境作りで気をつけているのは、「文脈を共有すること」と「対話的な雰囲気を作ること」の2つです。

会社の会議のような場では議論のゴールを共有しやすいのですが、営業やSEとお客様が場を共有するヒアリングの場では、その場で全員の共通のゴールといったものを設定することは困難です。

そこで大事なのは文脈の共有です。文脈を共有することとは、会話の方向性を作っていくことであり、お客様から文脈に沿った発言を引き出しやすくなります。

自己紹介と前提の共有

文脈を共有するために大事なポイントは2つあります。

1. お互いにどんな立場や役割なのか、どんな能力があるのかを知る
2. 訪問の目的や前提をあらためて共有する

ヒアリングの場では、まず名刺交換が行われると思います。しかし名刺の肩書きを見ただけでは相手がどのような立場なのか、詳しく分からないケースも多いでしょう。お客様も同じです。あなたの名刺の肩書きを見ても、あなたが何のエキスパートなのか、どんな相談にのってくれそうなのか、すぐにイメージできないはずです。

そこで、まず自己紹介をしましょう。名刺の肩書きを紹介しつつ実際の仕事の内容や専門分野などを30秒から1分程度で手短に説明すればいいのです。そして、お客様の名刺を見ながら、お客様の立場や仕事の内容などを手短に伺います。ヒアリングはここから始まっている、といってもいいでしょう。

続いて訪問の目的をあらためて説明します。ここで自己紹介が生きてくるはずです。例えばこんな感じ。「私は情報共有分野のソフトウェアをふだんは担当しています。社内の情報共有の効率化の面などでお手伝いできることが何かないか、ざっくばらんにお話を伺いにまいりました」

誰が何の目的で訪問しているのか、その訪問先の人たちはどんな仕事をしているのか、といった基本的な事柄をあらためて確認し共有すると、自ずとそこからある程度の文脈が見えてくるはずです。

fig

その文脈を踏まえつつ、質問をしていくことになるわけですが、ここで単純な質問をする以外のテクニックを見てみます。

対話している雰囲気を作ろう

質問と答え、質問と答え、という繰り返しでは役割が固定されて会話が単調になり、つまらないものになってしまいます。そこで質問に変化を付けて、できるだけ対話する雰囲気を作ることができれば、答えを引き出しやすい雰囲気作りになるでしょう。

ご存じの通り、質問にはオープンな質問とクローズな質問があります。

イエス、ノーで答えられる。もしくはA、Bで答えられるのがクローズな質問。例えば、「月末のバッチは営業時間内に収まっていますか?」「その要望は営業部からですか? 総務部からですか?」といった質問です。

自由に答えられるのがオープンな質問です。「そのアプリケーションで不便なところはどこですか?」といった質問ですね。

この分類とはやや異なりますが、もう1つの質問方法をここで紹介します。それが仮説をぶつける形での質問です。オープンな質問でもクローズな質問でも成り立ちます。例えば、「営業担当のデータ入力が負担になっているように見えます。どうですか?」

仮説をぶつける形での質問のやりとりを、実際にあった例で紹介しましょう。この会話は、まさにこの講座の依頼を受けたときのやりとりです。

fig

僕は「例えばどういうことですか?」と単刀直入に質問するのをぐっとこらえて、「やっぱり仕様検討の時ですかね?」と仮説を込めた質問をしています。すると相手の担当の方も場面を思い浮かべて答えやすくなり、より適切な答えの引き出しにつながったのです。 仮説をぶつける形式の質問には、いくつかの利点があります。

1つ目は、質問の中に質問者の仮説が含まれることで、質問が具体的になって相手が答えやすいことです。漠然とした質問よりも対話的になります。

2つ目は、仮説によって質問者の知識や経験を相手に知ってもらうことができるということです。例えば僕が「やっぱり仕様検討のときですかね?」と言えたということは、僕がSEの仕事の内容をある程度知っていることが相手に伝わります。これによって相手は僕への理解が深まり、会話がよりスムーズに行えることでしょう。

3つ目は、仮説によって文脈を質問者がある程度コントロールできる、ということです。「それって、こういうことではありませんか?」という質問では、質問者が場面設定できます。どういう方向の答えを引き出したいのか、質問をしつつコントロールすることができます。

4つ目は、単純な質問と答えのやりとりに変化が生まれ、より対話的になる、というものです。

fig

ではどんな仮説を持って質問すればいいのでしょう? それはここでの例で挙げているように、それほど鋭いものでなくてかまいません。一般的に考えられることで十分です。ITの世界なら「業務アプリケーションは画面が使いにくいとよく言われていますが、御社もそうですか?」「最近、モバイル対応への要求が高まっているのですが、御社ではいかがですか?」「セキュリティを高めるにはどうすればいいのか、悩んでいるお客様が多いようですね」などといったことでいいと思います。

ここまでのまとめ

ここまでで、お客様や相手から知りたいことを聞き出す環境作りや質問のやりとりについて、いくつかのポイントとそのためのテクニックを紹介してきました。

文脈を共有する
対話的な雰囲気を作る
単純な質問だけでなく、仮説をぶつける形式で質問する

文脈を共有する上で、自己紹介をしたり、相手の立場や役割を知ること。そして質問攻めにするのではなく対話的な雰囲気を持ちつつ質問する上で、仮説を持った質問を織り交ぜること。そうすることによって、質問が具体的になり、また自分のことをより理解してもらえるようになり(当然、相手からの答えによる情報収集も進むため)、より文脈が明確になっていく、ということになるはずです。

お客様の訪問前にいろいろと調べて、あらかじめお客様の状況の仮説を立ててヒアリングに臨むことをされている方は多いかと思います。ここで紹介した「仮説を立てて質問する」というのは基本的にそれと同じことです。あらかじめ仮説を3つ4つ持っておくといい準備になるのではないでしょうか。

そして、ここで紹介した以下の3点については、いずれも実際に練習したり経験を積むことで上手になれると思います。特に仮説をぶつけるには、相手の話を聞きつつ次の質問を考えなければならなかったりするので(僕はモデレータとしてよくそうしています)、機会があれば練習しておくことをおすすめします。

  1. 手短に自己紹介をする。あるいは、訪問チーム全員を手短に紹介する。
  2. 名刺を見ながらお客様の立場を訪ねる。
  3. 仮説を頭の中に入れつつ、その仮説を質問としてぶつける

講習では次のような演習を用意し、新野が客役で何人かの方とロールプレイをしました。

fig

ロールプレイには正解があるわけではありません。簡潔に自己紹介をするのはやってみると意外に難しいですし、実際に仮説を考えつつ相手との対話に応じて質問をすることを経験してみると思ったほどスムーズに仮説をぶつけられなかったりもしますので、そうしたことを体験するのが大事です。それに、自分以外の人のロールプレイを見て自分ならどうするかを考えることは、自分の改善にもつながります。

≫後編に続きます。後編では、ここで紹介したテクニックを1つのフレームワークにまとめて、実践の場で使いやすくします。

あわせて読みたい

編集後記




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本