はじめに：技術だけでは足りない時代
こんにちは、LEGAREA代表の三坂です。
エンジニアの評価を「技術力」だけで測る時代は、すでに終わりを迎えつつあると思っています。
それを象徴するのが、システム開発の現場でより一層重要性を増している言語化スキルの存在です。
今回は、現場で本当に評価されるエンジニアの条件として、「言語化とは何か」「なぜ重要か」「どう伸ばせるか」を、ロジカルに分解していきます。
言語化スキルとは何か？
定義：言語化スキルとは「構造化された情報を他者が理解できる形で出力する力」
以下の3つがそろってはじめて「言語化できている」と言えます。
- 要素の分解：複雑な事象を構成要素に分解できている
- 構造の整理：物事の因果関係や流れが整っている
- 相手目線の表現：専門用語の選び方やたとえ話が適切である
つまり、頭の中のモヤモヤを、他者が手に取るように理解できる状態に変換する能力です。
言語化ができるエンジニアはなぜ重宝されるのか？
① コミュニケーションコストが下がる
言語化ができる人は「何が分からないか」を説明できます。
→結果、調べる時間・聞き直し・認識齟齬などの無駄が劇的に減ります。
② 機能要件・仕様定義フェーズで差がつく
顧客が曖昧に話した内容を、構造化・定義・可視化できる能力はまさに武器。
→ドキュメントや仕様書作成でも“上流に向く人材”として評価されやすいです。
③ 教育・ナレッジ共有ができる
新人指導やドキュメント整備の中で、「思考過程を説明できる人」は社内で自然と頼られます。
言語化スキルがないことで現場で起きている弊害
- コードレビューでのなんとなくの指摘
- 会話の中でうまく言えないけど…が多い
- 報告が事実だけで、背景や意図が伝わらない
- 資料を見ても論理が飛躍していて伝わらない
→つまり、技術があるのに伝わらない＝損をしている人が非常に多いのです。
言語化スキルを構成する3つの具体スキル
1. 抽象化と具体化の行き来
- 【悪例】：この機能、バグってます
- 【良例】：現在地取得がnullになり、位置情報に依存する処理が動かない状態です
→抽象（全体像）と具体（数値・事例）をスムーズに切り替える力が必要。
2. 相手の理解レベルを推測する力
- 例：「PMに説明するのか」「同僚エンジニアに説明するのか」で使う単語も粒度も変わる。
- 言語化は知識の転送ではなく翻訳だという意識が重要。
3. 論理構造の理解
- Point（結論）→ Reason（理由）→ Example（具体例）→ Point（再主張）
- 要素の抜け・被りがないように整理するMECE
→こうした思考法を無意識で使いこなすことが言語化スキルの土台になる。
言語化スキルを伸ばす方法
① 誰かに「説明」する経験を意図的に増やす
- 説明してみる → 詰まる → 曖昧さに気づく → 言語化する
- このプロセスを繰り返すことで、理解と表現が深まります。
② 記述力を鍛える（Slack・Notionなどを活用）
- 社内Wikiや報告資料で、結論ファーストの構造を意識する
- 他人が見て理解できるアウトプットにこだわる
③ 他人の「上手い言語化」をストックする
- 上司の説明、YouTubeの解説動画、本などから
- この言い方使えるなという表現辞書を自分の中に増やす
なぜ今、このスキルが重視されているのか？
技術はコモディティ化している
- ChatGPTなどの登場により、「知っている」よりも「使える」「伝えられる」が価値に。
- 同じ技術力なら、言語化できる人が市場で選ばれる時代。
補足：うつ病・肥満と「言語化力」の関係
実は、エンジニアはうつ病・肥満の割合が高いことで知られています。
- 原因の一部は、自分の不調や不安をうまく言語化できないこと
- 特にうつ症状の初期は“自覚があるのに誰にも言えない”ことが引き金になります
→だからこそ、自分の内面や状態を言語化すること＝自己防衛でもあると僕は思います。
結論：技術だけで勝負できる時代は終わった
言語化とは、知識の伝達ではなく知識の翻訳です。
コードが書けるだけでは、上流にも行けないし、チームの信頼も得られない。
むしろ伝えられる人こそが評価され、昇進し、報酬も高くなる。
目に見えないスキルこそ、最終的に一番効く。
それが、「言語化スキル」というスキルだと、僕は本気で信じています。
