Workers-Strategy

エンジニアがやりがちな間違った伝え方と直す方法[エンジニアが説明上手になるために]

はじめに

私はこれまで職種として営業、エンジニア、コンサルタントを経験しています。
各職種を何年、何十年とキャリアを積んでいる方に比べれば能力の深さは劣るかと思います。
逆に言うと年齢に対して経験している職種の数が多いので、職種間での意思疎通の違いについては観察する機会に恵まれました。その経験をふまえ、エンジニアがやりがちな間違った伝え方とそれを改善するための案をまとめます。

エンジニアの思考

非エンジニアの方からするとエンジニアにどのような思考傾向があるのか、よく分からないという経験をお持ちではないでしょうか。
私がエンジニアだった頃の体験を回想してみると、以下のような思考のクセがあったように思います。

「抽象」より「具体」
「俯瞰」より「詳細」
「簡潔だが精度が低い」より「冗長だが精度が高い」
「何ができるか(何がうれしいのか)」より「どうやってつくるか(手段)」

エンジニアといっても、プログラマー、SI、SE、CEなど様々な職種があるとは思いますが、
私が接したことのある広義のエンジニアはこのような思考のクセがあったように感じます。(私を含め)

コミュニケーションロスが少ないエンジニアというだけで重宝される

私の経験から、立場の異なる職種とのコミュニケーションにおいて、エンジニアは特にコミュニケーションロスが発生しやすい職種と言えます。
例えば、私はこんな経験をしています。

営業が「ユーザがほしいもの」を求めるのに対して、エンジニアが「実現可能なベストなもの」を提示し、その間のギャップが埋められない
エンジニアの技術選定の説明に「So Why?」なぜ？「So What?」何をすればいい？が欠けている(意思、根拠がない、あっても伝わらない)

コミュニケーションロスを解消するためには、実現しようとしているシステムやサービスの中身は大切です。それと同様に、なにが言いたいのかを設計して相手に伝える技術が重要だと感じます。特にエンジニアという職種は設計において抽象と具体を行き来したり、細部までチェックする必要のある細やかな精度が求められる職種です。
そのために「モノをつくる脳」から「ヒトに伝える脳」にモードを切り替えるスイッチを持つだけで、多くのエンジニアとは異なる武器をもつことが出来ます。

伝え方を磨く具体的な方法

私が実践してきたエンジニアが「伝え方」を磨く方法をご紹介します。

結論ファーストで言葉を伝える
英語の長文を読むと感じるかと思いますが、どのカテゴリの文章・プレゼンでも「結論を先に述べる」は鉄則です。そうすることで、説明に説得力を持ちつつ、短い時間で話したい要点を伝えることができます。また、結論→理由→事例→結論の順で伝えるとさらに説得力が増していきます。詳しくはこちら
話を分かりやすく伝えるために大切な1つのこと[仕事で使えるコツ] | Workers-Strategy
はじめに私はシステム開発、プロジェクトマネージメント、営業など比較的幅広い職種を経験してきましたが、どの仕事でも役に立つスキルが「伝える能力」です。私がこれまで経験したケースでは以下のようなものがあります。・技術力はあるのに、説明が的を射て
「言い切り」は相手への優しさ
よく若いエンジニアが使いがちなのが「一応」や「たぶん、おそらく」といった不確定な修飾語をつけた報告や説明です。(私もそうでした…)
多くの場合、このような不確定な修飾語は情報が間違っていときや失敗したときのリスクを軽減する保険として「相手のため」ではなく「自分を守るため」に無意識のうちに使っている言葉だと思います。1%でもできない可能性があるときに「失敗する可能性がある」と答えるのがエンジニアの適正があり、「できます」と答えるのが営業の適正がある、という話を聞いたことがあります。
一理あるとは考えますが、できない可能性があった場合のリスクも踏まえて、「言い切り」で相手にコミットメント(誓約)ができるエンジニアとなれるか、という点が強い価値となると考えます。
「ひと言」力。サッと書いて、グッとくる99の方法

created by Rinker

最後に

エンジニアの立場としては「つくること」に集中するモードも大切ですが、「なんのために？」「要するになにがしたい？」といった自分を俯瞰したときのインターフェース(コミュニケーションの在り方)を設計していくこともスキルのひとつとして強い武器になるはずです。
研ぎ澄ました結果、ビジネス感度の高いエンジニアは会社、システム、ヒトを問わず重宝されると考えます。

エンジニアのための図解思考再入門講座情報の“本質”を理解するための実践テクニック

created by Rinker