エンジニアも伝え方が9割らしいってよ

本記事は、PHPカンファレンス沖縄2024で行った以下発表をテキストベースでまとめなおしたものです。
https://speakerdeck.com/ykanoh/90-percent-of-what-engineers-need-is-communication-skills

発表当時は「いろいろなところで取り上げられている内容をエンジニア向けにしたものだし...」と思っていたのですが、発表してから仕事をしていると、意外とこの話を引き合いに出すタイミングが多く、せっかくだから文字に起こして繰り返し見てもらえるようにしようと思った次第です。

また、この内容をまとめるきっかけをいただいた「PHPカンファレンス沖縄2024」の皆様に感謝いたします。

---

なぜエンジニアにも"伝え方"？

「エンジニアは技術力があれば食っていける」というのは間違いです。
ひょっとすると、とんでもなく技術力が高く、他全てを犠牲にしても価値があるエンジニアもいるかもしれませんが、少なくとも一般の人はモデルケースにすべきではないでしょう。

なぜなら、現在のエンジニアはチームで動くからです。

人から人への伝達はボトルネックになる

実は、人から人へものを伝えるということは、想像以上にボトルネックになります。
なぜなら、伝えるにあたって、情報を人と人の情報伝達プロトコルである「言語」に変換する必要があるからです。

もし、人に伝える必要がない場合は、言語化が不要なのでボトルネックにはなりません。
「事象はこんな感じだな」「バグの原因はこのへんか」「（言葉にはしづらいが）こうすれば直る」「あの辺に影響がありそうだな...」など、自分の中で理解できていれば十分仕事を進めることができるからです。（もちろん、言語化できていた方が理解度が上がり進みが早い、ということもあります）

わかりにくければ、システム間でのAPI連携と置き換えて考えてみましょう。

システムAとBがあり、システムAからBへAPIでデータを連携しているとします。
APIのフォーマットが決められたJSONフォーマットであり、内容もわかりやすくまとまっていた場合、システムBはあまりコストをかけず、送られてきたデータを処理することができるでしょう。

しかし、もし、システムAから送られてくるデータが、フォーマットもめちゃくちゃなCSVデータだったらどうでしょうか...


システムBは、このデータをパースするために、とてもややこしいロジックを用意しなければいけなくなり、コストがかかります。

これが、人と人のコミュニケーションでも言えるのです。

AさんからBさんへのバグ報告内容が以下のような文章だとします。

バグ報告書
SelectItemsクラス内の、180行目にあるループにて、変数selectedが最初のループ処理時にアイテムの情報が代入された後、次のループ処理にてアイテムの種別が「道具」だった場合、上書きされずに前ループの値が残ってしまうため、次かその次のループにてアイテムの種別が「道具」でなくなった時に、上書きされなかった値がそのまま利用されてしまうため、操作方法によっては選んでいないはずのアイテムが使用されてしまいます。

上記文章は、あまりわかりやすくまとまっているとは言えませんので、Aさんは脳内で行う情報のパースにコストがかかってしまいます。
情報を報告されるメンバが、Aさんだけならマシかもしれません。
この報告がチーム内のメンバに共有されると、伝えられたメンバは全員脳内でわかりづらい文章をパースして理解しようとするので、メンバの数だけコストがかかってしまいます。

このトークの目的

つまり、人と人が情報をやり取りする場合、言語に変換する必要がある以上、情報の "伝わりやすさ" が非常に重要なのです。
そのため、仕事のボトルネックを改善するために、"伝わる伝え方"の考え方を解説することが、この発表の（ひいてはこの記事の）目的です。

ここでは、以下の3つに分けて"伝わる伝え方"を解説します。

• 説明の大原則
• 知識のベースライン
• 伝えることをサボる

説明の大原則

説明の大原則は、ズバリ、抽象 から 具体 へ説明すること です。

抽象→具体

抽象から話し始める理由は、「相手に話の全体像を理解してもらうため」です。
抽象的な「全体の説明」を行い、結末を知った上で、話の流れを大体予想してもらいながら説明することで、相手の理解度を上げることができます。

わかりやすく言うと、伝える相手に "ハラハラドキドキ" をさせてはいけません。
「ああ、この話はだいたいこういうストーリーで、この辺りに落ち着くんだなー」と思わせながら説明を聞いてもらうことで、多少伝わらない内容があっても、相手に脳内で補完してもらうことができるのです。

抽象的な「全体の説明」ができたら、次は具体的な「詳細の説明」を行うことで、伝える内容の補強を行います。

場合によっては、最終的な結論と逆の情報を含めなければならない場合もあるでしょう。
しかし、そのような場合でも、最初に話の全体像を伝えてあるため、聞き手は「ああ、この話はどこかでひっくり返るんだな」と思いながら聞くことができ、"ハラハラドキドキ" せずに済みます。

具体から話してしまった場合の例

ではもし、「具体」である「詳細の説明」から話してしまうとどうなるでしょうか？

先ほど例に挙げたように、最終的な結論と逆の情報が含まれる場合、聞き手は結論が見えないまま左右に揺れる話から目を離さず集中して聞く必要があります。
結果、伝える人の一字一句に注意して聞いてしまい、なにが重要なのかわからないまま最後まで聞いてしまう可能性があります。

少しわかりにくいかもしれませんので、以下のような例で考えてみましょう。
部下が上司から頼まれたライブラリの調査結果を、上司に報告する必要があるとします。


おそらく報告者は時系列に従って報告してしまったのでしょう。この例の場合、細かい事情から話してしまったので、聞き手である上司は話がどこに着地するかわからずよくわからなくなってしまいました。

細かい事情から話すと、上記例のように着地点がよくわからなくなってしまいます。
何度も言うようですが、「話の全体像」を先に提示することで、このような問題を避けることができます。
具体的な「細かい事情」は、その全体像を補強するために使います。

なお、発表では触れませんでしたが、このとき補強に使う情報にも気を使うべきです。
上記図に補強に使われていない「具体」があるように、必要に応じて取捨選択が必要です。

「結論から話せ」ってほんとう？

この話をすると、多くの人は新社会人のころに「結論から話せ」と言われたことを思い出すのではないでしょうか？

「結論から話せ」という教えについて、私はある種の「話の全体を掴んでもらう話し方をするためのフレームワーク」だと考えています。
話の「抽象」と「具体」を理解するためには、ある程度の経験が必要です。そのため、まだ話の構造を考えきれない若手に伝える場合は、簡易的に「結局どうなったのか」を先に話すよう伝えることで、ある程度の話しやすさを保つことができるのです。

もちろん、これで十分伝えられる場合もあるのですが、可能であれば話の「抽象」と「具体」の構造を理解し、結論ではなく全体の概要を伝えられるようにすることがベストだと私は思います。

抽象から話した場合の例

うまく話の全体像から伝えられた場合、以下のように先ほどの例もすっきり伝えることができます。

この例では、最初の回答で「利用できる」という結論だけでなく、「いくつか問題はありますが」と付け加えています。これによりなにか考えるべきことはあるが、とりあえず利用できそうだという話の全体像を聞き手に理解してもらうことができます。

また、二回目の回答の冒頭で「2点あります」と伝えているのも、「抽象→具体」の伝え方です。
最初に全体で2つ伝えることがあるということを伝えて、全体像を理解してもらってから具体的な問題を列挙しています。

伝わりやすさと心理的安全性

ここで少し発表時にはお話ししなかった内容に触れます。
伝わりやすい説明と心理的安全性の関係です。

先ほど説明した「抽象から具体への説明」をする場合、抽象では全てを伝えないことになってしまいます。
場合によっては、最初の抽象を伝え終わった段階では、多少ニュアンスに齟齬がある状態になってしまうでしょう。
これは説明の構造上仕方がないことで、このあとの詳細説明で具体的な情報により齟齬が解消されるのですが、説明する相手との間に心理的安全性がない場合、報告者が齟齬のある状態を苦痛に感じてしまう場合があるのです。

たとえば、常日頃から間違った情報を伝えると激しく問い詰める上司がいたとします。
この上司に報告する場合、できるだけ正確な情報を伝えなければなりません。
しかし、前述の通り、この説明方法では最初の抽象を伝え終わった段階では、多少ニュアンスに齟齬がある状態になってしまう可能性があります。
よって、報告者は具体的な説明をする段階で「最初の話と内容が違うじゃないか」と言われてしまわないか心配になってしまうのです。
その結果、抽象的な報告を避け、具体的に細かく説明をしてしまい、なお一層話が伝わりづらくなって上司からの心象も悪くなってしまうと、いよいよ抜け出せない状態になってしまいます。

このような状態を避けるためにも、報告を聞くときには傾聴スキルが求められるのだと私は思います。

：
：
：

（...あ! これ、一応所属企業のアドベントカレンダーなので補足しておきますけど、当社にそんな人はいないっすよ！？！？）

知識のベースライン

次の伝わる伝え方のポイントは、「知識のベースラインを揃えること」です。

ベースラインを揃える理由

なぜベースラインを揃える必要があるのでしょう。それは、「説明してもどうせすべては伝わらないから」です。

読者の中には「いや、それは説明が下手なだけだろう！」と思った方もいるかと思います。
しかし、ここでの「すべては伝わらない」とは、説明の過不足ではなく、「事象を言語化することによる情報落ち」のことです。
人はなにかを伝える時、言語化しないと他人に伝えることができません。
言語はその事象そのものではないため、どうしても情報落ちが発生してしまいます。

言語化による情報落ちの例

たとえば、下記図のように、AさんがBさんに何かを伝えるとします。

Aさんは伝えたい事象を "日本語" にしてから、Bさんに伝えます。
しかし、この "日本語" は「事象そのもの」ではありません。そのため、日本語にした時点で「情報落ち」が発生しています。
（「事象から日本語への変換は非可逆である」とも言えるでしょう。）

もしピンときていない方がいる場合、伝えたいことを「日本語」ではなく「英語」に置き換えるとわかりやすいかもしれません。
この場合、（英語が得意な人でなければ）伝えたいことを英語に変換した場合、非可逆どころか伝えたいことをちゃんと表現できているかすら怪しいでしょう。

では、どうすればより正確に事象を相手に伝えることができるでしょうか？
ここで「知識のベースラインを揃える」ことが重要になります。つまり 同じ認識を持ってもらうことで、相手に内容を悟ってもらうのです。

認識を一致させることで、ある程度の説明ができていれば、その事象に対して同じ感想を持ってもらうことができるでしょう。そして言語化による情報落ちを類推して補完してもらうことができます。

ベースラインを揃える手段はいくつかあります。

「背景」も「目的」も、伝えてから説明をしないと、相手が自分と同じ考えに至るかはわかりません。

伝えることをサボる

最後の伝わる伝え方のポイントは、「伝えることをサボる」です。

他人になにかを伝える手段は、なにも言語による説明だけではありません。

どの手段が伝わりやすいかは、伝えたいものによります。

文章より図説の方が早い場合もある

たとえば、先ほど説明に使ったこの図を文章で伝えてみるとします。

こんな感じでしょうか？

これを読んでいる皆さんは、先に図を見ているのでわかりやすいかもしれませんが、図が存在せず、この文章だけだとどうでしょうか？
おそらく、先に図を見てからこの文章を読んだ方が伝わりやすいでしょう。

伝えたいことをドキュメントにする

伝え方の工夫は、なにも理解しやすさだけではありません。
伝えることをボトルネックにしないために、「伝えるための労力を少なくする」ことも重要です。

その一つが「伝えたいことをドキュメントにする」です。

たとえ3人、10人に伝える必要があるとしても、1回ドキュメント化してしてしまえば、伝えるための労力は1回のドキュメント化にかかる時間で済みます。

また、ドキュメント化は伝えることをサボる以外にも以下のようなメリットがあります。

ドキュメント化のメリット

1. 後から増えた関係者にも見せることができる
2. 時間が経っても見返すことができる

たとえば、何か仕様を決めたとして、ドキュメントに残っていなかった場合、事情を知らない他の人が後から別の仕様を提案してしまう可能性があります。また、口頭のみでの合意ではどのような合意が行われたかを後から見直すことができないのに対し、ドキュメントに起こしていれば後から確認することができます。

この話をすると、よく「細かいことであればドキュメント化するより手を動かした方が早いのでは？」と言われてしまいます。しかし、ドキュメントを作らず手を動かすことで得られるスピードと、あとから議論が行ったり来たりして結局時間がかかるリスクを考えてください。私は決まったことはできるだけドキュメントに残すべきだと考えます。

コツとしては、考えを整理するのと同時にアウトプットをすることです。
提案を組み立てる時の作業履歴をそのままドキュメントにする、Slack の投稿のみでなく、内容をちゃんとドキュメントとして残す、などです。

ドキュメントはわかりやすく

しかし、いくらドキュメントに起こしても、内容がわかりづらければ意味がありません。

この対策として、誰でもわかりやすいドキュメントが起こせるよう、ドキュメントの用途によってテンプレートを用意するといいでしょう。

いい例として、PHP の RFC があります。
PHP の開発コミュニティでは、ユーザから言語使用の提案を RFC として募集しています。
このときの提案にはテンプレートが用意されており、ユーザはテンプレートにしたがって自分の提案を記載するようになっています。
https://wiki.php.net/rfc/template

内容を読んでいただくとわかるかと思いますが、このテンプレートも、前書きで「抽象情報」を記載し、その後で「具体情報」である詳細の説明が行われる構造になっています。

そのため、提案者はフォーマットに従って記載することでわかりやすい提案をつくることができ、読み手はフォーマットを意識して楽に読むことができます。
（PHPのRFCについては、以前別イベントで発表したときの資料がありますので、ご覧ください。）

まとめ

エンジニアがチームで仕事を進める上で、ボトルネックとなる「情報の伝達」について、3つのポイントを説明しました。

• 説明の大原則
  • 内容は抽象から具体へ説明する
• 知識のベースライン
  • 相手に自分と同じ前提情報を与えて内容を類推してもらう
• 伝えることをサボる
  • 図やドキュメントを駆使して伝える

とはいえ、上記で挙げたポイントは、あくまで伝え方のコツです。
実際に重要なことは、本当に相手に事象が伝わるかどうかです。
伝わるかどうかを確認するためには、一度伝えられる人の立場に立って考えてみてください。
説明しようとしている内容を自分が報告されたら理解できるか、図や表は不要か、事前情報は足りているかなど、気づくところがあるかと思います。

結局のところ、試されるのは相手の立場に立って考える力である『共感力』なのかもしれません。