池上彰 相手に「伝わる」話し方

チーム内での情報の共有はとても大切。

自分の経験的に、いいエンジニアのチームや組織を作りたいとか維持したい場合に一番重要なことって、いけてる言語とか、豪華な福利厚生とか、トップがコード書ける書けないとかでは全然なくて、情報共有と透明性をどこまで徹底できるかだと思う。病的なくらいでもいいと思う

— Naoya Ito (@naoya_ito) 2013, 11月 20

情報共有のメリットは読んだ本に関係ないので端折るけど、共有の仕方・ものの伝え方には技術があって、情報を共有するぞ〜という意識だけではうまくいかないことがある。例えば、サーバーでの作業履歴を残したくて、GitHub issuesに数十行のコマンド履歴をずらずらと書いたとする。この履歴を読めば解決できる問題が発生した時、問題に関する情報を探している人が、履歴を見ても何の作業なのか分からないので、それを読むだけのコストを払えるか判断できず、最悪読み飛ばしてしまう。何をする目的で作業をしたときのメモなのか、履歴に一言書いておけば、事態は少しは軽減されたのかもしれない。この一言を書くかどうかの判断が伝え方の技術になる。

僕は口頭での説明が下手だと思っているから、こういう本を読む。下手な理由を考えると、理由のひとつに「説明するときに専門用語を使わない」というものがある。「このフォームはXSSが可能ですね」ということを伝えるのに「このフォームに入力された内容はエスケープしないで表示しているので、JSタグを実行したりすることが可能ですね」というようなまどろっこしい説明をすることが多い。XSSを知らない相手なら後者で良いけど、XSSを知ってる相手にこれだと、円滑に会話できない。最近、もっと用語を使って喋ってもいいよと言われて気がついた。

自分の場合、概念だけ覚えていて、名前を思い出せないということが多々あるので、そもそも用語を記憶していないのではないかと思っているけど、これはまた別の話だ。

池上彰のこの本の中でも、何かを伝えたい相手が会話に参加してくれるために、固有名詞を使うのは同じステージ・目線で話すための方法の一つだと書いてある。

会話は、相手が参加してくれてこそ成立します。だったら、相手を話題に引きこむ材料が必要です。それが、具体例なのです。あるいは、お互いがよく知っている固有名詞なのです。

この本は、話し方ってどうすればいいのという内容よりも、池上彰がニュースキャスターを始めた時の苦労とかのエピソードが面白かった。具体的な内容をもって話し方の説明をするということを実践できている証でもあるのかも。

相手に「伝わる」話し方　ぼくはこんなことを考えながら話してきた (講談社現代新書)