エンジニアに必要な「コミュ力」の正体
「エンジニアに必要なのはコミュ力」
よく聞く言葉ですが、かなり雑だと思うし、違和感を感じませんか？
ここでいうコミュ力は、雑談がうまいとか、明るく話せるとか、飲み会で盛り上げられるとか、そういう話ではありません。
エンジニアに必要なコミュ力とは、シンプルに言うと、
誤解を減らし、論点を揃え、仕事を前に進める力
もっと言えば、仕事の不確実性を下げる力です。
今回は、「エンジニアのコミュ力」を言語化をしました。
エンジニアの仕事は、コードを書く前にだいたい曖昧
現場では、最初から要件がきれいに決まっていることはほとんどありません。
よくあるのは、こういう状態です。
・何を作るべきか曖昧
・なぜ必要なのか曖昧
・誰が判断するのか曖昧
・いつまでに必要なのか曖昧
・どこまで作ればよいのか曖昧
この状態でそのまま実装に入ると、後でこうなります。
「そういう意味じゃなかった」
「そこまでは求めていなかった」
「なぜ先に確認しなかったの？」
「技術的には正しいけど、業務では使えない」
これは技術力の問題ではありません。
期待値のすり合わせに失敗しているだけです。
コミュ力1：技術を相手の言葉に翻訳する力
エンジニア同士なら、こう言えば伝わります。
DBクエリが重くて、インデックスが効いていません。
N+1も起きています。
ただ、相手がビジネス側なら、これだけでは判断できません。
伝えるべきは、こうです。
検索画面の表示が遅くなっています。
このままユーザーが増えると、さらに遅くなる可能性があります。
対応には半日から1日程度必要です。
今回のリリース前に直すか、リリース後すぐに対応するか判断したいです。
大事なのは、技術的に正しい説明をすることではありません。
相手が判断できる形に変換することです。
コミュ力2：論点を整理する力
会議でたくさん話す人が、コミュ力の高い人ではありません。
本当に価値があるのは、会議の目的をはっきりさせる人です。
例えば、こう言える人です。
今日決めたいのは、A案で進めるかB案で進めるか、で合っていますか？
または、
今日決めたいのは、A案で進めるかB案で進めるか、で合っていますか？
技術的な論点は3つあります。
実装コスト、運用負荷、将来の拡張性です。
今日はどこまで判断できればよいですか？
会議の価値は、話す量ではありません。
何が決まり、次に何をするかが明確になることです。
コミュ力3：否定ではなく、代替案や条件を提案する力
現場では、無茶な依頼が来ます。
来週までにできますか？
この機能も追加できますか？
簡単でいいので作れますか？
ここで、いきなり「無理です」と言うと対立になります。
一方で、「できます」と言うと自分たちが苦しくなります。
必要なのは、条件や代替案を出すことです。
来週までに出すことは可能です。
ただし、その場合はAとBに範囲を絞る必要があります。
Cまで含めるなら、追加で2週間必要です。
エンジニアの役割は、依頼を丸呑みすることではありません。
成立する条件や代替案を提示することです。
コミュ力4：悪いニュースを早く出す力
- 遅延しそう。
- 品質に不安がある。
- 仕様が曖昧。
- 外部APIの挙動が怪しい。
こういうとき、ギリギリまで黙るのが一番危険です。
悪いニュースは、早ければ相談になります。
遅いと、言い訳になります。
例えば、こう共有すれば十分です。
現時点で、予定通りのリリースにリスクがあります。
外部API連携で想定より時間がかかっています。
今日中に原因を切り分け、明日の午前に対応方針を出します。
最悪の場合、リリースが1〜2日後ろ倒しになる可能性があります。
完璧に原因が分かってから報告する必要はありません。
重要なのは、
・何が起きているか
・どこまで分かっているか
・何が未確定か
・次にいつ報告するか
を出すことです。
まとめ
エンジニアに必要なコミュ力とは、愛想の良さではありません。
必要なのは、次の力です。
・技術を相手の判断材料に翻訳する力
・論点を整理する力
・期待値を調整する力
・リスクを早めに共有する力
つまり、エンジニアのコミュ力とは、
仕事の不確実性を下げる力
です。
コードを書く力は重要です。
ただ、現場で信頼されるエンジニアは、コードだけでなく、認識・期待値・意思決定も整えます。
「コミュ力が大事」とは、明るく話せという意味ではありません。
仕事を前に進めるために、情報を設計しろという意味です。