■ 1. 抽象的フィードバックが引き起こす問題
- 「言語化が足りない」という言葉は診断名にはなるが処方箋にはならない
- 改善すべき内容が分解されていないと努力の方向が曖昧になる
- 「言語化」という一語で済ませると以下の区別が失われる:
- 会議で論点を整理する力
- 要件を文章で定義する力
- 相手の理解度に合わせて言い換える力
- 抽象語は会話を速くする便利な言葉だが自己理解を遅くする副作用がある
- 読書量・語彙・話し方など全て正しそうに見えながら全てがずれた状態になる
■ 2. 筆者の経験と転機
- 新卒時に「コミュニケーション能力が足りない」と指摘されたが何を改善すべきか分からず迷走した
- 努力の手応えが残らない苦しい時期を経験した
- 転機はトラブル対応時の顧客向けメール作成:
- 事実・原因・影響範囲・今後の対応を順番に整理
- 相手の不安を先回りして文面に盛り込む
- 誤解を防ぐため主語と時系列を揃える
- 上司から「理路整然として分かりやすい」と評価を受け自己理解が深まった
- 弱点は「コミュニケーション全般」ではなく「瞬発的な口頭コミュニケーション」のみと判明
- リアルタイム会話と非同期テキストは別競技であり得意不得意が分かれる
- 「コミュ力がない」のではなく「コミュ力を分けていない」だけだった
■ 3. 抽象語の分解方法
- 能力名ではなく「場面×行動×成果」で捉えることが重要
- 「コミュニケーション力」の場面別の内訳:
- 朝会での口頭報告: 結論先出しと時間管理
- 障害対応の報告: 時系列整理と影響範囲の明確化
- レビューコメント: 指摘の根拠を短く伝える力
- 「言語化力」の場面別の内訳:
- 要件定義: 曖昧な要望を仕様に落とす具体化
- 振り返り: 事実と解釈を分離する整理力
- 提案資料: 論点を絞り意思決定に必要な情報だけを置く構成力
■ 4. 得意が再現される条件の探索
- アウトプットの形は言語（会話・文章）に限らない
- コードの可読性・アーキテクチャ設計・開発フローの整備もコミュニケーションの一形態
- 本質は「いかに再現可能な価値を出せるか」にある
- 苦手を消すより先に得意が再現される条件を見つけることが優先
- 口頭が弱くても文章・コード・情報の構造化で確実に価値を届ける手段はある
- 自己理解と解像度の高さがこれからの時代を生き残るための最大の強みとなる