ITエンジニア日記 ~NO SKILL, NO LIFE~

学んだ技術や、気になることをアウトプットしていきます。プログラミング, インフラ, etc...

堀公俊 + 加藤彰「ロジカル・ディスカッション チーム思考の整理術」

「ロジカル・ディスカッション チーム思考の整理術」という本を読んだので、その読書備忘録です。

【書籍情報】
ロジカル・ディスカッション チーム思考の整理術
著者:堀公俊 + 加藤彰
発行:日本経済新聞出版社

総括

議論の受け答えの例で
「だから、何ですか?」
「要するに、何をおっしゃりたいのですか?」
など、実際にはそんなこと言えないようなぁっていうような例文もあるが、全体的にためになった。

スムーズに進む打合せとかをやる人は、ロジカルディスカッションが出来ていて、ファシリテーターであるということに気が付いた。日常の業務の中でも役立ちそうな考えやアイデアのまとめ方などあり、ディスカッションの場だけでなく使えそう。
でも、本を読むだけでなく、実践しないと身につかないのは言うまでもない。

ロジカルに考える

ディスカッションというと、あるテーマについて討論・議論して結論を出す=「筋道の通った答えを選び取る」ものだ思っていたが、「筋道の通った答えを作り上げていく」という視点は持っていなかった。
また、ディスカッションにファシリテーターという役割を持った人がいることを知った。話し合いを仕切る人というよりは、内容を要約・検証・整理・統合して議論を統括する人みたいなイメージ?

要約する

曖昧な発言の趣旨を、ポイントや真意がはっきりするように言い換えるのが難しい。この辺は練習あるのみか。
また、「曖昧な言葉を放置しない」ということで、「少し遅れている」とか曖昧な言葉を使い気味なので注意しようと思った。

検証する

ディスカッションで出てきた主張を妥当なのか判断する必要があるとのこと。たしかに、間違った主張をそのままにして議論を進めていったら、間違った結論に行き着く。主張に対する根拠も引き出し、メンバ全員の納得がいく根拠なら、それは確からしいと言えそう。

整理する

いろんな主張が出てきたら、それらを分類・分解して整理するのはやりやすそうだし、わかりやすいと思う。ロジックツリーによる分解は普段の業務の中でも、考えをまとめるのにやっていたりするので実践しやすそう。
分類・分解による整理の方法はいくつもあるらしいので、なにか一つの方法が正解というわけでなく、議論の種類によって使い分けが必要になる。
さらに、フレームワークという先人が開発した整理の方法で、それを活用すれば整理力は高まるらしい。フレームワークいっぱいある。。。

統合する

まとめはメッセージにならないといけないというのは、なるほどと思った。共通の要素をみつけてそれを"まとめ"とするだけではダメで、そこから"何が言えるのか"をメッセージとしてまとめないといけない。
レーニング例として、バラバラに見える意見の共通点を見つけ出す力を鍛える練習というのがあり、何人かで集まってやってみても面白そう。

構造化する

フレームワークは会議の目的によって、よく使うものがある程度決まっているらしい。フレームワークを知っておくことによって、ロジカルに議論を進められるとのこと。
また、ビジネスフレームワークという単語は他の書籍でも出てきた。迷ったときはビジネスフレームワークなどの「セオリー」使って考えることで判断しやすくなるらしい。1冊専門の本買って読んでみようかな。

まとめ

今回は読書備忘録を記事としてみました。
今後も、読んだ本があれば読書備忘録としてまとめてみようと思います。