本業でのコミュニケーションや、副業でのメンタリングで、
それは具体的すぎて伝わらないのでもう少し抽象化してみましょう
◯◯は具体的にはどういうことですか？
ここは抽象的すぎていろいろなことに該当してしまうのでもう少し具体化してみましょう
のように、具体と抽象と行き来する仕事を自分はしている。(と思っている)
今思えば、自分が具体と抽象という概念を知ったのは新卒で入った会社の新人研修、および、その後一緒に仕事をさせていただいたチームの先輩たちの影響が大きい。つまり「教えてもらう」という経験はすでに10年以上の前のもので、アップデートができていなかったり、実は自分も体系的に理解ができていない可能性があると感じていた。
ということでAmazon.co.jpで「具体 抽象」というキーワードで調べて上位に表示される本書を読んでみることにした。
ちなみに、この著者は具体と抽象 ―世界が変わって見える知性のしくみという本も書かれていて、購入時に少し悩んだ。しかし、こちらの本は2014年に発行された本で「知識のアップデート」という目的が達成できない可能性があることと、ページ数が少ないこと、実践要素が少なそうということが気になり、今回は手に取らなかった。
読後の感想
具体と抽象に対して私が持っていた認識は概ね間違っていなかったことが確認できた。一方で、自分が持っていた認識以外の切り口でも、具体と抽象にはさまざまな違いがあることを知れた。
お仕事で具体と抽象について語る場面で、例題や説明の引き出しが増えた点でも、本書を読んで正解だったと思う。
自分は場面によって物事を抽象化して説明することは心がけているものの、ベースとしては具体病かもしれないなと思った。
これ自体が良いとか悪いとかそういう話ではなく、そういう測定があることを知った上でコミュニケーションしていく必要性を感じた
SNS上の議論を見たとき、「感情を動かされること」がいい意味で減った気がする
共感した点
数における抽象化
具体と抽象を説明するときに使いたい
Rubyの組み込みクラスの設計に通ずるかも？
抽象化とは「線引き」すること
もともと自分が持っていた抽象化は「解像度を下げること」だった。が、本書では「線引きすること」「切り抜くこと」と語られている
言い回しが変わっただけで実態は変わっていないのかもしれないが、自分は「いらない情報は削ぎ落としている」という表現に一定の険悪感を持っていた。必ずしもそれは悪ではないんだなと思い直した。
抽象化とは「目的に合わせる」こと
物事を抽象化するとたどり着くゴールは1つだと思いこんでいたかもしれない
目的に応じてたどり着くゴールは複数ある、ということを学んだ
抽象化とは「マジックミラーを破る」こと
具体の世界にいる人からは抽象の世界が見えない
自分にもまだ見えていない抽象の世界がたくさんあるんだろうなと感じた
具体化とは「逃げ道をなくす」こと
確かにそのとおりだと思うし、その用途で「具体的にはどういうことですか？」という問いをよく使っている
「逃げ道をなくす」＝「良いこと」だと思ってやっていたが、無意識のうちに相手を追い込んでいっている可能性があることも、考えておいた方が良さそう
「成功」の反意語
「失敗」だと思っていたが、物事を抽象化して考えた場合、成功と失敗は紙一重である。つまり「何もしない」が反意語ではないか？という主張は目からウロコだった。
共感できなかった点
この本で語りたい本質ではないし、重箱の隅をつつく指摘ではあると思うが、『「頼む」「頼まれる」のメカニズム』で書かれている上司からの指示内容にいずれも「Why」が含まれていないことに違和感がある
抽象的に依頼する際の切り抜き方として、自分は「Why」を残すべきだと考えている
なぜならWhyを満たすことが「必要最低限満たしてほしい要件」であると考えているからである
メモ
社内でやってみると面白そうなトレーニング
ランチのお店の決め方
お店が具体化すればするほど、ついてくる人は減るかも？
システム障害の具体的な事象からの報告書作成
案件ごとの共通点を見出す
カンファレンススケジュールから次に出すプロポーザルを考えてみる
「仕事」と「遊び」の関係
みんなはどこに境界を引くんだろう？
本書にはないがある具体的事象を複数人がそれぞれ抽象化して、どういう理由でそのように切り抜いたのかディスカッションすると面白そう