ヒアリングの多様性
CS Harmony Radio のモデリング編を始めていきたいと思います。よろしくお願いします。
よろしくお願いします。
今回のテーマなんですけど、普段自分がやってる業務の中の内容のプロセスの構造をモデリングしてみた会員になっていて、
何をモデリングしたかというと、ヒアリングですね。
ヒアリングってお客さんにヒアリングする顧客ヒアリングもあれば、
社内の有識者とかもしくは意思決定をされる方にヒアリングすることもあって、
結構いろんな機会がヒアリングって多いと思っているんですが、一方で結構奥深いなとも思っていてですね。
普段の業務とかだとそんなに反省がないんですけど、お客さんにヒアリングとかすると、
結構あれ聞いとけばよかったなとか、あの話するよりこっちの話のが重要だったなみたいな話ってあるじゃないですか。
あると思います。
で、その辺って、じゃあなんでそういうふうに聞いとけばよかったみたいな話になっていくのかなみたいなところで、
分析してみたいなと思ってやってみたんで、それを題材に話していきたいなというふうに思ってます。
これまた例のごとくノートにその記事もアップしているので、それを元にまたその話をしていければなというところで、
今ちょっと少し問題提起みたいな話、僕の方でしたんですけど、
ヤギさん、実際にヒアリングの機会とかって結構ありますか。
ありますあります。お客さんとやり取りするときもそうですし、社内でURLときもあるしっていうので、話聞く機会は多いですね。
で、確かにその、あれ聞いとけばよかったというか、なんだろう、ヒアリングが得意、上手い人と下手な人いますよね。
だからちゃんと情報をつかんでくる人と、そうでもないというか、なんか当たり障りのない話だけ聞いてくる人といるなっていう印象はあります。
ヒアリング機会多いって話なんですけど、それってあれですかね、ヤギさん一人だけでやるっていうよりは、
なんかチームで組んで、まあそういう活動している中で、ヤギさんが代表的にヒアリングする場合もあれば、
誰かにヒアリングをお願いしてきて、その人が聞いてくるとか、そんな感じですかね。
そうですね、たまたまですね。
ヒアリング中の情報の本音を聞き出すための技術と準備
実際たぶん仕事でやる場合、単独でヒアリングをひたすら繰り返していくっていうよりは、
チームで何かしらの目的達成のために必要な情報を得るためにとか、
必要な意思決定をするために情報をヒアリングを通じながら集めてくるみたいなことが多いかなと思うので、
ヒアリングの機会は多いですし、あと複数が関わってやるっていうことが結構ありそうって感じですかね。
ありますね。
そうすると、ヒアリングするときによしよしありますみたいな話もあったんですけど、
ヤギさん自身が気をつけていることとか、心がけていることって何かあったりしますか。
2個あって、1つはヒアリング中の話です。
ヒアリング中の話でいうと、1つは相手側となるべく仲良く時間はなることを意識しますね。
仲良くなると。
本音を喋ってほしいなっていうのが基本あるので、表面的なので終わっちゃうとやってる意味あんまりないなと思うので、
基本的にはその事実を知りたいし、そのためには本当に起こっていることとか、そういう本音みたいなのを聞き出せないといけないなと思うので、
深掘りすることが重要かと思います。
ヒアリング中はそういう感じなんですけど、深掘りするためには準備がいるようで、
ある程度その分野に詳しくなるとか、想定をある程度置いて臨むんですけど、
ただそれも仮説なので、捨てることを厭わないぐらいのレベルで持っておくみたいな、
本件で昔すごい前に話したかもしれないですけど、そういうイメージの感じですね、ヒアリングやるとき。
なるほど、いろいろ話してくれたんですけど、
基本的には本音を聞き出すために気をつけてるってところで仲良くなるみたいなところが出てきたっていうところだと思うんですけど、
ヒアリングのプロセスとヒアリング力の重要性
あとは本音として聞くときに、その仲良くなる以外とかで気をつけたりとか何か心がけてることってあるんですか?
例えばさっき事実を把握したいみたいな話もあったんで、なるべくその実際どうだったかとか、事実的なところを聞くとか。
そういう実際の感想というよりか事象を聞こうとはしますかね、起こってることを実際に。
なるほどですね。結構そこ重要なところで、ヒアリングやるときは事実と意見が混ざりやすいんで、そこをやっぱり区別するって大事ですよね。
そうですね。
ありがとうございます。そんな感じでヒアリング自身も多分やるときに結構テクニックとか注意点あると思うんですけど、今回その辺のヒアリングの中身の話も大事だと思うんですけど、
さっきヤギさんが言ったように準備が実はあって、そこで下調べするみたいな話もあったんで、ヒアリングのプロセス、我々だと基本的にプロセスのモデリングするんで、
ヒアリングプロセスがどうなってんの?みたいな形でノートの方は整理したり分析してるんで、その観点で話を進めていければなと思ってます。
ヒアリングも結構様々だと思うんですよね。目的とかやることって。個人的には厳密に区別がされてるのかどうなのかってちょっと自信がないなと思うんですけど、
インタビューっていう行動とヒアリングっていう行動も結構似て非なるものみたいな区別あったり、人によっても捉え方が違ったりとかっていうので、
ヒアリング自体のイメージって範囲が広いかなっていうところがあるんで、ちょっと一旦ここを決めておきたいなというところで、今回のヒアリングの話って、さっき言ったような本音を聞くみたいなところって、
基本的にはCSの文脈の中でも言ってた期待値ですね。なので、相手の期待値を聞き出して、かつ調整する活動っていうのもヒアリングというふうに今回の話の中では考えてます。
なので、聞き出して、その中でどこら辺が合意するとか折り上げつくポイントどこまでっていうところまでを聞いていくっていう。
なので調整っていうのはある種そこに対する引き出しをどうやっていくかっていうところが調整する活動になってるっていうところで、そこまでがヒアリングの行動というかヒアリングでやることの今回話す範囲かなと思ってます。
あと、ヒアリング力みたいなこともよく言葉としてあるじゃないですか。ヒアリング力が高いとか低いとか。そこもついでに定義しとくと、今言った期待値を聞き出して調整するっていうところを行う活動を成功させる能力の高さみたいなことがヒアリング力に現れてるかなと思うので。
ヒアリングプロセスっていうのを見たときには、このヒアリング力みたいなところっていうのも基本的には入ってくるかなというふうに思います。
結局ヒアリングって期待値調整していくんで、結構力気を変にやらなきゃいけないところがあって、本音の引き出し方も結構バラバラっていうか、いろんなやり方でもう確実的なものはないと思うんで。
そこが難しいところだと思うんですけど、例えば役さんヒアリングしてて、自分のヒアリング力の不足を感じるとかそういうこともあったりしますか?
リュウチョウに喋るタイプじゃないので、自分が。なので、場をつなぐような会話はできないんですよ。比較的考えてから喋るんで。
シーンとなっちゃうところはたまにあって、その辺が居心地の悪さを知ってる可能性があるなって思うときはありますね。
なるほど。冒頭で言ってた仲良くなるみたいな話の時には、こういう変な間を作るっていうのが具合が悪いというふうに感じることもあるって感じですかね。
そんな感じですね。
ありがとうございます。ヒアリング力でさっき言ったように、場つなぐとかそういう部分で、本番ではすごい大事なんですけど、結局プロセスで見た場合って準備があるので、ヒアリング力だけ高いとヒアリングが成功するかっていうと、
僕はそうでないと思ってるんですけど、八木さんも同じ意見ですか?
はい、そうだと思います。やっぱり準備もそうですし、今日の議題かもしれないですけど、その後のアフターも含めて、全体が目的に対しての実際の実施している最中以外の部分でのが大事だなって思いますよ。
ヒアリングっていうのってプロセスで見たときに、まずヒアリングの事前があって、本番のヒアリングの実施があって、ヒアリングの事後があるっていう感じで、プロセスって流れてきますよねっていうところで、結局プロセスなんで、事前の結果が実施の時の結果に影響を与え、実施の結果が事後の結果に影響を与えるってことになるので、どっかでつまずいちゃうと、ヒアリング自体が成功しないっていうことになりますよねっていう話で。
もちろん10秒ごとあるとちゃんと引き出せないし、引き出せたとしても、ちゃんとその後の事後でその内容を拾い上げてまとめて共有できるようにしとかないと抜け漏れちゃうんで、そういう意味だと、どっかでつまずくとヒアリング自体ってうまくいかないですよねっていうことになるかなと。
あと一方でプロセス的な観点で言うと、矢印が左から右に流れてフローっていうか流れ的な感じで表現しがちなんですけど、1回で終わることってほとんどないかなっていうのが僕自身の経験的な感覚なんですけど、八木さんどうですか。
八木さん 今回の趣旨で言うと、北市っていうお客がメインにいて、その人とってなると1回ってことはなくて、例えばビザスクみたいなサービス使って話聞きますっていうヒアリングだとワンタイムだと思うんですけど、普通にお客さんってなったときは1回ってことはないんじゃないですかね。切られたらしょうがないかもしれないですけど。
ヒアリングって基本的には今みたいに一発で終わる話じゃなくて、ビザスクみたいなワンショットのスポットコンサル使うっていうのも、テーマに対しての相手との期待値を調整するために、そのための予備情報とか必要な情報を得るためのヒアリング活動っていうのもあり得るんで、相手が変わってもそういう意味だとテーマ的にはやりたいことがぶれてないので、1回聞いて全くその後使わないっていうヒアリングってないんかなみたいな。
そう思います。
ヒアリングのプロセス
そうなると結構ヒアリングってワンタイムじゃないんで、1回やった後事故でおしまいじゃなくて、その事故が次の事前準備になってくっていうことになるじゃないですか。なのでぐるぐる回ってるんだと思うんですよね、プロセス自体は。
最初のヒアリングして準備をし実施をし事故があって、その事故の結果をまとめて次のまた準備に入るみたいな。そんな簡単に終わらないというかぐるぐる回り。結局はちゃんとプロセス上しっかりそのぐるぐる回るところで、どっかで手抜いちゃうと、結局最終的な結果に大きな影響を与えることにはなるっていう。
極端に言えばそういうことはありえるかな。もちろん失敗したりとか外したりしてもリカバーできれば全然いいとは思うんですけど、基本的には初期段階でつまずいた時の影響が大きい話にはなりますよね。ぐるぐる回ってるからみたいなことになるかなと思います。
そうすると、ヒアリングっていうところでいった時に、継続的な活動として回さなきゃいけないじゃないですか。その時ってぐるぐるさせなきゃいけないんで、使うスキルっていうのは別にヒアリング力だけが必要じゃないっていうことになってくるかなと思うんですよね。
分かると、事前実施事後みたいなところでいったときに、事前っていうところって例えばヤギさんやってることとかあります?
事前はちょっと先ほども触れましたけど、ヒアリング項目を書き出すときもありますが、ヒアリング項目を書き出す前にですけど、こういう内容を想定としては聞きたいっていうのは、想定を作る仮説を置くっていうのは一般的にやられるかなっていう感じですね。項目にするかとか置いていって。
そうですね。なので、仮説を作るみたいなところの力がいるところですよね。もうちょっと言うと、その仮説を作るための必要なインプット情報がいるじゃないですか。ゼロからは仮説は作れないので。
そのとりです。
リーディング作業が比重が大きいかなって思うんですよね。事前のところって。
はい、はい、その通りですね。
で、それをもとに仮説を作ってインタビューの内容を設計していくみたいなことになるかなと。その後に、実際の実施でヒアリングでさっき話したような期待値調整していくっていうところで、割と仲良くなったりとか本で引き出すみたいなところとかで、その場に応じて結構臨機応変に対応していくことで、
その手を変え品を変え、そこの相手からの期待値を引き出していくっていうところで、ここはまさにヒアリング力が求められるところかなと思いますと。
次に事後っていうのはヒアリング聞いた後っていうところなんで、基本的にそのヒアリングした内容を整理してまとめていくところになると。
事前の準備
やってることってまとめ作業が何かあります?
単純に分かりやすいのが議事録作るっていうパターンのやつと、あとは基本連続してヒアリングとかするようなパターンだと、それをもう一度絵にしてみてまとめますみたいなのが大体入ってくるっていうイメージですかね。
絵にしてまとめるっていうのは何を絵にしてまとめる感じなんですか?
聞いた意見を。
テキストみたいなのをブロックで貼り出して、マッピングとかグルーピングするとかそんな感じですかね。
例えばですね、今回聞いたことはこういう認識ですっていうのを形にするっていう。
だいたい文字だと分かりづらいんで絵にしましょうみたいなのが多いかなって感じ。
絵にするっていうのってやっぱりなんかメンバーと議論するとか、チームで共有して意見擦り合わせたりとかするためにやるって感じですかね。
それもありますし、実際お客さんに次のタイミングにヒアリングする時に直接見せるも含めて。
見せるところも含めて。
議事録まとめるみたいな話の前に、基本的には何を書くべきかとか、何を整理すべきかみたいな話が入ってくるっていうことですよね。
そうですね。
ヤギさんの今の絵にするみたいなやつって割とレアケースかなと思うんですけど、
だいたいチームでやってるっていう場合に、結構多いパターンって誰か一人が議事録まとめてきて、それで終了ってことになりません?
そうですね。議事録誰かが作って、見てください、直してくださいって言って、多少の指摘が入って直して終了っていうのがよくあるパターンですね。
事後のところってライティング力みたいなところで、書くってところが結構求められるかなと思うんですけど、
事後の整理
そうですね。
一方で大事なところって、いわゆるリーディングとかヒアリングで相手から聞いてきたインプット情報っていうのを、ある種議事録でアウトプット転換してるってことじゃないですか。
はい、その通りですね。
インタビューも一人だけ聞いてる場合じゃなくて、結構複数に立ち会うこともあるじゃないですか。
はい。
まとめるのは結構一人になってるので。
そうですね。
アウトプット転換するときに、一人の人の情報のアウトプット転換してるんで、その複数の人の観点や認識がいっぱい落ちるんですよね。
うん、落ちると思いますね、はいはい。
プロセスの構造上。なので、さっき彰さんが言ったように演技するみたいな話とか、やってないんじゃないかなみたいなことを感じるんですけど、その辺どうですか。
それはそうじゃないですかね。特に議事録でありがちなのが、最近だと録音してチャットGPTに配すみたいな話もありますけど、
要はお客さんが言っている言葉をそのまままとめるパターンがたまにあるんですけど、それすると、実はお客さんが言っている言葉の認知というか定義と、こっちが取る認知という定義が違っていることがあり得て、
そもそも認知が違っているかどうかっていうのを明らかにするには、聞いた言葉そのまま返しちゃダメなんですよ。これってこうですかって返還しなきゃいけなくて、
それは多分、複数人一緒にヒアリングとかの場で聞いてたとしても、それぞれ多分認知違う取り方をしてるんで、
持ち替えたときにチーム内でこういうことでしたよねって一回やらないと、それぞれ違うことを思っている状態なので、
そういう全体をもうちょっと見るという作業が入るのが、おそらく精度が上がるような気はしますね。
そうなんですよね。だから、僕も同じような感覚を持ってて、ヒアリングした後に認識どうだったとか、こういうことがお客さんとしては期待値なんじゃないかとかっていうところの、
なんかチームでのすり合わせ、いわゆる振り返りみたいなことが設計できてないのではみたいなことをプロセスを整理してて感じたんですよね。
一般的にはそうかもしれないですね。
一人でやってる場合はいいと思うんですよ。もうなぜなら一人だから、もう一人でライティングをするときに脳内でそれをやるんで全然いいんですけど、
複数で行ったとしたときも、そこのアウトプット転換のところの一人だけにやらせてるんで、もったいないなみたいなことが、
プロセス的にいきなりライティングに飛んでるなみたいなことが見えてきた感じなんですよね。
実は振り返りをするっていうところって、基本的にさっき言ったように認識を合わせるなんで、
基本話す必要があるじゃないですか。自分の認識を。それを話しながらすり合わせていくんで、
どっちかというと振り返りでスピーキングみたいなことやってるんだなっていうふうに最近この整理をしたら気づいたんですけど、
スピーキング自体が抜けているのではないか。
そうですね。それはそうなんじゃないですかね。
今言ったように、アウトプット転換するときの肝が話すことなんじゃないかなっていうのが、今回モデリキューの中でいうとツボンで、
話したらヒアリングの解像度上がるんじゃないのって思ってるんですよね。
なぜなら、一人の分析観点や認識だけじゃなく、複数の人の認識があれば、自分が気づいてなかった情報もインプットされるし、
解釈の違いから、よりフィットした解釈に近づくってことは、お客さんの心意に1人よりも2人とか3人とかの方が近づきやすくなるっていう可能性が高まるところがあるので、
この活動をやるっていうのが結構お勧めなんじゃないかなっていうふうに整理してて思い始めてるというか、思っているという感じですね。
ヤギさんがさっき言った図式化するっていうのも、ある種そういう振り返って次のネクストをより良くするための活動だと思うんですけど、そういう理解で合ってますか?
そうでいいんじゃないですかね。基本、書き出す前に、一旦情報を棚卸しするというか、書き出してっていう意味合いですね。
棚卸しですね。
僕らも実はチームで仕事でやってるときに、最終的に次の打ち合わせのための資料とか作るんですけど、その前にチーム内でどうだったかっていう、ラップアップに近いんですけど、
振り返りをやってて、そっからどういう資料を作ろうか今度っていう話をだいたい毎回してるんですけど、それが近いのかなと聞いてました。
おっしゃる通りで、ラップアップだと思うんですよ。ただ、残念なことに、ヒアリングとかってやると、結構そこの本番までの準備の方に比重が高くて、終わった後って結構、終わったって感じで気が抜けるというか、
振り返りまでやってワンタンっていうか、振り返ってちゃんとまとめるところまでしっかり作ってワンタンって感じなくて、なんか実施のところに結構ピークが来るような感じがちょっとするんですよね。
グラフで言うと、徐々に徐々に上がっていって、実施でストーンと落ちて、また徐々に徐々に上がっていくみたいな感じになってるんで、振り返りのところが結構お休みしちゃう場合が、プロジェクトによってはあるかなみたいな風に感じると思います。
場合によっては若者に議事録書かれる、まあ議事録は大変ですからね。
大平 そうですね。議事録係がいて、書かせたことでなんか終わっちゃって。
終わっちゃうんですね。
ヒアリングの解像度向上の必要性
大平 で次のヒアリングみたいな話になって、また行くけど、実は認識の擦り合わせとかアップデートをする機会があんまりないんで、ヒアリング自体の質が上がりづらくなってる、解像度が上がりづらくなってるんじゃないかなみたいなことを、そうすると同じような話を何人にも聞いてしまうみたいな。
大平 だけどヒアリングの振り返りで、新たな仮説とか知見とかそういうところを得られたら、次の聞き方変わるはずなのにみたいなことちょっと思ってるんですね。
それは思います。ダメなヒアリングのパターンでよくあるのは、まあそういう議事録書くんですけど、お客さんが言ったキーワードみたいなのを拾ってくるようなヒアリングの仕方をする人たちがいて、
それって、キーワードそのものは言ったじゃないですかみたいな感じで、後で話を繰り返して、あの時ああ言いましたよねみたいな話になって、なんかうまくいかないような感じでよく言うなと思ってて、ロジョガードのキーワードそのもののどういうことのことなのかって認識の擦り合わせじゃなくて、なんか言いましたよね、その言葉みたいな。
本当にそれがエビデンスとか現地として抑えられる。じゃなくて、たぶん本来はそれを言った背景、意図っていうのをヒアリングした側がちゃんと理解して、じゃあそういう認識やそういう意図だったら、こういう話をしたりとかこういう質問をして、より深掘ってこうみたいな話にたぶん本当はできるといいなって。
若干誘導っぽいかもしれないですけど、ヒアリングプロセスの中で、個人的にはこのスピーキングっていうのがかなり大事なんじゃないか。他も大事なんですけど、ない箇所にされてちょっといるのではないかみたいなふうに感じるんですけど、八木さん的にはどうですか?ここまで話してきて、その辺の認識とか。
八木さん そういう意味で言うとそこはすごくアグリで、自分たちはそうならないように振り返りやってますし、ダメな人たちはやってないなっていうのは思うので、これはそうかなって思う。
その意味だとオススメって、スピーキングする機会をもう自動的に設定するのがいいんだと思うんですよね。話すだけなんですけど、新鮮なうちに話すと前向きな議論になりやすいかなと思ってるのと、抜け漏れが減るんで、振り返りの時間をもうスケジューリングしてしまうっていうのがオススメなんじゃないかなって。
実際自分もそういう意味だと、やってるプロジェクトとやってないプロジェクト混ざってるんですけど、やってたプロジェクトのほうがしっかり進捗して、プロジェクト的にも成功したなみたいな感覚あるんですよね。こんな話じゃなかったよねみたいなとか、あれこんなふうだったっけみたいな、なんか変な認識のすり合わせみたいなものが時間が経てば経つほど発生すると思うんですけど、その辺が最初の新鮮なうちに議論してもう議事録にちゃんと言語化できてると、
もうそういうことが発生しづらいんで、認識が話していく中でも整っていくっていうか、アウトプットしていくことをみんながしたほうがいいなあみたいなことがあって、誰かが議事録書くと、実はアウトプットしてる人って一人で、インプットしてる人は複数にいるのにっていう、そういう抜けがあるなあみたいなことが、今回のプロセスの構造の整理をしながら改めて気づいたのとは、自分も確かにそのプロジェクトをやってる時とやってない時で成果違ったのかなと。
成果違ったなあみたいなことを感じたんで、整理してみました。
そんな感じなんですけど、ヤギさんどうですか?
ヤギさんいいんじゃないですか。
ノートのほうを見てもらう、この4小弦で書かれているので、きれいな整理だなと思いますんで。
興味ある方は、今の話でノートを見ていただくと、こういう考え方でヒアリングプロセスって見れる。ヒアリングのプロセス構造って捉えれるんだなあみたいなことがわかるといいのかなと思うんで、ぜひ読んでいただければなと思います。
ということで、本日は以上としたいと思います。ありがとうございます。
ありがとうございます。
