Empowerment Engineering

内発的動機づけをソフトウェア開発の力で支援する

対人関係が一番むずい。対人トラブルの典型例である「抽象化の飛躍」とは?

  • やるべきことは分かっているが変化を嫌う人が多くてものごとが進まない!
  • 誰かが私の名前を出してヒソヒソと話している。きっと悪口を言っているのだろう
  • ブログにアウトプットをするとマサカリが飛んで来るだろう。こわいのでやめておこう

このようなことで、より好ましい結果を得る機会を逃したり、
好ましくない結果を招いてしまった、巻き込まれた経験はないでしょうか?

そこには「 抽象化の飛躍 」が存在します。
たぶん、この連想は抽象化の飛躍ではないと思います。

抽象化の飛躍とは?

抽象化の飛躍(Leaps of abstraction)は、 Peter Senge が主張した概念で、
それが本当であるか事実を確認せずに一般化することによって起こる事象です。

具体例

例えば、茶髪はけしからんというマインドセットをもった教師が
生まれつき髪の色が薄い生徒を見て
「茶髪の生徒を見つけた。けしからん。善意によって指導してやろう」
と考えるのは抽象化の飛躍ですね。
その子は生まれつきその髪の色をしているだけで、人格とは何ら関係ありません。

こういったことの弊害は身の回りには大量にあるでしょう。
される側だけではなく、する側としてもです。

抽象化の飛躍への対処

抽象化の飛躍への対処には何が必要でしょうか?
これは「人を変える」「人が変わる」話であり、非常に難易度が高いですが重要な話です。

必要なこととしては自分と相手が飛躍にきづくことがあります。
そのための方法が複数存在します。

振り返り

抽象化の飛躍に対処するには、まず気づく必要があります。
そのため振り返りの機会を儲けることが重要でしょう。

一人の振り返りだけでは問題を問題と認識しないため
どれを思考の対象にするか自体を誤る可能性があります。
そんな時に仲間が第三者の視点から指摘してくれるような機会があるとよいでしょう。

左側の台詞

何か抽象化の飛躍にあたるようなお題を選びます。

まずホワイトボード等の真ん中に線を引きます。
そのお題について会話をし、お互いが話した内容を右側に書きます。
そして左側には発言した際に口には出さなかったが思っていたことを書きます。

この思っていたが口には出していなかったことを確認することで、
抽象化の飛躍と認識齟齬の原因を把握することができます。

この手法を「左側の台詞」と呼びます。

探求と主張のバランスをとる

対話(Dialog)をします。
対話はお互いの考えを明らかにし、相互理解を深め、
主張するだけではなく相手の考えを探求することによって合意を形成します。
これが相互にできている状態を「相互探求」と呼びます。

まとめ

ざっくりまとめると「機会を設けて本音で話す」ということに尽きるわけですが、
相手がこの舞台に乗ってくれるかどうかが一番の難題になりそうですね。

関連資料