「説明のための知識」を持つことで説明能力は上がる──アイデアクラフト代表 開米瑞浩氏

「顧客へシステムの説明をするのが苦手」

「エンジニアは人とコミュニケーションをとることが少ない職業だと思っていた」

エンジニアとして働いている方のなかには、このような想いを抱いている人も多いのではないでしょうか?

今回、話を伺った開米瑞浩さんは、『エンジニアを説明上手にする本』など図解と説明の技術に関する本を出しています。しかし開米さん自身は、子どもの頃から人と喋ることが苦手だったそうです。

そんな開米さんに、エンジニアが説明することに苦手意識を持ってしまうのはどうしてなのか? 説明上手になることのメリットは何か? をお聞きしました。

エンジニアなら人とあまり喋らなくていいと思っていた

image1

――プログラミングをはじめたきっかけはなんだったのでしょうか?

大学時代に、寮の同室の友人がパソコンを持っていたんです。そのパソコンを触ってみたらおもしろくて。最初はゲームをやっていて、その流れでプログラミングもやるようになりました。自分が書いた通りにプログラムが動くのが楽しかったです。

当時は大学の授業に出る気にもなれなくて、だらだらしていました。大学に行かないなら仕事をした方がいいと思い、中退してITエンジニアとして働きはじめたんです。

――どうしてエンジニアという仕事を選んだのでしょうか?

人と喋るのが苦手だったので、エンジニアなら人とあまり喋らなくていいと思って選びました。働いてみたら、喋らなきゃいけない機会は多かったんですけどね(笑)。システムを作りたいお客様への説明や会社説明会での技術部門の紹介とか。

喋るのが苦手なので、書くことでどうにかしようと考えたんです。ただ技術情報って文章で書いたところで、相手が知識を持っていないと通じないことが多い。だったら図解にしてみようと思って、やってみたらうまく通じました。

そこで、うまく伝えられない人にやり方を教えてあげることが仕事になるんじゃないかと思いはじめたんです。

その頃、仕事をしていた会社に出版社と繋がっている人がいて、考えていたことをまとめた書籍の企画を持っていきました。すると雑誌での連載が決まり、現在やっている図解と説明の技術を伝える研修をする仕事へと繋がっていきました。

――そこから『エンジニアを説明上手にする本』を出版するまでに至るわけですね。この本はどういった問題意識から書かれたのでしょうか?

近年、「わかりやすく説明する」ことが記述されている本は多く出版されています。しかしエンジニアの日常業務のシーンにあったものはあんまりない。そこに向けた本があってもいいのではないか? という意識から出発しました。

説明がうまくできないのはエンジニアだけの問題ではない

――そもそもエンジニアにはどんな説明能力が求められているのでしょうか?

「わかってもらう説明」と「わかったつもりにさせる説明」を状況に応じて使いわける能力ですかね。エンジニアが説明を求められるときって5パターンあるんです。

image1

▲ロジカルコミュニケーションの5類型の図。ヒアリング、レポーティング、プレゼンテーション、ティーチング、インストラクションの5種類に分類されている。

この図でいうとプレゼンテーションの部分では「わかったつもりにさせる説明」、ティーチングやインストラクションの部分では「わかってもらう説明」が必要です。

IT技術の知識がない顧客(意思決定者)に、現場担当者がシステムの説明をするとき、すべてを理解してもらうことは難しいですよね。そういうときは、これからする話を顧客にどこまで理解してもらう必要があるのかを、自身が理解して説明しなければいけない。どうしてそのシステムが必要で、導入することで顧客にどんな効果が得られるのか、どれくらいの費用がかかるのかなどを伝え、顧客が判断できる材料を渡さなければいけない。これが「わかったつもりにさせる説明」と言えます。

しかし、エンジニアとして実際にシステムを作る場合は、「わかったつもりにさせる説明」は避けたほうがいい。たとえば、エンジンの設計図があった時に、「あ、この部分、ごちゃごちゃしてわかりづらいから消しちゃおう」としてしまったら、大変なことになりますよね(笑)。

不具合なくエンジンが動くように、複雑な情報であっても、正確に伝えなければいけない。これが「わかってもらう説明」です。

説明が苦手だと感じる人は、「わかってもらう説明」と「わかったつもりにさせる説明」を混同しているのかもしれません。そのせいで顧客に話が通じず、苦手意識を持ち、極力避けるようになり、説明するための技術を知ることもなく悪循環にはまっている。

でも説明がうまくできないことってエンジニアだけの問題だけではないと思うんです。たとえば、顧客側が自分のしていることを抽象化し定式化して言葉で伝える習慣・能力を持っていないことがあります。

その場合はエンジニアが誰であってもITとの適切なおつきあいができません。これはエンジニアの説明能力の問題ではないのですが、ここも含めて「エンジニアの説明が下手」とされてしまっているケースは多いです。

そういった場合、エンジニアの説明の大事な部分がどこか理解できず、認識のズレが発生してしまう。そのズレをエンジニアの説明が下手ということにしてしまうのはおかしい。

image1

日本人と外国人の違いをあげるときに「ハイコンテクスト」か「ローコンテクスト」という考え方があるんですね。日本はお互い同じ意識、常識を持っているという前提で、相手と接する。言いたいことをはっきり言わないし、察し合う文化と呼ばれている。一方海外では、たとえばアメリカでは、それぞれ常識や文化が違うことが当たり前だから、1から10まで全部言葉にして伝える。

察し合う文化に慣れてしまうと、伝えたいことを言語化することに慣れておらず、仕事の抱えている問題を伝えられない。すると仕事の改善がスムーズにできない。今挙げた点を顧客側も、エンジニア側もお互いに自覚して、一緒に仕事をしていく姿勢を持つことが大事です。

説明上手な人は顧客や同僚に信用される

image1

――エンジニアが説明上手になることのメリットってなんなのでしょうか?

いくつかあります。

まずは、仕事をする上での誤解が少なくなる。顧客とのやりとりや、同僚同士で情報をスムーズに渡すことができるので、お互いの認識のズレが少なくなります。そうすることで仕事の生産性が上がります。

次に、勉強の効率が上がります。説明が上手になることで、わからないことをはっきりさせることができる。はっきりしていることで何を学べばいいか、何を聞けばいいかがわかる。

何を聞きたいかをピンポイントで聞けるようになると、聞かれた側も応答しやすいですし、結果的にそういう人は成長速度も早い。

最後に、顧客や同僚に信用してもらえるようになります。理路整然と的確に話してもらえると、仕事を任せてもいいって安心感を持ってもらいやすい。

説明が苦手なのは、「説明に必要なノウハウ」を知らないだけ

――説明上手になるためにはどうすればいいのでしょうか?

どんな仕事でも言えることだと思うのですが、上達するためには知識と実践と修正(他人からのフィードバックをもらうこと)が必要です。知識を持っておくことで、やらずに済む失敗を避けられるようになり、実践と修正を繰り返すことで上達することができます。

説明上手になるための知識として一番知っておいてほしいのは、ラベルをつける習慣が重要ということです。

ラベルづけを習慣にしておくことで、説明したいことの情報量が多かったり、わかりづらかったりする場合にスムーズに整理することができます。トレーニング方法としては「3行ラベリング」がおすすめです。

image1

▲3行程度の文章を、ラベルづけして組み替えるトレーニング。様々な文章でトレーニングすることで、類似したラベルを発見でき、説明しやすいパターンを発見することができる。Wordで打った際に3行程度になる短い文章を使用すると言う意味で「3行」ラベリングと名付けられている。(画像引用元「開米の図解思考ライブラリー3行ラベリングの勧めより 」)

あとは、目標、問題、方法を切り分ける習慣を持つことは効果的です。目指すものが目標、それが実現できない理由が問題、それを具体的にどうするかが方法。これらを混同して話す人って多い。なので顧客の話していることや、チームで話していることが、目標なのか、問題なのか、方法なのか切り分けて考えることは大事です。

切り分けの時のポイントとしては「課題」という言葉を使う人の話を注意深く聞いてみるのもいいかもしれません。

image1

上記は全部「課題」と言う言葉が使われていますよね。使われ方に違和感はないのですが、言っていることは全部違うんです。(1)は目標、(2)は問題、(3)は方法です。

いろんな解釈ができる「課題」という言葉が出てきたときは、どんな意味か確認することが大事ですし、自分が説明で使うことは避けるほうがいいです。

ここまでお話したことは全部知識なんです。こうやって知識を持つことで、説明能力はどんどん上がります。

――最後にお伺いしたいのですが、エンジニアって必ず説明上手にならなければいけないんでしょうか?

必ずしもそうではないですね。

エンジニアにもいろんな役割があるし、人それぞれタイプがある。仕事はチームでやるものなので、Aさん、Bさん、Cさんが同じ能力である必要はない。コミュニケーションが苦手な人がいても、ほかの人がカバーできたらそれでいい。

資料を作るのが得意だったら誰がやって、話すのが得意なら誰がやってと、チームでうまく仕事を割り振れるマネージャーがいることで、スムーズにやっていくこともできる。対外的にチームが機能していればいいですから。

でもプログラミングに必要な知識の量と比較したときに、説明するための知識ってそこまで多くないんです。本気で学べば、ほんの数日で上達します。多くの人は知らないからできないだけです。最低限知っておいたほうがお得ですよ。

協力:アイデアクラフト

この記事が気に入ったらいいね!しよう

いいね!するとi:Engineerの最新情報をお届けします

プライバシーマーク