私自身、物事を分かりやすく伝えるスキルを身に着けるため、手あたり次第に、いくつかノウハウ本を読んだり、YouTube動画を観たりしてきました。本記事では、本や動画から得られたノウハウや、私が普段の仕事で発見した個人的に使っているテクニックをまとめてみました。

本記事は育っていく記事です。筆者が新たに発見したノウハウは、随時、本文に追記されます。追記した箇所は、都度コメント欄でお知らせします。

0 本記事の最重要ポイント

本記事がストックの墓場に行ってもいいように、本記事の最重要ポイントだけ先に伝えておきます。

質問に答える時は、聞かれたことにシンプルに答える。
事実と解釈を分けて話す。

1 本記事で伝えたいメッセージ

1-1 コミュニケーション能力の苦手意識はノウハウで解決する

ITエンジニアの裾野が広がるにつれて、SNSでも「コミュニケーション能力の低いITエンジニア」の話題をちらほら見かけるようになりました。いわく「これからはITエンジニアにもコミュニケーション能力が求められる」「プログラミングができるだけでは生き残れない」「プログラミングの前に日本語を勉強しろ」（言い方キツいなー）とかね。仕事でも、上司や先輩から「何を言っているのか分からない」とイラつかれて自己嫌悪している人も少なくないのではないでしょうか。¹

でも、これって新聞の社説みたいに「重要だ」「求められる」と言ってるだけで、解決策を提示していないんですよね。そりゃ重要なのは分かってますがな。部下に対して「何を言っているのか分からない」と感想を言いっぱなしで建設的なフィードバックをしない管理職も多く、「説明が下手なのは自分でも分かってる。でも、どうすればいいかが分からない」とストレスを溜めている人も多いと思います。

この問題については、私自身も「じゃあどうすればいいか」というアクションプランをずっと考えていました。手あたり次第に本を読んだり動画を観たりするうちに、たどり着いたのが「説明下手を抜け出す程度であればノウハウで解決する問題なんじゃないか」という仮説です。本や動画で学んだことをまとめたノウハウ集を作れば、コミュニケーションに悩んでいる人の突破口になるかもしれないという思いから、本記事を書きました。

1-2 分かりやすく伝えることは、直観に逆らう「脳にしんどい」行為である。自分を責める必要はない

喫茶店や居酒屋で、対面に座った相手にメニューを見せるとき、相手に見やすいように、自分から見て上下逆に見せますよね。物事を分かりやすく伝えるとは、相手に見やすいように情報構造を組み替える作業です。相手からは見やすくなるかわりに、自分からは見づらくなります。

同様に、結論を先に話す、聞かれたことに答える。これらは人間の直観に逆らう行為なので、難しくて当然なのです。「結論を先に言いましょう」と言われても、本来、直観に逆らわず時系列に沿って過程や根拠から話すほうが、脳に負担がかかりません。「聞かれたことにシンプルに答えましょう」と言われても、我々はすでに日本語でのハイコンテクストな会話に最適化されてしまっています。突然、プログラミングのような会話をしろと言われても厳しいものがあります。「ボールペンと消しゴムの値段は合わせて110円。ボールペンは消しゴムより100円高い。では、消しゴムの値段は？」という問いに誤答する人が続出する事実を見ても、人間は直観を裏切るわずかな段差にあっさりと躓いてしまう生き物なのです。説明が下手なのは、別にその人が無能だからではなく、直観に反して考えることに脳が慣れていないだけ。自己嫌悪せず、少しずつ慣れていくしかないのかな、と私は思います。²

以下、対策案です。分かりやすく伝えるのを、いきなり口頭でやるのは難しいです。メールや報告書、チケットなどの文章を書くときに、気が済むまで文章を試行錯誤でブラッシュアップしましょう。

1-3 コミュニケーション能力の向上は生産性向上につながる

システム開発費用というと、開発費や管理費を思い浮かべる人が多いと思いますが、意思疎通のエラーがもたらす「隠れコスト」も無視できません。

意思疎通のエラーによる手戻りの発生や、メールの往復などで、2者間で１日10分のロスが発生すると仮定します。これは、1ヶ月で200分（20日 * 10分）、1年で40時間にあたります。この40時間のロスがチームのメンバー5人の間のコミュニケーションで発生すると仮定すると、5人のコミュニケーションパスは10本（5 * 4 * (1/2)）なので、5人分のロスは400時間（10パス * 40時間）。400時間は人日換算で50人日（1人日=8時間）。年間50人日のロスが発生するという試算です。

あくまで試算ではありますが、コミュニケーションスキルにテコ入れするだけで50人日もセーブできるわけです。これは馬鹿にならない数字です。ITエンジニアとして技術力の研鑽はもちろん重要ですが、技術力と並行して、チーム全体のコミュニケーションスキルを底上げすることも生産性向上に大きく寄与するのではないでしょうか。

2 「人に物事を伝える」ことの大前提

2-1 相手の立場に立って考える

「伝え方」のノウハウは、「相手の立場に立って考えること」の一言に集約されます。「相手の立場に立って考える」とはどういうことかを理解するには、以下の書籍とスライドを読むことを強くオススメします。

『新装版「分かりやすい表現」の技術　意図を正しく伝えるための16のルール』（文響社）
あいまいな道路標識、ユーザー置いてきぼりな家電の取扱説明書、肝心なことが書かれてない設備点検のお知らせ、構造化されていない冊子の目次。巷に溢れる「分かりづらい表現」の実例を取り上げながら、その原因と改善ノウハウが分かりやすく解説されています。日頃、これらの分かりにくい表現にストレスを感じている人なら「あるある！」と膝を打つことでしょう。本書を読むことによって、分かりづらい表現を見た時に受け手が感じるストレスを体験できます。
『世界で一番やさしい　資料作りの教科書』（日経BP）
大事なのは、伝えたいことがあるかどうか。全体を通して何が言いたいのか、受け手にどうしてほしいのか。どのノウハウ文にも書かれてない「伝えること」の本質論は慧眼です。個人的な意見ですが、PowerPointやExcelなどのソフトウェアの高機能化が、「伝えたいこと」そっちのけで資料が盆栽にされる傾向に拍車をかけたのかもしれません。
「誰がどう見てもそうとしか受け取れない文書術（公開版）」
言葉足らずなパートナー会社とのやり取りの臨場感ある描写に、強い共感を覚えました。文章に書かれていない意図の解読を丸投げされた受け手が味わうフラストレーションがよく伝わってきます。スライドの28ページ目にある「３．自分は「何の話をしているのか？」を知っているが相手がそれを理解できる訳ではないことが分かっていない」には、何度も頷きました。

報告も、メールも、質問への回答も、プレゼン資料も、ブログ記事も、それぞれカタチは違えど、その本質は「相手に伝える」です。これらの書籍やスライドには「相手の立場に立って考えながら伝えること」の本質が詰まっています。

2-2 「分かりやすく表現する」は手段である

「分かりやすく表現すれば、相手に理解してもらえる」ではなく「相手に理解してもらうために、分かりやすく表現する」です。「分かりやすい表現」はあくまで手段。「表現を分かりやすくしよう」と意識すればするほど、ぎこちなくなります。目線の先は、つねにゴール「相手が理解した状態になる」に置くようにしましょう。

これについては、ケンブリッジ・テクノロジー・パートナーズさんの以下の動画でとても分かりやすく解説されています。

3 伝え方のキホン 9

ノウハウ本やYouTube動画によると、世の中の非常に多くの人が「聞かれたことに答える」と「事実と解釈を分けて話す」ができてないそうです。ここでは、そのテの「どのノウハウ本や動画でも言われるキホン」について示します。

3-1 質問に答える時は、聞かれたことにシンプルに答える

「タスクは終わりましたか？」に対して「いま○○で止まってまして、それが解決したら今日中に終わると思います」と答えるのが「質問に答えてない」状態です。相手が知りたいのは「タスクが終わったか終わってないか」なので「はい、終わりました」または「いいえ、終わっていません」と答えます。

3-2 事実と解釈は分けて話す

事実と解釈は、明確に分けて話します。これについては、ハック大学さんの以下の動画でとても分かりやすく解説されています。

「事実と解釈を分けないやつはバカと思われます」（ハック大学）

これは私の補足ですが、その時点では事実が明らかでなく解釈しか話せない場合、「事実が分かってないという事実」を示します。「まず事実は分かっていません。ただ、これは私の解釈ですが、○○だと見ています。事実については別途、裏どりします」というふうに。そうすれば「事実を知らないから事実を話さない」のか、「事実を知っているが話していないだけ」なのか、区別がつきます。

3-3 相手の頭にフォーマットを作る

分かりやすく説明するには、相手の頭にフォーマットを作ったうえで、そのフォーマットに言いたいことをはめ込むイメージで説明します。説明のフォーマットには「PREP法」「SDS法」「CRF法」があります。

3-4 冒頭で「これからどんな話をするか」を示す

「これからどんな話をするか」を先に伝えておけば、相手は話を受け入れる態勢が作れます。最初に結論を話すことや「二点ほど質問ですが」「ひとつ相談ですが」もこれにあたります。

3-5 主題から外れる話は後回しにする

Aについて説明している最中に、補足的にBの話をすると、聞き手は「今はAの話をしてるんじゃないの？」と迷子になるため、脇道にそれる話は後でまとめて話します。

3-6 自分が話したいことではなく、相手が知りたいことを話す

自分が知ってることを思いついた順序でアレもコレも話すと、相手は混乱します。説明した内容は、相手の理解や納得、意思決定を行うためのインプット材料になります。理解や意思決定にとってノイズになりそうな材料は伏せておくか、後でまとめて話します。

3-7 1センテンス1メッセージを守る

「けども」「なんですけど」で文をダラダラ続けないようにします。思いついた順に話すのは楽ですが、ポイントがぼやけてしまいます。以下を心がけます。

1センテンス1メッセージを心掛ける。
既知情報に新情報を付け足すイメージで、インクリメンタルに説明する。

3-8 報告はアクションプランとセットで行う

報告の場では、報告が「事実の報告」だけで済むことは少ないです。事実を踏まえた上で、自分はどうしたいか？相手にどうしてほしいか？などのアクションプランも併せて示します。

3-9 あいまいな質問には意図を想定して答える

「新人のAくん、どんな感じ？」「状況どうですか？」のように、ふわっとした質問なので、ふわっとした答えしかできない場面はよくあります。このケースでは、質問の意図を確認しましょう。「といいますと？」と言うと、相手は意図を言ってないことにハッと気づき、質問の意図を話し始めます。

もし、あなたの職場が「質問に質問で返すことは大変失礼にあたります」という宗教を信仰している場合、自分の中で質問を具体化します。例えば「新人のAくん、どんな感じ？」という質問は、「Aくんはチームになじんでるか、孤立してないか」や「Aくんの仕事ぶりはどうか」のように具体化します。

質問を「Aくんはチームになじんでるか、孤立してないか」に具体化した場合、回答例は「作業に没頭するタイプなので、他のメンバーとの交流はほとんどないですね。自分から質問してこない子なので、こちらから、何か悩んでることある？と定期的に聞くようにしてます」のようになります。
質問を「Aくんの仕事ぶりはどうか？」に具体化した場合、回答例は「小学生から趣味でプログラミングを続けてきた子なので、さすが手が早いですね。モノづくりでは即戦力になりそうです」のようになります。

「状況どうですか？」という質問は、「終わってるか終わってないか。終わってない場合は、何で止まっているのか」のように具体化します。回答例は「状況は、まだ終わっていません。終わっていない理由はAさんの返信が無いためです。今日中にAさんに電話してフォローします」のようになります。

余談ですが、質問の意図を外すと「いや、そうじゃなくて」と言われるんですがね。だったら最初から意図を言えや！と思いますが。あれめっちゃ腹立つ。

4 伝え方のテクニック 22

ここでは、参考文献や参考動画で得られた、物事を分かりやすく伝えるための小技を紹介します。私が経験的に発見したテクニックも含まれます。

4-1 全体像における現在位置を示す

全体像を示したうえで、「いま話しているのがどの部分か」の現在地を示します。
例「開発プロセスは大きく分けて、要件定義、設計、実装、テストの4工程に分かれます。この4工程のうち、今日話すのはテストについてです。」

4-2 タスクを分解する

タスクを複数チャンクに分解したうえで、チャンク単位で説明します。
例「ホストに接続できません。具体的には、ホストの名前解決、ホストとの3ウェイハンドシェイク、ホストとのHTTP通信のうち、3ウェイハンドシェイクで失敗しています」。

4-3 Fit & Gapで同じ／違うを分ける

類似しているが、部分的に異なる二つのもの（as-isとto-beなど）を並べた上で、どこまでが同じで、どの部分がギャップか？を説明します。

4-4 感覚をスコアで伝える

感情の度合いなど、言葉では伝わらない情報をスコアで示します。
例「タンスの角に足の小指をぶつけた時の痛みを10とすると、紙の端で指を切った時の痛みは2です」。

4-5 二値の質問を、スコアを問う質問にする

進捗会議の場でしばしば耳にする「本当に大丈夫ですか？」「これで間に合うんですか？」という質問。
このテの質問は、進捗会議を「参加者を安心させる場」にするだけで、プロジェクトのリスクを早期発見してリカバリプランを策定するという進捗会議の目的には何一つ貢献しない無意味な質問です。このテの連中で、「大丈夫です」と言わせて言質をとってリスクヘッジしようとする奴－アラートを上げると「えー！こないだ聞いた時は間に合うって言ったよね？」とか嫌味たらしく驚く奴もいますが、死ねばいいのに。

そこで「間に合いますか？」ではなく、「間に合う確率は何％ですか？」のようにスコアで問います。この聞き方だと、例えば「20%です」という答えに対して、「どんな不安要素がありますか？」「何があれば残り80%を埋められますか？」というような建設的な議論につながります。

本項の内容は『プロジェクトのトラブル解決大全』（KADOKAWA）のp116「31 「社内報告のシンプル化」で実利と期待感をUP」を参考にしました。

4-6 「であるもの」を「でないもの」で説明する（補集合の否定）

Aを外延的に定義する時、「Aであるもの」を列挙するのではなく、「Aでないもの」を示したうえで「これら以外のすべてがAです」と説明します。
例「副詞が修飾するものは名詞以外すべてです」。

4-7 表形式にして「他にはないの？」を無くす

大抵のことは、表形式で表現すると見通しが良くなります。組合わせの網羅性が担保できるメリットもあります。

4-8 キャラクター化して論理関係を示す

複雑な話を説明する場合は、話のポイントを2~3つ抜き出し、それらを登場人物とします。つぎに登場人物を矢印でつないで論理関係を説明します。プログラミングで例えると、ひとつのプログラムを関数やクラスに分割したうえで、それらの関係を説明するイメージです（分割して統治せよ）。

4-9 キーワードを分解する

キーワードを単純語に分解したうえで、単純語をそれぞれ説明します。
例「固定資産税とは何か？固定、資産、税に分けて説明します」。

4-10 キーワードを拡大する

地図のある地点を拡大表示するように、キーワードを具体的に説明します。
例「AとBの違いは○○です。この○○というのはですね」。

4-11「質問に答えると」ではじめる

質問に回答する際、「質問に答えると」という枕詞で始めることによって、回答者自身が質問に答えるように矯正できます。「回答の後に、回答に至った事情や背景が説明される」という予測を相手に与えることによって、質問に端的に答えると怒り出す人を牽制する効果もあります。

4-12 「結論から言うと」ではじめる

「まず結論から言うと」という枕詞で始めることによって、説明者自身が結論ファーストで話すように矯正できます。「結論の後に、その結論に至った過程が説明される」という予測を相手に与えることによって、結論を聞いた時の驚きを緩和する効果もあります。

4-13 原則と例外を重みづけする

例外のある法則を説明するとき、原則と例外で重みづけしないと主張がぼやけます。原則はメインで、例外は補足で説明します。

4-14 非含意を明示する

AはBを含意しない場合、相手を迷わせないために、「Bを含意しないこと」を明示します。
例「プレミアム会員を解約します（アカウントは削除されません）」。

4-15 比較表現の基準を示す

「速い」、「多い」、「高い」などの比較表現を使う際は、「何と比べて？」という基準を明示します。他の何かと比べて、なのか。理想と比べて、なのか。

4-16 最上級表現の制約条件を示す

高校数学Aに出てくる、以下のような最短経路問題。

上図において、スタートからゴールまでの最小通過マス数は 10 ですが、これに「途中、A地点とB地点を順に 1 回通過すること」という制約をくわえると、最小通過マス数は 14 になります。つまり「何が最小か」は制約条件で変化します。

「最大、最小、最短、最長」といった最上級表現を使う時は「〇〇という制約のもとで」という制約条件を示すようにします。他にも、「すべて」を使う際は「どの範囲において」という全体集合を定義します。

以前「コストを度外視してでもリスクは徹底排除すべきだ」と発言した人がいました。コスト度外視でいいのなら、事業を中止すればリスクはゼロになりますね…。

4-17 正しさの基準を示す

物事の「正しい／正しくない」は、「何が正しいか」の基準とセットで伝えます。日常会話では主に「道徳やマナー」が暗黙に基準とされるため基準を明確にする習慣が無いせいか、仕事でも正しさの基準はあいまいにされがちです。

4-18 「で、俺は何をすればいいの？」に答える

システムの不具合発生時、エンドユーザが仕事を進めるには何をすればよいか、アクションプランの提示が求められます。エンドユーザの最大の関心事は、システムの仕組みや使い方ではなく「自分の仕事を進めること」です。

4-19 「そもそも何に困ってたんだっけ？」に答える

質問する時、質問するに至った背景を伝えると、別の解決策を提示してもらえる可能性があります。
仕様検討時は「どんな機能を作るか？どうやって実現するか？」で頭がいっぱいになりがちです。「顧客が本当に必要だったもの」を外さないためには、まず「エンドユーザのお困り事は何か」という原点に立ち返って考えるとよいです。
納期を守ることと要件を満たすことにしか興味のないSEが構築したシステムにありがちな話として、マニュアルを読み込んでお勉強して、そのシステムのオタクにならないと使えないようなインタフェースは世の中に多いです。エンドユーザの関心事を念頭に置き、そのようなインタフェース設計は極力避けるべきです。
部下やメンバーに作業を依頼する場合、その作業の目的も一緒に伝えると「一つ一つ細かい質問をされること」が激減します。作業を依頼された側としては、目的を知らされていないと「何が正しいかを判断する基準」を持ちようがないため、何か疑問がわいた時にひとつひとつ「これはどうしますか？」と確認せざるを得ません。

4-20 「結果的にどうなってほしいか？」に答える

すぐ「どうやって作るか？」に走りがちなSE脳を黙らせる一つの方法として、エンドユーザのお困り事を「結果的にどうなってほしいか？」というゴールから眺めてみる、という切り口もあります。エンドユーザへのヒアリングや、仕様検討の打ち合わせでは、「エンドユーザのお困り事は何か」「結果的にどうなってほしいか」を一番最初に設定しておくのもテですね。

4-21 「たぶん～だと思います」を「です」に変える

「たぶん～だと思います」を「～です」に変えます。「です」と言い切るのに強い心理的抵抗を感じるとすれば、その抵抗は「裏が取れてないので不安だ」という心の声である可能性が高いです。自分の予想や解釈を言うこと自体が悪いわけではないので、現時点では予想や解釈しか言えない時、あるいは裏どりしようのない時は、あくまで予想や解釈であること、裏どりは別途行うこと（あるいは裏どりしようがないこと）をはっきり示します。

4-22 相手のプロファイルを定義する

「相手の立場に立って考える」の「相手の立場」を分解すると、以下のポイントに具体化されます。このポイントの集合を「プロファイル」とします。相手のプロファイルに合わせて説明を切り替えながら話すのは高度なテクニックであるため、メールやプレゼン資料などの文章を作る時の参考にして下さい。

相手の理解力（例：運用手順書は「誰が作業しても結果が同じ」であるべき。行間を察しなくてもいいように、箸の上げ下ろしまで事細かに指示する）
相手の前提知識（例：システムの専門用語は営業部門には通じない）
相手の関心事（例：部長の関心事は、技術的な詳細よりも予算や顧客の話）
相手の熱意（例：マス向けの広告は「消費者は広告内容に無関心である」ところからスタートする）

本項の内容は『新装版「分かりやすい表現」の技術　意図を正しく伝えるための16のルール』（文響社）のp60「犯人2　「受け手」のプロフィールの未定義」、p68「犯人3　受け手の熱意の読み違い」他から着想を得ました。

5 参考文献・参考動画

5-1 参考文献

★★　…　強くおすすめ。
★　　…　おすすめ。

5-2 参考動画

「ロジカルな人になる簡単な方法（ロジカルシンキングができる人の会話・聴き方＆話し方）　元リクルート　全国営業成績一位、リピート9割超の研修講師）」

100回ぐらい繰り返して観たい、永久保存版の動画です。こちらの動画でコツを学んで場数を踏めば、仕事の会話や思考が激変するのではと思います。

「【一瞬でバレる】仕事ができない人の話し方５選（リピート9割超の研修講師／元リクルート　全国営業成績一位）」

「伝わらない人の話し方は「粒度」が粗い」、ありすぎる…。

「説明がうまくなる方法　5選!　（元リクルート　年間日本一トップ営業マン）」

ゆっくり話す。これが何にもまして大事かもしれません。

「事実と解釈を分けないやつはバカと思われます」

「根本原因として、作業者マインドになってしまっている」は慧眼だと思いました。

「【誰でも出来る！】説明が上手くなる方法」

人に物事を伝える時のベースとなる考え方が、分かりやすく解説されています。100回ぐらい繰り返して観たい動画。

「【即改善】仕事で「何言ってるかわからない人」の話し方 TOP3」

「意見を通す」ありきにならない。

「【話し方の極意】なぜあなたの話はわかりにくいのか」

相手の頭にメンタルモデルを作ったうえで、そこに話す内容を落とし込む。

「【社長直伝】やれば周りと差がつく！絶対に毎日実践すべき仕事のキホン 5選」

聞かれたことに答える。

「【一瞬でバレる】仕事が出来ない人の話し方TOP3」

解釈は事実とセットで話す。聞かれたことに答える。

「無能な人が毎日言ってる言葉」

人間の注意力に頼るのではなく、仕組みで解決する。

【説明が上手い人、下手な人①】説明上手になれば仕事・恋愛・人間関係が上手くいく！

中田敦彦さんの解説動画。上司への報告、部下への指示、顧客や投資家へのプレゼンなど、どの伝え方がベストかは、相手の立場によって異なります。この動画では「下手な人の特徴」「上司への報告が下手な人」のケースについて解説されています。

【説明が上手い人、下手な人②】説明上手の共通点は自分よりも相手ファースト

上の動画の続編。この動画では「部下への指示が下手な人」と「客や投資家へのプレゼンが下手な人」のケースについて解説されています。

コミュニケーション能力の低いITエンジニアの話題が、最近になって増えたように見える原因は、以下のいずれかが考えられます。どれが原因であっても、本記事のノウハウ集としての機能には支障をきたさないため、本記事では深掘りしません。原因によっては本記事そのものの存在意義が否定される可能性がありますが、否定されたとしても「意味の無い記事だ」で終わるだけの話。
・昔と比べて、IT業界でのコミュニケーション能力の要求水準が高くなったため、コミュニケーション能力の低いITエンジニアが可視化されるようになった。
・昔も今も要求水準は高いが、ITエンジニアの裾野の広がりに相関して、コミュニケーション能力の低いITエンジニアの絶対数が増えた。
・昔と比べて、要求水準も高くなったし、コミュニケーション能力の低いITエンジニアの絶対数も増えた。
・現実に変化は無い。ポジショントークとしてITエンジニアのコミュニケーション能力が問題視されているかのように振る舞うメディアや個人、ポジショントークを真に受けて「問題視されている」を既成事実としたうえで何かを語るメディアや個人が増えた。
・最近になって話題にされることが増えたというのは筆者の妄想である。すなわち、昔も今も話題になっていないか、あるいは昔から話題にされているかのいずれかである。 ↩
人間がいかに直観を裏切る事実に弱いか？に興味がある人は、「4枚カード問題（ウェイソン選択課題）」や「モンティ・ホール問題」を調べてみてください。 ↩