これはなに

• 難しいこと説明するときに話が通じないのをどうにかするドキュメント

  • 思い出してください、色々喋ったあとに相手の顔に現れる「こいつなに言ってんのか分からんな」の表情を…

発端: 「難しいことを説明する」とは？

• 発端

  • エンジニアはややこしい概念を扱うことがある

    • TBL_AとひもづくTBL_Bの状態がXのとき、Yを起点に処理_1するが、その際X_1の値を参照してX_2を更新しないと処理_2をやったときに不整合が…
  • 難しくする必要があるものもあれば、ないものもある

    • 必要で難しいものが難しいのは、しょうがない
  • が、諦めなくてもよい

    • やれることはある、そしてそれ知らんよね
    • 具体的には心理学の文脈でいわれる認知的負荷が具体的にはどのように発生し、それを減らすためにどんなことができるのか？　を説明します
• 以下の流れで考える

  • 前提：会話の構成図
  • 本題：ややこい説明したい場合
  • 補足：その他会話
  • 参考文献

まとめ

説明のきほん

• 難しい説明の仕方に入る前に、基本的な説明のやりかたなどを説明
• 説明ってどんな構造か？

  • 「説明する」の登場人物は、わたし、会話そのもの（発話行為）、相手

    • なお厳密な構造というより、どんな観点で考えられそうか？　という話
• 説明するとき、それぞれでどんなことが起きているべきか？

  • わたし

    • 説明したいことがまとまっている
  • 発話行為

    • 分かりやすい順番で説明される
  • あいて

    • 説明を受けて脳が頑張る※1
• それぞれ見ていく

「説明」とわたし

• 説明したいことが決まってないと、説明できない

  • 考えをまとめる、とは？
  • ひたすら考えて、まとめる
• ひたすら考える、とは

  • アウトプットしないと思考はできない（脳にそんなメモリはないから）

    • 思ったこと全部書く
    • カメラを回して喋る
    • 誰かに壁打ち相手になってもらう
• まとめる、とは

  • ロジカルなストーリーを作る

    • ピラミッドストラクチャー
    • 結論、根拠3つ、それぞれの具体例という構造で作るとよい

「説明」と発話行為

• いかに分かりやすく伝えるか

  • ピラミッドストラクチャーを伝えるだけではきつい
• やれることいくつか

  • メモ

    • ここ認知負荷のところで伝えたいことを事前に書く、伏線
  • 前提を揃えよう
  • 説明の順番を伝えよう
  • 視覚に訴えよう

「説明」とあいて

• 相手の理解度に合わせた説明

  • 言葉

    • 専門用語を使わない、相手が普段使う言葉で喋る
    • 例）マスタのリストを更新したい→選択リストに出てくるあたいを変えたい
  • 比喩

    • 複雑な話を例え話で理解してもらう
    • 例）？？？
  • 理解度の確認

    • 相手がどれくらいの知識を持っているのかを確認する
• 相手に考えてもらう

  • 一方的に話を聞くだけで理解できる人はあんまりいない
  • どうやって考えてもらうか？

    • 質問する
    • 「考えてみてください」と言っちゃう
• 受け入れられやすい表現

  • エゴグラムをもとに、どんな言葉が響くのか考える

    • 自由にやってみてほしい、こういうのが参考になります、前提から考えると〜など

難しいことを説明をする

• 難しいことを説明する際に気をつけること

  • するな

    • そもそも難しいことを説明するな
  • どうしてもしたいなら…

    • 軽減する
• 難しい説明を聞いているとき、わたしたちの頭の中で何が起きているか？

  • 何かを理解しようとするとき、みっつの記憶を使っている

    • 長期記憶
    • 短期記憶
    • ワーキングメモリ
  • 例）システムAのレポートでシステムB連携対象の求人推薦一覧をだしたい。連携対象になるかの条件は、エンジニアがシステムBを使っていること、求人推薦が連携対象の営業情報に紐づくこと、そして営業情報のステータスが特定のものであること。

    • そもそも「システムAのレポート」「システムB」を知っているか？
    • 連携対象の条件
    • 連携対象の条件を組み立てる
• どううまく行かなくなるか？

  • 長期記憶にない

    • 「システムAのレポート？　システムB？」となりついていけない
  • 短期記憶に乗り切らない

    • 「営業情報のステータスがなにかで、求人推薦がその営業情報に紐づいてて……あとなんだっけ？」となって忘れる
  • ワーキングメモリで処理できない

    • 「えーこのデータで対象のデータを見ると、エンジニア契約形態と営業情報が紐づいてて、その営業情報に求人推薦が紐づいてて、営業情報のステータスはこの値じゃなくちゃだめで、あとシステムBの利用状況がこの値で……（メモしたい…）」となり処理が手に余る
  • つまり

    • 長期記憶にないような覚えておきたい内容（この変数がこれで、、とか）が短期記憶に乗り切らなくなったり、ワーキングメモリで思考しきれなくなると、話についていけなくなる
• どう対策するか？

  • 対策一覧

    • 長期記憶に載せてしまう
    • 短期記憶で覚えられる量を増やす、覚えなくてもよくする
    • ワーキングメモリの代わりになる外部メモリを使う
  • 具体例

    • 前提を揃えよう
    • 説明の順番を伝える
    • 視覚に訴えよう

具体的にできること

• 説明の前にできること

  • アジェンダ、スライド、触って理解できるデータを作る

    • 短期記憶、ワーキングメモリの負担を減らす
  • 事前に考えてきてもらう

    • 基本的な知識を長期記憶に移してもらい、当日の短期記憶に余裕を持たせる
    • 事前に考えればその場で使うワーキングメモリの負荷も減る
• 説明中

  • 話す順番や構造を伝える

    • 相手の短期記憶の負担を減らす
    • 構造が伝わることで、話の流れの調整にワーキングメモリのリソースを割かなくて良くなる。
  • 論点のマッピング

    • 考えないといけない点がどれほどあり、いま何について喋っているのか整理する
  • 前提を揃える、理解度を確認する

    • 長期記憶にない単語を把握する
  • 簡単な言葉で置き換える

    • 難しい言葉で短期記憶やワーキングメモリに負荷をかけず、相手の理解できる言葉で伝える
• 説明後

  • 議事録を共有する

    • 明文化することで長期記憶に収めてもらう
    • 振り返りできる
  • フォローする

    • 別途口頭でフォロー

補遺

• 補遺

  • ここからは参考文献のなかで面白かったところだけピックアップ

対話

• 双方向のコミュニケーション

  • お互いのピラミッドストラクチャーを擦り合わせて、一緒に結論を考える
  • 前提として、自分と相手の意見がまとまってないといけない

    • 適宜相手の構造を整理してあげる
• 自分の構造の整理

  • 自分の意見の強度を高めれば相手から出てくる意見の強度も上がる

    • 議論の質が上がる
• 相手の構造の整理

  • 結論を聞き、その根拠と実例を深掘りする
  • ピラミッドストラクチャーの構造に当てはめ、整理して合意を取る
• すり合わせ

  • 意見が合致するならそれでOK
  • 対立するときは前提や立場に違いがあることが多い

ファシリテーション

• 議題についての全体図を示す
• 論点のマッピング的なもの

  • 多人数で議論すると、思いもよらぬことを言われてハテ？？？　となりがち
  • あらかじめ論点のマッピングをして全体の地図を作っておくことで、そこに当てはめながら整理できる

    • ワーキングメモリの負荷も減るし、ちゃんと言ったのに理解してもらえなかった、、とかも減る
    • 間違ってたら指摘してもらえるし、良い

ビジネスコミュニケーション

• なぜ結論が大切か？

  • ビジネスコミュニケーションの目的は物事を前に進めること

    • 情報を交換し、決めて、行動するために行う
    • なにをどう決めたいか、どう行動したいか？　まで明らかにならないとNAがワンテンポ遅れる
  • さっさと進めるためには結論を出す、できることは全てやる

補足

• ※1

  • 説明の構造としてあげている「発話行為」と「あいて」はわざわざ分ける必要あるか？　とも思う。いまのところは「発話行為」は人間一般にはこのやり方が伝わりやすい点、「あいて」は個人の特性にフォーカスを当てて考える点としてまとめている。

参考文献、読書ログ