言語化が下手な人は5つのタイプに分けられる
「Slackで何を言いたいのかわからない」「ドキュメントを書くのに異常に時間がかかる」
こういった人は組織に一人はいないだろうか。
マネージャーとして「言語化能力を鍛えてほしい」と思うことは多いとは思います。また、LLMを利用して業務を行う際には言語化能力が非常に重要となると考えております。
ですが、正直なところ、できていない人に対して、トレーニングでなんとかなるのか疑問に感じることもあるのではないでしょうか。
僕は23歳の頃、会社の先輩に「お前、何言ってるかわからないから話すのやめるわ」と言われたことがあります。かなりショックだったのですが、それ以来、「どう伝えればわかってもらえるか」を強く意識するようになりました。
その結果、今では言語化能力が高いと言われることもあります。(このようなnoteを書いていると言語化してもらうの助かるとも言われます。)
このような経験から言語化能力は天性のものではなく、一定は鍛えられる能力だと考えています。
ただし、トレーニングが効く人と効かない人がいるのも事実です。そして、重要なこととして、どこで詰まっているかを把握しないと、適切なトレーニングができないということです。
文章を作るまでのプロセス
実際に人間がパソコンを使い、文章を出力するまでには、下記のような思考・行動プロセスがあります。
読解:状況を正しく理解する
構造化:頭の中で組み立てる
表現:文章にする
整形:相手が読みやすいように整える
タイピング:物理的に入力する
「言語化能力が低い」と一括りにしがちだが、実際には上記のどこかで詰まっている。読解で詰まっている人に文章の型を教えても意味がない。構造化で詰まっている人に「結論から書け」と言っても、結論が整理できていないのだから書けない。タイピングが遅くて思考を文字に変換できていない人もいる。
この記事では、それぞれのプロセスで何が問題になるのか、どうすれば改善できるのかを整理していく。
1. 読解で詰まっている人
読解力の問題は、すべての入り口です。
ホスト業界で「軍神」と呼ばれるホストがいます。売れないホストに小学3年生の国語ドリルをやらせる動画があるのですがその中で彼は「すべての入り口は読解です。ここをミスったらすべてが終了する」と説明しています。
相手の言葉や状況を認識し、読み解いて、考えて、表現する。この流れの中で、読解でミスると、その先の思考もミスる。結果、意味のわからないことを発言することになります。
チェック方法
質問に対して的外れな返答をする
指示の意図を取り違える
「そういう意味じゃなくて…」と言われることが多い
「読解力診断」のレベル3で満点が取れない
読解力診断に関してはぜひ試してほしいところ。
客観的に小学生レベルの読解力を持っているか把握することができます。
改善方法
小学校高学年〜中学生レベルの国語ドリルをやる
自分のレベルに合わせた問題を解く
読書量を増やす(技術書、ドキュメント、何でもいい)
相手の発言を「つまり○○ということですか?」と言い換えて確認する習慣をつける
2. 構造化で詰まっている人
構造化とは、「具体的な情報を抽象化して整理し、それを再び具体的な形で出力する」プロセスです。言語化能力の核心部分であり、最も改善が難しいです。
具体と抽象を行き来する力
言語化が上手い人は、具体と抽象を自在に行き来ができます。
たとえばクレーム対応の報告を考えてみます。
「10:15にお客様から電話があった」「10:30に上司に報告した」「11:00に折り返し電話をした」——これが具体
「配送遅延によるクレーム」「原因は在庫管理ミス」「対応として謝罪と再発防止策を提示」——これが抽象
構造化ができない人は、具体の羅列しかできない。「あれが起きて、これもあって、それで対応して…」と時系列で話すことが多いです。
一方、構造化ができる人は、具体を抽象に引き上げてから整理する。「原因は何か」「背景は何か」「対応は何か」というフレームに当てはめて、必要な具体を配置しています。
具体から抽象に上がり、抽象から具体に下りる。この往復ができないと、構造化された文章は書けません。
帰納と演繹
この「具体と抽象の往復」を論理学では帰納と演繹と言います。
帰納:複数の具体的事実から一般的な結論を導く(「A、B、Cが起きた。だからDが原因と言える」)
演繹:一般的な前提から個別の結論を導く(「Xという原則がある。今回はYの状況だ。だからZになる」)
技術文書の多くは、この2つの組み合わせで成り立っている。「自分の文章は帰納で書いているのか、演繹で書いているのか」を意識するだけで、論理構造のない文章を書く確率は大幅に下がります。
チェック方法
「で、結局何が言いたいの?」と言われる
時系列でダラダラ話す・書く
口頭で説明させても要点がまとまらない
話が長い割に情報量が少ない
改善方法
「原因/背景/対応」「目的/手段/結果」などのフレームワークを使う
書く前に「要するに何?」を自問する
ChatGPTに「この内容を構造化して」と頼み、出力を見て学ぶ
良いドキュメントを読み、「なぜこの順番で書かれているか」を分析する
構造化能力を本格的に鍛えたいなら、『具体と抽象』(細谷功)がオススメ。
具体と抽象の往復思考を体系的に学ぶことができます。
事実と解釈を分ける
構造化のもう一つの重要なポイントは、事実と解釈を分けて書くこと。
人がどう振る舞ったかという「事実」と、それに対して自分がどう意味づけしたかという「解釈」は別物だ。これが混同されると、読み手は何が起きたのか正確に把握することができません。
悪い例
佐藤さんはやる気がないようです。
良い例
佐藤さんは今週、2回遅刻し、タスクの期限を1日超過しています(事実)。
モチベーションが下がっているのかもしれません(解釈)。
悪い例では「やる気がない」という解釈だけが書かれている。読み手は「何をもってやる気がないと判断したのか」が分からない。
良い例では、まず事実(遅刻、タスクの期限超過)を示し、その上で自分の解釈を述べている。読み手は事実を見て、同じ解釈をするかどうか判断することができます。
テキストコミュニケーションでは、この区別が特に重要だ。対面なら「それってどういう意味?」とすぐ聞けるが、テキストではそうはいかない。事実と解釈が混在した文章は、誤解や不要な摩擦を生みやすいです。
3. 表現で詰まっている人
頭の中では整理できているのに、それを文章にできない人がいる。「話すと分かりやすいのに、書くと分かりにくい」というパターンです。
このタイプは、構造化まではできている。何を伝えたいか、どういう順番で説明すべきかは頭の中にある。しかし、それを文字に落とす段階で何かが抜け落ちています。
文章例
表現で詰まる人は、情報は揃っているのに読みにくい文章を書く傾向があります。
例1:接続詞がない
悪い例
今回のリリースは延期します。API連携の仕様が変更になりました。テストの追加が必要です。3日間の延期を予定しています。
良い例
今回のリリースは延期します。理由は、API連携の仕様が変更になったためです。その結果、追加のテストが必要となりました。したがって、今回は3日間の延期を予定しています。
悪い例では、文と文のつながりが見えません。読み手は「なぜ延期なのか」「仕様変更とテストの関係は?」を推測しなければならないのです。
良い例では、「理由は」「そのため」「結果として」という接続詞で因果関係が明示されています。
例2:段落が分かれていない
悪い例
先週のミーティングで決まった件ですが、デザインはパターンAで進めます。開発は来週から着手予定です。テストは外部に依頼することになりました。予算は別途確認が必要です。リリースは来月末を予定しています。
良い例
先週のミーティングで決まった件について報告します。
デザイン:パターンAで進めます
開発:来週から着手予定
テスト:外部に依頼
なお、予算は別途確認が必要です。リリースは来月末を予定しています。
悪い例では、デザイン・開発・テスト・予算・リリースがすべて1つの段落に詰め込まれている。
良い例では、段落と箇条書きで情報が整理され、一目で全体像が把握できるようになっています。
例3:強調すべきポイントが埋もれている
悪い例
データ移行作業は明日の午前10時から開始します。作業中はシステムが停止します。ユーザーへの事前通知は完了しています。作業時間は2時間を予定しています。
良い例
重要:明日10時〜12時、システム停止
データ移行作業のため、明日の午前10時から12時までシステムを停止します。
準備状況ユーザーへの事前通知:完了
作業時間:2時間を予定
悪い例では、最も重要な「システム停止」という情報が他の情報と同列に書かれています。
良い例では、冒頭で強調し、読み手がすぐに重要情報を把握できるようになっています。
例4:口語的すぎる
悪い例
さっき話した件なんですけど、やっぱりちょっと難しいかなと思っていて、というのも時間的に厳しいんですよね。なので別の方法を考えた方がいいかもしれないです。
良い例
先ほど相談した件ですが、実施は難しいと考えています。理由は、スケジュール的に厳しいためです。別の方法を検討したいと思います。
悪い例では、口語表現(「さっき」「やっぱり」「ちょっと」「〜かなと」「〜なんですよね」)が多く、表現があいまいとなってしまっています。
良い例では、書き言葉に変換され、簡潔で明確になっています。
チェック方法
上記の例のような文章になっている
話すと分かりやすいのに、書くと分かりにくい(と言われる)
頭の中では整理できているが、文章にできない
「言いたいことは分かるけど、文章が読みにくい」と言われる
改善方法
良いドキュメントを「写経」する
書いた文章を音読してみて、違和感がないかを確認する
接続詞と段落を意識する
「しかし」「つまり」「たとえば」「一方で」といった接続詞は、読み手に思考の流れを示す標識になります。また、1つの段落には1つの話題だけを入れることを意識するだけで、格段に読みやすくなります。
表現力を上げたいなら『考える技術・書く技術』(バーバラ・ミント)が名著。構造化の手法を学ぶことができます。
4. 整形で詰まっている人
内容は正しいのに、見た目が読みにくい人がいる。これは「型」を知らないだけのケースが多く、教えれば劇的に改善するケースが多い印象です。
チェック方法
結論が最後に来る
箇条書きを使わず、すべて地の文で書く
話題が混在している
相手に何をしてほしいか明示されていない
整形の4つの型
型1:結論から書く
悪い例:
昨日のミーティングで話してた件なんですが、Aさんが言ってたようにBの方法もあると思うんですけど、Cの観点から考えるとDの方がいいかなと思っていて、でもEの問題もあるので、結局Fにしようと思います
良い例:
結論:Fにします
理由:Cの観点から見るとDよりFの方が適切
補足:Bの方法も検討しましたが、Eの問題があるため見送りました
型2:箇条書きで構造化する
悪い例
リリースが遅れそうで、理由としてはAPI連携の仕様が途中で変わって、それに対応するのに想定より時間がかかっていて、あとテストも追加で必要になりました。
良い例
状況
- リリース予定日から3日遅延の見込み
原因
- API連携先の仕様変更(先週通知済み)
影響
- 実装修正:2日
- 追加テスト:1日
型3:話題を分ける
悪い例
今週期限のデータ集計ですが、完了しております。あと、来週の定例ミーティングの時間を変更したいのですが大丈夫ですか?
良い例
データ集計について
- 完了しております。
来週の定例ミーティングについて
- 時間を変更したいのですが、ご都合いかがですか?
型4:相手に求めるアクションを明示する
悪い例
先日ご指摘いただいた点を修正しました。一部、元の表現を残した箇所があります。
良い例
先日ご指摘いただいた点を修正しました。
確認いただきたいこと
- 資料全体の確認
- ○○の部分は元の表現を残しています。
この判断で問題ないか確認をお願いします
5. タイピングで詰まっている人
見落とされがちだが、タイピング速度がボトルネックになっているケースがある。実際、脳の思考速度にタイピングが追いついていないケースはかなり多く見られます。
頭の中では「こう書きたい」と思っているのに、手が遅いから途中で思考が途切れる。打っている間に次に書きたいことを忘れる。結果として、端折った文章や、途中で論理が飛んだ文章になってしまいます。
本人は「うまく言語化できない」と思っているが、実際には言語化はできていて、単に出力のスピードが追いついていないだけというケースが少なくないです。
リモートワークだと、同僚のタイピングが遅いことに気づけない。チャットの返信が遅い人がいたとき、「考えるのに時間がかかっている」のか「打つのに時間がかかっている」のか分からないのです。
チェック方法
「寿司打」などでスコアを測定する
キーボードを見ながら打っている
チャットの返信が異常に遅い
短い返信しかしない(長文を打つのが面倒)
目安として、寿司打の高級(10,000円)コースで10,000円以上が最低ライン。日常的にテキストでやり取りする仕事なら、15,000円以上を目指してほしいところです。
改善方法
毎日「寿司打」をやらせて、目標スコアを取れるまで続ける
タッチタイピング(ブラインドタッチ)の練習をする
タイピング速度は練習すれば確実に上げることができる
タッチタイピングができないなら、まずそこから始める。1〜2週間も練習すれば基本は身につく。学べばすぐにできるスキルを学ばずに放置しているのは、長期的に見て損でしかないです。
トレーニングが効く人・効かない人
ここまで5つのプロセスを見てきたが、すべてに共通する前提がある。
トレーニングが効くのは、「自分の文章が伝わっていない」という自覚を持てる人だけです。
この自覚さえあれば、どのプロセスで詰まっていても改善の余地があります。
「うまく書けない」という課題意識がある
読み手の視点を想像しようとする意志がある
フィードバックを素直に受け止め、次に活かそうとする
逆に、自覚がない人にはトレーニングは効かない。
「書いたのに読んでもらえない」と不満を言う
長文を読む習慣がなく、作る気もない
フィードバックを受けても「そういう見方もある」で終わる
こういう人に対して、いくら「結論から書け」「読み手を意識しろ」と言っても響かないし、改善することはできません。
組織としての対応
組織としてはやるべき対応を考えてみる。
できている人を褒める
効果があるのは、良いコミュニケーションをしている人をみんなの前で褒めること。
「この報告、すごく分かりやすかった」「このチャット、構造化されていて読みやすい」——こういうフィードバックを公開の場で行う。すると、周りの人は「ああ、こういう書き方が評価されるのか」と学ぶ。
「要するにこういうこと?」で返す
分かりにくい文章が来たとき、「要するにこういうことですか?」と1行で返すのも育成になる。
相手が10行書いてきたことを、1行で返す。相手は「自分の10行は1行で済む内容だったのか」と気づくことができます。
マネージャーとしての現実的な判断
言語化能力のトレーニングは、本人に自覚と意志がある場合にのみ有効です。自覚がない人に対して時間を投資しても、費用対効果は低いです。
すでにチームにいる場合は、まず「自覚があるかどうか」を見極める。自覚があれば育成投資する価値がある。自覚がなければ、テキストコミュニケーションが少ないポジションを検討する、対面でのフォローを手厚くするかなどの対応が必要となります。
「誰でも鍛えられる」と楽観視するより、「鍛えられる人と鍛えられない人がいる」という現実を受け入れた上で、適切なリソース配分を考える方が、チームとしては健全だと僕は考えております。
個人としての対応
まずは自分がどのプロセスで詰まっているかを客観的に把握することから始めましょう。
自己診断の方法
読解力のチェック
読解力診断でレベル3が満点になるか確認する
「そういう意味じゃなくて…」と言われた経験を振り返る
構造化のチェック
自分が書いた文章を見直し、「結論は何か」が一目で分かるか確認する
時系列でダラダラ書いていないか確認する
表現のチェック
口頭で説明したことを文章にしてみて、同じ分かりやすさになっているか確認
整形のチェック
過去に送ったチャットやメールを見返し、箇条書きや結論ファーストができているか確認
タイピングのチェック
寿司打で自分のスコアを測定する(高級コースで10,000円以上になるか確認)
改善の優先順位
ボトルネックが分かったら、上流から順に対処する。読解→構造化→表現→整形→タイピングの順番です。
読解で詰まっているのに表現の練習をしても意味がないので、入り口を直しましょう。
言語化能力は、一度身につければ一生使えます。LLMを使う際にも、相手に伝える際にも、考えを整理する際にも役立ちます。投資する価値のあるスキルです。
まとめ
言語化能力が低い」という一言で片付けられがちですが、実際には5つのプロセスのどこかで詰まっています。
そして、トレーニングが効くのは「自分の文章が伝わっていない」という自覚を持てる人だけです。
自覚があれば、どのプロセスで詰まっていても改善ができます。自覚がなければ、変わることはありません。
組織としては、自覚の有無を見極めた上で適切なリソース配分を考えるべきで、個人としては、まず自分のボトルネックを特定し、上流から順に対処していくだけです。
言語化能力は天性のものではなく、正しく診断し、正しくトレーニングすれば、確実に伸ばせる能力です。
いいなと思ったら応援しよう!
よろしければ応援お願いします! いただいたチップはおいしいご飯を食べるのに使わせていただきます。


非常に分かりやすいまとめ、ありがとうございます! 自分でチェックして、出来ていないなと思う部分が多々ありました。 参考にさせていただきます。