LoginSignup
49
11

エンジニアが非エンジニアにしてしまう3つのコミュニケーションアンチパターン

Last updated at Posted at 2022-12-15

この記事は、リンクバルアドベントカレンダー2022の16日目の記事です。

はじめに

私は新卒でエンジニアとして入社してから、途中で事業部に異動し、4年近く非エンジニアを経験しました。そんな私が非エンジニアの視点で社内のコミュニケーションを見ていて感じた、エンジニアから非エンジニアに対する3つのコミュニケーションのアンチパターンと改善案を紹介します。

この記事の内容は、もともとは社内のLT会で発表して、わりと評判がよかった気がするので、記事にしました。

パターン1 専門用語を使ってしまう

事例

とあるエンジニアと非エンジニアの会話

非エンジニア「これって実装大変だったりしますか?」
エンジニア「うーん、これはAPI作るのがかなり大変かもしれないですねー」
非エンジニア「(APIってなに)」

さらに会話していくとこんな状態に。。。

Screen-Shot-2022-10-06-at-12.11.14.png

そして、結局非エンジニアは知りたいことがよくわからず、この場で正確な情報を知ることを諦めてしまいましたとさ...

どうすればよかった?

専門用語を使わない

※後述しますが、ベストは、非エンジニアも最低限の技術知識があって、建設的に議論できることだと思います

専門用語は使わずに、伝わりやすいように言い換えましょう。

例 「〇〇○のAPIで〜」→「〇〇の処理で〜」

もしあなたが、「IT企業で働いているんだから、APIの意味くらい知っていて当たり前だろ」と思っていたら、注意しましょう。

仮に、あなたがネット広告に関連する企業で働いているとして、ROASやGDNなどの用語を、全エンジニアが知っていて当たり前だと思われますか? 必ずしも、そうだと思えないのではないでしょうか。

全社員が知っていて当たり前かどうか≒どのレベル感を求めるか決めるのは、部署や会社など、組織が決めることのはずです。

「当たり前」には、一人ひとり個人差があるのが当たり前です(当たり前だけにな!)。「あなたの当たり前」を、「みんなの当たり前」にはしないようご注意ください!

(まあ、正直私は、自身が属する業界の用語は、職種に限らずみんなが極力知っておくべきだと思っていますが)

相手が理解しているか確認する

今回のケースでいうと、以下のように適宜相手の理解状況を確認すると、よかったかもしれませんね。

  • 「APIの意味ってなんとなくわかりますか?」と質問する
    • YESならそのままAPIを使いましょう
    • NoならAPIの意味を説明するか、伝わる表現に変えましょう
  • 「今の説明でわからないところはありましたか?」など相手の理解状況を確認する
    • このとき、相手が流れで「大丈夫」と言っていないか注意しましょう
      • 割とあると思います。特に、関係が浅い状態のときや、あなたがあまり笑顔にならなかったり、感情が表に出づらいタイプの場合。

こうすることで、相手が理解していないまま話がどんどん進んでいくことを、減らせます。

理解してもらえないまま話を続けても、時間が無駄です。それだけではなく、エンジニアは相手が理解したと思っていて、非エンジニアは理解できていない状態になり、お互いの認識にギャップが生じてその後のやり取りにも支障をきたすおそれすらあります。

パターン2 要点を説明しない

コミュニケーションでは、相手が知りたいことを予想して、要点を簡潔に説明しましょう。
そもそも、技術うんぬんに関わらず、ダラダラと説明するのはビジネスではよろしくありません。

事例

例えば、こんなやり取りがあったとしましょう。

非エンジニア「〇〇の画面に××の機能を追加したいんだけど、なにか懸念ある?」
エンジニア「いいですね! でも、その機能の追加は結構悪影響があるかもしれません」
非エンジニア「どんな悪影響?」
エンジニア「△△の処理に影響があり、〇〇の画面の△△の表示が結構遅くなりそうです」
非エンジニア「"結構"って、どれくらい?」
エンジニア「うーん、、、1000ミリセックくらいでしょうか?」
非エンジニア「(ミリセック?)それってユーザー体験に悪影響が出そう?」
エンジニア「そうですね、悪影響が出ます」

非エンジニアは、ユーザー体験に悪影響が出るかどうか結果的に知れましたが、そこまでに会話の往復が何度も発生しちゃっていますね。

どうすればよかった?

このやり取りは、例えば以下のように改善できそうです。

非エンジニア「〇〇の画面に××の機能を追加したいんだけど、なにか懸念ある?」
エンジニア「いいですね! ただし、その機能を追加すると、△△の表示が遅くなりそうで、〇〇の画面を開いたときに明確にユーザー体験に悪影響が出る遅さになりそうですね」
非エンジニア「それはよくないね。ありがとう!じゃあ、××の機能をこんな感じに変えたら、どうだろう?」

非エンジニアは、ユーザー体験に悪影響が出るほどの遅さとわかり、代替案をエンジニアと一緒に考え始めることができました。

相手が知りたいことをうまく察することができると、スムーズにやり取りが終わるかもしれません。
本来は、回答する側が察するのではなく、質問する側が知りたいことを知れるように、相手に適切に質問をすべきです。とはいえ、全員が全員いきなりうまくコミュニケーションできるわけではないので、あなたがうまくリードしてあげましょう!

パターン3 非エンジニアがいる会議で技術的な話の深掘りをしてしまう

これ、私が観測した限りではやっちゃっているエンジニアが結構いました。特に若手メンバー。

事例

このように、複数のエンジニアと非エンジニアが新機能について会議をしていました。

Screen-Shot-2022-10-06-at-12.11.42.png

Screen-Shot-2022-10-06-at-12.12.13.png

オーマイガー🤦

どうすればよかった?

非エンジニアがいる会議で、技術的な深堀りは極力避けましょう。

  • 技術的な話は、できるだけ別の場でエンジニアだけで詰めましょう
    • その場の非エンジニアの時間が無駄になってしまいます
      • 一人ならまだしも、複数人なら人件費をかなり無駄にしています
    • 実装の詳細は、非エンジニアはわからないし、興味がない(人が多い)です
  • ただし、技術的な話がすぐ終わるかつ結果によって非エンジニアとさらに話した方がいいなら、その場でさっと決めて、全員の話を進めましょう

お互いの歩み寄りが大事

「非エンジニアも技術的なことは最低限知っておくべき」

そう思われているエンジニアは多いだろうと、勝手に予想しています。
「IT企業に所属しているなら」という前提のもとで、非エンジニアも技術的なことは最低限知っておいてほしいなと私は思います。(最低限の範囲も人によって違うから難しいですが。)

冒頭に記載した通り、この記事の話は社内のLT会で発表したのですが、発表後の質疑応答で反応が多く、多くの方が興味がありそうな話題だと知ることができました。

LT会では、結論として「非エンジニアも最低限の技術的な知識があるとよい」「エンジニアが知っておいてほしい用語の説明会を開くなどお互いが歩み寄れるといいよね」となりました。

非エンジニアも最低限の技術的な知識があると、以下のような恩恵があります。

  • 「実装が難しい」とエンジニアから言われたときに、仕様の代替案を出せることがある
  • エンジニアから「できない」と言われても、適切な質問や議論をして実現方法を探ることができる
    • 知識がないと、「できない」と言われたらどうしようもなくなる可能性が高い
  • エンジニアの説明がわかりづらかった場合でも、理解しやすい

そして、お互いが歩み寄ること、これはとてつもなく大事だと思います。

コミュニケーションの問題の多くは、相手のことを考えないせいで発生していると私は思っています

エンジニアと非エンジニアが、お互いになにを大事にしているか、なにを達成したいか、なにに気をつけているか、、、
こういったことを、相手の立場になって考えることで、今よりもずっとコミュニケーションが円滑になるだけでなく、関係性がよくなって仕事も楽しくなるはずです。

おわりに

気づいた方がいるかもしれませんが、この記事の内容は、エンジニアと非エンジニアに限った話ではないのですよね。事業部と管理部、営業とマーケ、デザイナーと非デザイナーなど、ありとあらゆる部分で共通のお話です。

結論、相手の立場になって考えようぜ!


関連した内容で、最近、すごいわかりやすくて激しく共感した記事があったのでぜひご覧ください!

また、コミュニケーションに関連する書籍では、かなりの名著のD・カーネギーの 人を動かす や、一番伝わる説明の順番 あたりは非常におすすめです!

おわり

49
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
49
11