アイキャッチ

エンジニアを苦しめる「言語化力」の正体。鍛えようと努力しても、迷走してしまう理由とは?

NEW!  スキル

「もっと言語化能力を磨くべきだ」

評価面談などで、上司からそんなフィードバックを受けた経験を持つエンジニアは少なくないはずだ。現代では、ビジネスの文脈を理解し、会議で雄弁に語る「喋れるエンジニア」こそが市場価値が高いという声もよく耳にする。

では、瞬発的な会話が苦手な人間は、この業界から淘汰される運命にあるのだろうか。

そこで今回、ソフトウエアエンジニアとしてSNSやnoteで積極的に情報発信を行い、書籍執筆やイベント登壇など「言葉」を武器に活躍するいぐぞーさん(@igz0)に、エンジニアに求められる「言語化」の正体について聞いた。

プロフィール画像

エンジニア
いぐぞー(@igz0

神奈川県出身の旅好きプログラマー。小学生の頃からプログラミングに親しみ、新卒でSIerに入社。その後フリーランスを経て、現在は上場企業のWebエンジニアとして活躍中。旅とプログラミングをこよなく愛し、noteでの発信は多くの読者から支持を集めている

抽象的な言葉で済ませると、努力の方向を見失う

はじめまして、いぐぞーと申します。旅とプログラミングをこよなく愛する、 30代前半のADHD・ASD持ちWeb系プログラマーです。

私はインターネットでの発信を続けた結果、2025年に書籍出版の話をいただきました。周りからみたら「言語化が得意な側」だと言えるかもしれません。

ですが、何も最初から「言語化が自分の強みだ」と分かっていたわけではありません。むしろ、とある時期までは、自分の強みが全く分からずに迷走していました。

そもそも「言語化が足りない」と言われて、すぐに改善できた人を私はほとんど知りません。理由は単純。その言葉は診断名にはなっても、処方箋にはならないからです。

「熱がある」というだけで薬は決められません。風邪なのか、インフルエンザなのか、脱水なのかで処方は変わります。

同じように「言語化が足りない」のであれば、本来は「会議で論点を整理する力が弱い」のか、「要件を文章で定義する力が弱い」のか、「相手の理解度に合わせて言い換える力が弱い」のかまでは最低限、分けないといけません。

ここを分けないまま「言語化を鍛えよう」と考えると、努力は一気に曖昧になる。読書量を増やせばいいのか、語彙を覚えればいいのか、話し方を改善すればいいのか。全部正しそうに見えて、全部ずれている状態になってしまいます。

「言語化」のような抽象語は、会話を速くする便利な言葉としては有効ですが、自己理解を遅くする副作用がある。自己評価や人生設計までその一語で済ませてしまうと、努力の方向を見失うことになり、良い結果は望めません。

薄暗い部屋で頭を抱え葛藤する男性の姿。ADHD・ASDを抱えるWeb系プログラマのいぐぞー氏が指摘する、周囲から「言語化が足りない」という抽象的な指摘を受け、改善の処方箋が見つからずに努力の方向性を見失ってしまうエンジニアの心理的停滞状態を表現している。

リアルタイム会話と非同期テキストは「別競技」

これらの話は、机上の理屈で書いている訳ではありません。私は実際に、抽象語で長く迷走していた側の人間です。

新卒の時、当時の上司から「いぐぞーくんはコミュニケーション能力が足りない」と言われたことがあります。その瞬間はかなり傷つきましたが、自分に足りていないのは事実なのだろうと、なんとか改善しようとしました。

そこで、最初の壁にぶつかります。「で、何をやればいいのか?」です。

会話のテンポなのか、説明の順番なのか、語彙なのか、相手の反応を見る力なのか。全部ありえそうで、全部ぼんやりしている。ぼんやりした課題に対しては、ぼんやりした努力しかできません。

結果として、自分は「頑張っている感」だけが増して、手応えが残らない時期を過ごしました。反省はしているのに前進感がないというのは、かなり苦しい経験です。

転機は、思ったより地味な場面で訪れました。

トラブル対応が発生し、上司から「お客さんへの説明メールを代わりに考えて」と言われた時のことです。まだ生成AIがない時代で、当然コピペ元もない。自分の頭で組み立てるしかありません。

まずは状況を整理し、事実、原因、影響範囲、そして今後の対応を順番に並べ、相手が不安になりそうなポイントを先回りして文面に入れました。そして派手な表現は避け、誤解が生まれないように主語と時系列を揃える。

やったことは、たったそれだけです。書いたメールを上司に見せたところ、「理路整然として分かりやすい。喋っているときの君と大違いだね」という主旨の言葉が返ってきました。

オフィスでPCを前に上司とやり取りするビジネスパーソン。口頭での瞬発的な会話には課題があっても、トラブル対応のメールのように状況・事実・原因・対策を論理的に構造化して伝える「非同期テキストコミュニケーション」において、エンジニアが独自の強みを発揮できる場面を象徴している。

今思うとなかなか失礼な言い方ですが、ここで初めて、自分ははっきりと理解しました。

「自分が苦手だったのは、コミュニケーション全般ではない。瞬発的な口頭コミュニケーションは弱いが、情報を整理して構造化し、文章で伝えるコミュニケーションは強いのだ」と。

実際、会議では詰まってしまうけれど、議事録やメールだと評価される人は少なくないと思います。これらは同じ「伝える」に見えても、リアルタイム会話と非同期テキストという別競技です。

「コミュ力がない」のではなく、「コミュ力を分けていない」だけだった。

この気付きがあった瞬間、自己否定はかなり減りました。苦手が消えたわけではないですが、どこで勝負するかが見えるだけで、キャリアの進み方は全く変わります。

抽象語を疑い、鍛えるべきスキルの単位を明確にする

あの頃の自分に足りなかったのは根性ではなく、課題設定の解像度でした。もっと言えば、能力を一語で扱う癖を疑う視点です。ここを変えない限り、同じ場所で回り続けることになります。

では、抽象語を分解するにはどうすれば良いのか。ポイントは、「能力名」ではなく「場面×行動×成果」で捉えることです。

例えば「コミュニケーション力が必要」と言われても、その中身は業務によって全く違います。

朝会での口頭報告に必要なのは、結論先出しと時間管理。障害対応の報告に必要なのは、時系列整理と影響範囲の明確化。レビューコメントに必要なのは、指摘の根拠を短く伝える力。

これらは全部「コミュニケーション」とひとくくりにされますが、鍛える単位は異なります。

「言語化力」も同じです。

要件定義なら、曖昧な要望を仕様に落とす具体化が必要になる。振り返りなら、事実と解釈を分離する整理力が必要になる。提案資料なら、論点を絞って相手の意思決定に必要な情報だけを置く構成力が必要になる。

言語化という一語でまとめてしまうと、必要な訓練が見えなくなってしまいます。

会議で資料を指し示し議論する様子。いぐぞー氏が提唱する「場面×行動×成果」でスキルを捉えるメソッド。要件定義なら「曖昧な要望の仕様化」、振り返りなら「事実と解釈の分離」など、抽象的な言語化力を具体的単位に分解することで、エンジニアが取り組むべき訓練を明確にする重要性を説いている。

苦手を消すより、得意が「再現される条件」を探そう

また、ここで大事になってくるのが、アウトプットの形は必ずしも会話や文章といった「言語」だけに限らないということです。

例えば、誰もが読みやすい美しいコードを書くこと、バグを未然に防ぐ堅牢なアーキテクチャを設計すること、あるいはチームが迷わない開発フローの仕組みを作ること。媒体が違うだけで、これらも周囲との意思疎通を円滑にする立派なコミュニケーションであり、本質は「いかに再現可能な価値を出せるか」にあります。

もしも今あなたが「言語化が足りない」「コミュ力がない」と言われているのであれば、落ち込む前に、その言葉を分解してみてください。

抽象語の呪縛から抜け出し、自分が過去に少しでも価値を出せた「具体的な場面」を思い出してみてほしいです。自分にとっては、それが顧客向けのメールであり、情報を整理して相手の不安を下げる文章でした。

苦手を消すことより先に、得意なことが再現される条件を見つけることです。

口頭のコミュニケーションが弱いなら、それは事実として受け止めればいい。ただ、文章や構造化で価値を出せるなら、そこを先に伸ばすこと。成果が出る領域を先に育てるほうが、結果として苦手の改善やカバーにも効いてきます。

瞬発的に喋れなくても、文章で、コードで、情報の構造化で、確実に価値を届ける方法はあります。曖昧な言葉で自分を追い詰めるのをやめ、自分が勝てる「具体的な場面」を見つけ出してください。

その解像度の高さと自己理解こそが、これからの時代を生き残るための、あなたの最大の強みになるはずです。

文/いぐぞー 編集/今中康達(編集部)

転職力診断

Xをフォローしよう

この記事をシェア

RELATED関連記事

JOB BOARD編集部オススメ求人特集

RANKING人気記事ランキング





サイトマップ