今日のフォーカス
傾聴・謝罪・影響力という3つの場面に共通する原則がある。「自分のゴール（解決・謝罪・説得）を優先すると、相手の本音・信頼・自律性が損なわれる」。EQ-Bの真髄は「押力」ではなく「引力」——相手が自発的に動きたくなる場を設計する技術だ。
傾聴の5レベル
ほとんどのエンジニアは「解決策モード」でLevel 2-3の傾聴に留まっている。Level 5は言葉の背後の感情・ニーズに届く傾聴。「大丈夫」の裏にある「しんどい」を言語化して返すことが鍵。
NVC（非暴力コミュニケーション）
観察→感情→ニーズ→リクエストの4ステップ。謝罪の場でも「あなたが悪い」でなく「私が引き起こした影響を私が語る」構造で相手の防衛を下げる。
権力なき影響力
専門権力と参照権力を積み上げることが長期的に安定。「押力」で動かそうとする説得は逆効果。相手の正しさを認め、味方として機能することが最も強い影響力になる。
同僚Bさん「最近、自分のコードが何のためにあるか分からなくなってきた」
あなた「ああ、スプリントが詰まっているからだよ。来月落ち着いたら改善提案出せばいいよ」
Bさん「そうですね」（…それ以降、話題を出さなくなった）
次の 1on1 で「実は転職を考えています」と告げられた。
- あなたの返答は傾聴の5レベルのどのレベルか、理由とともに説明せよ
- Bさんの発言の背後にある感情・ニーズを3つ挙げよ
- Level 5（共感的傾聴）を実践した場合の具体的な返答セリフを示せ
思考プロセスのフロー
傾聴5レベル — 診断マップ
模範解答を見る
問1: 傾聴レベルの診断
Level 3（選択的傾聴）——「スプリントが詰まっている＝原因」という自分に都合のよい解釈だけを拾い、感情・ニーズには一切触れず即座に解決策へ移行。「来月」という先送りは、今起きている感情の否定にも等しい。
「そうですね」はBさんが「これ以上話しても無駄」と判断したサイン（学習性無力感の入口）。
問2: 背後にある感情・ニーズの仮説
| # | 感情 | 背後にあるニーズ |
|---|---|---|
| 1 | 無力感・疎外感 | 「自分の仕事が会社の方向性とつながっている」という意味・目的のニーズ |
| 2 | 孤独感・承認欲求の未充足 | 自分の貢献が認識・評価されているという確認のニーズ |
| 3 | 将来への不安・アイデンティティの揺らぎ | このチーム・この仕事を続けることへの意味を再確認したいニーズ |
「コードが何のためにあるか」は技術的な問いではなく、「自分がここにいる意味は何か」という実存的問いの変形。
問3: Level 5 の応答（具体的セリフ例）
技術的な話というより……もっと根っこの部分、
自分がここで何をしているのかが見えなくなってきている感じ？
もし良ければ、もう少し聞かせてもらえる？
最近どういうときにそれを感じる？」
- 感情の命名を試みる（断定せず「〜な感じ？」と確認スタンス）
- 拡大質問で深掘りの許可を求める
- 解決策・励ましは一切入れない（これが最も重要）
実践への応用
エンジニアのマネジメント
技術的な不満の裏に「認められていない」「成長が止まっている」感があることが多い。先に解決策を出すと「話すだけ無駄」と学習させてしまう（学習性無力感）。
グローバルチームの 1on1
"That sounds tough. Can you tell me more about what it's been like?" が Level 5 の入口。日本語と同じ構造で機能する。
自己評価を記入する
PRレビューで後輩CさんにSlackパブリックチャンネルで「このコード、設計の基本が分かってないですね」と投稿。Cさんは以降、質問もPR提出も減少。別メンバーDさんから「Cさんが転職を検討しているらしい」と聞いた。
- あなたのコメントが与えた影響を「困難な会話の3種類」で分析せよ
- NVC の4ステップを使って 1on1 でCさんに伝える内容を設計せよ
- チーム全体の心理的安全性を再構築するために今週取るべきアクションを3つ挙げよ
思考プロセスのフロー
模範解答を見る
問1: 困難な会話の3層分析
| 層 | 内容 | Cさんへの影響 |
|---|---|---|
| What Happened | Slackで設計を公開批判した | 事実の解釈のズレ（技術指導のつもり vs 公開侮辱） |
| 感情層 | Cさんの感情的反応 | 恥・怒り・恐怖（またやられる）・失望が複合発生 |
| アイデンティティ層 最も深刻 |
エンジニアとしての自己定義への攻撃 | 「自分は基礎もできていない」→ 質問しない・PRを出さない行動変容に直結 |
問2: NVC 4ステップの設計
問3: 心理的安全性の再構築（今週3アクション）
1. Slack への公開謝罪
パブリックで傷つけたなら、同じチャンネルで自己訂正する。「先月の私のコメントは言い方が不適切でした。技術的な議論はDMや1on1で行います」。他メンバーへの暗黙のメッセージにもなる。
2. フィードバックルールの明文化
「コードの批判は行動・成果物に向ける」「Slackのパブリックで個人の能力を評価しない」をチームWikiに追加。自分が破ったルールを自分で設定することで、責任を取る姿勢を示す。
3. Cさんへの貢献の可視化
Cさんが出したPRやアイデアへの小さく具体的な承認を意識的に増やす。自己効力感の回復には「安全なフィードバックの体験を積む」ことが最も効果的。
実践への応用
PMへの転換視点
Google Project Aristotle が証明したように、心理的安全性は生産性・イノベーションの基盤。「謝罪→修復→ルール化」の3ステップを CTO 候補として身体に染み込ませる。
自己評価を記入する
SGチームリード・Eさん（経験8年・年上）が半年以上クリーンアーキテクチャ移行に抵抗。コードベースが独自進化し統合困難に。CEOから「Eさんを説得してほしい」と依頼。あなたにEさんへの直接権限はなく、Eさんはあなたを「若い本社の代理人」と見ている可能性がある。
- Eさんとの初回対話（Slack DM）で「説得を目的にしない」対話を設計し、具体的な文面を書け
- 権力なき影響力（専門権力・参照権力）の6週間アクションプランを設計せよ
- 「CEOの指示に応えること」と「Eさんの信頼を得ること」のトレードオフを And Stance で論じよ
思考プロセスのフロー
模範解答を見る
問1: 初回 DM の設計（「説得を目的にしない」対話）
最近、SGチームのコードを読んでいました。
[具体的な機能名]の非同期処理の設計、面白いアプローチですね。
本社側では同じ課題をこう解いているんですが（リンク）、
Eさんのアプローチのほうが[具体的な部分]では合理的だと感じました。
少し技術的な話を聞かせてもらえますか？
「クリーンアーキテクチャは現実的じゃない」という判断の背景を、
もう少し理解したくて。本社の提案の何が問題なのかを
正しく把握したいんです。
30分程度、時間をもらえますか？
- 最初にEさんの仕事を具体的に認める（好意の原則、かつ誠実）
- 「理解したい」——説得ではなく理解が目的と明示
- 「本社の何が問題か」と聞くことでEさんに批判を安全に話せる場を提供
- 30分という小さなコミットメントを要請（フット・イン・ザ・ドア）
問2: 6週間の影響力構築アクションプラン
問3: And Stance——トレードオフを統合する
Eさんの信頼なしに統一は形骸化する。CEOへの誠実な報告は「進んでいないのではなく、より確実な方法を設計している」というフレーミングで対応する。
ジレンマが深刻化したときの判断基準： 長期 > 短期。CEOへの報告を最適化して表面上の「合意」を取っても、Eさんが自発的に動かなければ実装は止まる。ただし隠さない——「今月は説得の進捗ではなく、問題の根本理解を進めました」と正直に伝える。
実践への応用
CTO としての組織統合
M&Aやグローバル展開では必ず「買収先チームとの文化・技術衝突」が起きる。今回のシナリオはその縮小版。権力なき影響力の構築が組織統合の成否を決める。
起業家のステークホルダー管理
投資家・共同創業者・重要エンジニアの利害が衝突するとき、And Stance で「両者の正しさを統合した第三の提案」を作れる人が組織をまとめられる。
自己評価を記入する
今日のまとめ・次回へ
核心： 傾聴・謝罪・影響力の3問を通じて共通するのは、「自分のゴール（解決・謝罪・説得）を優先すると、相手の本音・信頼・自律性が損なわれる」という原則。EQ-Bの真髄は「押力」ではなく「引力」——相手が自発的に動きたくなる場を設計する技術だ。
次回へ（金: IQ-B — 批判的思考・認知バイアス）
今日学んだ「選択的傾聴＝自分に都合のいい情報だけを拾う」は、認知バイアスの「確証バイアス」と同じ構造を持つ。明日は情報評価・バイアス検出・メタ認知をより分析的な観点から鍛える。EQ的「頭の中の声」が認知バイアスとどう結びつくかを意識すると理解が深まる。