お客さんへのヒアリング、意思決定のための打ち合わせ、プロダクトに関するユーザーインタビューなど、ITエンジニアの仕事をしていると、その時々の目標やテーマにあわせて「人に質問をする」「話を聞きだす」機会が発生します。
必要な話がきちんと理解できるように、相手の意図を十分に汲み取れるように、注意深く話を聞くようにするものの、結局のところは別の人間同士。蓋を開けてみれば、お互いの理解に齟齬があり、たくさん説明したのに、意図が正しく伝わっていなかった……なんてことも少なくありません。
こういった「理解のズレ」を無くすために、聞き手はどのようなことを心がければ良いのでしょうか。良い質問の仕方とは？ そして、相手にきちんと情報を示してもらうための「良い聞き方」とは、どのようなものなのでしょう。
特定非営利活動法人しごとのみらい・理事長の竹内義晴さんに尋ねてみたところ、「そもそも、コミュニケーションは誤解が生まれやすい特徴がある」のだとか。「わかりあえない」ことを受け入れつつも、「それでもわかりあう」ための方法を伺いました。
竹内 義晴（たけうち・よしはる）さん
特定非営利活動法人しごとのみらい理事長。コミュニケーションや組織づくりの企業研修・講演に従事している。元は技術肌のプログラマー。「ストレスをかけるマネジメント」を受け心が折れかかった経験から、コミュニケーションの必要性を痛感し、コミュニケーション心理学やコーチングを学ぶ。著書に、『Z世代・さとり世代の上司になったら読む本 引っ張ってもついてこない時代の「個性」に寄り添うマネジメント（翔泳社）』などがある。
「焼きうどん」でも、理解のズレが起きる理由
——ITエンジニアの仕事に限らず、そもそもコミュニケーションにおいて「誤解が生じやすい」のはどうしてなのでしょうか？
竹内さん：まず前提として知っておきたいのが、コミュニケーションを行うときに起きる、人は自分の思考や体験のすべてを言葉にできない、という特徴です。そうですね……例えば、今日のお昼に何を食べたか、覚えていますか？
——今日は焼きうどんでした。
竹内さん：具材は何が入っていましたか？
——ええと……玉ねぎとニンジンと、豚肉だったかな？
竹内さん：紅しょうがとか、トッピングはしていない？
——そうですね。かつお節はかけました。
竹内さん：なるほど、ありがとうございます。いまお昼のメニューについていくつか質問をしましたが、恐らく、質問に答える際「今日食べた焼きうどん」の映像を頭の中で思い出しながら話していたと思います。
しかし、お昼の絵が浮かんでいるはずなのに、私の「お昼に何食べた？」という質問に対して、「玉ねぎと豚肉が入っていて、かつお節がかかっている焼きうどん」ではなく、シンプルに「焼きうどん」と答えられましたよね。
竹内さん：これが、「人は自分の思考や体験のすべてを言葉にできない」ということなんです。頭の中にはイメージが浮かんでいるのに、言葉にする時は無意識に「こういう具材が入っていた」という情報を削除して、「焼きうどん」という言葉がアウトプットされた、という状況ですね。
——無意識のうちに行っていました……！ ですが、「昨日、何してた？」と聞かれた時、「朝7時に起きてから……」と逐一説明するのではなく、「映画を観てきた」などの断片的な内容で答えることがほとんどですから。会話内容から考えるとごく自然な行為ですよね。
竹内さん：そうですね。それで誤解が生じていないなら大丈夫です。しかし、「情報の削除」の結果として端的にまとめられた言葉では「焼きうどんの具」や「コンビニで買ったのか自炊なのか」などの細かい情報は伝わらないんです。もうこの時点で、話し手と聞き手の間で「全く同じ焼きうどん」をイメージするのは不可能ですよね。
話し手が「焼きうどんです」と言った時点で、もうコミュニケーションギャップは発生しています。なので、まずは「人は、思考やイメージをすべて言葉にすることはできない」という前提に立つ必要があるんですよ。
——伝わりやすくするために「情報の削除」をしているものの、それで伝わらなくなってしまう場合がある、と。
竹内さん：また、今回は「焼きうどん」という皆が同じような絵を想像できそうなものだからこそややこしいんです。仮にいままで聞いたことがない料理だったら、「それってなんですか？」と尋ねれば、理解のギャップをある程度は埋めていくことができますよね。
しかし焼きうどんは、日本人の多くがよく知っているメニューです。そのため、お互いが「ああ、焼きうどんね」と、なんとなく納得してしまう。話し手は必要以上に説明をしないし、聞き手も細かく聞こうとしない。その結果、違う具材で作られているところを想像したり、勝手に山盛りの紅しょうがを盛り付けたりと、解釈にズレが出てしまうんです。
——通じ合っているつもりになったときこそ、コミュニケーションはより注意深く行ったほうが良さそうですね。
竹内さん：エンジニアとユーザーの場合、ユーザーは自分の仕事や課題は知っているけどITのことは知らないし、エンジニアはその逆で、ユーザーの仕事や課題を知らない。しかも、ユーザーが「こんなシステム作って欲しいんだけど」と発した言葉は、情報がかなり削除されています。
お互いが伝えたいことを理解しあうのは本当に難しい。「たぶんこんな意味だろう」と思ってやりとりをしてしまうと、それがギャップの原因になるんですよね。コミュニケーションは、話し手の言葉を聞き手が解釈して受け取り、また言葉を発することの繰り返しです。なので、言ってしまえば「お互いの理解があっている方が、奇跡」なんです。
質問は、構造を意識して投げかけていく
——コミュニケーションギャップを埋めていけるような「聞き方」のコツはあるのでしょうか？
竹内さん：「聞き方」というのは、大きくわけて2種類あります。まずは、相手に問いを投げかけ、答えてもらう「質問」。そして、相手の言っていることにひたすら耳を傾ける「傾聴」です。
——それぞれ詳しく教えてください。まず「質問」とは、得たい情報を問いにして、それに答えてもらうという、一般的なヒアリングの方法に近いものでしょうか。
竹内さん：そうですね。両者を比較したときに意識したいのが、質問は「こちらの問いを通して、相手の思考に介入する」行為である、ということです。
先ほどの「お昼になにを食べましたか？」という質問を例にあげると、話し手は、その質問を投げかけられてはじめて、お昼のメニューを思い出そうとして思考を働かせますよね。質問する、ということは、「問いに対して、相手に考えることを促す」行為なんです。
例えば、業務の課題をヒアリングする際、「どうして業務がうまく行っていないんですか？」と聞くのと、「どうすれば業務がうまく行くと思いますか？」と聞くのとでは、相手の考える内容と、答えが変わってきますよね。質問する側が、「何を聞き、何を答えてほしいのか」を意識して問いを立てるのはとても大切なことなんですよ。
——では、「良い質問」とは具体的にどのようなものになるのでしょう。
竹内さん：聞きたい内容にも左右されるため、一概に「これが良い聞き方」とまとめるのはとても難しいのですが、シチュエーションを問わずに意識するのと良いと思っているのが、「筋道を意識して質問すること」です。
例えば、「このシステムは、何のために作るのでしょうか」という質問と「ここの入力項目は、数字以外の文字を入れますか」という質問は、粒度が全く異なっていますよね。
粒度がバラバラな問いかけをされたり、「現在の課題は？」「将来的に、どう解決したいんですか？」「現在の課題について、もう少し具体的に教えてください」のように、時系列を無視して交互に質問をされたりすると、聞かれる側は「どういう意図で聞いているんだろう？」「なにを聞きたいんだろう？」と答え方に困ってしまいます。
——つまり、「今は、これについて話しているぞ」という前提が共有できない状況ですね。
竹内さん：良い質問とは、「どういう言葉で質問するか」ではなく「筋道を立てて質問できていること」、つまり「構造的であること」だと思うんです。
「構造的であること」の他の例では、「抽象から具象（ぐしょう）へ」を分けて質問するのもいい方法です。ここでいう「抽象」とは、システムを作る目的や意味、価値など、高い視点でとらえる質問。「具象」とは、「どんなパッケージを使って」「どんな機能があって」「どんなシステム構成にするのか？」のような、物事を具体的にし、解像度をあげる質問になります。
「どんな目的があって」「それを実現すると、どんな課題が解決して」のように、最初に抽象度の高い質問をして、目的を明確にする。そののちに、「では、そのシステムを実現するためには……」のように、具体的な質問をしていくと、流れが自然でいいですよね。
構造的に聞いていくことのメリットは他にもあって。それが、「話し手も、自分の思考を整理できる」ことです。自分の発した言葉を一番近くで聞いているのは自分自身ですから。話しながら、経緯や必要は情報を改めて精査することができるんです。
——目的と意味など、抽象的で大きな質問を通して大まかな方針を共有し、具体的な小さな質問でディティールを詰めていく、というイメージでしょうか。
竹内さん：そうですね。これはあくまでも私のイメージですが、ITエンジニアの場合は、他の職業よりも「抽象的で、大きな質問」をすることを意識すると良いかもしれません。
——それはどうしてでしょう？
竹内さん：情報システムは、基本的には「現状の課題を、解決するための手段」として採用されるものですよね。ITエンジニアは「その手段を、どうやって実現していくか？」を考えるのが仕事です。なので、エンジニアさんは「どんなシステム構成で」「どんな言語を使って」「どんなデータのやりとりで」のような「具現化すること」が得意だし、そちらに注力して質問をしてしまいがちです。
しかし、その前提にある「そもそも、このシステムは何のために作るのか」という目的や方針を理解できていないと、プロジェクトが行き詰まった時などに、立ち返るべき方針を見失ってしまうんです。
逆に、「そもそも」が理解できていれば、方向性を見失ってもリカバリーしやすくなるし、お客さんの要望に対して「それをやるなら、この方法がいいですよ」と提案することもできる。「具体的にどうやるか」を意識し過ぎている方は、もう少し抽象度の高い質問を意識してみても良いかもしれません。
意外と難しい、じっくり聞く「傾聴」
——では、先ほどもうひとつ伺った「傾聴」とは、どのような聞き方なのでしょうか。
竹内さん：傾聴は、「自分の意見を極力口にせずに、相手の言葉に耳を傾ける」ことです。聞き手が先導するのではなく、ひたすら相手の言い分を聞く、という言い方がわかりやすいかもしれません。
人って、なぜだか他人の悩みを聞いていると自分も喋りたくなってしまうんです。すぐに自分なりのアドバイスをしてしまったり、システムの話だったら「こうすれば良くないですか？」と提案してみたくなったりしてしまう。多くの人が、驚くほど人の話を聞いていないんです。
ヒアリングの場のお客さんとしては、自社の課題にじっくり耳を傾けてほしいし、何なら自分たちのことをもっとよくわかってほしい。そんな時にピントのずれた提案をされてしまうと……？
——「もう！」となりますね……。
竹内さん：なので、まずは自分が話したくなるのをこらえて、相手の話をじっくり聞く。そうすれば、お客さんも「この人は、自分たちの悩みに寄り添ってくれている」と感じて、信頼感を持ってくれるかもしれません。
「傾聴」は、「あれはどうですか？」「これはどうですか？」と急かすように質問するよりも、相手が話したくなるようなシチュエーションを作るためにとても大事なことだと思います。
——「聞くこと＝質問すること」ではないんですね。そういった「質問」と「傾聴」のコミュニケーションで活用できそうな「聞き方のテクニック」があれば、教えていただきたいです。
竹内さん：例えば、「聞いている姿勢」を示すために、相手の言ったことを相槌でそのまま繰り返す「オウム返し」といった、個別のテクニックもあるにはあります。
しかし「オウム返し」は相槌の方法としてメジャーになりすぎていますし、機械的に相槌を打たれると、「なんかわざとらしいな」「聞いてもらっている感じがしないな」のように、嫌な気持ちを誘ってしまうんですよ。
——会話のなかで「あ、この人オウム返ししてるな」と気付かれる、という感じでしょうか。
竹内さん：なので、テクニックに傾倒するのは、正直あまりおすすめできません。ですがその前提のもと、比較的やりやすくて、お客さんとの関係を構築しやすいテクニックを挙げるとするならば「バックトラッキング」でしょうか。
バックトラッキングとは、相手の言葉をそのまま返すのではなく、「あなたがおっしゃりたいことは、つまり、こういうことですね」のように、相手が言わんとしていることを要約し、確認しながら話を聞く方法です。相手が言った言葉を要約して伝えてもいいですし、自分なりの言葉に言い換えてもいい。
それで、相手が「そうそう、そういうこと」と言ってくれたら理解はおおむね間違いないし、「いや、ちょっと違うんだよな」と言われた場合は、改めて説明をしてもらえばいいんです。
この「私はこういうふうに受け取りましたが、合っていますか？」というやりとりを繰り返せば、解釈のずれはかなり抑えられるし、「そうそう、それでね」と次の話にも展開しやすい。「この人は理解してくれている」と思ってもらえて、相手とも関係が築きやすくなるかもしれません。傾聴が上手な人は、こういったコミュニケーションを丁寧にできる人なのだと思います。
完全な理解は難しいが、「それでも耳を傾ける」
——いろいろな方法を教えていただくなかで、「聞くって、こんなに大変なんだ」とあらためて驚きました。でも方法はとてもシンプルですので、これだけのことが実践できればコミュニケーションギャップはだいぶ埋めることができそうですね。
竹内さん：しかし、いろいろな手を打っても、どうしても「解釈のずれ」や「情報の聞き漏らし」は起きてしまうんですよ。なぜなら最初にお伝えしたように、人はすべての思考を言葉にできないから。
竹内さん：コミュニケーションギャップによるリスクをもっと減らしたいのであれば、それは仕組みで解決していくのが現実的だと思います。例えば、「開発にあたって、お客さんに絶対に聞いておかなければいけない質問リスト」をあらかじめ用意しておけば、聞き忘れのリスクは減らせますよね。
意図のズレに対処するなら、開発プロセスのなかで中間チェックポイントを設けて、プロトタイプをお客さんに見てもらうのもひとつの方法です。あとは、作っているものに何かしらの違和感を抱いたときに、すぐにチーム内で共有できる雰囲気を作っておくのも大切ですね。
——結局のところ、より良い方法を考えながら「とにかく丁寧に、相手の言葉に耳を傾ける」ことに尽きるんですね。
竹内さん：マーケティングの世界でよく言われる話で、「ドリルを欲しがっているお客さん（※）」のエピソードがあるじゃないですか。
質問を通して得られた回答もそれと同じで、言葉にしているのはすべての思考やイメージのうちのごく一部なんですよ。その背景にあるものを理解しようとし、本当に伝えたいことはなんなのか、を考えるのが大事なのかもしれないです。
※ 「ドリルを欲しがる客が本当に必要なのは、ドリルではなく穴」という、マーケティング領域で顧客目線に立ったニーズ理解の重要性を示すのに用いられる例え。元ネタはハーバード・ビジネス・スクール名誉教授のセオドア・レビット博士の著書より
——「完全に理解し合うのは難しい」という前提に立ったうえで、それでもコミュニケーションギャップを埋められるように尽くす、と。
竹内さん：そうですね。いまおっしゃった「それでも」という言葉、私も大好きなんです。
完全に理解するのは難しい、それでも意識して聞く。すべてを伝えるのは難しい、それでも言葉を尽くす。そういった姿勢が、コミュニケーションギャップを埋めるための第一歩なんだと思います。
文＝伊藤 駿／図版とイラスト＝藤田倫央／編集＝ノオト
