この形式で書評を書く場合は、過去記事は末尾においたほうがいいことに気づいたので、今回から過去記事は末尾にあります。
第４章コミュニケーションの極意‐伝え方・聞き方・ディスカッション
「情報量を減らす」大切さ
扱い切れない量の情報を出しても仕方がない。 ただし、どのくらいの情報が扱いきれないのかの見極めは難しそう。
見極めに労力をつぎ込むくらいなら、基本的に最小限に統一したほうがいいんだろうか。 チャットベースでは一度で色々情報を注ぎ込んでしまうタイプではある。 何度もやり取りするのが手間に感じてしまう。
とりあえず実践してみて感触をつかもうと思う。
準備の力
日本のカルチャーが有利に働く事例が紹介されているのは、ホッとする要素ではあると思う。 準備をした上で、情報を最小限にして「かんたん」に伝える。 これは一部実践していると思う。 進捗の共有だったり、仕様の説明などではかなり有用である実感がある。
しかし、LT会などの技術プレゼン系ではあまり有用性を感じ切れていない。 おそらく「かんたん」にしきれていなかったり、準備が不足しているのが主な原因だと思う。 選択したテーマや聴衆の反応にも左右されていそうではある。
今までは情報を有していることによる優位性を意識して取り組んでいたことだったが、 もっとシンプルにそのほうが生産的という気持ちで取り組めそう。
相手が本当に必要としている情報
相手が何を必要としているかは、常に気を配っている事柄ではある。 困ったことに必要な情報を相手が自覚しているとは限らないということがよくある。 ここはどんな問いをするのかでカバーするしかないと現状は感じている。
書籍の中で出てくる「メモを取る」や「人に伝えることを前提とした準備をする」は仕様や技術ドキュメントという観点で活用できるとは思う。
コードを読み物として扱う
基本的にはリーダブルコードに準じていれば、そんなに問題になることはないと思う。
具体的な例は著者の人がnoteに記事公開している note.com
クイックコール
音声のほうが情報量が多いのは実感している。 業務で困ったときにミーティングでヘルプを求めることは実践している。
「メンタルモデル」や「コンテキスト」がない場合は、すぐにクイックコールすることを推奨している。 ただ、誰も「メンタルモデル」「コンテキスト」を有していない場合どうすればいいのか。 そのあたりも深堀りしてほしかった。 １章にあるように時間をかけて「理解」するしかないという結論なのかもしれないが。
気軽に聞ける空気の大切さ
大切なのは理解しているが、一番むずかしいと思う。 自分が実践してもあとが続かない。 その空気が醸成されているか分かりづらい。 など難しさを挙げればきりがない。
とはいえ自分だけにメリットがあるわけではなく、チーム全体にメリットがあることなので、諦めたくない事項ではある。
自己解決してしまうことが多い性分なので、確認という名目で小さなことでも聞くことを徹底してみようと思う。
ディスカッション
基本的に意見交換は好きだ。 でも皮肉というかブラックジョークを交える傾向があるので、TPOをわきまえる必要があるというのは自戒すべきだ。
相手のことを理解して認めるということは、できるタイプの人間ではあると思うが、カロリーも相当に必要する。
意見が対立しても否定しないということは、この書籍に限らず、どこでも指摘されている事項だが、 これが実践できているかは常に不安に思う。 皮肉を交えているということは少なからず否定的なニュアンスを伝えているということなので、不安になるんだと理解はしている。
「自分の意見では」という接頭辞はかなり便利に思う。 コードレビューでコメントを付けるときに活用したい。 正解が一通りではない問題の中で頻繁に出会うのがコードレビューだと思うので。
