エンジニア日記

プロダクト開発をしてるアラサーエンジニア

一番伝わる説明の順番 を読みました。

プロダクト開発チームで開発をしているアラサーエンジニアです。

弊社は人が少ないこともあり、基本設計・詳細開発・リリースまで担当させてもらっています。
その中で「今回の課題を解決するために、このような機能が必要になります」という基本設計フェーズでの打ち合わせを数回行うのですが、「うまく説明できてないなぁ。」「そもそも自分の思考をコントロールできてないな」という思いがずっとあり、その時手に取ったのがこの本でした。

どんな本か

だれかに何かについての説明をするとき、相手から「何を言いたいの?」や「結局何をすればいいの?」というはてなマークが返ってきたことがある人もいるかと思います。
では分かりやすい説明とはなんなのか?どのような順序で、どのような構成で説明すれば相手にすんなり理解してもらえるのかについて書かれています。

今回はこの本の解釈を、私なりの目線も含めて書いていきます。

なぜ説明が下手なのか

「下手」と言うと少しグサっとくるかもしれませんので、「苦手」というオブラートで包んでおきます。
説明が苦手な人は以下3点の過ちを犯しています。

  1. 話そうとする事柄を時系列でそのまま話してしまう
  2. 相手に合わせた説明ができていない
  3. そもそも自分の中で整理ができていない

頭の中で考えたことをそのまま説明するのではなく、一旦「整理」するフェーズが必要になります。
時系列をそのまま話すとは、思い付きで話すと同義であり不要な情報が多く含まれがちです。
また、自分の頭の中で整理できていないのであれば、そもそも説明しようがありません。

「整理する」とは、具体的にどのように実行すべきかについてもこの本に書かれています。
それが書き出すということです。
書き出す行為は自分の頭の中にある情報。つまりは主観を客観することができるのです。

  • 今回説明することについて、聞き手に必要な事前情報はあるか
  • 重複した情報がないか
  • まとめられる情報はないか
  • どのような順序で説明する必要があるか
  • 不足した情報はないか(これについては事前に知識を集めるフェーズが必要になるかもしれません)

これらの結びつきをノートで紐づけしながら、説明順序を構成する必要があります。

「説明する」という行為の究極的な目的は「相手に何かをしてもらうこと」です。
例えばそれが、許可をもらいたいのか、意見が欲しいのか、どうすれば解決できるかの助言をもらいたいのか、はたまた単純に情報の共有なのか。
最終的に相手にどのようなアクションを取ってもらいたいのか。という大前提をブレずに持つことが分かりやすい説明の入り口なんだと思います。

分かりやすい説明とは

では、分かりやすい説明とはどのような説明なのかについてです。
本書では以下の5つの順に説明することが分かりやすい説明であると述べられています。

  1. 前提を揃える
  2. 結論・主張・本質を述べる
  3. 根拠・理由・事実を述べる
  4. 補足情報があれば付け加える
  5. 結論を述べる

前提とは、今説明する事柄の範囲(スコープ)について共有します。
これは他の書籍でも良くあるメンタルモデルを共有するということです。
最近読んだ「世界一流エンジニアの思考法」の本でも「一流エンジニアは複雑な事象理解するためにメンタルモデルを持っている」という言葉があります。
メンタルモデルは、話す事柄についての地図のような働きをします。
このメンタルモデルが話し手と聞き手で合致したイメージを持つことが「前提を揃える」ことなんだと思います。

そして「結論・主張・本質」を述べた後、それについての「根拠・理由・事実」を述べます。 補足情報があれば補足し、最後に再度結論を述べます。 1~4までの説明で時間が経過していることもあり、聞き手が「あれ、最終的に何をすればいいんだっけ」となりかけた時に、再度道しるべを示すような締めくくりをします。

最後に

この本や、途中紹介した「世界一流エンジニアの思考法」、そのほかの本にも同じく書かれていることに、 「しっかり物事を理解することが大切」という言葉が何度も現れてきます。
自分自身で理解できないものは説明しようがありません。
理解する。ということはそれ相応の時間が必要になりますが、理解せず付け焼刃の知識だけをやりくりし「あれって何なんだっけ」ということがあれば都度都度検索して、その時だけ分かった。という状態は、中長期的に見て生産性が低いです。
しっかりと理解し次のステップに進む。その時に時間はかかりますが、それは確実な一歩なんだと思います。