エンジニアに必要な「コミュ力」の正体

「エンジニアに必要なのはコミュ力」

よく聞く言葉ですが、かなり雑だと思うし、違和感を感じませんか？

ここでいうコミュ力は、雑談がうまいとか、明るく話せるとか、飲み会で盛り上げられるとか、そういう話ではありません。

エンジニアに必要なコミュ力とは、シンプルに言うと、

誤解を減らし、論点を揃え、仕事を前に進める力

もっと言えば、仕事の不確実性を下げる力です。
今回は、「エンジニアのコミュ力」を言語化をしました。

エンジニアの仕事は、コードを書く前にだいたい曖昧

現場では、最初から要件がきれいに決まっていることはほとんどありません。

よくあるのは、こういう状態です。

・何を作るべきか曖昧
・なぜ必要なのか曖昧
・誰が判断するのか曖昧
・いつまでに必要なのか曖昧
・どこまで作ればよいのか曖昧

この状態でそのまま実装に入ると、後でこうなります。

「そういう意味じゃなかった」
「そこまでは求めていなかった」
「なぜ先に確認しなかったの？」
「技術的には正しいけど、業務では使えない」

これは技術力の問題ではありません。

期待値のすり合わせに失敗しているだけです。

コミュ力1：技術を相手の言葉に翻訳する力

エンジニア同士なら、こう言えば伝わります。

DBクエリが重くて、インデックスが効いていません。
N+1も起きています。

ただ、相手がビジネス側なら、これだけでは判断できません。

伝えるべきは、こうです。

検索画面の表示が遅くなっています。
このままユーザーが増えると、さらに遅くなる可能性があります。
対応には半日から1日程度必要です。
今回のリリース前に直すか、リリース後すぐに対応するか判断したいです。

大事なのは、技術的に正しい説明をすることではありません。
相手が判断できる形に変換することです。

コミュ力2：論点を整理する力

会議でたくさん話す人が、コミュ力の高い人ではありません。

本当に価値があるのは、会議の目的をはっきりさせる人です。

例えば、こう言える人です。

今日決めたいのは、A案で進めるかB案で進めるか、で合っていますか？

または、

今日決めたいのは、A案で進めるかB案で進めるか、で合っていますか？
技術的な論点は3つあります。
実装コスト、運用負荷、将来の拡張性です。
今日はどこまで判断できればよいですか？

会議の価値は、話す量ではありません。

何が決まり、次に何をするかが明確になることです。

コミュ力3：否定ではなく、代替案や条件を提案する力

現場では、無茶な依頼が来ます。

来週までにできますか？
この機能も追加できますか？
簡単でいいので作れますか？

ここで、いきなり「無理です」と言うと対立になります。

一方で、「できます」と言うと自分たちが苦しくなります。

必要なのは、条件や代替案を出すことです。

来週までに出すことは可能です。
ただし、その場合はAとBに範囲を絞る必要があります。
Cまで含めるなら、追加で2週間必要です。

エンジニアの役割は、依頼を丸呑みすることではありません。

成立する条件や代替案を提示することです。

コミュ力4：悪いニュースを早く出す力

遅延しそう。
品質に不安がある。
仕様が曖昧。
外部APIの挙動が怪しい。

こういうとき、ギリギリまで黙るのが一番危険です。

悪いニュースは、早ければ相談になります。
遅いと、言い訳になります。

例えば、こう共有すれば十分です。

現時点で、予定通りのリリースにリスクがあります。
外部API連携で想定より時間がかかっています。
今日中に原因を切り分け、明日の午前に対応方針を出します。
最悪の場合、リリースが1〜2日後ろ倒しになる可能性があります。

完璧に原因が分かってから報告する必要はありません。

重要なのは、

・何が起きているか
・どこまで分かっているか
・何が未確定か
・次にいつ報告するか

を出すことです。

まとめ

エンジニアに必要なコミュ力とは、愛想の良さではありません。

必要なのは、次の力です。

・技術を相手の判断材料に翻訳する力
・論点を整理する力
・期待値を調整する力
・リスクを早めに共有する力

つまり、エンジニアのコミュ力とは、

仕事の不確実性を下げる力

です。

コードを書く力は重要です。

ただ、現場で信頼されるエンジニアは、コードだけでなく、認識・期待値・意思決定も整えます。

「コミュ力が大事」とは、明るく話せという意味ではありません。

仕事を前に進めるために、情報を設計しろという意味です。