「人と組織」という切り口で、経営と現場の課題解決についてカレンコンサルティングが分かりやすくお伝えしていきます。

コミュニケーションを考える(2):変わりつつあるコミュニケーションスタイル

»

『コミュニケーションを考える』の第2回目は、時代の変化と共に変わりつつあるコミュニケーションスタイルについて、一緒に考えていきましょう。
可能な限り図は綺麗に作成しています。今回は文章も長いです。決して軽い内容ではなく、きちんと皆さんの役に立つことを丁寧にお伝えしていければいいなと思ってます!

序章:古き良き時代の回想録より

筆者がメーカーで開発に携わっていた頃――もう20年以上前のことだが、ちょっと辛抱して耳を傾けてもらいたい。
当時の筆者は電子計測器のハードウェア設計が主な仕事で、組込み等のソフトウェア開発も行うこともあった。1990年代前半はハード設計者とソフト開発者の境界は曖昧で、ハード設計者がボードのCPUを引っこ抜き、ICE(In Circuit Emulator)をつなぎ、今ではすっかり死語とも思えるマシン語やアセンブラで開発やデバッグをするのが当たり前の時代だった。現在と違い、製品規模のソフトウェアに占める比率が少なく、規模も小さかったからできる芸当だったと思う。

technical-647488_1280.jpg
[Source:Pixtabay]

この時代は、ハード設計者がソフトの中身を知っていたこともあるし、ソフト開発者もハードウェアの知識を持っていて、お互いに積極的なコミュニケーションをとらなくても開発業務そのものは進んだ。コミュニケーションのやり取りにしても、ハードウェア設計者が「これ、うまく動かないんだけど、ソフトがどっか間違っていない? 仕様書ではこうだけど...ちゃんと理解している?」とソフト開発者に問う場面をあまり見たこともなかった。なぜなら、ハードウェア設計者が自分で解決してしまうので、コミュニケーションの必要性がさほどなかったからだ。

それでも、時代とともに製品規模が大きくなり、ASIC/FPGAがどんどん搭載されるようになり、ソフトウェア規模も肥大化してくると、自己完結できなくなってきた。当時の職場では開発プロセスやコミュニケーションについて勉強会をよくしたものだ。
UMLもその1つで、3アミーゴの時代でまだグローバルに表記方法が統一されていない時代に、抽象的なオブジェクト指向は筆者の頭にさっぱり入ってこなかったが、当時の上司にはコミュニケーションツールとして使えるとごり押しされた(今でこそわかるが当時は理解し使うに至らなかった)。
次はアジャイル開発プロセスで、当時としては斬新だったが、とりもなおさず、これまでコミュニケーションをさほどとらなくても開発業務が成り立っていたエンジニアからすれば、「アジャイルではコミュニケーションが大事」というアメリカ流の考えはなかなか定着しなかった。どういうことが起こったかと言うと、 『ソフトウェア要求管理(ピアソンエデュケーション, 2002年)』という本にも書かれているが、「なるほど...しかし症候群」だ。一度は、「なるほど」と同意しているにもかかわらず、「しかし(でもねぇ...)」と話がひっくり返されることだ。決まるべきことが、いつも土壇場でひっくり返されるちゃぶ台返し攻撃に筆者は腹を立て、「自分のやり方には合わん」と思ったことは一度や二度ではなかった。

成立しないコミュニケーションとは何か?

コミュニケーションが大事だと言われる――常識的なオトナならば誰も反論はないだろう。そんなこと言われなくてもわかっているよと...。
仕事を進める上では、嫌な上司や関わりたくない同僚ともコミュニケーションをとらざるを得ない。相手は何を言っているのか、言いたいのかわからない。こちらの言ったことを理解しているのかも疑問だ。人の話を最後まで聞かずに「わかったわかった」と話を遮る人、きちんと伝えたにもかかわらず全く違う解釈をやらかす人(後でお前の言い方が悪いと怒られる不条理等)など、皆さんの周りにいないだろうか? そして、皆さん自身がそうなっていないだろうか?
図1はご覧いただきたい。左側が送り手(話し手)で右側が受け手(聞き手)とする。ここでは受け手の問題の問題として、AからCまでの3つのパターンを挙げる。

図1:成立しないコミュニケーション

191128-1.png

スルーされたり(A)、最後まで人の話を聞け(B)、偉そうに決め付けるな(C)と、感じることはないだろうか?
そして、これらの原因は全て相手(ここでは受け手)が悪く、「聞く気がない」「理解力が不足している」「コミュニケーションスキルが足りない(コミュニケーション能力が低い)」と相手のせいにしていないだろうか?

売り言葉に買い言葉ではないが、Aの場合に「こっちもスルーしてやる」となればコミュニケーションはそこで打ち切り。Bの場合、次に送り手(話し手)がやる行動としては「お前の話などもう聞かん」。Cの場合は「よくもやりやがったな~、こっちはもっと強く投げ返してやる!」――いずれも永遠に話が噛み合うことなく平行線のまま交合うことはないだろう。相手のことを嫌いになるのも時間の問題だ。通信のプロトコルのように、きちんと「ハンドシェイク」できるようになるまで、当分、時間がかかりそうだ。
コミュニケーション以前に、コミュニケーションができる土台として関係性ができているかも考えなければならない。このことについては、後の回で述べたい。

コミュニケーションスタイルの変化と問題解決

冒頭、筆者の回想録を述べたが、日本のコミュニケーションの取り方を少し、歴史を遡って考えてみたい。
文章で説明するより、図を見ていただいたほうが早いので、図2をご覧いただきたい。文字が小さく見えないところはクリックして拡大した図で見てほしい。

図2:日本型コミュニケーションの取り方の変化

191128-2.png

特に、「今は...」の部分が職場において当てはまることはないだろうか? (「さらに...」の部分は筆者著の『EE Times Japan:いまどきエンジニアの育て方』 第1回』をご覧ください)。
そうそう......山本五十六の語録をあえて示したのは、動機づけやコミュニケーション、コーチング、任せるという仕事の与え方など人材育成にも通じるもので、時代を経た現在でも当てはまるからだ。
コミュニケーションスキルとか言っている割に、コミュニケーションにかける時間が不足していたり、コミュニケーションが不要でも仕事は「とりあえずは」は何とかなるというのが現実ではないか? しかし、仕事が順調にいっている時はコミュニケーションを意識しなくても良かったが、トラブル発生時には上司やメンバーとの共有、関連部門との問題解決に向けた協議等、コミュニケーションを必要とする場面が山ほど待ち構えている。さて、あなたならどうするだろうか? 一方的に要求事項だけを相手に突き付けても問題が解決しないことはわかっているはずだ。

コミュニケーションの種類(上意下達型の場合)

聞き手の「理解力」、伝え手の「伝達力」も大事だが、これらをひとくくりにしてコミュニケーションスキルと言うのはちょっと待ってもらいたい。これから数回に分けて、きちんとお伝えするので!
ここで、コミュニケーションの種類について考えてみたい。次回(第3回)と続き物となってしまうが、今回、皆さんにお伝えするのはそのうちの1種類――「上意下達型コミュニケーション」だ。「上意下達」の漢字が読めればその意味はわかるはずだが、わかりやすく言えばこうだ。上の意見がガツンと下に落ちてきて、下はひたすらそれに従う、上には下の意見は通らないというものだ。この上意下達型コミュニケーションがとられる組織、とらなければいけない組織は警察や消防にも一部当てはまるが、軍に代表される。軍の指揮官がアホだと部下は戦死する。部下を死なせるわけにいかない指揮官は、敵の状況を掌握し、迅速に意思決定をしなければならない。その判断には身につけた知識、蓄積された経験などがベースになり、決して間違えてはいけない判断だ。それを言葉にして部下に伝える。のんきに「敵を右の丘から攻めようと思うがみんなはどう思う?」などと"同意をあおぐこと"はやっていられない。「我が軍は敵の死角である右側に回り込み攻撃せよ!」と"命令"として伝えるはずだ。部下が指揮官に「なぜですか?」と聞き返すことは許されていない。
ここで図3をご覧いただきたい。上意下達型コミュニケーションの特徴である。図では部長から担当者に情報を落とすときに、情報がどんどん減衰していくイメージを示している。

図3:上意下達型コミュニケーションと情報の減衰

191128-3.png

この時、上司側が伝え手で、部下側が受け手だ。これを順々に部下の担当者まで情報を落し込む場合、情報の受け手であった人が、次の瞬間には伝え手にならなければならないので、冒頭示した「成立しないコミュニケーション」の両側を演じなければならない。攻守が入れ替わるのと同じだ。上意下達型コミュニケーションでは、下から上に聞き返すことはできない。話(ここでは情報と書いている)を聞き返せないということは、確認プロセスが欠損していることに他ならない。わからない、不明、曖昧なところがある等々、その場その場で聞き返していれば防げるミスが防げないのである。電子部品で言えばダイオードみたいなもので一方通行だ。
この場合、海外の実験でも検証されているが、きちんと記憶に残る情報量はおおよそ10分の1とされている。電気で言えば、1階層(1つの役職)ごとに「-20dB(パワーでは-10dB)」ずつ減衰するアッテネータみたいなもので、これでは現場の担当者に届く頃には訳が分からなくなっている。場合によっては、Aの内容が全く異なるBに化けているかもしれない。

今回はここまでとし、続きは次回、お伝えしていこう。
先に予告しておくが、コミュニケーションの範囲は広範囲で多岐にわたるが、できるだけエンジニアの視点に立ちながらも、皆さんには組織やマネジメントの内容も伝えていく。さらに、コーチングやファシリテーションなどコミュニケーションと関わりの深いこともお伝えしていく予定だ。次回をお楽しみに!

記:株式会社カレンコンサルティング / 世古雅人

Comment(0)

コメント

コメントを投稿する