『コミュニケーションを考える』の第2回目は、時代の変化と共に変わりつつあるコミュニケーションスタイルについて、一緒に考えていきましょう。
可能な限り図は綺麗に作成しています。今回は文章も長いです。決して軽い内容ではなく、きちんと皆さんの役に立つことを丁寧にお伝えしていければいいなと思ってます！
序章：古き良き時代の回想録より
筆者がメーカーで開発に携わっていた頃――もう20年近く前のことにだが、皆さんにはちょっと耳を傾けてもらいたい。
当時の筆者は電子計測器のハードウェア設計が主な仕事で、組込み等のソフトウェア開発も行うこともあった。1990年代前半はハード設計者とソフト開発者の境界は曖昧で、ハード設計者がボードのCPUを引っこ抜き、ICE（In Circuit Emulator）をつなぎ、今ではすっかり死語とも思えるマシン語やアセンブラで開発やデバッグをするのが当たり前の時代だった。現在と違い、製品規模のソフトウェアに占める比率が少なく、規模も小さかったからできる芸当だったと思う。
[Source:Pixtabay]
この時代は、ハード設計者がソフトの中身を知っていたこともあるし、ソフト開発者もハードウェアの知識を持っていて、お互いに積極的なコミュニケーションをとらなくても開発業務そのものは進んだ。コミュニケーションのやり取りにしても、ハードウェア設計者が「これ、うまく動かないんだけど、ソフトがどっか間違っていない？ 仕様書ではこうだけど...ちゃんと理解している？」とソフト開発者に問う場面をあまり見たこともなかった。なぜなら、ハードウェア設計者が自分で解決してしまうので、コミュニケーションの必要性がさほどなかったからだ。
それでも、時代とともに製品規模が大きくなり、ASIC/FPGAがどんどん搭載されるようになり、ソフトウェア規模も肥大化してくると、自己完結できなくなってきた。当時の職場では開発プロセスやコミュニケーションについて勉強会をよくしたものだ。
UMLもその1つで、3アミーゴの時代でまだグローバルに表記方法が統一されていない時代に、抽象的なオブジェクト指向は筆者の頭にさっぱり入ってこなかったが、当時の上司にはコミュニケーションツールとして使えるとごり押しされた（今でこそわかるが当時は理解し使うに至らなかった）。
次はアジャイル開発プロセスで、当時としては斬新だったが、とりもなおさず、これまでコミュニケーションをさほどとらなくても開発業務が成り立っていたエンジニアからすれば、「アジャイルではコミュニケーションが大事」というアメリカ流の考えはなかなか定着しなかった。どういうことが起こったかと言うと、 『ソフトウェア要求管理（ピアソンエデュケーション, 2002年）』という本にも書かれているが、「なるほど...しかし症候群」だ。一度は、「なるほど」と同意しているにもかかわらず、「しかし（でもねぇ...）」と話がひっくり返されることだ。決まるべきことが、いつも土壇場でひっくり返されるちゃぶ台返し攻撃に筆者は腹を立て、「自分のやり方には合わん」と思ったことは一度や二度ではなかった。
成立しないコミュニケーションとは何か？
コミュニケーションが大事だと言われる――常識的なオトナならば誰も反論はないだろう。そんなこと言われなくてもわかっているよと...。
仕事を進める上では、嫌な上司や関わりたくない同僚ともコミュニケーションをとらざるを得ない。相手は何を言っているのか、言いたいのかわからない。こちらの言ったことを理解しているのかも疑問だ。人の話を最後まで聞かずに「わかったわかった」と話を遮る人、きちんと伝えたにもかかわらず全く違う解釈をやらかす人（後でお前の言い方が悪いと怒られる不条理等）など、皆さんの周りにいないだろうか？ そして、皆さん自身がそうなっていないだろうか？
図1はご覧いただきたい。左側が送り手（話し手）で右側が受け手（聞き手）とする。ここでは受け手の問題の問題として、AからCまでの3つのパターンを挙げる。
図1：成立しないコミュニケーション
スルーされたり(A)、最後まで人の話を聞け(B)、偉そうに決め付けるな(C)と、感じることはないだろうか？
そして、これらの原因は全て相手（ここでは受け手）が悪く、「聞く気がない」「理解力が不足している」「コミュニケーションスキルが足りない（コミュニケーション能力が低い）」と相手のせいにしていないだろうか？
続きはこちらより ⇒ https://el.jibun.atmarkit.co.jp/carren/2019/11/33ok1.html
記：株式会社カレンコンサルティング / 世古雅人
