技術よりコミュ力？評価されるエンジニアの特徴を解説

こんにちは！
今日は「技術よりコミュ力？評価されるエンジニアの特徴」について書きたいと思います。

これ、SNSでも現場でもよく聞く話です。
「結局コミュ力がすべて」みたいなやつです。

でも、ここで一回立ち止まってみたいです。
本当にそうなのか。
そして、もしそうなら「どういうコミュ力」なのかです。

というわけで今回は、評価されるエンジニアの共通点を、技術とコミュ力を対立させずに整理していきます。
未経験の方も、経験者の方も「これなら明日から試せるな」と思える形にします。

よくあるアドバイス「コミュ力が大事」の正体です

転職アドバイスでありがちな言葉があります。
「技術よりコミュ力が大事です」です。

言われる側としては、ちょっとモヤっとします。
「え、じゃあコードは適当でいいのですか」みたいになります。
もちろん、そんなはずはないです。

ここで大事なのは、コミュ力という言葉が雑すぎることです。
コミュ力って、飲み会の盛り上げ力みたいに聞こえることがあります。
でも、現場で評価されるのはそこではないことが多いです。

つまり「コミュ力」と言いながら、別の能力をまとめて呼んでいるだけです。
ここを分解すると、だいぶ気が楽になります。

「技術」と「コミュ力」を比べるのがそもそも変です

技術とコミュ力を天秤にかけると、話がややこしくなります。
なぜなら、エンジニアの仕事は基本的にチームスポーツだからです。

たとえば、サッカーで「走る力より声かけ力が大事です」と言われても困ります。
どっちも必要です。
エンジニアも似ています。

コードを書くのは大事です。
でも、コードは誰かと一緒に動かしていきます。
だから「技術だけで勝てる日」と「技術だけでは勝てない日」が混ざっている感じです。

とはいえ、コミュ力が高ければ技術がなくても評価される、という話でもないです。
そこは安心してください。
技術は必要です。
普通に必要です。

評価されるエンジニアの「コミュ力」はこれです

ここからは、よく言われる“コミュ力”を、現場で使われる形に変換します。
つまり「何をすると評価されるのですか」を具体化します。

結論から言うと、評価されるコミュ力は「作業を前に進めるための会話力」です。
これをものすごくざっくりいうと、「今なにが起きていて、次に何をするかを共有できる力」です。

カフェで雑談が上手いかどうかは、そこまで関係ないです。
悲しいけど、ここでのトーク力は別競技です。

特徴1：状況を言語化できる人は強いです

評価される人は、だいたい状況説明が上手いです。
上手いというより、相手が困らない言い方ができます。

たとえば、進捗報告でこう言う人がいます。
「ちょっと詰まってます」です。
これ、言われた側は困ります。
どこで詰まっているのかが分からないからです。

評価される人は、こう言います。
「認証で401が出ています。ログを見るとトークンの生成はできていそうで、API側の検証で落ちているっぽいです。次は中継しているリバプロの設定を確認します」です。

長いです。
でも分かりやすいです。
短く言うと、安心です。

このタイプは、技術力が高く見えます。
実際は「分かる形にして出している」だけのこともあります。
でも、仕事としてはそれが価値です。

特徴2：相談が早い人は評価されます

相談が早い人は、評価されやすいです。
なぜなら、事故が小さく済むからです。

ここでのポイントは「自分で頑張りすぎない」です。
頑張りすぎると、気づいた時には期限が燃えていることがあります。
炎上はだいたい静かに始まります。

とはいえ、何でも丸投げするのも違います。
なので、相談の形が大事です。

おすすめはこのテンプレです。
「やりたいこと」
「やったこと」
「分からないこと」
「助けてほしいこと」
この順番で話すと、相手が助けやすいです。

例です。
「APIのレスポンスを改善したいです。N+1を疑ってSQLを確認しましたが、クエリ数は増えていませんでした。次にキャッシュ周りを見ますが、設計的に触っていい範囲を確認したいです」
こう言うと、相談が仕事になります。

特徴3：相手のコストを下げる人は信頼されます

評価される人は、周りの負担を減らします。
これをものすごくざっくりいうと、「周囲があなたと仕事をすると楽です」と思える状態です。

たとえば、レビュー依頼が上手い人がいます。
「レビューお願いします」だけではなく、こうします。

・何を見てほしいかを書きます
・影響範囲を添えます
・動作確認手順を添えます

これだけでレビューが早くなります。
レビューが早いと、リリースが早くなります。
リリースが早いと、あなたの評価が上がります。
世の中、だいたいそういう連鎖でできています。

特徴4：「わからない」を言える人は強いです

ここ、意外かもしれません。
でも「わからない」を適切に言える人は、評価されることが多いです。

大事なのは、雑に「わかりません」と言うことではないです。
「どこまで分かっていて、どこから分からないか」を言えることです。

例えば、未経験の方が現場に入ったときです。
「Dockerが分かりません」だと広すぎます。
「Dockerfileは読めますが、composeでのネットワークのつながりがイメージできません」だと助けやすいです。

短いです。
そして強いです。

この力は、経験者にも必要です。
経験者ほど「知らないと言いにくい」からです。
でも、知らないことは普通にあります。
技術は広すぎます。

特徴5：仕事を“完了”まで運ぶ人が評価されます

技術力が高いのに評価されにくい人の特徴もあります。
それは「着手は速いけど、完了が遅い」パターンです。

例えば、改善案を出すのは早いです。
でも、関係者への説明がなくて止まります。
あるいは、実装は終わっているのに、テスト観点が共有されていなくて戻ります。

評価される人は「完了の定義」を合わせます。
つまり「どこまでやったら終わりか」を先に確認します。

・受け入れ条件は何ですか
・誰がOKを出しますか
・リリースはいつですか
これを聞ける人は強いです。

ここまでくると、コミュ力というよりプロジェクト推進力です。
でも、世の中はそれを雑にコミュ力と呼びます。
ややこしいです。

じゃあ技術はどうでもいいのですか、という不安について

ここで読者が不安になりやすいポイントがあります。
「コミュ力が大事なら、技術は二の次なのですか」です。

そんなことはないです。
技術は大事です。
ただし、技術は「伝わって初めて評価される」ことが多いです。

極端な話をします。
すごいコードを書いていても、誰にも使われなければ価値が伝わりません。
逆に、そこそこでも再現性があり、運用され、チームに共有されると強いです。

つまり、技術とコミュ力はセットです。
技術がエンジンなら、コミュ力はハンドルです。
ハンドルがないと壁に突っ込みます。

笑い話みたいですが、現場では割と起きます。

今日からできる「評価される動き」の小さな練習です

最後に、明日からできる小さな練習を置いておきます。
急に人格を変える必要はないです。
ちょっとずつでいいです。

まずはこれがおすすめです。

・進捗報告に「次にやること」を1行足します
・相談するときに「仮説」を1つ添えます
・レビュー依頼に「見てほしい点」を1つ書きます

この3つだけで、周りの反応が変わることがあります。
変わらなかったら、会社の仕組みが悪い可能性もあります。
そういう日もあります。

とはいえ、あなたの市場価値を上げる練習としては、かなりコスパが良いです。

というわけで、評価されるのは「話がうまい人」ではないです

結局のところ、評価されるエンジニアは「場を回すのが上手い人」であることが多いです。
それは、盛り上げ担当という意味ではないです。
作業を前に進める担当という意味です。

技術を磨くのは大事です。
同時に、技術が伝わる形にするのも大事です。
この2つが揃うと、評価はわりと自然に上がっていきます。

というわけで、コミュ力にビビりすぎなくて大丈夫です。
あなたのコミュ力は、鍛えられます。
筋トレと同じで、ちょっとずつでいいです。

ITエンジニアが「自分はこんなことができる！」とスムーズに理解・発信できるスキルシート作成プラットフォームです。そこから市場価値を高めて、スキルやキャリアをのびのび育てられるようサポートしていきます。

SkillMove編集部

SkillMove編集部は「ITエンジニアのキャリア形成をもっと自由に、もっと前向きに」をコンセプトに、スキルアップや転職に役立つ情報を発信しています。現役ITエンジニアやキャリアアドバイザーの知見をもとに、実践的なノウハウや最新トレンドをわかりやすくお届けします。SkillMove編集部は、すべてのITエンジニアの「次の一歩」を応援しています。