エンジニアにまつわるコミュニーケーション・ジレンマ三選 | Offers Tech Blog

はじめに

こんにちは。
プロダクト開発人材の副業転職プラットフォーム Offers を運営する株式会社 overflow のエンジニアの藤井です。

人とのコミュニーケーションは、本当に難しいですよね。
私もエンジニアの仕事を始めて 20 年ほどが過ぎ、前より少しはプログラミングが上手になったと思えるようになりましたが、
人とのコミュニーケーションについては未だ悩みの種がつきません。

エンジニアという職業を選択した以上、大抵いつかは専門領域の異なるステークホルダー(上司、同僚、顧客など)と協同していく場面が訪れます。

ですが、こういった場面でのコミュニーケーションに一定の苦手意識を覚えるエンジニアの方が多いのではないでしょうか？

たとえば何かを他人に説明しなければならないとき、以下のように感じたことは誰にでもあるはずです。

• 説明しても、なかなか相手にわかってもらえない。
• そもそも、どのように説明していいのかわからない。

もともとエンジニアの道を選ぶ人の多くは、コミュニーケーション能力の強化に労力を費やすより、もっと直接的に技術力を伸ばす努力を重要視するはずです。

また、ネガティブな体験から「自分は人とのコミュニーケーションが苦手」という自己認識を強化していき、できるだけそういった場面を避けようとする人もいるでしょう。

私自身かつて、

「相手の理解が得られない」 = 「自分のコミュニーケーション能力不足」

という図式で考えることが多かったのですが、あるとき別の構造的な問題があることに気がつきました。

それが、今回のテーマとなる『ジレンマ』です。

本記事が、

• 他部門とのコミュニケーションに悩むエンジニア
• エンジニアとのコミュニケーションに悩む関係者

といった方の参考になれば幸いです。

ジレンマ(dilemma)とは？

ある問題に対して2つの選択肢が存在し、そのどちらを選んでも何らかの不利益があり、態度を決めかねる状態。葛藤。

引用：https://ja.wikipedia.org/wiki/ジレンマ

日本語の類語では『板挟み』とも言い表されることもあります。

以下、有名なジレンマをいくつか挙げてみました。

• イノベーションのジレンマ
• ヤマアラシのジレンマ
• 囚人のジレンマ

ジレンマは相反する 2 つの命題のうち、どちらも痛みや不利益が伴うので簡単に選ぶことができない状態です。

一方で、ビジネスの現場で行われるコミュニーケーションは何らかの意思決定を目的とすることがほとんどなので、ジレンマはより苦しくなります。
こういった二律背反を指して トレードオフ(trade-off)という言葉もよく使われますが、ジレンマのほうがより当事者の困難さを表していると思います。

また、我々はジレンマに陥ったとき、必ずしも背後にある相反する命題自体を明確に意識するわけではありません。

むしろ、我々が最初に意識するのは、"困惑"や"怒り"といった感情的な反応がほとんどでしょう。
そのため本来の問題に、さらに感情的な対立構造まで加わって余計に話がこじれる、ということも往々にして起こるのではないでしょうか。

しかし後で冷静になって振り返ってみると、じつは見えない構造が隠れていたことに気がつくことも多いのです。

そこで今回は、私がエンジニアとして体験した 3 つのジレンマをご紹介します。

逆算 vs 順算

ここでいう逆算とは、逆算思考(=目的思考)を指します。
つまり、ある目的・ゴールから出発して、どういった手段が取り得るのか探っていく思考法のことです。

一方の順算は、積み上げ思考のことを指します。
こちらは、いま目の前にある事実・現実から出発して、その先に何ができるかを探っていく思考法となります。

顧客と向き合う営業や、未来的な事業目標を追う事業責任者は総じて、逆算思考の傾向が強くなります。

一方、エンジニアは技術的な実現性や合理性に目を向けることが多いので、積み上げ思考に偏りやすくなります。

何より問題なのは、このマインドの偏りが当事者にとって無意識であることがほとんどだ、ということです。

• 営業が顧客獲得のため機能改善の必要性を伝えても、エンジニアが懸念ばかりを口にして協力的な姿勢を見せない。
• エンジニアが現行システムの問題を訴えても事業責任者が理解を示さず、むしろ問題を悪化させるような仕事を押し付けてくる。

製品開発の現場でよく見られる対立の裏側では、構造から生じるマインドの偏りが影を落としていることがあります。
しかし、ビジネスを成功させる視点で考えれば、逆算思考と積み上げ思考は対立的なものでなく、むしろ相互補完的なもののはずです。

思考法のスイッチを切り替えられれば、より多くの解決策に目を向けることができるようになるのではないでしょうか？

要約 vs 正確

あなたがエンジニアで、他部門の関係者に自社のシステムについて説明している場面を想像してみください。

たとえば、システムの不具合で顧客に迷惑をかけたので、CS 担当者が事情を説明しなければならない。
そのためにもまずはエンジニアのあなたからの説明が必要としている、そんな場面だとしましょう。

運の悪いことにその不具合は再現性が低く、ごく稀な条件でしか発生しないのですが、自社製品をヘビーユースしている重要顧客で問題が起こり、今回のクレームになってしまったのでした。

あなたはできる限り丁寧に説明するのですが、すぐに CS 担当者は首を傾げてしまいます。

「結局、何が原因なんですか？　今のまま顧客に説明できないので要点を教えてください」

こう言われて、ますます説明が難しくなる、そんな気持ちになったことはないでしょうか？

システムとは、複数の要素が体系的に構成され、相互に影響しながら、全体として一定の機能を果たす何物かのことである。

引用：https://www.sophia-it.com/content/システム

日本語のカタカナで"システム"と書くと機械的な印象を受けますが、システムの日本語訳は"系"であり、太陽系や生態系も等しくシステムの一形態です。

システムの動作を説明するとき、ある要点だけを切り出して説明するというのは、じつはそれほど簡単ではありません。

システムとは相互に影響しあい、複雑に繋がり合っている要素の集まりです。
そして、世のシステムの多くは理解を深めれば深めるほど、電子顕微鏡の解像度を上げるかのように眼前の情報量が増加していく、という共通項があります。

そのためエンジニアがシステムの問題を正確に説明しようとすればするほど、他部門の担当者が困惑することになります。

一方で要点を伝える、ということは逆に重要(正確には、コミュニケーション相手にとって重要)な情報以外は捨てる、ということです。

エンジニアにとって、時にそれは不正確、もっと悪く言えば嘘をついているような気分になることがあります。

エンジニアの話が多少長いと感じたとしても、できる限り遮らず、最後まで話を聞いてあげると良いでしょう。

論理 vs 非論理

コンピュータはプログラムという厳密な論理構造を通じて、
「〇〇のときは〇〇をしなさい」
という命令のセットを記述し与えてやらねば、ただの箱も同然です。

そのためエンジニアの多くは論理的であることをより重視するようになります。

論理的に記述できないことをプログラムに変換することを実質不可能ですし、論理の矛盾はそのままシステムの誤動作に直結するからです。

この辺りの厳密性は、『スコットランドの羊』という有名な小話にも通じるものがあります。
この小話に出てくるのは数学者ですが、仕事で要求される情報の厳密さの程度問題、という意味ではエンジニアのそれと似ているものがあると思います。

天文学者、物理学者、そして数学者がスコットランドを走る列車に乗っている。
天文学者は窓の外を眺め、一頭の黒い羊が牧場に立っているのを見て、「なんと奇妙な。スコットランドの羊はみんな黒いのか」と言った。
すると物理学者はそれに答えて「だから君たち天文学者はいいかげんだと馬鹿にされるんだ。正しくは『スコットランドには黒い羊が少なくとも一頭いる』だろう」と言う。
しかし最後に数学者は「だから君たち物理学者はいいかげんだと馬鹿にされるんだ。正しくは『スコットランドに少なくとも一頭、少なくとも片側が黒く見える羊がいる』だ」と言った。

引用：https://ja.wikipedia.org/wiki/数学的なジョーク#数学者ってこんな人？

逆にエンジニアは総じて、論理的ではない状況や意思決定に対してより不信を持つ傾向が強くなります。

ところが現実の、特にビジネスの世界では必ずしもすべてが論理的に記述できるとは限りません。

ビジネスとは、人と人、あるいは人と物を仲介することで生じる経済活動です。

人の基本的な行動原理は「快-不快」で、その営みには常に一定の誤りと矛盾、そして複雑性を含みます。

また、論理(ロゴス)という概念自体が人間の脳の認知機能に強く依存しています。

そのため、本来は論理的に記述されたプログラムで構成されているはずのコンピューターシステムであっても、あまりに複雑度が増して人間の認知機能を凌駕するようになると、論理的に記述・認識し、制御することが難しくなるという逆転現象が起こり得ます。

こういった複雑度が高い事象に対するとき、大部分の人間は経験則や勘など、非論理的なアプローチを取ることが多くなります。
逆に論理的に対応しようとすれば、有名な人工知能の難問のひとつである「フレーム問題」に陥ってしまいます。

実のところ、エンジニア自身も実際の仕事の中では、思考の大部分は感覚的(=非論理的)な判断に委ねているのですが、こういった過程は無意識に行われることが多いので、あまり自覚はされません。

ビジネスの現場では論理的思考を求められる場面が多々ありますが、行き過ぎると摩擦の原因にもなります。

エンジニアも時には、論理的な解決が難しい場合もあると認め、ビジネスの現場にある矛盾に対して心を広く保つべきでしょう。

まとめ

いかがでしたでしょうか？

今回は、エンジニアがコミュニケーションの場面で直面しうる 3 つのジレンマ、その背景にある構造について取り上げてみました。

• 逆算 vs 順算
• 要約 vs 正確
• 論理 vs 非論理

他にも多くの構造があり得ますが、今回は私にとって特に既視感の強いものを取り上げさせていただきました。

エンジニアはコミュニーケーション能力が低い、などと言われることもありますが、そもそも『コミュニケーション能力』という言葉自体がじつに曖昧です。

一方で何かの問題を構造的にとらえる抽象思考は、エンジニアが仕事の中で日頃から行っているものです。
個人の能力云々するより、こういった構造により光を当て詳らかにする方が、人間同士の相互理解には有益ではないかと愚考する次第です。

本記事が、皆様のお役に立てれば幸いです。