四十三庵

蔀の雑記帳

わかりやすい説明をするテクニック

仕事柄、小難しいことを噛み砕いて説明する機会が多い。
僕は10年くらいこのブログを書いてきて、その中で体得した方法論が、結構仕事でそのまま使えることがある。
そういう経験知を、このたび文章化してみようと思う。

(目次)

最悪の方法

一番わかりづらい説明にするには、思いついたまま喋ることだ。
大学教授とか、講義の準備一切せずに思いついたままに喋ってる人がちょいちょいいましたが、大抵わかりづらい説明になっていた。
ただアドリブで喋ってもある程度形になるトーク力を持ってる人も、
世の中一定数いるので、訓練すれば思いついたまま喋っても、最低限の形にすることはできる。

ただ内容が高度になってくればくるほど、それだと辛くなる。

多分一番大事なこと

わかりやすい説明する上で、たぶん一番大事なのは、構造化することだと思う。

人間は新しい情報をインプットする際、受け取った言葉を、
1から順番に処理しているわけではなく、ある程度自分の中で構成して処理していく、と思う。
一時間の授業の中で、「あ、ここは雑談パートなんだな」とか、「ここは試験にでるから必ず覚えないといけないんだな」とか、
優先順位をつけて、勝手に序論→本論→(話題転換)→本論……みたいにして、メリハリをつけて処理する。
意識的であるか、無意識であるかは別にして、どんな人でもやっている。
人間の記憶力はそんなによくないので、取捨選択しないといけないため、こういう風に処理してるのだと思われる。

日常の雑談の中でも、相手がどうでもいい、忘れてもいいような話をしているときと、
すごく大事な話をしているときとで、反応をわけていると思う。
これもまた無意識の構造化の例だ。

わかりやすい説明をする際は、意識的に構造を組み立てて、相手に提供することだ。
そうすることで、相手の理解と、自分の説明したいことを限りなく近くすることができる。
(完全に一緒にはならないだろうけども)

構成について

以下、構成について書く。
具体例を書いてもいいけど、割と常識的なことだと思うので、
「こういう構成にするといいよ」とだけ簡潔に書く。

起承転結をつくる

説明の流れがあるとわかりやすい。

前提から本論へ

前提があるのなら、最初に話した方がわかりやすい。

具体から抽象へ

抽象論をするときは、具体的な例から話すとよい。

抽象から具体へ

ただ扱う内容や相手によっては、順序が逆の方がいいときもある。
相手が学者や専門家であるならば、こっちの方が話が早いかもしれない。

全体から部分へ

最初に全体像を示してから、各論を掘り下げていく方がわかりやすい。
×「これから全社PCのWindows10アップデート対応について説明します。
 現在我が社ではWindows7がメインで〜〜(云々かんぬん)
 マイクロソフトのサポートは〜〜(云々かんぬん)
 競合他社の対応状況は〜〜(云々かんぬん)
 したがって我が社の対応スケジュールは〜〜(云々かんぬん)」
最初で一応自分が何を話すかは最低限説明しているが、できればもう少し説明した方がいい。

◯「これから全社PCのWindows10アップデート対応について説明します。
  まず我が社の現在の状況をご説明します。
  その次に対応スケジュールのご説明ですが、その前にマイクロソフトのサポート期限と競合他社の対応状況をご説明し、
  その後にスケジュールについて説明致します。
  現在我が社ではWindows7がメインで〜〜(云々かんぬん)(以下同)」

難易度を下げる試み

何かを説明されてわからないのは、結局説明内容が難しいという場合が多い。
まあでもなにか説明して誰でもパッっと理解できることなら、その説明してお金もらえるということもないだろう。

難易度を下げるための方法論を列挙してみる。

割愛する

説明しなくてもいいことは、できるだけ割愛するほうがいい。
学校の授業であれば、脱線して勉強になることをやってもいいけれど、
特に仕事のプレゼンなりなんなりであれば、その場で理解する必要がない事項について補足説明を入れるくらいなら、
多少関連性があっても思い切って割愛したほうが良い。
ただその知識がないと、本質が説明できない、というときは、多少難しくても割愛しないほうがよい。

専門用語を省く

相手が専門知識を持っていない可能性があるなら、専門用語は極力使わない方が良い。
「このぐらいの用語は知ってるだろ。むしろ知ってろ」みたいな気持ちになるときもあるかもしれないが、
専門用語が理解の妨げになることは結構多いので、注意したほうがいい。
経験的に、知らない専門用語が一文に三つ以上でてきたときにその文章が理解できる確率はほぼゼロだ。
二つでもだいぶキツい。

例え話をする

適切なたとえは理解を助けるので、入れるとよい。

たとえば下のサイトのたとえなんてよいですね。
保険加入者がりんご、保険未加入者をバナナにたとえているので、頭の悪い僕でもスッと入ってきます。
hokensc.jp

……ということで、たとえ話は結構センスが問われる。
本質をとらえてるか、芯食ったたとえになってるかは、誰かに確認した方がいい。

よくオブジェクト指向の説明のときに、
「オブジェクトとは、モノやコトです。
 たとえばAnimalというクラスがあって、このクラスを継承してDogやCatのインスタンスをつくって、
 鳴き声をワンとニャーにしますね? これがポリモーフィズムです。
 ポリモーフィズムとは多態性です。わかりますね?」
みたいな説明はよくされるけど、これもよくないと思っている。
「え? じゃあオブジェクト指向で書くときは全要素のクラスつくるの?
森羅万象すべてをクラスで表現しないといけないの?」
みたいな気持ちになる。

ただ本質を理解させるのを諦めて、
もうわかったような気持ちになってもらわなければならない状況というのも世の中にはままあるので、
そういうときにもたとえ話は有効だ。
年配の人と話すと、クラウドをホントに雲の中に何かがあると思っていたり、
コンピュータウィルスとワクチンが医療のウィルスとワクチンのイメージでとらえてたりする。
パソコンすら触ったことないし、これから触ることもない人に、コンピュータウィルスを理解させるのは多分不可能なので、
別にパソコンも人間みたいにウィルスに感染するので、そのときは注射しないと動けなくなるとかいうイメージでとらえておいてくれてもよい。

ポンチ絵を描く

ポンチ絵、という言葉がどこまで通じるかわからないけど、要は概要図・概念図のこと。
官公庁とかでよく使われる、らしい。
長々と文章で説明しても、お偉いさんは読んでくれないので、
そういうときに「このペーパーだけだと説明しづらいんで、大臣にご説明するために、ポンチ絵一枚お願いしますわ」みたいな。

これもたとえ話と同じで、適切なポンチ絵は理解を助けるが、
結局モノによっては本質をブレさせたり、誤解を与えたりするので、使い方には要注意である。

メリットを語る

具体例・応用例を話す

対学者に話すときはずっと抽象論で何時間も話せたりするけども、
学生とかビジネスマンとかは、別に理論を知りたいのではなく、
その理論を覚えると何の役に立つのか*1をまず知って、
役に立つのであれば頑張って覚える、というモチベーションになる。
知的欲求から、その分野の知識なら何でも知りたい! みたいな学者タイプとはちょっと相容れない。
学者タイプと言っても、アメリカの大学レベルの教科書とか読むと、
「この学問は何の役に立っているのか」という話がだいたい第一章に来ているように思う。
イマドキは学者であっても、「で、そのご高説は何の役に立つんですか?」という質問の回答は用意しておくべきだ。

いずれにせよ、抽象的な概念を説明するのであれば、具体例・応用例は必ずセットになっているべきだと僕は思っている。
そしてできるなら、具体例に入る前に、メリットを語れると尚よい。
たとえば、

・オブジェクト指向という概念を説明しました、それは何の役に立つんですか? それは具体的にどうやって使うんですか?
 ⇒たとえば
  設計がわかりやすくなります
  コードの再利用性が高まります
  Javaで書くのであれば、こういう感じです。
  (以下略)

・哲学って何の役に立つんですか?
 ⇒その問い答えるためには、役に立つとは何なのかを考えなければなるまい。
  役に立つ、という日本語は、ドイツ語にするとNützlichである。
  哲学がNützlichであるか判断するには、カントの「純粋理性批判」まで遡る必要がある。
  なぜならばNützlichを判断する基準は、紛れもなく純粋理性に他ならないからである。
  (以下略)

どうでもいいですけど、人文系の学者の人って突然日本語を外国語に訳して、
この単語はその国では◯◯という風に扱われている……つまり、これは◯◯ということなのかもしれない、みたいな論法使う人多くないですか?

完全な印象論だけど、文系寄りだとまず先にメリットを説明して、理系寄りだと具体例を説明して、
腹落ちしてからメリットを説明する、という順番の方が、いいような気がする。
文系/理系で二分する考え自体あんま好きじゃないけども。

それがなかったらを話す

正面からメリットを話しても相手がなかなか腹落ちしてくれなかったら、
「それがなかったら何が困るか」で話すとわかりやすいときがあります。
数学の背理法みたいな感じですね。

・オブジェクト指向の説明はわかりましたが、メリットがイマイチ納得できません……
 ⇒じゃあ、オブジェクト指向を使わない場合を考えよう。
  手続き型の設計になるわけだけど、
  それだと似たような関数があっても、ちょっと引数や戻り値が違うだけで別の関数として書かないといけないよね?
  オブジェクト指向を使えば、オーバーロードを使うと引数・戻り値が変えられるので、
  似たような関数がソースのあちこちに散らばることは避けられるね?
  これで将来の変更に強い、保守性の高いソースコードが書ける! うれしい!

・哲学のメリットがイマイチ納得できません……
 ⇒じゃあ、哲学がなくなった世界を考えよう。
  哲学というのは、人の思考そのものだ。
  哲学がなくなるということは、人が存在しないということだ。
  つまり人間が存在する限り、哲学は存在する。
  わかるね?

一旦ここまで

今思いつくことはこんなところです。
将来なにか「これも大事だな」と思ったら追加していきます。
(了)

*1:ITエンジニアはよく「何が嬉しいか」って言いますね