エンジニアのコミュニケーション力とは？「話が通じる人」になるために意識したいこと
エンジニアにもコミュニケーション力が必要だ。
これは、よく言われることです。
ただ、私は長くエンジニアとして働いてきて、
コミュニケーション力＝話が上手いこと
ではないと感じています。
社交的であることでもありません。
雑談が得意であることでもありません。
仕事の中で本当に大切なのは、
相手と認識を合わせること
だと考えています。
私が長く仕事をする中でたどり着いた「技術より人を見ろ」という考えについては、
「技術より人を見ろ」20年以上エンジニアをしてたどり着いた仕事の教訓
でも詳しく書いています。
私はこれまで、コミュニケーション不足が原因でうまくいかなかった経験を何度もしてきました。
でも振り返ってみると、その原因は話し方のテクニックそのものではありませんでした。
むしろ多かったのは、
「経験があるから大丈夫だろう」
「前と同じ対応で問題ないだろう」
「今回は確認しなくても大丈夫だろう」
という油断や思い込みです。
つまり、
コミュニケーションが足りなかったというより、
そもそもコミュニケーションが必要だと気づいていなかった。
ここに大きな問題がありました。
文章より動画で見たい方はこちらからどうぞ。
コミュニケーションの失敗は「話し方」より前に起きている
経験を積むと、仕事は速くなります。
判断も早くなります。
過去の経験から、
「これはこうすればいい」
と予測できることも増えます。
これは、本来は強みです。
でも、その経験が油断につながることがあります。
以前うまくいったから、今回も同じでいい。
この程度なら、わざわざ確認しなくても大丈夫。
自分が分かっているから、相手も分かっているだろう。
そう思い込んで進めてしまう。
そして問題が起きたあとに振り返ると、
「確認しておけばよかった」
「思い込んでいた」
「あのとき油断していた」
と気づく。
私にも何度もありました。
報連相の方法を知らなかったわけではありません。
確認するという行為を知らなかったわけでもありません。
ただ、
問題ないと思い込んでいたから、確認しようとしなかった。
だから私は、
コミュニケーションの前に、
まず自分自身を疑うことが重要だと考えています。
本当に大丈夫か。
前回と条件は同じなのか。
自分の認識に抜けはないか。
相手も同じ理解をしているのか。
考え抜いているか。
油断していないか。
慢心していないか。
こうした自問自答を繰り返すことで、
初めて「確認した方がいいかもしれない」と気づける。
コミュニケーション力は、
話し始める前から始まっているのだと思います。
一番大切なのは「話す力」より「聞く力」
コミュニケーションに必要なスキルの中で、
私が最も重要だと思うのは、
聞く力
です。
人によって、話し方は違います。
話を整理して簡潔に話せる人もいます。
少し遠回りしながら話す人もいます。
途中で考えながら話す人もいます。
だからこそ、
聞き手は相手の話し方に合わせる必要があります。
私は、
相手の話をできるだけ最後まで聞くことを大切にしています。
途中で否定しない。
必要以上に遮らない。
まず、話したいことを出し切ってもらう。
話し手にとって、
「最後まで聞いてくれる」
という感覚は大きいと思います。
途中で何度も遮られるより、
安心して話すことができます。
そして、
「この人には話が通じる」
と感じてもらいやすくなる。
話が上手いことより、
まず聞いてくれること。
私は、それがコミュニケーションの土台だと思っています。
「聞く」とは、黙っていることではない
ただし、
最後まで聞くというのは、
何も考えずに黙っていることではありません。
むしろ逆です。
聞き手は、
頭をかなり使います。
相手は何を言おうとしているのか。
事実は何か。
困っていることは何か。
何を求めているのか。
どこが重要なのか。
話を聞きながら、
頭の中で整理し続ける必要があります。
理解できない部分があれば、
質問する。
認識が曖昧なら、
確認する。
そして最終的には、
「つまり、〇〇と言いたいのね」
と自分の言葉で言えるくらいまで理解する。
そこまでできて、
初めて「聞いた」と言えるのだと思っています。
話し手の説明が分かりにくいこともあります。
でも、
「分かりにくく話す相手が悪い」
で終わってしまえば、
コミュニケーションは成立しません。
伝える責任を話し手だけに置くのではなく、
聞き手にも、理解しようとする役割がある。
私はそう考えています。
話の腰を折ると、両方が話しにくくなる
聞き手として、
できるだけ避けたいと思っていることがあります。
それは、
話の腰を折ること
です。
最後まで聞けば分かることを、
途中で質問してしまう。
自分が気になったことを、
相手の話を遮ってまで確認する。
こうしたことは、
ついやってしまいます。
でも、
話し手は自分の中で、
ある程度ストーリーを組み立てて話しています。
最初に背景を説明して、
次に経緯を話して、
最後に言いたいことを伝える。
その流れを途中で壊されると、
話し手は話しにくくなります。
どこまで話したのか分からなくなる。
何を話そうとしていたのか忘れる。
話す順番が崩れる。
結果として、
聞き手側も全体像を理解しにくくなる。
両者にとって、
あまり良い状態ではありません。
もちろん、
理解に必要な確認まで我慢するという意味ではありません。
話の流れを壊してまで、
自分の疑問を優先しない。
最後まで聞けば分かりそうなことなら、
まず聞き切る。
それから確認する。
この順番は大切だと思っています。
聞く姿勢は、言葉以上に相手へ伝わることがある
聞くときには、
内容だけではなく、
姿勢も意識しています。
手を止める。
相手を見る。
視線だけではなく、
体ごと相手の方を向く。
適度に相槌を打つ。
急かさずに聞く。
こうした姿勢は、
「あなたの話を聞いています」
というメッセージになると思っています。
逆に、
パソコンを操作しながら、
画面を見たまま、
返事だけしている。
それでは、
たとえ内容を聞いていたとしても、
話し手には
「本当に聞いているのかな」
と思われるかもしれません。
私は、
相手に安心して話してもらうためにも、
聞く姿勢を見せることは大切だと考えています。
伝えるときは、最初に「何の話か」を示す
今度は、
話す側についてです。
私がまず意識しているのは、
これから何について話すのかを最初に示すこと
です。
たとえば、
「〇〇の件について、結果を報告します」
といった形です。
なぜこれが必要なのか。
聞き手は、
あなたから話しかけられる直前まで、
別の仕事をしています。
別のことを考えています。
別の問題に集中しています。
そこへ突然、
何の前置きもなく話し始める。
すると聞き手の頭には、
まず、
「何の話？」
という疑問が出てきます。
その疑問を抱えたまま話を聞くと、
理解しにくくなります。
だから私は、
最初に話の入口を作ることを意識しています。
今から何の話をするのか。
報告なのか。
相談なのか。
確認なのか。
それを短く伝える。
それだけでも、
聞き手は頭を切り替えやすくなります。
その次に「結論」を伝える
話のテーマを伝えたら、
次に結論を話します。
仕事上の報告では、
細かい経緯より先に、
結果を知りたい場面が多いと感じているからです。
問題があるのか。
問題ないのか。
すぐに対応が必要なのか。
少し様子を見てよいのか。
自分は何か行動する必要があるのか。
聞き手は、
結論を聞くことで、
次に何をするべきかを考えます。
だから、
自分が話したい順番よりも、
相手が理解し、判断し、行動しやすい順番
で話すことが重要だと思っています。
経緯から説明した方がよい場面もあります。
それでも、
相手がまず何を知りたいのかを考える。
そこから順番を決めることが大切です。
「誰に話すか」で伝え方は変わる
伝えるときに、
もう一つ大切だと思っていることがあります。
それは、
聞き手が誰なのかを考えること
です。
社長。
経営層。
エンジニア。
他部署。
若手。
同じ内容を話すとしても、
聞きたいポイントは違います。
経営層なら、
事業への影響や判断材料を知りたいかもしれません。
エンジニアなら、
技術的な原因や仕組みを詳しく知りたいかもしれません。
他部署なら、
自分たちの業務にどんな影響があるかが重要かもしれません。
若手なら、
前提から説明した方が理解しやすいかもしれません。
ただし、
肩書だけで決めつけるのも違います。
大切なのは、
その人が何を判断するために、この話を聞いているのか
を考えることです。
だから私は、
すべての相手に通用する魔法の話し方はない
と思っています。
誰に話すのか。
その人は何を知りたいのか。
どこまで知っているのか。
何を判断する必要があるのか。
そこを考えず、
自分が言いたいことだけを一方的に話しても、
伝わりません。
話す前に、
相手の立場を考える。
それが大切です。
相手によって伝え方を変えるには、まず相手の特徴を知る必要があります。私は、得意・不得意や関わり方を把握するために「人間マップ」という考え方も使っています。
言葉だけで伝わらないなら、手段を変えればいい
相手が本当に知りたいことが分かれば、
伝える方法は一つではありません。
口頭で話す。
文章にする。
図を書く。
絵にする。
データを見せる。
実物を見せる。
画面を共有する。
方法はいろいろあります。
大切なのは、
話すことそのものではありません。
相手に理解してもらうこと
です。
言葉で伝わりにくければ、
図を使えばいい。
文章の方が分かりやすければ、
書けばいい。
実物を見た方が早ければ、
見せればいい。
一つのやり方にこだわる必要はないと思っています。
相手に伝わるために、
必要な手段を使う。
それでいいのだと思います。
「話が通じる人」とは何か
ここまで書いてきたことをまとめると、
私が考える「話が通じる人」は、
話が上手い人ではありません。
自分の思い込みを疑う。
相手の話を最後まで聞く。
聞きながら理解しようと考える。
分からないところを確認する。
相手の主張を自分の言葉で要約する。
相手が何を知りたいかを考える。
相手に合わせて伝え方を変える。
必要なら、
言葉以外の手段も使う。
そうやって、
少しずつ認識を合わせていく人です。
だから私は、
コミュニケーション力とは、
相手と自分の認識を丁寧に近づけていく力
だと考えています。
私は、コミュニケーション力をエンジニアの市場価値を支える重要なコアスキルの一つだと考えています。
一度で完璧に伝わることはありません。
聞き間違いもあります。
説明不足もあります。
思い込みもあります。
だから、
聞く。
確認する。
伝える。
また確認する。
この繰り返しが必要です。
まとめ｜コミュニケーションは、相手を理解しようとするところから始まる
エンジニアに必要なコミュニケーション力は、
話術だけではありません。
むしろ、
話す前に大切なことがあります。
本当に自分の認識は正しいのか。
確認しなくてよいのか。
相手は何を言いたいのか。
何を知りたいのか。
そうやって、
自分を疑い、
相手を理解しようとすること。
そして、
相手に合わせて伝えること。
管理職として仕事を任せるときも、伝え方を一方的にせず、相手がどう理解したかを確認することが大切でした。
私は、
そこにコミュニケーションの本質があると思っています。
話が上手である必要はありません。
でも、
相手を理解しようとすることはできます。
自分の思い込みを疑うこともできます。
相手に伝わる方法を考えることもできます。
そうした積み重ねが、
「話が通じる人」
につながっていくのだと思います。
採用面接でも、私は話の上手さより「質問の意図を理解しているか」「話に一本の筋が通っているか」を見ています。
40代・50代エンジニアの中途採用で面接官が見ていること｜採用する側になって分かったこと
今日の一歩
次に誰かから話しかけられたら、
一度、手を止めて最後まで聞いてみてください。
途中で言いたくなることがあっても、
まずは相手に話し切ってもらう。
そして最後に、
「つまり、〇〇ということですか？」
と一度確認してみる。
それだけでも、
コミュニケーションは少し変わると思います。
聞く。
考える。
確認する。
まずはそこから始めてみてください。
