今日のフォーカス
テーマ：課題定義・選択肢生成・意思決定フレームワークの3層——疑わしい原因に飛びつく前に問題の輪郭をIS/IS NOTで精密に定義し、意思決定は「誰が・どう決めるか」を感覚でなく構造で選び、そもそも一度で解決できる「問題」なのか、永続的に管理すべき「両極」なのかを見分ける。
デプロイ直後の性能劣化に「直近の変更が原因だ」と飛びつくチームを、Kepner-TregoeのIS/IS NOT分析で問題の輪郭を精密に再定義させる（Q1）。オンコール変更を独断で決めて反発を受け、クラウド移行を全員参加にして議論を発散させたVPが、Vroom-Yetton-Jagoモデルで「情報の所在」と「コミットメント要件」から意思決定スタイルを選び直す（Q2）。集権化か分権化かの決着を迫られるCEOが、Polarity Managementで「そもそも一度で解決すべき問題なのか」を問い直し、両極を継続的にマネジメントする設計へ転換する（Q3）。PM/CTO移行期に問われる「答える前に、何を・どう・そもそも何を決めるべきかを設計する」メタ規律を3問で鍛える。
Kepner-Tregoe問題分析
IS（起きている）とIS NOT（起きていない）をWhat/Where/When/Extentで対比し、疑わしい手がかりへの飛びつきを防いで問題の輪郭を精密に定義する。
Vroom-Yetton-Jagoモデル
情報の所在・コミットメント要件・問題の構造化度から、独断型〜参加型のどの意思決定スタイルが適切かを構造的に診断する。
Polarity Management
一度決めれば終わる「問題」と、永続的に管理すべき「両極」を区別する。両極では勝敗を決めず、上側の恩恵を活かし下側の弊害を早期検知する。
Q1
★★★☆☆ 基本
Kepner-Tregoe問題分析——「先週のデプロイが原因」に飛びつく前に、IS/IS NOTで問題を精密に輪郭づける
シナリオ — B2Bデータ分析SaaS「MetricPilot」（従業員60名・エンタープライズ顧客120社） / プラットフォームエンジニアリングリード
先週火曜日のデプロイ以降、一部の大口顧客からダッシュボードの読み込みが遅いという苦情が入り始めた。チームメンバーの多くは「先週のデプロイが原因に違いない」と即断し、ロールバックを提案している。しかしあなたが顧客リストを確認すると、同じデプロイを受けた顧客のうち約8割は問題を報告していない。さらにSlackの過去ログを遡ると、ロールバック対象のデプロイより前の3週間にも、同様の遅延報告が散発的に（週1〜2件のペースで）上がっていた記録が見つかった。
問い
- Kepner-Tregoe問題分析のIS/IS NOTフレーム（What/Where/When/Extentの4次元）で、この問題をどう精密に定義し直すべきか。「デプロイが原因」という仮説への飛びつきがなぜ危険かを含めて説明せよ
- 「デプロイが原因」という仮説を、IS/IS NOTの比較（同じデプロイを受けたが問題が出ていない顧客との違い）でどう検証するか、具体的な比較質問を設計せよ
- チームが実際に取るべき次の一手（切り分け調査の設計）を提案せよ
Kepner-Tregoeの問題分析は、「何が起きているか（IS）」と「起きていてもおかしくないのに起きていないこと（IS NOT）」を並べて比較することで、原因の輪郭を精密に絞り込む古典的手法。実務では「直近の変更」という最も目立つ疑わしい対象に飛びつき、実際にはそれと無関係な問題を見逃す、あるいは逆に本当は無関係な変更を巻き戻して時間と信頼を失う、という失敗が頻発する。目立つ手がかりに飛びつく前に、問題を"何が・どこで・いつ・どの範囲で"起きているか（そして起きていないか）を精密に輪郭づけるという、課題定義の基礎体力を鍛える。
罠：「直近の変更」という時間的に目立つ手がかりだけで原因を即断し、実際には無関係な変更をロールバックして時間を浪費する。デプロイ前から散発していた既存の兆候（3週間の遅延報告）を「別の問題」として無視してしまう。
判断の軸：「この仮説（デプロイ原因説）は、IS（問題がある顧客）とIS NOT（問題がない顧客）の違いを説明できるか」を問う。説明できない仮説は、たとえ時間的に近く見えても棄却対象になる。
① IS/IS NOTでの問題の再定義
| 次元 | IS（起きている） | IS NOT（起きていない） |
|---|---|---|
| What | ダッシュボードの読み込み遅延 | データ欠損・エラー画面・クラッシュ（遅延のみで機能停止はない） |
| Where | 一部の大口顧客（エンタープライズ層） | 同じデプロイを受けた顧客の8割（問題報告なし） |
| When | 先週デプロイ以降に苦情が増加。ただし類似報告はデプロイの3週間前から散発 | デプロイ直後に一斉発生ではない（単純なデプロイ起因なら対象顧客全員でほぼ同時発生するはず） |
| Extent | 苦情件数は週数件〜十数件、大口顧客に偏る | 全顧客の一律の性能劣化ではない |
「先週のデプロイが唯一の原因」という仮説には矛盾がある。デプロイ前から同様の兆候が存在していたこと（When次元のIS NOTとの不一致）、同じデプロイを受けた顧客の大半が無症状であること（Where次元のIS NOTとの不一致）は、単純な「デプロイ原因説」では説明できない。時間的に近いという理由だけで原因を即断することが最大の罠であり、IS/IS NOTの対比によってその矛盾を可視化できる。
② デプロイ原因説の検証方法
データ量/顧客規模の違い
苦情を上げている顧客は、データ量が特に大きい・クエリ数が多いエンタープライズ層に偏っていないか（＝デプロイ由来ではなくスケール由来の可能性）アクセスパターンの違い
苦情顧客は特定のダッシュボード機能（重いクエリを含むもの）を頻繁に使っていないか地域/インフラの違い
苦情顧客が特定リージョンのインフラに偏っていないか（デプロイと無関係なインフラ要因の可能性）時系列の違い
デプロイ前3週間の遅延報告顧客リストと今回の苦情顧客リストは重なっているか（重なっていればデプロイは真因ではなく既存問題の悪化・可視化のトリガーに過ぎない可能性）③ 次の一手
比較表の作成
苦情のあった顧客とない顧客の比較表（データ量・クエリパターン・リージョン・過去の遅延報告有無）を即日作成する
クエリログ調査
ロールバックを即断せず、まずは苦情顧客のクエリログを直接調査し、遅いクエリの実行計画・データ量を確認する
既存兆候との突合
デプロイ前3週間の遅延報告顧客リストと今回の苦情顧客リストを突き合わせ、重複があれば「既存のスケール限界が別要因で表面化した」という仮説を優先検証する
顧客への一次連絡
検証と並行して影響の大きい顧客へ原因調査中である旨を連絡し、ロールバックはIS/IS NOTの検証結果が出てから判断する
実践への応用
実務・キャリアへの展開
- インシデント対応全般：「直近の変更」に飛びつくのは人間の認知的な癖（時間的近接性バイアス）。IS/IS NOTの型を持っておくと、パニック下でも機械的に問題を輪郭づけられる。
- プロダクトマネジメント：「特定セグメントだけで解約率が上がっている」といった問題も、IS/IS NOT（どのセグメントは上がっていないか）を先に埋めることで闇雲な原因探索を防げる。
- グローバル文脈：多国籍チームでのインシデント対応では「何が起きているか」の共通認識がないまま各拠点が独自に原因究明を始めがち。IS/IS NOT表を共有ドキュメント化することで拠点をまたいだ議論の土台になる。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q2
★★★★☆ 標準
Vroom-Yetton-Jagoモデル——「みんなで決めるべきか、自分で決めるべきか」を感覚でなく構造で判断する
シナリオ — 受託開発スタートアップ（従業員25名） / VP of Engineering
あなたは直近2つの意思決定で対照的な進め方をした。1つ目は「オンコールローテーションを週次から隔週に変更するか」という決定を、エンジニアに相談せず24時間以内に一人で即決した。発表後、複数のエンジニアから「生活に関わる話なのに相談もなく決められた」と強い不満が上がった。2つ目は「新しいクラウドベンダーへ全面移行するか」という、コスト構造・移行リスクの詳細をあなたともう一人のシニアエンジニアしか正確に把握していない技術的に複雑な決定を、チーム全員参加のワークショップ形式で3週間かけて議論した。結果、議論は発散し、技術的に不十分な折衷案に着地しかけている。
問い
- Vroom-Yetton-Jagoモデルの主要な診断的問い（決定の質要件・メンバーのコミットメント要件・リーダーの情報十分性・問題の構造化度・受容される見込み・目標の一致度・対立の可能性）に照らし、この2つの決定それぞれについて、実際に取ったプロセス（独断的 vs 参加的）が適切だったかを診断せよ
- なぜ「オンコールローテーション変更」は参加型が適しており、「クラウドベンダー移行」はより指示型（または個別相談型）が適していたのかを、情報の所在とコミットメントの必要性の観点から説明せよ
- 今後の意思決定に向けて、あなたがVPとして「意思決定スタイルをどう選ぶか」のプロセスをどう設計するか提案せよ
Vroom-Yetton-Jagoモデルは、「独断で決めるか」「相談してから決めるか」「合意形成で決めるか」というリーダーの意思決定スタイルを、感覚や性格ではなく、決定の性質（質要件・コミットメント要件・情報の所在など）から構造的に選ぶための診断ツール。実務でよくある失敗は、「本来コミットメントが重要な決定を独断で決めてしまう」逆と、「本来リーダーの専門知識が重要な決定を過度に参加型にしてしまう」逆の両方。技術的判断力はあってもマネジメントスタイルの選択に無自覚なエンジニアリングリーダーが陥りやすい罠を診断させる。
罠：「生活・働き方に関わる決定＝民主的に決めるべき」「技術的に複雑な決定＝みんなで議論すべき」という直感的な思い込みが、実際には逆に働く場合がある。コミットメントが必要な決定を独断で決めると反発が起き、専門知識が偏在する決定を参加型にすると議論が発散し質が下がる。
判断の軸：「この決定の質は、情報を持つ人が一人で決めても十分に高いか」「この決定の実行には、決定に関与しなかった人の納得なしでも十分な協力が得られるか」の2つの問いで、スタイルの位置を決める。
① 2つの決定の診断
| 診断項目 | オンコールローテーション変更 | クラウドベンダー移行 |
|---|---|---|
| 決定の質要件 | 中程度（複数の妥当な選択肢がありうる） | 高い（コスト・リスクの技術的精査が結果を大きく左右する） |
| コミットメント要件 | 非常に高い（生活リズム・当番負荷に直結し、納得なしでは不満・離職リスクに直結） | 中程度（実行は一部エンジニアが担い、日常業務への影響は限定的） |
| リーダーの情報十分性 | 高い（頻度・負荷のトレードオフはVP単独でも判断可能） | 低い（コスト構造・移行リスクの詳細は自分と1名のシニアにしか偏在していない） |
| 問題の構造化度 | 構造化されている（選択肢が明確） | 相対的に非構造的（未知のリスクが多い） |
| 対立の可能性 | 低い〜中（好みの違い程度） | 低い（技術的合意は取りやすいテーマ） |
オンコールローテーションは、情報はVPだけで十分足りるが、コミットメント要件が極めて高い決定。にもかかわらず独断で決めたため、実行段階での納得感の欠如という代償を払った。クラウドベンダー移行は、コミットメント要件は中程度だが情報がVPと1名のシニアに偏在する専門性の高い決定。にもかかわらず全員参加のワークショップにしたため、情報を持たないメンバーの議論が発散し、決定の質が下がった。
② なぜ逆が適切だったか
指示型が適する条件
情報がリーダー（と一部専門家）に偏在し、コミットメントの必要性が実行担当者に限定される決定。クラウドベンダー移行はここに該当。全員参加にすると情報を持たないメンバーの発言が議論の質を下げ、時間も浪費する。
相談型が現実的な着地点
情報はリーダーで十分だがコミットメントが不可欠な決定。オンコールローテーションはここに該当。決定の"質"はほぼ変わらないが、"実行の成否"がメンバーの納得感に直結する。
参加型（合意形成）が適する条件
情報がメンバー側に分散し、かつコミットメントも不可欠な決定。今回の2ケースはどちらもここではなく、参加型を一律の"良いマネジメント"として適用したこと自体が誤り。
③ 意思決定スタイルを選ぶプロセスの設計
1. 着手前チェック
「①この決定の質を左右する情報を自分は十分持っているか」「②実行にはメンバーの納得・協力が不可欠か」の2問を自問する簡易チェックリストを使う2. マッピングの明文化
①YES・②NOなら指示型、①NO・②YESなら参加型、両方YESなら相談型、というマッピングをチームにも共有する3. 理由を添えて伝える
決定を発表する際「なぜこのプロセスを選んだか」を一言添える習慣を持ち、独断的に見える決定でも納得を得やすくする実践への応用
実務・キャリアへの展開
- エンジニアリングマネジメント全般：「みんなで決めるのが良いマネージャー」という思い込みを外し、決定ごとにスタイルを選び分ける規律は、意思決定の速度と質の両方を守る。
- PM/CTOへの移行：意思決定の対象が技術的判断から組織運営に広がるほど、情報の所在とコミットメント要件の見極めが重要になる。すべて合意形成にすると遅くなり、すべて独断にすると実行力が落ちる。
- グローバル文脈：参加型を好む文化と指示を明確に求める文化が混在するグローバルチームでは、同じスタイルの選択が受け止められ方を大きく左右するため、事前の期待値合わせが重要になる。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q3
★★★★★ 応用
Polarity Management——「解決すべき問題」ではなく「マネジメントすべき両極」を見分ける
シナリオ — 急成長中のプロダクト企業（従業員90名・過去1年で従業員数2倍） / CEO
組織拡大に伴い、各チームが独自に技術選定・意思決定を行う分権的な運営方針を進めてきた。しかし直近、重複したツール導入・インフラの断片化・チーム間のナレッジ分断が顕在化し、経営陣内で意見が割れている。CFOを中心とする一派は「もっと中央集権的に技術標準を統制すべきだ」と主張し、創業初期のエンジニアを中心とする一派は「分権こそが自律性とスピードを生んできた。統制を強めればイノベーションが死ぬ」と譲らない。あなたはこれを「集権化するか、分権を守るか」という一度決めれば終わる意思決定問題として捉え、次の取締役会（6週間後）までに結論を出すよう迫られている。
問い
- なぜこの状況は「問題（Problem）」として一度解決すれば終わるものではなく、「ポラリティ（Polarity＝両極性）」として捉えるべきなのか、Problem SolvingとPolarity Managementの違いから説明せよ
- Polarity Map（集権化の上のメリット／行き過ぎた集権化の下のデメリット、分権化の上のメリット／行き過ぎた分権化の下のデメリット、という4象限）を、このケースに即して具体的に埋めよ
- 6週間という期限、経営陣内の対立という制約の中で、CEOとしてこの両極を「解決」するのではなく「マネジメント」する提案を、早期警戒シグナルとアクションステップの設計を含めて行え
Barry JohnsonのPolarity Management理論は、「一度選んで終わりの問題」と「永続的に管理し続けるべき両極（トレードオフの二極）」を区別する意思決定フレームワーク。集権化 vs 分権化、スピード vs 品質、個人の自律性 vs 組織の一貫性といった対立は、多くの場合どちらか一方に"正解"があるのではなく、行き過ぎればどちらも害になる両極であり、振り子を意図的に管理し続けることが求められる。「今回はどちらが正しいか決めよう」という一度きりの意思決定フレームで臨むこと自体が誤りである、というフレームそのものを問い直す応用力を試す。正解のない状況を「決めて終わらせる」のではなく「持続的にマネジメントする」設計に転換できるかが核心。
罠：「今回は集権化派が勝った/分権化派が勝った」という一度きりの決着をつけようとすることで、勝った側の行き過ぎ（過剰統制によるイノベーション停滞、または過剰分権による断片化の再発）が数ヶ月後に必ず再燃する。
判断の軸：「この決定を下した後、逆側のデメリットが出始めたことをどうやって早期に察知するか」を、決定そのものと同じレベルで設計できているかを問う。
① なぜPolarityとして捉えるべきか
Problem Solvingは「AかBか」を選び切れば恒久的に解消する構造（例：バグを直せば直る）に適用する。しかし集権化と分権化は、どちらも独立した"正解"ではなく、相互依存する両極である。分権化を選び切って統制をゼロにすれば断片化が再発し、集権化を選び切って統制を最大化すれば、当初分権化が生んでいた自律性・スピードが失われる。つまり「一度決めれば終わる問題」ではなく、どちらの極に振れすぎても組織にダメージを与える、永続的に管理し続けるべき緊張関係であり、この状況を「決着をつけるべき問題」として扱うこと自体が、経営陣の対立を不必要に先鋭化させている。
② Polarity Mapの4象限
集権化
分権化
上（メリット）
技術標準の統一・重複投資の削減・ナレッジ共有の効率化・セキュリティガバナンスの一貫性
上（メリット）
各チームの意思決定速度・現場に最適化した技術選定・当事者意識とイノベーションの創出・経営層のボトルネック回避
下（行き過ぎのデメリット）
現場の意思決定速度低下・画一化によるチームごとの最適解の喪失・官僚化・エンジニアの当事者意識低下
下（行き過ぎのデメリット）
ツールの重複・インフラの断片化・ナレッジの分断・新メンバーのオンボーディングコスト増大・セキュリティ統制の欠如
現在の状況は「分権化の下（デメリット）」がすでに顕在化している状態。ここで集権化に完全に振り切ると、今度は「集権化の下」（現場の意思決定速度低下・当事者意識の喪失）が数ヶ月後に再燃するリスクが高い。
③ CEOとしてのマネジメント提案
議題の再フレーミング
取締役会には「集権化か分権化かを選ぶ」議題ではなく、「両極を継続的にマネジメントする仕組みを導入する」議題として再フレーミングする
層の切り分け
セキュリティ・データガバナンス・コア基盤インフラなど全社リスクに直結する層は最小限の標準化（集権化）を導入し、アプリケーション層の技術選定など現場最適化が価値を生む層は分権のまま残す、部分的な集権化を設計する
早期警戒シグナル
集権化側は「新技術導入までのリードタイム」「当事者意識サーベイスコア」の悪化を、分権化側は「重複ツールの数」「オンボーディング所要日数」の悪化を指標化し、四半期ごとにレビューする
振り子を戻す責任者
どちらかの下側の兆候が閾値を超えたら誰がどう介入するか（例：CTOが技術標準委員会を招集する）をあらかじめ決めておく
6週間への対応
「今回はコア基盤層のみ最小限の標準化を先行導入し、残りは四半期ごとに指標を見ながら振り子を調整する」という段階的提案で、期限内に具体的な一歩を示しつつ恒久的な決着は急がない
実践への応用
実務・キャリアへの展開
- 組織設計全般：スピード vs 品質、個人の裁量 vs 組織の一貫性、成長投資 vs 収益性など、経営の多くの対立軸はPolarityであり、一度の意思決定で"勝敗"をつけようとする姿勢自体が組織を消耗させる。
- エンジニアリング組織：マイクロサービス化 vs モノリス回帰、コードレビューの厳格化 vs 開発速度なども同型の両極構造を持つ。CTOへの移行期に「今回はどちらが正しいか」ではなく「両方の恩恵をどう共存させるか」という発想の転換が求められる。
- グローバル文脈：本社主導のグローバル標準化 vs 現地法人の裁量という多国籍企業特有の対立も典型的なPolarity。文化的に「決着をつけたがる」経営スタイルの地域では、Polarity Managementの発想そのものを丁寧に導入する対話が必要になる。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
今日のまとめ・次回へ
次回への接続（明日: EQ-B 対人スキル・関係管理）
今日のQ2で扱った「独断で決めて反発を受けた」「参加型にして議論が発散した」という2つの失敗の背後にある、メンバーとの信頼構築・納得形成の技術に直結する。決定プロセスの選び方（Thinking）だけでなく、決定を伝え、納得を得る対話そのもの（EQ）を明日は鍛える。