説明が苦手なエンジニアのためのお手本
――『エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方』は書名から開米さんが持っていらっしゃる問題意識を強く感じますが、具体的にはどういうきっかけがあって「エンジニアを説明上手にすること」に取り組まれているのでしょうか。
開米：我々の世界を現実側と実装側に分けると、現実側には自然言語があり、実装側にはアセンブリ言語やプログラミング言語があります。実装側の言語が開発されITが発達してきましたが、次第にそれだけでは自然言語しか知らない人とはコミュニケーションできないことが明らかになってきました。そういう状況で困ったことのある方は多いのではないでしょうか。
そのため、両者を繋ぐフローチャートやUMLなどが作られてきたんですが、それらはたしかにアセンブリ言語よりは自然言語に寄っているとはいえ、まだ理解しづらい表現体系です。ですから、実際にはまだUMLと現実側を繋ぐ言語や表現体系がない状態なんです。
私が取り組んできたのがそのギャップの解消です。最初はUMLに期待していました。UMLのようなIT技術の仕様をビジュアルで表現する手法が確立すれば、実装側と現実側は齟齬なくコミュニケーションできるだろうと考えていたからです。
そこで自分でも取り組んでみましたが、UMLは完璧には遠く、やはりもっと現実側に寄った表現が必要だと思い至りました。その一つが図解で、かねて私は図解の作り方を解説する本を書いてきました。以前翔泳社から刊行した『エンジニアのための図解思考 再入門講座』もそうですね。
そして、図解だけでなく「話すこと」も含めたのが本書です。現場の方は自分の言葉でうまく説明することができなくて困っているんです。会社でプレゼン研修を受ける方もいるかもしれませんが、講師側はたいていエンジニア出身ではないので、現場の事情が加味されません。そのため、どこでも使える一般的なテクニックに終始してしまいがちです。
たとえば、スライドの文字数は減らして口頭で説明しようとよく言われます。ですが、IT技術系のプレゼンや説明ではそれは成り立ちません。どうしても細かく説明しなければならないからです。
もちろん、だからといってプログラムのコードを書いて説明すればいいわけではありません。チャート図などを駆使する必要もあります。ですが、こうしたことはなかなか学ぶ機会がなく、エンジニアでもきちんとできる方は少ないのではないでしょうか。
本書はそうした方のお手本になるように執筆しました。苦手なことに取り組むのは誰でも腰が重くなりますから、「こういうやり方ができる」という例を示すのが大切だと思っています。
「説明すること」は思っているよりも大変ではない
――実際に、エンジニアが自身が説明しなければならない場面が増えてきているのでしょうか。
開米：そう思います。私の場合、かつては人と話したくないからプログラマになったので、説明しなくていいのならしたくないと考えていました。ところが、どうしても自分がやっていることは自分が一番詳しいので「説明」を求められてきました。そこで編み出したのが図解だったんです。
私としては、本書を通じて「説明すること」は皆さんが思っているよりも大変ではないと伝えたいんです。ポイントを押さえて練習し、場数を踏めば難なくできるようになりますから。
ただ、場数だけを踏めばいいわけではありません。多くの方がそこを勘違いして実践し、嫌な思いをして諦めてしまうのですが、説明の技術をきちんと知っておかなければならないんです。そこにフィードバックを積み重ねることで、説明の技術が身についていきます。
――エンジニアは説明上手ではない方が多いようなイメージがありますが、それは事実なのですか？
開米：そうかもしれません。ただ、本来はそうではないのに説明下手だと捉えられてしまう状況も意外とあります。というのは、最低限の知識がなければそもそも理解できないにもかかわらず、それを勉強していない相手に対して説明するとき、その人が理解できないということをエンジニア側のせいにしてしまうことがあるからです。
――一方で、最近は技術者出身の方が企業やブランドのエバンジェリストになり、イベントでサービスやプロダクトを紹介したり、セミナーで講師をしたりすることも多いですよね。
開米：エバンジェリストとして多くの方が連想するのはスティーブ・ジョブズでしょうか。ですが、ジョブズがケータイショップでお年寄りにプレゼンして買ってもらえるかといえば、おそらく無理でしょう。ジョブズのプレゼンはAppleが好きな人たちに向けたもので、説明は場面に合わせて行わなければなりません。
ですから、必ずしもエバンジェリストをお手本にすればいいわけではありませんので、自分が誰に何を説明するのかを明確にしておく必要がありますね。
説明上手になるための三要素
――本書では説明をするために必要な作業をプランニング、ライティング、デリバリーの三つの要素で解説されていますが、それぞれ要点を教えていただけますか？
開米：プランニングはスタート、ゴール、ルートを考えることです。ゴールとは、自分が説明することで相手にどういう状態になってほしいかということです。理解してもらったり、行動を起こしてもらったりすることですね。ゴールを認識できていないと余計なことを話してしまい、真意が伝わりにくくなります。
ゴールに辿り着く前提として、スタートを理解する必要があります。つまり、相手の予備知識や価値観など、相手が今どんな状態なのかを把握することです。スタートとゴールがわかれば、どういうルート、論理で説明するか考えることができます。
ライティングは材料出しとコンテンツ化です。材料出しとは、気がついたことを箇条書きで手当たり次第に書き出す作業で、コンテンツ化はそれらを整理して組み立てることです。いきなり文章や図表を作る必要はないんですね。
ライティングが苦手なエンジニアは多いですから、この技術を磨いてほしいと思います。時間がなければ誰かに任せるのもいいでしょう。プランニングは説明する対象――プロダクトやコンテンツをよく知っている人でしかできませんが、ライティングはプランニングをもとに組み立てられますから、特に詳しくなくても行えるわけです。
デリバリーは口頭説明のことです。面と向かって話をすることが求められる場面は多いでしょう。プランニングとライティングを活かすも殺すもデリバリーにかかっていると言っても過言ではありません。しかし、パターンさえ知っていれば難しくありませんから、ノウハウはきちんと押さえておいてください。
この三つが揃うと、説明上手になることができます。この中で特に意識してもらいたいのがゴールの設定です。ゴールさえ見えていれば、多少下手を打ってもなんとかなりますから。
――ゴールが見えていないということは、自分が最終的に何を伝えたいのかわかっていないということですか？
開米：そうですね。たとえば、技術教育とシステム提案ではゴールがまったく異なります。技術教育は教える相手に悩ませ、疑問を抱かせ、とにかく頭を使ってもらって自分で課題を解決できるようになってもらわないといけません。
しかし、システム提案は相手にすっかり理解してもらって承認をもらうことがゴールですから、疑問の余地を残してはいけません。その差は大きいですよね。
分類してラベルをつける習慣を
――最後に、説明の必要に迫られている方、あるいは克服しなければと思っている方にアドバイスをいただけますか？
開米：本書のノウハウをすべて覚えきるのは難しいかもしれません。ですが、せめて一つだけでも実践してほしいのは、「単純ラベルと分類ラベルをつける習慣」です。
説明力向上のための基本がこの「分類してラベルをつける」ことです。説明したいことの情報量が多いとき、ラベルをつけることでわかりやすく整理することができるんです。単純ラベルは物事をストレートに表したラベル、分類ラベルはより大まかに表したラベルのことです。
分類ラベルを使うと物事を一般化して認識しやすくなり、パターンを見つけることができるようになります。1日3分、3行程度の短い文を分解してラベルをつける習慣を身につけることで、いざ説明のための文章を書くときや図解をするときに役立つでしょう。
これからもエンジニアが説明しなければならないケースは増えていくと思います。それは普段仕事をしているときにさえ発生するでしょう。IT技術は細分化する一方ですから、たとえ隣の席のエンジニア同士でも知っていることが違うという状況が当たり前になっています。そんなとき、すべて自分で調べるよりも、お互いに得意なことを教え合ったほうが効率的です。
各々が知っていることを簡潔に伝え合うことができれば、個人はもちろん、全体としてもスピード感をもって成長できる時代になっています。説明力はますます必要とされてくるのではないでしょうか。
