【まとめ】最強のエンジニアになるための話し方の教科書
こんにちは、ヒロ（ @road_of_hero ）です。
先日、「最強のエンジニアになるための話し方の教科書」という本を読みました。
エンジニアのみなさん、こんな経験ありませんか？
-上司の「言ったはず」を否定して、ミゾを深めてしまう
- 影響がないからと、だまっていた不都合が発覚して信頼を失う
- ズバリ技術の解決策を提案しても、技術力を認めてもらえない
いかがでしたか？どれか一つでも当てはまったら要注意です。
でも大丈夫です。
今回は、ITエンジニアの僕が本書に書かていたことを深堀りし、具体的な対策を提案したいと思います。
エンジニア以外の方でもきっと役に立つと思いますので、ぜひ見ていってください。
なぜエンジニアが「話し方」を身につける必要があるのか？
エンジニアといえば技術の専門家です。
ではなぜ、エンジニアなのに話し方を身につける必要があるのでしょうか？
「マネージャーや営業にまかせておけばなんとかなる」
僕もそう思っていました。
でも答えはNo。
なぜならどんなに優秀なエンジニアでも、その成果を関係者や世の中の人に正しく説明することができなくては、その価値はゼロになってしまうからと著者は言っています。
技術力（２００％）×伝え方（０）＝０
みなさんの周りでも、技術力はいまいちだけど上司を説得するのがうまい同僚はいませんか？
これは、話し方の工夫をしているに他なりません。
ちなみに、話し方が上手い人は、「専門用語」を使わず、たとえ話を使って説明するのだそうです。
そういう人はIQが高く見られるという研究もあります。おもしろいですね。
せっかく魅力的な商品を持ったお店をオープンしても、無人島にオープンしたのでは誰にもその魅力が伝わらないですし、気づいてもらうことすらできません。
エンジニアが伝える技術を強化することで、
- コミュニケーションコストが下がり、問題解決にかかる時間が削減される
→会議などの無駄な時間が減り、プログラミングに集中する時間が確保できる
- 非エンジニアの人でも、技術の大変さが伝わる
→「このくらいの作業なら明日には終わるよね…？」が「それなら１週間はかかるね！」となる
- 上司や同僚からYESと言ってもらいやすい環境になる
→チームのコミュニケーションが良好になり、上司や同僚を説得しやすくなる
といった効果が期待できそうです。
エンジニアの話し方の特徴
では、具体的にエンジニアの話し方にはどんな特徴があるのでしょうか？
- 会話＝戦いであり、正しいことを言ってナンボ
- 技術は答えが一つだから他に伝え方はない
- 資格や知識をもっている人の方の方がエラく、発言力もある
上記の通り。
冷静に考えたらわかるのですが、このような話し方では気づかないうちに相手を傷つけ、怒らせている可能性があります。
これでは、問題解決が遠のく上に、周りからの孤立を深めてしまいますよね。
具体的なシチュエーションを見ていきましょう。
上司の「言ったはず」を否定して、ミゾを深めてしまう
資料を修正するための会議での上司と部下の会話です。
上司：「○○くん、前に言った代替案が資料に盛り込まれていないじゃないか？」
【悪い例】
部下：「そんなことは聞いていませんよ。ほら、議事録にも書かれていませんよ！」
これでは、上司の指示ミスを証明することに躍起になり上司を追い詰めてしまいました。
上司も振り上げた拳のもって行き場がなく、言った言わない論争になっていまいました。
【良い例】
部下：「（そんなことは聞いてないけどな…）メモしていたんですけど忘れてましたね、、、訂正はいつまでですか？」
上司のミスは指摘せず、会議の目的に話を戻すという方法です。
メモしていたのに、忘れてしまった自分という構図にしています。
ここでの会話の目的は「資料を修正する」ということでした。
決して「上司の指示ミスを証明すること」ではありません。
おかげで上司も目的を思い出すことになり、かつメモしてくれてたという事実を感心してくれると思います。
上司との会話では、昨日言ったことと今日言った内容が全く違うということはよくありますよね。
でも、相手を攻撃してしまっては本来の目的を遠ざけるだけでなく、今後の関係も悪化してしまいます。
むしろ、会話をコントロールし、上司をてのひらで転がすくらいの気持ちでのぞむのがいいと思います。
ズバリ技術の解決策を提案しても、技術力を認めてもらえない
お客さんに安全性を証明するために、技術の説明をして解決策を提案するケースです。
ズバリ、技術の解決策を提案しましたが、お客さんに技術力を認めてもらえず却下されてしまいました。
【悪い例】
- 解決策が却下されたのは、自分に権威が足りないからだ。誰もが認める資格を取ろう。
- 説明不足だから、より詳細に説明しよう。
【良い例】
内容以外のところに同意して解決を図る。
技術力をもって証明したとしても、それっぽい根拠をもってそれを却下することはいくらでもできます。
また、資格をとって技術力を証明しようとすれば、それを面白くないと思った相手はかえって反発してくることでしょう。
ところでアドラー心理学に「目的論」という考え方があります。
例えば、飲食店の店員を殴るというケース。
【原因論】
店員の接客態度に腹が立ったから殴った。
【目的論】
自分のうさ晴らしをするために殴った。
原因論が「過去」に目を向ける一方、目的論の場合、は「未来」に目が向いています。
これをこのケースに当てはめると、単に却下したいという目的を達成するために、却下したということが言えると思います。
例えば、後輩が、自分よりその分野のことを詳しく知っていたら、鼻につきますよね。
それで、権力を誇示するために、意味もなく否定したくなるみたいな。
これと同じ状況が起きていたと考えられます。
影響がないからと、だまっていた不都合が発覚して信頼を失う
「商品に欠陥があるけど相手に聞かれなかったから、だまっておこう」
「このデータには信頼性が低いから、説明を省略しよう」
影響がないからといって、必要な説明をおこたると問題の解決を遅らせる上に、自分自身の信頼を失うことになってしまいます。
著者は、都合の悪いことは自ら切り出して話すことが大切と言っています。
都合の悪いことを話すことによって、「嘘をつかない正直な人」「助けてあげよう」という印象を相手に与えることができ、むしろ信頼を得ることができそうですね。
またアドラー心理学の話になりますが、「他責思考」という言葉があります。
これは、物事をすべて他人のせいにするという考え方。
今回の件に当てはめると、「問題に気づかなかった相手が悪い」という相手に責任を押し付ける思考です。
そんなのあるわけないと思うかもしれませんが、例えばこんなこと。
心当たりはありませんか？
- 「給料が上がらないのは、上司が正しく評価してくれないからだ。悪いのは上司だ。」
- 「資格試験の勉強をしたいけど、仕事が忙しいから落ち着いてからやろう」
- 「モテないのは、自分が太っているからだ」
どれも自分の努力次第で解決することができるのに、「他人のせい」、「環境のせい」、「条件のせい」にして一向に行動しないパターンです。
話を戻すと、ここでの目的はあくまで説明して問題点を共有すること。
説明内容が不足していたり、懸念事項があるのなら積極的に開示し、お客さん一緒に解決する方向にもっていくのが賢明です。
聞かなかった相手が悪いのではなく、悪いのは、伝えなかったあなたです。
ラポール（伝える力）×技術力＝最強のエンジニア
最後に、「最強の話し方」とはどんなものかをご説明します。
それは、「ラポールを築くこと」だと著者は言っています。
ラポールとは自分と相手との信頼関係のことです。
具体的には、相手の話すことに共感したり同意すること。
ちなみに、人は自慢話を聞いてあげると、「ご飯を食べる」「お金をあげる」のと同じくらいの快感を脳に与えることができるのだそうです。
相手の話を聞いて、脳に快楽を与えることで、ラポール（＝信頼関係）が生まれる。
つまり、話し方をする前に、話を聞いてもらえる環境を作っておく必要があるということですね。
具体的なラポールの築き方と、話し方についてご紹介します。
まったく価値観の違う相手
話をしていてもまったく価値観の合わない人っていますよね。
そんなときは、「XXXと考えたんですね〜」、「なぜ〜と考えたんですか？」など、話の内容を認めるのではなく、考えた事実を認めて掘り下げるようにします。
本書にも書いてありましたが、価値観は決して相手と同じになることはありません。
であれば、相手の価値観を尊重することが大事。
相手の考え方に興味をもって、「教えてください！」のスタンスをとる。
心理学ではアドバイス・シーキングというそうです。
これだと、相手が不快に思うことはないでしょうし、何より自分の考えに共感し興味をもってくれたことに対して、うれしく思ってくれているはずです。
自己開示する
先に言った、「問題が発覚するまでだまっておく」でもそうですが、この行為自体は、自分を守っている（保身）ことに他なりません。
でも、相手からしたらどうでしょう？
完璧な情報ばかりそろえられていたら、「なんかおかしいな」ときっと思うはずです。
初対面の女性と会うときでも、自分のことをさらさないで一方的に相手のことを聞いていると、「何この人」となりますよね？
自分のことを開示することで、相手は安心します。
弱みなどは、むしろ相手と打ち解けるチャンス。どんどん開示しちゃいましょう。
リフレーミング
リフレーミングとは、ある出来事や物事を、今の見方とは違った見方をすることで、それらの意味を変化させて、気分や感情を変えることです。
例えば、プレゼンの発表の前に「緊張してきた…」と思うのではなく、見方を変えて「やる気がみなぎってきた！」と自分を緊張感から開放して、自分を奮い立たせたりするときに使います。
解決の糸口が見えないときや、全くYESと言ってもらえない場合、「例えば、〜」「仮に〜」など、条件をとっぱらって見方を変えることで、解決策を模索することです。
例えば、「これを解決するには、これしかありません！」と言われたらどうでしょう？
自信たっぷりに聞こえますが、「本当にそうか？」「他の条件下だったら…？」と相手は不安になってしまいます。
解決のアプローチが、一つしかなかったり、思考が浅かったりすると、YESと言うに足りる情報が不足しているため、Noと言わざるを得ない。
相手が意思決定する上で、複数パターンの解決案の提示し、相手に責任が及ばないように準備してあげることも大事です。
ちなみに「私たちが思っているよりも約二倍、人は誰かを助けようと思っている」という研究があります。
つまり、あなたが思う以上に、世間はあなたのことを助けてあげたいと思ってくれているのです。
Noと言いたくて言っているのではないということを念頭においておきましょう。
相手がYESと言ってあげやすい情報の提示と、責任が及ばないような工夫をすることが大切です。
まとめ
いかがでしたでしょうか？
今回は「最強のエンジニアになるための話し方の教科書」というテーマでお話しました。
話し方を鍛えるメリットは以下の通り。
- コミュニケーションコストが下がり、問題解決にかかる時間が削減される
→会議などの無駄な時間が減り、プログラミングに集中する時間が確保できる
- 非エンジニアの人でも、技術の大変さが伝わる
→「このくらいの作業なら明日には終わるよね…？」が「それなら１週間はかかるね！」となる
- 上司や同僚からYESと言ってもらいやすい環境になる
→チームのコミュニケーションが良好になり、上司や同僚を説得しやすくなる
エンジニアは、技術の勉強に割く時間と同じくらい、話し方についても勉強する必要がありますね。
ご紹介した本
エンジニア人生において、もっと早く出会いたかった本です。
ビジネスや、子育てのシーンなど、ケーススタディがたくさん含まれていますので、サクッと読めちゃいます。
エンジニア以外の方でも、話し方を鍛えてコミュニケーション力をアップしたい人は必読です。
この記事が気に入ったらサポートをしてみませんか？