職能をまたぐエンジニアのコミュニケーション術
はじめに
当たり前にそんなわけはありません。
どのレベルのエンジニアでも、誰かしらとコミュニケーションを取りますよね。
・ 先輩エンジニアとの技術相談
・ PMとの要件すり合わせ
・ デザイナーとの UI/UX 議論
・ 営業からの機能要望
・ CS からの問い合わせ対応
技術的に正しい判断を下しても、それが人にうまく伝わらなければプロジェクトはうまく前に進みません。
この記事では日頃から色々な職能の方とコミュニケーションを取っている私が、意識していることやテクニック、それによって得られた気づきを書いていきます。
背景
- 自社サービス（COMSBI）の運用・開発を担当
（営業 3 名、CS 5 名、エンジニア 4 名、マーケター 1 名） - 職能を超えたコミュニケーションは日常的に発生
- 私の立ち位置はエンジニアのまとめ役
意識・実践していること
① 積極的「翻訳」
技術用語は我々にとっては当たり前でも、非エンジニアには呪文にしか聞こえません。
「API 連携が必要です」「レスポンスが遅延しています」「DB のマイグレーションが」、、、
これらの言葉を聞いた他職能の方は 「で、結局何が起こるの？」 という疑問だけが残ります。
❌ よくない例
CS：「お客様から『反映できない』という問い合わせが来ています」
エン：「429ですね。レートリミットに引っかかってるみたいですね。」
CS：「429...レート...？？」
✅ 良い例
CS：「お客様から『反映できない』という問い合わせが来ています」
エン：「アクセスが集中したため、システムが一時的に処理を制限している状態ですね。詳細また連絡します！」
CS：「承知しました！感謝！」
専門用語を平易な言葉に置き換えてあげるだけで、CS は安心して顧客対応ができます。込みいった話の場合は返信文案まで用意するとさらに良いです。
エンジニア自身、平易な言葉で説明できるということは、 全体を理解しつつ事象の要点を押さえている証拠です。逆に言えば、 うまく説明できないときは自分の理解が曖昧な証でもあります。
言語化の過程で知識が整理され、理解の穴が見えてきます。
② 共通言語を構築して仕事を楽に
これは ① 「翻訳」の派生で、長期的な観点で利益を生むために意識していることです。
❌ よくない例
営業：「OEM提供に際して、URLを変えれたりとかってできますか？」
エン：「ドメインとDNS変更が必要ですね。別案としてサブドメでいいなら楽に終われるかもです。」
営業：「？？？」
✅ 良い例
営業：「OEM提供に際して、URLを変えれたりとかってできますか？」
エン：
「今使っているURLを"お客さんごとに独自のものにしたい"ということであっていますか？
可能ではあるんですが、既存影響や工数の観点でサブドメインだけの対応で要望を満たせるかもです。
・ 今のURL： sample.com
・ サブドメインをつけた形： company-a.sample.com
こんなイメージ」
営業：「なるほど、まずはお客様に確認してみます！」
① で書いたように専門用語を使わず、事象を説明するだけでラリーが格段に減ります。
ただし、過度に翻訳しすぎるのも考えものです。
時には「サブドメイン」のような用語を例として使うことで、相手の知見を広げるきっかけになります。
エンジニア同士の技術的な会話をしている場面に営業が出くわしても、共通言語があれば議論に参加できるようになります。
以前は用語の壁に阻まれていたが、 「営業視点という貴重な別軸」 を議論に持ち込めるようになります。
③ 箇条書きを使え
確認事項を投げる際、文章ではなく箇条書きで送ることを心がけています。
オフラインでの会話のように、口語をそのままテキストに用いると無駄なコンテキストが多くなり、本当に必要な情報に辿り着くまで時間を要します。
箇条書きはホワイトボードのような役割を担い、情報が構造化され、スレッドでの議論の流れが追いやすくなります。
また、以下のポイントも意識しています：
-
「スレッドの最後に何に着地したかを書く」
後でスレッドを読んだ人が最終結論に辿り着きやすくなる -
「採用されなかった案は取り消し線」
最終結論後もスレッドが続くことがあり、「最後の文章 = 結論」が成り立たない場合がある。
途中の廃案を取り消し線で囲うことで、後続を混乱させる可能性を下げます。
④ 質問の背景を理解する
これはテクニックというより、単純にホスピタリティを持とうという話になります。
質問に対して「できます」「できない」とバッサリ Yes/No を返すだけではなく、質問の意図を汲み取って寄り添う姿勢を見せることが大切です。
この小さな寄り添いを積み重ねることで他職能の連携はスムーズになり、互いの信頼関係構築につながると考えています。
チームは持ちつ持たれつの関係であり、メンバーの誰かがやらかしてしまった際には 「こいつのためなら仕方ない、いっちょ助けてやるか！」と思えるような関係性を築くのは、問題の解決速度や今後の仕事のしやすさの観点からも大切なことだと思います。
まとめ
ここまで書いてきたことは、特別なスキルや高度なテクニックが求められるものではありません。
一歩下がって本質を理解する努力をすることで、自然と視野がプロダクト全体に移ります。
全体を見てスムーズなコミュニケーションや判断が下せるエンジニアは、チームにとってかけがえのない存在になっていくはずです。
AI が台頭してきた今、エンジニアは人間力でもバリューを提供できる人材にならなければならないと考えています。
Discussion