僕たちはきっと理解し合える〜SenseとMeaning〜
PFP関東#9に参加した。
id:J_Matsumotoさんの「チームのコミュニケーションをSenseとMeaningで考える」から
いくつかの気付きを得ることができた。
id:J_Matsumotoさんと、このイベントを開催したPFP関東に感謝です。
コミュニケーションはSense
とMeaningからなると考えることができるそうです*1。
Meaningとは、そのままのとおり、対象が持つ「意味」のこと。
例えば、バナナをWikipediaで引くと、
バナナ（甘蕉 ・実芭蕉／学名Musa spp. ）はバショウ科バショウ属の食用品種群の総称。幾つかの原種から育種された多年草であり、その果物である。原産は熱帯アジア、マレーシアなど。生産地はインド、ブラジル、フィリピン、エクアドルなど、アフリカ諸国でも重要な食料。
とあります。
おそらく、ここに書いていることは、「意味」として
バナナを的確にあらわしているのでしょうね。
しかし、上の文から「バナナ」を取ってみて下さい。
○○○（甘蕉 ・実芭蕉／学名Musa spp. ）はバショウ科バショウ属の食用品種群の総称。幾つかの原種から育種された多年草であり、その果物である。原産は熱帯アジア、マレーシアなど。生産地はインド、ブラジル、フィリピン、エクアドルなど、アフリカ諸国でも重要な食料。
私は、この文からバナナを推測することなんてできません。
一方、
私が、こんな絵を書いて、
「黄色くてね、皮がむけるんだよ。中は白い柔らかい果肉があって、甘いんだよ！」
といえば、バナナのことを言っていると大概の方が理解できるでしょう*2。
これがSense。
Senseとは、感情・感覚・ムード・その場の空気といった意味合いのようです。
別の例。
例えば、とあるプログラムの進捗確認のケース。
開発者が、開発したバッチプログラムの本数から
「進捗率は90%(10本中9本完了)です。」と答える。
管理者は、9割にも進んでいることに大喜びするだろう。
ところが、あとの1割が何日経ってもビクとも進まない。
当然、管理者は、彼/彼女のことを問い詰める。
「いやー、あとの10%が大変なんです。この1本が売上の月次集計処理を
行っていまして、色々なところからデータを取得して…」
なんて答えても中々管理者は納得してくれない…。
この例では、
「進捗率は90%(10本中9本完了)です。」
は、meaningのみを伝えている。
管理者は大喜びして、そのmeaningを理解したつもりになっている。
一方、
「いやー、あとの10%が大変なんです。…」
は、senseを、その残りの1本の難しさを伝えようとしている。
管理者は、それを理解することができていない*3。
つまり、コミュニケーションをとる際には、
meaningだけでは十分ではなく、senseの共有も行う必要があり、
senseの理解ができて、真の意思伝達ができたと
言えるようだ。
偶然にも、以前このようなエントリを書いている。
感情の海で溺れてしまう前に。 - papandaDiary - Be just and fear not.
コミュニケーションは感情を媒体にする。
コミュニケーションはsenseを共有することで真の理解を生むことができる。
私たちが仕事を進める上で取るコミュニケーションというのは、
meaningに偏りすぎているかもしれない。
仕事に感情は不要だろうか。
確かにそうかもしれない。やる気で仕事の成果が左右されるのは
組織にとっては望ましいことではないかもしれない。
しかし、そのやる気が、時として爆発的な生産性を生む。
諦めない気持ちが、奇跡を生む。
私たちがいつも悩まされる、「要件の認識違い」「仕様の認識違い」は
senseが欠落しているがゆえに生まれるコミュニケーション不全なのではないだろうか。
お客様は、自分の業務をsenseとmeaningで語る。
システム屋は、それをmeaningですべて捉えようとする。
よって、OUTPUTの要件定義書や外部設計書からはsenseが抜ける。
お客様は、その文章を、meaningとしては理解できるかもしれない。
だが、自分がsenseとして語った部分が反映されているかどうかまでは
分からない。
その結果、いくらそのドキュメントに基づいて、モノを作って収めたところで、
「これは違う！」「そんな意味では言っていない！」
という言葉を皮切りに迷走が始まることになる。
であるならば、senseは、実際に動くモノでお客様に確認してもらおうではないか。
動くモノから、アフォーダンスを感じ取ってもらう。
そこから得たフィードバック(=sense)と言葉で定義したmeaningから、
お客様の要求が何であるか、そこに近づくことができるのではないか*4。
meaningとsenseのから得たもう一つのヒント。
それは、「開発標準」のこと。
ISOなんたらや、CMMIのために組織によっては、重厚な「標準」を
用意していることだろう。
この「標準」にはmeaningが詰まっている。開発プロセスのための辞書だ。
それを利用(服従?)したエンジニアは、様々なsenseを持つ。
「これは、本当に必要なタスクなのか？」
「これは、本当に必要なドキュメントなのか？」
「あまりにも、手間が掛かりすぎる。」
senseが、meaningにフィードバックされ、適時、改善されていくのであれば
その「標準」はむしろ現場の叡智になりうる。
しかし、往々にして、それが欠けている。
「標準」の腰は重く、なかなか中身が変わることはない。
現場にとって「標準」は、何のために存在するのか分からないものになっていく。
これでは、お互いが理解するのは難しいだろう。
標準は現場で開発されるもの。現場の気付きで改善されるもの。(Mary Poppendieck)
