「話せばわかる」という常識は、現代組織において最も危険なバグの一つです。エンジニアと営業の間の深い溝は、個人の性格や努力不足ではなく、システム化と共感化という異なる「脳内OS」の衝突（ダブル・エンパシー問題）に起因しています。本稿では、精神論的な歩み寄りを否定し、認知科学と組織工学の視点からコミュニケーション不全を解剖します。互いの認知特性を仕様書化する「User Manual of Me」や、通信規約としての「Team API」の実装を通じて、組織内の「見えない摩擦」をイノベーションの駆動力へと変換する、Neuro-Inclusiveなチームビルディングの科学的メソッドを公開します。
序論：なぜ「コミュニケーション能力」の研修は無意味なのか
現代の組織開発において、最も頻繁に叫ばれ、かつ最も効果が薄いスローガンがある。「コミュニケーションを密にせよ」という言葉だ。企業は従業員の「コミュ力」を向上させるために莫大なリソースを投じ、対話集会を開き、飲み会を推奨し、あるいはコーチング研修を導入する。しかし、現場の断絶—特にエンジニア組織（開発部門）と営業（ビジネスサイド）の間の冷たい戦争—は一向に解消されない。むしろ、「話せばわかる」というナイーブな前提が、互いの疲弊を加速させているのが現状である。
なぜか。それは、我々が「コミュニケーションの問題」を「個人の性格」や「努力不足」という道徳的な次元で処理しようとしているからだ。特に日本企業においては、「空気を読む」という高度なハイコンテクスト文化が、この問題をより深刻化させている。「言わなくてもわかるだろう」「普通の感覚ならこうするはずだ」という、同質性を前提とした圧力—いわゆる「空気」—が、脳の認知特性が異なる集団間の相互理解を阻害し、組織のパフォーマンスを殺しているのである。
本レポートは、精神論や道徳的な「相互尊重」を説くものではない。「伝わるを科学する」というShinji Designの基本哲学に基づき、認知科学、神経科学、および組織論の知見を統合し、エンジニアと営業の対立構造を「脳のOS（オペレーティングシステム）の違い」として解剖する「知的探求」である。我々は、組織内のコミュニケーション不全を、システムのバグとして扱い、デバッグ（修正）するためのエンジニアリング手法を提示する。
その中心となる概念が、「ダブル・エンパシー問題（Double Empathy Problem）」だ。これは、コミュニケーションの断絶を「どちらか一方の能力欠如」ではなく、「異なる認知特性を持つ者同士の相互理解の不全」として捉え直すパラダイムシフトである。この視点に立てば、エンジニアが営業の意図を汲めないのも、営業がエンジニアの説明を理解できないのも、どちらかが「劣っている」からではない。異なるプロトコル（通信規約）で動作するシステム同士が、変換アダプタなしに通信しようとしてパケットロスを起こしている状態、すなわち「プロトコル・ミスマッチ」に過ぎない。
本稿では、この「断絶」を科学的に可視化し、組織内に「翻訳レイヤー」を実装するための具体的なガイドラインを提示する。これは、ニューロ・ダイバーシティ（神経多様性）を組織の駆動力へと変換する「Neuro-Inclusive Team Building」の第一歩である。
第1章：ダブル・エンパシー問題の科学的本質と歴史的背景
1.1 「共感（Empathy）」という言葉の呪縛
まず、「共感」という概念そのものを疑うところから始めよう。ビジネスの現場では、マネージャーもマーケターもエンジニアも、「共感の言語」を話すことが期待されている。しかし、この期待こそが分断の起点となっている可能性がある。
「Empathy（共感）」という言葉が英語圏で使われ始めたのは1909年、心理学者エドワード・ティッチナー（Edward Titchener）による造語であり、比較的新しい概念である。それ以来、心理学やビジネス書は「他者の靴を履く能力」、すなわち相手の視点に立って感情や思考をシミュレーションする能力を、社会的成功の必須条件として神聖視してきた。
しかし、従来のモデル、特に自閉症研究における「心の理論（Theory of Mind）」のアプローチでは、コミュニケーションの障害は「一方的」なものと見なされてきた。つまり、自閉症スペクトラム（ASD）の人々や、特定の技術的思考を持つ人々（ここでは広義のエンジニア気質を含む）は、他者の心を推測する能力が「欠如」または「障害」されているため、社会的相互作用に失敗するという「欠損モデル」である。
このモデルに基づけば、解決策は常に「マイノリティ（エンジニア側）がマジョリティ（営業・定型発達側）の作法を学び、矯正すること」になる。「もっと顧客の気持ちを考えろ」「空気を読め」という指導は、この欠損モデルに由来する。しかし、これは科学的に誤りであることが証明されつつある。
1.2 ダミアン・ミルトンとパラダイムシフト
2012年、自閉症当事者であり研究者でもあるダミアン・ミルトン（Damian Milton）博士は、「ダブル・エンパシー問題（The Double Empathy Problem）」を提唱し、学界に衝撃を与えた。ミルトンの主張はシンプルだが革新的である。「相互理解の不全は、異なる気質（disposition）を持つ二者が相互作用する際に生じる『双方向』の問題である」。
この理論の核心は以下の3点に集約される：
- 相互性の欠如：コミュニケーションの断絶は、一方の能力不足ではなく、双方の「世界の見え方（Lifeworld）」があまりにも異なるために発生する相互の理解不能状態（Mutual Incomprehension）である。
- 文脈の壁：定型発達者（非自閉症者）は、自閉症者の意図や感情を読み取ることにおいて、自閉症者が定型発達者を読み取るのと同様に「無能」である。
- 権力の非対称性：社会のマジョリティ（定型発達者、あるいはビジネスサイド）は、自分たちのコミュニケーションスタイルを「標準」と定義し、マイノリティに対して一方的な適応（Learning）を強いる権力を持っている。ミルトンはこれを「権力とは、学ぶ必要がないという能力のことである（Power is the ability not to have to learn）」と表現した。
1.3 実証研究が示す「同族間の流暢さ」
この理論を裏付ける興味深い研究結果がある。キャサリン・クロンプトン（Catherine Crompton）らの研究によれば、自閉症者同士のコミュニケーションは、定型発達者同士のそれと同様に円滑で、相互理解度が高く、ラポール（信頼関係）の形成も容易であることが示されている。さらに、「伝言ゲーム」形式の実験では、混合グループ（自閉症者と定型発達者）では情報の劣化が激しいのに対し、自閉症者だけのグループでは、情報の伝達精度が極めて高いことが確認された。
これは何を意味するか。エンジニア組織が「閉鎖的でコミュニケーションがない」ように見えるのは、外部（営業）からの観察バイアスに過ぎない可能性があるということだ。内部では、高密度かつ高精度な情報のやり取りが行われている。ただ、そのプロトコルが外部と互換性がないだけなのだ。
営業担当者がエンジニアに対して「あいつらは何を考えているかわからない」「コミュニケーションが取れない」と嘆くとき、それは営業担当者自身の「エンジニア的認知に対する共感能力の欠如」を露呈しているに過ぎない。これがダブル・エンパシー問題の正体である。
第2章：脳内OSの解読：「システム化」対「共感化」
エンジニアと営業の対立を「性格」の問題から引き剥がし、より生物学的な基盤へと落とし込むために、サイモン・バロン＝コーエン（Simon Baron-Cohen）の「共感化－システム化（E-S）理論」を導入する。
2.1 E-S理論による認知プロファイルの分類
バロン＝コーエンは、人間の脳の認知スタイルを、以下の2つの独立した次元でモデル化した。
| 次元 | 定義 | 脳内での機能 |
| システム化 (Systemizing) | システム（入力・操作・出力の規則性を持つもの）を分析し、構築するドライブ。変数を制御し、法則性を発見しようとする欲求。 | 事実の分析、パターンの抽出、構造の理解。物理的・抽象的システムの予測。 |
| 共感化 (Empathizing) | 他者の感情や思考を同定し、適切な感情的反応を返すドライブ。予測不可能な人間の行動を理解しようとする欲求。 | 他者の意図の推論（メンタライジング）、感情の共有、社会的つながりの維持。 |
この2つの次元の強弱によって、個人の脳タイプ（Brain Type）は以下のように分類される。
- タイプE（Empathizing > Systemizing）：共感化能力がシステム化能力より高い。多くの営業担当者、HR、カウンセラーなどがここに分類される傾向がある。
- タイプS（Systemizing > Empathizing）：システム化能力が共感化能力より高い。エンジニア、数学者、科学者がここに集中する。
- タイプB（Balanced）：両方の能力が同程度。
- 極端なタイプS（Extreme Type S）：システム化が極めて高く、共感化が平均以下。自閉スペクトラム症（ASD）の特徴と重なる。
2.2 エンジニア脳（High SQ）の動作原理
高いシステム化指数（SQ）を持つ「エンジニア脳」にとって、世界は「if-then」のルールで記述されるべき巨大なメカニズムである。彼らの快楽の源泉は、「決定論的なシステムを完全に理解し、制御すること」にある。
- 入力への敏感さ：彼らは詳細な仕様、明確な境界条件、矛盾のない論理を好む。
- ノイズの排除：曖昧な言葉、感情的な修飾語、論理的整合性のない指示は、システムのエラー（ノイズ）として処理される。
- 真実への執着：社会的配慮（Social Niceties）よりも、事実としての正確さ（Accuracy）を優先する。バグがあるのに「素晴らしい出来だ」と褒めることは、彼らにとって嘘であり、苦痛である。
脳画像研究（VBMなど）において、高いシステム化能力は、視覚空間処理や分析的思考に関与する特定の脳領域（例えば、頭頂葉や側頭葉の一部）の灰白質体積と相関することが示唆されている。彼らの脳は、物理的法則や論理構造をシミュレーションするためにハードウェアレベルで最適化されているのだ。
2.3 営業脳（High EQ）の動作原理
一方、高い共感化指数（EQ）を持つ「営業脳」にとって、世界は「関係性」と「感情の流れ」で構成されるネットワークである。
- メンタライジング：彼らは常に「相手がどう思うか」「どうすれば相手を動かせるか」をシミュレーションしている。これには、左側頭頭頂接合部（TPJ）や内側前頭前皮質（mPFC）といった「社会脳」ネットワークが深く関与している。
- 文脈の優先：事実の厳密さよりも、その場の空気、相手の顔色、政治的な力関係といった「コンテキスト」を優先して情報を処理する。
- 曖昧さへの耐性：人間という予測不可能なエージェントを扱うため、曖昧さや矛盾に対して高い耐性を持ち、走りながら考えることを好む。
2.4 衝突のメカニズム：OSの非互換性
この二者が会議室で対峙したとき、何が起きるか。
営業担当者が「顧客がすごく困ってるから、なんとかならない？（感情的訴求）」と言ったとき、営業脳（High EQ）は「困っている顧客を助けたい」という共感回路を活性化させている。しかし、エンジニア脳（High SQ）は、この入力を「変数（期限、予算、仕様）が定義されていない不正なクエリ」として受け取る。
エンジニアが「その変更を行うと、データベースの整合性が崩れるリスクが30%あります（システム的分析）」と返すと、営業脳はこれを「冷たい」「協力する気がない」という社会的拒絶として処理する。しかし、エンジニア脳にとってこれは「システムを守るための誠実な報告」であり、最大の貢献なのである。
ここには善悪はない。あるのは、異なる目的関数に向けて最適化されたアルゴリズムの衝突だけである。
第3章：動機付けの神経科学：プロモーション vs プリベンション
認知の「処理方法」の違いに加え、「何に突き動かされるか」という動機付けシステムの神経科学的差異も、両者の対立を決定的なものにしている。ここで、コロンビア大学のE. トリー・ヒギンズ（E. Tory Higgins）が提唱した「制御焦点理論（Regulatory Focus Theory）」と、最新の神経科学的知見を接続して解説する。
3.1 脳内のアクセルとブレーキ
人間の動機付けシステムは、進化的に形成された2つの異なる生存戦略に基づいている。
1. 促進焦点（Promotion Focus）：営業のエンジン
- 基本原理：快への接近（Approaching Gains）。
- 動機：理想、希望、成長、獲得。
- 戦略：Eager（熱望的）。「勝つためにやる（Hit）」。チャンスを逃すこと（Error of Omission）を恐れる。
- 神経基盤：ドーパミン作動性経路が深く関与している。報酬予測に対して強く反応し、リスクを取ってでもリターンを最大化しようとする。脳波研究では、促進焦点の誘導は左前頭皮質の活動増加と関連している。
- 行動特性：新しい機能の提案、市場拡大、アグレッシブな目標設定。楽観主義バイアス（Optimism Bias）がかかりやすい。
2. 予防焦点（Prevention Focus）：エンジニアのエンジン
- 基本原理：不快の回避（Avoiding Losses）。
- 動機：義務、責任、安全、維持。
- 戦略：Vigilant（警戒的）。「負けないためにやる（Correct Rejection）」。ミスをすること（Error of Commission）を恐れる。
- 神経基盤：コルチゾールなどのストレス反応系や、セロトニン系（行動抑制）が関与している可能性がある。脅威検知に対して敏感であり、現状維持（ホメオスタシス）を乱す変化に抵抗する。脳波研究では、予防焦点の誘導は右前頭皮質の活動増加と関連している。
- 行動特性：バグの発見、セキュリティ対策、リファクタリング、リスク見積もり。
3.2 脳の非対称性と「不機嫌」の正体
営業（促進焦点・左脳的活性）が「この新機能を実装すれば、市場を支配できる！」とドーパミン全開で提案するとき、彼らの脳は「利得」にロックオンしている。
対して、その提案を聞いたエンジニア（予防焦点・右脳的活性）の脳内では、全く別の回路が発火している。「新機能追加＝既存システムの安定性に対する脅威」として認識され、右前頭皮質と扁桃体が「警戒信号」を発する。彼らが不機嫌に見えるのは、性格が悪いからではない。脳が「危険（Danger）」を検知し、組織を守るために防衛的ペシミズム（Defensive Pessimism）を発動させているからだ。
防衛的ペシミズムとは、最悪の事態を詳細にシミュレーションし、その不安を動力源として準備を行う適応的な戦略である。ソフトウェアエンジニアリングにおいて、楽観主義は致命的なバグを生む。サーバーダウンや情報漏洩を防いでいるのは、エンジニアたちの「ネガティブな想像力」と「病的なまでの細部へのこだわり」である。
3.3 「前向きに検討してくれ」が引き起こすコンフリクト
営業がエンジニアに対して「もっとポジティブに考えてよ」「否定ばかりしないで」と言うとき、それは「お前の右前頭葉の活動を停止し、左前頭葉を強制的に活性化させろ」と要求しているに等しい。これは生理学的に無理な要求であり、エンジニアに強烈なストレス（制御不全感）を与える。
逆に、エンジニアが営業に対して「リスク管理が甘い」「根拠のない楽観論だ」と批判するとき、それは営業のドーパミン駆動型の推進力（これがなければ新しい市場は開拓できない）を否定することになる。
ここで重要なのは「制御適合（Regulatory Fit）」という概念だ。人は、自分の制御焦点（促進または予防）に合致した方法で目標を追求するとき、最もパフォーマンスが高まり、”Feeling Right”（正しさの感覚）を得る。営業には「夢と獲得」を、エンジニアには「安全と責任」を語ることでしか、彼らの脳は「Yes」と言わないのである。
第4章：「プロトコル・ミスマッチ」とコンテキスト・スイッチングの悲劇
認知と動機の違いに加え、実務レベルで組織を疲弊させているのが「通信プロトコル」の不一致と、それによる「コンテキスト・スイッチング」のコストである。
4.1 ハイコンテクスト vs ローコンテクスト：文化神経科学の視点
コミュニケーションには「ハイコンテクスト（文脈依存）」と「ローコンテクスト（言語依存）」の2種類がある。日本のビジネス、特に営業の世界は極めてハイコンテクストだ。「よしなに」「なるはやで」「いい感じで」といった曖昧な指示が飛び交い、受信側が発信側の意図を推測（空気を読む）することで成立している。これは包括的注意（Comprehensive Attention）と呼ばれる認知スタイルであり、対象そのものよりも背景や関係性に注意を向ける。
一方、プログラミングとは究極のローコンテクスト作業である。コンピュータは空気を読まない。1は1、0は0であり、定義されていない変数はエラーとなる。エンジニアは、この「曖昧さゼロ」の世界に脳を適応させている。これは分析的注意（Analytic Attention）であり、対象の属性や法則性に焦点を当てる。
営業がエンジニアに対して、日常のハイコンテクストなプロトコルで（例：「クライアントが急いでるから、例の件、ちょっと早めに修正できない？」）話しかけることは、厳密な型定義を要求するAPIに対して、非構造化テキストデータを投げつけるようなものである。
エンジニアの脳では、以下のパースエラーが発生する：
ReferenceError: “例の件” is not defined.（チケットIDは？）TypeError: “ちょっと早め” is not a valid Date format.（具体的な日時は？）ScopeError: “修正” context is ambiguous.（スコープは？）
この「翻訳」にかかる認知的負荷（Cognitive Load）は、エンジニアの脳内リソースを浪費させ、本来のコーディング業務へのパフォーマンスを著しく低下させる。
4.2 コンテキスト・スイッチングの莫大なコスト
さらに深刻なのが、割り込みによる集中力の分断だ。プログラミングやシステム設計のような高度な認知的作業には、「フロー状態」と呼ばれる深い集中が必要である。この状態に入るには、脳のワーキングメモリに関連するコードの構造、変数の状態、呼び出し履歴などの複雑な「メンタルモデル」を展開する必要があり、これには平均して15〜20分のセットアップ時間を要するとされる。
ここに、営業からの「今ちょっといい？」というチャットや、定例会議が割り込むとどうなるか。
| 状態 | 営業（Manager’s Schedule） | エンジニア（Maker’s Schedule） |
| 時間の単位 | 30分〜1時間のブロック単位。 | 半日〜1日の連続したブロック単位。 |
| 割り込みの影響 | 歓迎。新しい情報や機会の獲得。 | 壊滅的。メンタルモデルの崩壊。 |
| 復旧コスト | 低い。すぐに次の話題に移れる。 | 極めて高い。 元の集中状態に戻るには平均23分15秒かかる。 |
ポール・グレアムが提唱した「メーカー（作り手）のスケジュール」と「マネージャー（管理者）のスケジュール」の対立である。営業にとっての「たった5分の確認」は、エンジニアにとっては「メンタルモデルの再構築を含めた30分の損失」を意味する。頻繁なコンテキスト・スイッチングは、IQの低下と同等の認知機能低下を招き、バグの混入率を高め、エンジニアの燃え尽き症候群（Burnout）の直接的な原因となる。
第5章：解決策としての「翻訳ガイドライン」とTeam API
ここまでの分析で、エンジニアと営業の対立が「性格の不一致」ではなく、「脳のOS」「動機付けシステム」「通信プロトコル」「時間感覚」という4つの次元における構造的なミスマッチであることが明らかになった。
精神論でこれを解決することは不可能である。必要なのは、異なるOS間を接続するための「ミドルウェア」の実装である。ここでは、科学的知見に基づいた具体的な「翻訳ガイドライン」と「構造化コミュニケーション」の手法を提案する。
5.1 コンセプト：トレーディング・ゾーンとバウンダリー・オブジェクト
解決の糸口となる概念が、科学史家ピーター・ギャリソン（Peter Galison）が提唱した「トレーディング・ゾーン（Trading Zone）」である。これは、物理学者とエンジニアのように、全く異なるパラダイムを持つ専門家集団が、互いの「言語」を完全に理解し合うことなく、局所的な共通言語（ピジン言語）を用いて協力し合う領域を指す。完全に相手の文化に同化する必要はない。取引（Trade）ができればいいのだ。
また、社会学者スター（Star）とグリーセマー（Griesemer）による「バウンダリー・オブジェクト（Boundary Object：境界オブジェクト）」の概念も重要だ。これは、異なる社会的世界の間を行き来し、双方にとって異なる意味を持ちながらも、協働を可能にする情報や人工物（地図、標本、リスト、共通のダッシュボードなど）を指す。
組織において、我々が作るべきは「完全な相互理解（＝空気を読むこと）」ではなく、業務遂行に必要な情報を損失なく交換できる「トレーディング・ゾーン」であり、そのための「バウンダリー・オブジェクト」である。
5.2 実践的手法①：ユーザー・マニュアル・オブ・ミー（User Manual of Me）
まず、個人の認知特性を可視化し、「ダブル・エンパシー問題」をハックするためのツールとして「User Manual of Me（私の取扱説明書）」を作成し、チーム内で共有することを推奨する。
これは、自己紹介ではない。「自分の脳がどう機能しているか」をエンジニアリング的に記述する仕様書である。以下のような項目を含めることで、相互の「翻訳コスト」を劇的に下げることができる。
| 項目 | 営業（Empathizer/Promotion）の記述例 | エンジニア（Systemizer/Prevention）の記述例 | 認知科学的背景 |
| 最適な通信手段 | 電話、対面、チャット（即時性を好む）。ブレストしながら考えたい。 | チケットシステム、ドキュメント（非同期を好む）。考えがまとまってから話したい。 | プロトコル・ミスマッチとコンテキスト・スイッチングへの配慮。 |
| モチベーション | 「すごい！」「画期的だ！」という賞賛と、新しい挑戦の機会。 | 「正確だ」「無駄がない」という評価と、邪魔されずに没頭できる時間。 | 制御焦点理論（獲得への熱望 vs 損失の回避）。 |
| フィードバック | まずポジティブな点から伝えてほしい（関係性の維持）。 | 結論から端的に、事実ベースで伝えてほしい。感情的な「サンドイッチ」はノイズ。 | ローコンテクスト vs ハイコンテクスト、曖昧さへの耐性の違い。 |
| ストレス反応 | 多弁になる、感情的になる。人に話を聞いてほしがる。 | 無口になる、引きこもる。一人にしてほしがる。 | 扁桃体の反応と対処行動（コーピング）の違い。 |
| 「空気」への期待 | 期待する。文脈を察して動いてほしい。 | 期待しない。明文化されていないルールは存在しないものとみなす。 | ダブル・エンパシー問題の核心。 |
このマニュアルをプロジェクト開始時に交換し合うことで、「なぜ彼はあんな言い方をするのか」という感情的な摩擦を、「彼のOSはそういう仕様だから、この入力形式に変えよう」という技術的な調整へと昇華させることができる。
5.3 実践的手法②：Team API（チーム・エーピーアイ）の定義
個人のマニュアルに加え、チーム間の通信プロトコルを定めた「Team API」を策定する。これはマシュー・スケルトンらが『チーム・トポロジー』で提唱した概念であり、チームを一つのソフトウェアコンポーネントに見立て、外部とのインターフェースを明確に定義するものだ。
エンジニアと営業の間で合意すべき「Team API」には、以下のような仕様が含まれるべきである。
- リクエストの形式（Input Schema）：
- 営業からエンジニアへの依頼は、必ず指定のフォーマット（チケット、フォーム）を通すこと。「ちょっといい？」という口頭やSlackのDMでの割り込み（Direct Memory Access）は原則禁止とする。
- 必須パラメータ：背景（Why）、期限（When）、優先度（Priority）、期待値（What）。特に「Why（ビジネスコンテキスト）」の記述を必須化することで、エンジニアの納得感を高め、彼らのシステム化脳が「目的関数」を理解するのを助ける。
- レスポンスの保証（SLA: Service Level Agreement）：
- エンジニアは、正式なリクエストに対して、必ず「いつまでに回答するか」というACK（確認応答）を返す。即答を求めない代わりに、応答期限を遵守することで、営業側の「無視されているのではないか」という不安（予防焦点的な懸念）を解消する。
- 同期・非同期の使い分け：
- 緊急度高・複雑度高の場合のみ「同期通信（ミーティング）」を行う。それ以外は「非同期通信」をデフォルトとする。
- ミーティングを行う場合は、事前にアジェンダ（仕様書）を共有し、脳内の「スタック」を準備する時間を与える。これにより、エンジニアは「今からミーティングモードに入る」というコンテキスト・スイッチングの準備ができる。
5.4 実践的手法③：構造化翻訳プロトコル（SCQAとNVC）
具体的な会話やテキストコミュニケーションにおいては、双方の認知特性に配慮した「共通フォーマット（ピジン言語）」を使用する。これが「トレーディング・ゾーン」の実体となる。
A. エンジニアから営業へ：SCQAフレームワーク
エンジニアが技術的な課題やリスク（予防焦点）を営業（促進焦点）に説明する際は、事実の羅列ではなく、ストーリーとして構成する「SCQA」を用いる。これはマッキンゼーなどで用いられる論理構成法である。
- S (Situation：状況)：共有されている背景。「現在、システムは順調に稼働し、ユーザー数はX人に達しています（事実の共有）」
- C (Complication：複雑化・問題)：新たな障害。「しかし、来月のキャンペーンで予想されるアクセス増に対して、現在のDB構成では耐えきれず、ダウンするリスクがあります（ここで初めてリスクを提示）」
- Q (Question：問い)：「では、どうすればキャンペーンを成功させつつ、ダウンを防げるか？（営業と共有できる問いの設定）」
- A (Answer：答え/提案)：「解決策として、一時的にサーバーを増強する予算Y円を承認してください。これにより、機会損失を防げます（促進焦点への訴求）」
この順序で話すことで、エンジニアの懸念（Complication）が、営業にとっての障害解決（Answer）という文脈に「翻訳」され、スムーズな意思決定が可能になる。いきなり「C（問題）」から話し始めると、営業脳はそれを「言い訳」や「抵抗」として処理してしまう。
B. 営業からエンジニアへ：NVC（非暴力コミュニケーション）
営業がエンジニアに対して要望や不満を伝える際は、マーシャル・ローゼンバーグの「NVC」の4要素を用いることで、感情的な対立（扁桃体ハイジャック）を防ぐ。
- 観察 (Observation)：評価を交えず事実だけを言う（エンジニア脳への入力）。
- ○「今週の進捗MTGで、機能Aの実装が遅れているという報告があった」
- ×「最近、仕事が遅いよね」（評価・判断が含まれるため、エンジニアは反発する）
- 感情 (Feeling)：その事実に対してどう感じているか（内部状態の開示）。
- ○「それを聞いて、私はクライアントとの約束が守れないのではないかと焦っている/不安だ」
- ×「君たちのせいで困る」（非難）
- ニーズ (Need)：感情の奥にある自分たちの必要性（要件定義）。
- ○「私たち営業チームにとって、顧客からの信頼（納期遵守）は何よりも重要だからだ」
- リクエスト (Request)：具体的で実行可能な要求（アクションアイテム）。
- ○「キャッチアップのために、どの機能を削れば納期に間に合うか、明日までに案を出してもらえないか？」
- ×「なんとかしてよ」（曖昧な命令）
このフォーマットは、営業の「感情」を論理的な「パラメータ」としてエンジニアに提示することを可能にする。エンジニアにとって、怒声などの「感情的表出」はノイズだが、「不安（リスク検知）」と「ニーズ（要件）」は処理可能なデータである。これにより、エンジニアは「空気を読む」必要がなくなり、明確な要件に対して解決策を提示するモード（システム化）に入ることができる。
5.5 脳間同期（IBS）と「飲みニケーション」の功罪
最後に、日本企業が好んで用いる「飲み会」による融和策について、脳科学的視点から補足する。
「脳間同期（Inter-brain Synchronization: IBS）」の研究によれば、人々が協力して作業を行ったり、深い対話を行ったりする際、二者の脳波（特に前頭葉や側頭頭頂接合部）が同期する現象が確認されている。しかし、この同期が発生するための条件は「共有された注意（Shared Attention）」と「予測可能な文脈」である。
「飲み会」という場は、極めてハイコンテクストであり、社会的信号（視線、声のトーン、序列）が乱れ飛ぶ環境だ。高いEQを持つ営業にとって、この環境は脳間同期を促進し、オキシトシンを分泌させる「報酬の場」となり得る。しかし、高いSQを持つエンジニアにとって、ノイズが多く予測不可能なこの環境は、過剰な感覚入力（Sensory Overload）を引き起こし、脳間同期どころか「認知的シャットダウン」を招く可能性が高い。
つまり、飲み会は営業サイドの脳OSに最適化された「ホーム戦」であり、エンジニアにとってはアウェイ戦、あるいは拷問に近い環境である可能性がある。この非対称性を無視して「腹を割って話せばわかる」と強要することは、ダブル・エンパシー問題を悪化させる典型的なパワーハラスメントとなり得る。
真の融和（脳間同期）は、アルコールによる麻痺ではなく、ホワイトボードとポストイット、そして明確なアジェンダのある静かな会議室（またはオンラインのMiroボード）で、互いの「論理」を同期させたときにこそ生まれるのである。
結論：対立を「構造的摩擦」から「創造的摩擦」へ
「空気を読め」という日本的組織の不文律は、認知特性の異なるエンジニアと営業の間では機能しないどころか、組織を殺す猛毒となる。ダブル・エンパシー問題が教えるのは、相互理解の不全は「個人の責任」ではなく「関係性のバグ」であるという事実だ。
本稿で提案したアプローチは、以下の3点に集約される。
- 科学的理解：脳のOS（システム化 vs 共感化）や動機付け（予防 vs 促進）の違いを認め、互いを「異文化の住人」として尊重すること。
- プロトコルの定義：「User Manual of Me」や「Team API」によって、通信の規格を明文化し、空気を読む必要性を排除すること。
- 翻訳の実践：SCQAやNVCといったフレームワークを「バウンダリー・オブジェクト」として用い、情報を損失なく変換すること。
これらの手法を導入した初期段階では、形式張ったやり取りに違和感（Static Friction：静止摩擦）を感じるかもしれない。しかし、その摩擦こそが「認知的多様性」が機能し始めた証拠である。摩擦のない組織は、同質的で脆弱だ（グループシンクの罠）。異なるOSを持つ者同士が、適切なインターフェースを通じて激しく議論し、互いの視点を補完し合うとき、組織は初めて「ニューロ・インクルーシブ」な強さを獲得する。
次回は、この理論をさらに拡張し、「リーダーシップ」の文脈における脳科学的アプローチ、特に「カリスマ性の正体とIBS（脳間同期）」について詳述する予定である。組織のOSをアップデートする旅は、まだ始まったばかりだ。
引用文献
- 伸滋Design, https://shinji.design/
- Double Empathy Problem – Stimpunks Foundation, https://stimpunks.org/glossary/double-empathy-problem/
- Rethinking Social Challenges in Autism: Beyond Deficits to Mutual Understanding, https://www.stepaheadaba.com/blog/the-double-empathy-problem-in-autism
- A modular approach to the communication protocol and standard for multimedia information: A review | Request PDF – ResearchGate, https://www.researchgate.net/publication/257857712_A_modular_approach_to_the_communication_protocol_and_standard_for_multimedia_information_A_review
- Decoding the Language of Empathy – what works, https://whatworks.fyi/articles/decoding-the-language-of-empathy
- Full article: The double empathy problem and the problem of empathy: neurodiversifying phenomenology – Taylor & Francis, https://www.tandfonline.com/doi/full/10.1080/09687599.2023.2220180
- The double empathy problem – National Autistic Society, https://www.autism.org.uk/advice-and-guidance/professional-practice/double-empathy
- Autism and the double empathy problem.pdf – Kent Academic Repository, https://kar.kent.ac.uk/102377/1/Autism%20and%20the%20double%20empathy%20problem.pdf
- Learning ‘autistic’ – Arts Professional, https://www.artsprofessional.co.uk/magazine/328/feature/learning-autistic
- Autism diagnosis and the double empathy problem | The British Journal of Psychiatry, https://www.cambridge.org/core/journals/the-british-journal-of-psychiatry/article/autism-diagnosis-and-the-double-empathy-problem/DFC4822A2C62F2A7E048134A501E1BF1
- The Double Empathy Problem: Autistic Communication Is Not a Deficit, https://neurodivergentinsights.com/the-double-empathy-problem/
- The Essential Difference | Summary, Quotes, FAQ, Audio – SoBrief, https://sobrief.com/books/the-essential-difference
- The Essential Difference – Bookey, https://cdn.bookey.app/files/pdf/book/en/the-essential-difference.pdf
- empathic brain responses: Topics by Science.gov, https://www.science.gov/topicpages/e/empathic+brain+responses
- Abstracts PDF Posters – SfN, https://www.sfn.org/-/media/SfN/Documents/Annual-Meeting/FinalProgram/NS2017/Full-Abstract-PDFs-2017/SFN17_Abstract-PDFs—Posters_2_Sun_AM.pdf
- Regulatory focus theory and the entrepreneurial process – Columbia Business School, https://business.columbia.edu/sites/default/files-efs/pubfiles/398/BrocknerHiggins_RegFocusTheory.pdf
- Regulatory focus theory – Wikipedia, https://en.wikipedia.org/wiki/Regulatory_focus_theory
- CEO Regulatory Foci, Environmental Dynamism, and Small Firm Performance – Terry College of Business, https://www.terry.uga.edu/wp-content/uploads/Wallace_et_al._-_2010_-_Journal_of_Small_Business_Management.pdf
- Tuncdogan, Acar and Stam (2016)_Individual Differences as Antecedents of Leader Behavior.pdf – City Research Online, https://openaccess.city.ac.uk/id/eprint/15816/1/Tuncdogan%2C%20Acar%20and%20Stam%20%282016%29_Individual%20Differences%20as%20Antecedents%20of%20Leader%20Behavior.pdf
- Risky decision-making predicts dopamine release dynamics in nucleus accumbens shell, https://pmc.ncbi.nlm.nih.gov/articles/PMC6901435/
- The Effect of Induced Regulatory Focus on Frontal Cortical Activity – MDPI, https://www.mdpi.com/2076-328X/14/4/292
- Invulnerability bias in perceptions of artificial intelligence’s future impact on employment, https://pmc.ncbi.nlm.nih.gov/articles/PMC12328832/
- Full article: Exploring the nexus between persuasive principles and regulatory focus: an online experiment – Taylor & Francis, https://www.tandfonline.com/doi/full/10.1080/23311975.2025.2501489
- Revisiting the form and function of conflict: Neurobiological, psychological, and cultural mechanisms for attack and defense within and between groups | Behavioral and Brain Sciences | Cambridge Core, https://www.cambridge.org/core/journals/behavioral-and-brain-sciences/article/revisiting-the-form-and-function-of-conflict-neurobiological-psychological-and-cultural-mechanisms-for-attack-and-defense-within-and-between-groups/E622ABBFEE29A785463F506458468BEA
- 7. Balancing Optimism, Pessimism and Realism – The Foresight Guide, https://foresightguide.com/balancing-optimism-pessimism-and-realism/
- What is Defensive Pessimism? – Simplicable Guide, https://simplicable.com/new/defensive-pessimism
- Regulatory Focus and Conspiratorial Perceptions: The Importance of Personal Control – UCLA Anderson Review, https://anderson-review.ucla.edu/wp-content/uploads/2021/03/Whitson-et-al_Regulatory_Focus_PSPB2018.pdf
- A regulatory focus theory perspective on the dynamics between action and power, https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=8494&context=lkcsb_research
- Mitigating Context Switching in Software Development – Jellyfish, https://jellyfish.co/library/developer-productivity/context-switching/
- Programmer interrupted: The cost of interruption and context switching (2022) | Hacker News, https://news.ycombinator.com/item?id=35459333
- The Hidden Cost of Context Switching: How Many Software Tools Tech Professionals Use Daily—and What It’s Costing Us – Burai, https://www.burai.com/blog/the-hidden-cost-of-context-switching-how-many-software-tools-tech-professionals-use-daily–and-what-its-costing-us
- Trading Zones in Early Modern Europe | Isis: Vol 106, No 4, https://www.journals.uchicago.edu/doi/full/10.1086/684652
- Trading zones – Wikipedia, https://en.wikipedia.org/wiki/Trading_zones
- Trading zones combining cognitive psychology and disciplinary science – SERC (Carleton), https://serc.carleton.edu/getspatial/blog/trading_zones.html
- Boundary Objects, Agents, and Organizations: Lessons from E-Document System Development in Thailand | IEEE Conference Publication, https://ieeexplore.ieee.org/document/6149287/
- Revisiting the notion of boundary object – OpenEdition Journals, https://journals.openedition.org/rac/18243?lang=en
- Boundary object – Wikipedia, https://en.wikipedia.org/wiki/Boundary_object
- How the Manual of Me can help build stronger teams | CharityComms, https://www.charitycomms.org.uk/how-the-manual-of-me-can-help-build-stronger-teams
- User Manuals, https://hr.northwestern.edu/essentials/alternative-work-strategies/team-user-manual-worksheet.pdf
- A user manual for me. There are lots of ways to build good… | by …, https://cassierobinson.medium.com/a-user-manual-for-me-d3a851fbc694
- Working with me: a personal user manual – Sarah Lay, https://www.sarahlay.com/2023/07/working-with-me-a-personal-user-manual/
- 7 Cross-Functional Communication Best Practices for Engineering Teams – DEV Community, https://dev.to/remotebranch/7-cross-functional-communication-best-practices-for-engineering-teams-2jb1
- Team API Template | Miroverse, https://miro.com/templates/team-api/
- Key Concepts — Team Topologies – Organizing for fast flow of value, https://teamtopologies.com/key-concepts-content
- Visualizing Team Dependencies with a Team API – IT Revolution, https://itrevolution.com/articles/visualize-team-dependencies-with-a-team-api/
- The Hidden Costs of Context Switching — and How to Avoid Them – NextPlane, https://nextplane.net/blog/hidden-costs-of-context-switching/
- Strategies for Success: Cross-Functional Team Collaboration | Slack, https://slack.com/blog/collaboration/strategies-for-success-cross-functional-team-collaboration
- Technical Requirements Document (with Examples) – TimelyText, https://www.timelytext.com/technical-requirements-document/
- SCQA Framework: Overview, Examples & How To Use It – Slide Science, https://slidescience.co/scqa-framework/
- Logical message structure underlies all effective workplace communication. | by Jason Yip, https://jchyip.medium.com/logical-message-structure-underlies-all-effective-workplace-communication-d7f62d805826
- The Power of Nonviolent Communication in Software Testing – Richard Seidl, https://www.richard-seidl.com/en/blog/nonviolent-communication-testing
- Power Up Your Team with Nonviolent Communication Principles – First Round Review, https://review.firstround.com/power-up-your-team-with-nonviolent-communication-principles/
- Navigating Conflict Constructively with the Nonviolent Requests Guide, https://www.teamalignment.co/blog/manage-conflict-constructively-with-the-nonviolent-requests-guide
- Communication and Affirming Neurodiversity with Natashia – Illustrative, https://www.illustrative.us/blog/expert-interview-natashia
- Quiet Engineer’s Dilemma: How to Advance and Be Yourself | Articles | Doray Hong, https://doray.me/articles/quiet-engineers-dilemma-how-to-advance-and-be-yourself-DBSD4
- How Conflict Can Be Positive: Harnessing Diversity for Innovation – Impact Consulting, https://workwithimpact.co.uk/news/how-conflict-can-be-positive/