今日のフォーカス
チームの信頼ループを感知し構造で修復するEQ×IQ×Thinking（Q1）、権威への反論を「判断材料の提供」に変換して場を動かす複合発言設計（Q2）、個人の信念・アイデンティティと組織の生存が衝突するリーダーシップジレンマでの誠実かつ戦略的な判断（Q3）。今日のカギは「3軸を順番に使うのではなく、同時に構造化すること」。
あなたは30人規模のプロダクト開発チームのエンジニアリングマネージャー（EM）だ。3ヶ月前から月次の全体振り返り会議（レトロスペクティブ）への参加率が落ちてきている。最初は80%だったが、今は55%まで下がった。
会議自体は続いており、表向きには「業務が立て込んでいる」という理由が多い。しかし1on1では「会議が長い」「同じ話が繰り返される」「何も変わらない気がする」という声がぽつぽつ出ている。
あなたはこの状況を「EQ（何が起きているのか感情・関係的に）」「IQ（どんなデータ・構造的問題があるか）」「Thinking（どう介入するか）」の3軸で分析し、次の1ヶ月のアクションを設計せよ。
表面的な「参加率低下」という問題を、感情的・論理的・戦略的の3層で深掘りする能力を鍛える。EQだけでは感情的な対処に終わり、IQだけでは数値管理になり、Thinkingだけでは机上の改善策になる。3軸を同時に動かすことで「人が動く介入設計」ができる。
ラーニングループの断絶診断
「アクション決定 → 実行」のループが詰まっていることが根本。参加率低下はその結果指標に過ぎない。
EMへの信頼の問い: 「この人に言えば動く」という期待が失われると会議への投資をやめる。
EQアクション: 1on1を5名実施し「最近レトロに来ない理由を正直に聞かせてほしい。批判ではなく設計を直したい」と切り出す。
仮説: 完了率が30%未満であれば、「言っても変わらない」という感覚はデータとして正しい。
IQアクション: アクションアイテムリストを棚卸しし、完了/未完了/放置を分類して可視化。次のレトロ冒頭に正直に共有する。
第2週: 棚卸し結果をレトロで開示 + 「やめるアクション」を選ぶ（正直さで信頼回復）
第3週: アクション3件にオーナーと期日を明示 / Slackで進捗共有
第4週: 「完了した3件」を振り返り、「言えば変わる」体験を作る
実践への応用
スプリントレトロが形式化し「問題が挙がらない」場合、小さな約束の完遂を繰り返すことで信頼のループを回す。高文脈文化（日本）のメンバーは「不満を言わずに静かに離れる」パターンが多く、参加率の数値変化は言語化されない前の貴重なシグナルとなる。
あなたはシリーズAのBtoB SaaSスタートアップで、3名のプロダクトエンジニアを率いるチームリードだ。CEO・CTO・あなた・PM の4人で週次定例を行っている。
今日の定例で、CTOの田中さんが新機能の開発ロードマップとして「次の6ヶ月でAPIのマイクロサービス分割を進めるべき」と提案した。あなたは以下の3点でこの判断に強い懸念を持っている：
- 事業観点: 現在の顧客数は12社で、スケーラビリティの問題はまだ発生していない
- 技術観点: マイクロサービス移行は最低でも4〜6人の専任チームが必要な規模で、3名体制では他のすべての開発が止まる
- 組織観点: CTOは前職でマイクロサービス移行を成功させた経験があり、自身の強みを活かしたい動機があると推察される
しかし同席しているCEOは技術に詳しくなく、「田中さんが言うなら正しいんじゃないか」という雰囲気で頷いている。
設問：
1. 「正しいことを言うだけ」では失敗する理由を、EQ・IQ・Thinkingの各観点で分析せよ
2. 「組織を動かすために最も効果的な発言」を設計し、実際のセリフを示せ
「技術的に正しい反論」と「場を動かす発言」の差を理解させる。権威（CTO）への反論、上位者（CEO）の理解、自分の動機管理（嫉妬・競争ではなく事業へのコミット）という複合的な関係性の中で、3軸を統合した発言設計を鍛える。
「正しいことを言うだけ」が失敗する理由
最も効果的な発言（実際のセリフ）
一点だけ、CEOの矢野さんにも判断材料として共有させてください。今の状態でこれを進めると、3名の開発リソースの9割近くが6ヶ月間この移行に集中することになります。つまり、新機能の追加はその間ほぼゼロになります。
矢野さん、今の12社フェーズでの最優先は「顧客獲得のための機能追加」か「将来のスケール基盤づくり」か、どちらでしょうか？
もし「50社を超えたときにこの問題が爆発する」という見通しがあれば、今がタイミングだと思います。一方で「まず30社」が直近ゴールであれば、移行開始の条件を「顧客30社達成後」に設定する選択肢もあるかと。
田中さん、このトレードオフ、どうお考えですか？
このセリフが機能する理由
- Ethos先渡し: 「方向性は同意」でCTOの防衛を下げる
- Logos数値化: 「9割リソース・新機能ゼロ」でCEOが判断できる情報に変換
- 権限の返還: 「どちらでしょうか」でCEOに判断を返す
- CTOへのリスペクト: 最後に「田中さんのお考えは？」で対話の促進者として振る舞う
- 「私の懸念は3点あります」と羅列する
- 技術的な正しさだけを論拠にする
- CTOの動機を暗示・指摘する
- 自分の結論を押し付ける
あなたはグローバルHRテックスタートアップのCTO（社員数45名）だ。以下の状況に直面している。
背景：
- 会社は6ヶ月後にシリーズBを目指している。VCから「ARR 5億円達成」「プロダクトの安定性・スケーラビリティの証明」が必須条件
- 主力エンジニア・鈴木さん（35歳）はコードの品質が高く、エンジニア仲間の信頼も厚い。しかし、リリーススピードが著しく遅く、3ヶ月で完成するはずの機能が6ヶ月経っても未完成
- 鈴木さんは「品質を妥協したくない」という強い信念を持ち、自分のペースで完璧なものを作ることにアイデンティティを置いている
- 鈴木さんを外すと、チームの士気が大きく落ちる可能性が高い（「鈴木さんと働けるから続けています」という発言が複数）
- このままでは6ヶ月後のシリーズB条件を満たせない可能性が高く、会社の存続にかかわる
設問：
1. EQ：鈴木さんに「真実」をどう伝えるか。会話設計と具体的なセリフを示せ
2. IQ：「鈴木さん個人の問題」と「組織の構造問題」に分けて分析。どちらが根本原因に近いか
3. Thinking：6ヶ月のうちにどの選択肢を取るか。選択肢を複数設計し、リスク・ベネフィットを整理した上で「自分の判断」を述べよ
個人の能力・信念・アイデンティティと組織の生存が衝突する局面で、感情・論理・戦略を同時に動かせるかを問う。「正しい判断」が人を傷つける可能性がある場面でのリーダーとしての覚悟と設計力を鍛える。EQのみでは「鈴木さんを守ること」に流れ、IQのみでは「非効率な人材の排除」になり、Thinkingのみでは「人間をリソースとして扱う」になる。3軸を持ち寄ることで「誠実で戦略的な」判断を導く。
EQ：鈴木さんへの「真実の伝え方」
鈴木さんは「品質への強い信念」にアイデンティティを置いている。そこへの否定は人格への攻撃として受け取られやすい。しかし「曖昧な優しさ」は最終的に鈴木さんを傷つける。
鈴木さんのコードの品質は、本当に高い。チームへの信頼も本物だし、それはあなたが積み上げてきたものだと思っています。その点は全く変わっていません。
その上で、今の開発スピードが、会社の存続にかかわるレベルの問題になっています。3ヶ月の機能が6ヶ月を超えていること、これは数字として事実です。シリーズBには6ヶ月後という期限があり、このままでは到達できないリスクが高い。
私が聞きたいのは「なぜこうなっているか」です。品質を妥協したくないという気持ちは知っています。でも今、私には見えていない何かがあるのかもしれない。スコープが大きすぎるのか、技術的な壁があるのか、他に優先していることがあるのか。
一緒に考えたい。でも正直に言うと、今後6週間で変化が見えなければ、私はロール・担当範囲の変更を含めた判断をしなければならなくなります。それをあなたに隠したまま決定するのは、誠実じゃないと思うから今日話しています。
IQ：個人問題 vs 構造問題の分析
- 完璧主義・リファクタリング優先がスループットを下げている
- 小さいPRが出ない / 「まだ完成ではない」が続く
- コードレビューに時間をかけすぎる
- スコープ管理がされていない（初期定義が不明確）
- CTOが「品質 vs スピード」のトレードオフを明文化せず暗黙に委ねていた
- フィードバックループが遅い（週次での進捗確認がなかった）
- 「品質へのこだわり」は環境がその行動を許可していた結果でもある
→ 構造問題の方が根本に近い。しかし構造を直しても鈴木さんの行動変容が伴わなければ意味がない。両方を並行して対処する。
Thinking：選択肢の設計と判断
| 選択肢 | 内容 | ベネフィット | リスク |
|---|---|---|---|
| A 構造改善試行 |
週次進捗確認・スコープ切り出し・スプリント導入 | チームへのダメージなし / 鈴木さんが変われる可能性 | 6週間試して変化がなければ残り4.5ヶ月に減る |
| B ロール変更 |
実装担当 → コードレビュー・品質設計担当へ移行 | 強みを活かしながら会社課題を解決できる可能性 | 鈴木さんが「降格」と感じ退職する可能性 / 代替人材の採用が必要 |
| C 段階的処遇変更 |
6週間のマイルストーン設定、未達の場合はロール変更または退職処理を明示 | 透明性が高く、鈴木さんが「自分で選択する機会」を持てる | チームへの影響が不可避 / 信頼関係の破綻リスク |
理由: 構造問題への責任はCTO（自分）にある。まず自分の設計ミスを直す義務がある。同時に、ロール変更という選択肢を事前に設計しておくことで「Aが失敗した場合の判断が遅れない」。鈴木さんへの会話（EQ設計）は今週中に行う。
覚悟: 「正しい判断が誰かを傷つける」局面では、最終的に「どのルートでも傷は避けられない」ことを認める。ならば、誠実に・早く・本人の尊厳を守りながら動くことが、リーダーとして取れる最善の行動である。
今日のまとめ
EQ・IQ・Thinkingを「順番に使う」のではなく「同時に構造化する」のが統合の核心。チームの信頼、場を動かす発言、人材と組織の葛藤——いずれも感情・論理・戦略を切り離したままでは「部分的に正しいが全体が壊れる」判断になる。
次回への接続
明日（月曜）はEQ-A（自己認識・感情管理）。今日の統合問題で「自分はどこで感情が動いたか」を振り返ると、EQ-Aの鍛錬の入口になる。特にQ3で「正しい判断が誰かを傷つける」場面での感情反応（罪悪感・回避衝動）を自己観察することが明日の準備になる。