今日のフォーカス
テーマ：課題定義・選択肢生成・意思決定フレームワークの3層——「観察」と「推論」を切り分け、問題領域に応じて型を選び、"誰が決めるか"まで設計する。
声の大きい要望をそのまま課題と誤認したPMを、Ladder of Inference（推論のはしご）で解剖し課題定義の検証ステップを設計する（Q1）。あらゆる判断に同じ合意形成プロセスを適用する新任VPを、Cynefinフレームワークの4領域（Simple/Complicated/Complex/Chaotic）で診断し、領域ごとに正しい型を選び直す（Q2）。ローンチ判断をめぐり3人のリーダーが「自分が決める」と信じ込み対立する組織で、DACIフレームワークによる意思決定権限の設計と、板挟みのシニアPMとしての対立収束を行う（Q3）。PM/CTO移行期に問われる「答える前に、何を・どう・誰が決めるかを設計する」メタ規律を3問で鍛える。
Ladder of Inference
観察データの選択→意味づけ→仮定の追加→結論、という各段階で無意識に情報が失われ・偏る。結論だけを受け取らず、生データまで遡って検証する。
Cynefinフレームワーク
問題領域はSimple/Complicated/Complex/Chaoticの4つ。領域ごとに「即実行」「専門分析」「実験して学ぶ」「まず行動して安定化」と正しい型が異なる。
DACI（意思決定権限）
Driver/Approver/Contributors/Informedで役割を明文化する。Approverを事前に1人決めておくことが、権限の曖昧さによる対立を防ぐ。
Q1
★★★☆☆ 基本
「観察」と「推論」を混同しない——課題定義のはしご（Ladder of Inference）
シナリオ — B2B プロジェクト管理SaaS企業（従業員110名） / プロダクトマネージャー（3年目）
セールスチームから「エンタープライズ顧客がCSVエクスポート機能を強く求めている」という要望が繰り返し上がってきた。あなたはこれを最優先課題と判断し、2ヶ月かけて開発・リリースした。しかしリリース後30日間の利用率は、対象のエンタープライズ顧客のわずか4%。振り返りミーティングで発端を遡ると、実は「四半期に2件、大口商談が失注した際に、顧客が『データをエクスポートできないから』と理由を挙げた」という2つの逸話に過ぎなかったことが判明した。あなたは「顧客が求めている」という結論に飛びつき、実際に何十社が本当に必要としているか、なぜ必要か（どんな業務フローのためか）を検証しないまま開発に着手していた。
問い
- このPMの思考プロセスにおいて、どこで「観察された事実」から「推論・結論」への飛躍が起きたか、Ladder of Inferenceの段階を用いて特定せよ
- 「顧客が求めている」という課題定義がなぜ不十分だったか、良い課題定義の要件（誰の・何が・どの程度の規模で・なぜ）に照らして指摘せよ
- 今後同様の要望が来た際、開発着手前に踏むべき「課題定義の検証ステップ」を設計せよ
Chris Argyrisの"Ladder of Inference"（観察可能なデータの選択→意味づけ→仮定の追加→結論→信念→行動、という無意識の飛躍のプロセス）を用いて、実務でよくある「声の大きい要望をそのまま課題と誤認する」失敗を構造的に見抜く力を鍛える。課題定義の質は、はしごのどの段階で立ち止まり検証したかで決まる。PM/エンジニアリードは、要望の"表面"と背後にある"実際のデータ規模・業務フロー"を区別できねばならない。
罠：声の大きいステークホルダー（セールス）の解釈をそのまま最終結論として受け取り、下位のはしご（実際の生データ）を遡って検証しない。逸話の件数と規模の大きさを混同する。
判断の軸：「結論から2段階以上下のはしごの生データに、自分は実際にアクセスしたか？」を常に問う。
① どこで飛躍が起きたか
1
観察データ
四半期に2件の失注商談で、顧客が「エクスポートできないから」と述べた2
意味づけ（選択的注目）
セールスが「これは頻出の不満だ」と一般化——ここで飛躍が始まる3
仮定の追加
「エクスポート機能があれば失注が減る」「これはエンタープライズ顧客全体の共通ニーズ」4
結論
「エンタープライズ顧客がCSVエクスポートを強く求めている」5
PMの行動
検証なしに最優先開発着手
「2件の逸話」から「全エンタープライズ顧客の強いニーズ」への飛躍は、意味づけ〜仮定の段階で起きた。PMは結論だけを受け取り、生データに遡らなかった。
② 良い課題定義の要件に照らした不十分さ
誰の
「エンタープライズ顧客」と一般化されているが、実際は2社限定。母集団規模が不明。
何が
「エクスポートできないこと」が失注の"直接原因"か"表面的理由"かが未検証（本当は価格や機能不足かもしれない）。
どの程度の規模で
全エンタープライズ顧客のうち何%が同じ課題を持つか未計測。
なぜ
エクスポートが必要な業務フロー（経理システム連携・監査対応等）が特定されていない。機能の"形"が正しいかも不明。
③ 検証ステップの設計
1. 生データへの遡及
声を上げた顧客・失注理由の一次情報（商談メモ、CSログ）に必ず自分でアクセスする2. 規模の定量化
同様のニーズが何%の顧客セグメントに存在するか、CRMやNPSコメントを横断検索3. Whyの深掘り
5 Whysで「エクスポートが必要な理由」を業務フローレベルまで掘り下げ、代替解決策（API・自動連携）も比較4. 仮説の明示化
「この機能を作れば◯%のエンタープライズ失注が防げるはず」という検証可能な仮説を文書化してから着手判断実践への応用
実務・キャリアへの展開
- プロダクトマネジメント：「声の大きい要望」への即応は信頼構築に見えるが、規模検証を欠くと工数の無駄を生む。ロードマップ判断は必ず一次データに遡る。
- エンジニアリードとの協働：エンジニアも要件の"はしご"を遡って質問する権利がある。「なぜこの機能が必要か」を聞くのは越権ではなく品質保証。
- グローバル文脈：異文化間では"意味づけ"の飛躍がさらに大きくなりやすい（言語・文化的コンテキストの違い）。生データの確認はグローバルチームでこそ重要。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q2
★★★★☆ 標準
Cynefinフレームワーク——「同じやり方」で全ての問題を解こうとする罠
シナリオ — フィンテック企業（決済インフラ・従業員150名） / 着任3ヶ月の新任VP Engineering
新任VPは、あらゆる重要判断に同じプロセスを適用している。「関係者を集め、外部専門家の意見を聞き、十分なデータ分析を行い、コンセンサスを得てから決定する」。このプロセスが、以下の3つの状況すべてに適用された。
| 状況 | 内容 | VPの対応 |
|---|---|---|
| A | 深夜、決済レイテンシ急上昇・取引失敗開始。原因不明 | 会議招集に30分、その間も失敗継続 |
| B | 老朽ゲートウェイ刷新。制約は明確・業界のベストプラクティスも確立済み | 3週間の外部コンサルワークショップ。結論は最初からシニアが提案していた内容 |
| C | 新興国進出。現地の決済習慣・規制が不明、前例なし、専門家も意見割れる | 「データが揃うまで保留」で3ヶ月停滞。競合に先を越された |
問い
- 状況A・B・CをCynefinフレームワークの4領域（Simple/Complicated/Complex/Chaotic）に分類し、理由を述べよ
- VPが「常に同じプロセス」を適用したことがそれぞれの状況でなぜ問題だったか、領域ごとの正しいアプローチと対比して説明せよ
- 3つの状況それぞれに対する具体的な次の一手をどう変えるか設計せよ
意思決定フレームワークの選択自体が、問題の"性質"に依存するという発想を鍛える。Dave SnowdenのCynefinフレームワークは、問題領域をSimple（明白・ベストプラクティスで即対応）／Complicated（専門知識で分析すれば正解に到達できる）／Complex（正解が事前にわからず、小さく試して創発を観察する）／Chaotic（分析している時間はなく、まず行動して安定化させる）に分ける。多くのリーダーは「丁寧なプロセス＝常に正しい」と誤解し、緊急対応が必要なChaotic状況に分析プロセスを持ち込んで被害を拡大させたり、逆に実験が必要なComplex状況を「データが揃うまで待つ」ことで機会を逃したりする。「意思決定の"型"は問題領域ごとに変えるべきだ」という発想の転換が核心。
罠：①Chaoticな状況に丁寧な合意形成プロセスを持ち込み初動が遅れる（状況A）。②Complicatedな問題を、既に専門家が答えを持っているのに外部コンサル起用で時間を浪費する（状況B）。③Complexな状況を「データが揃うまで待てば正解がわかる」と誤解し、実験せずに機会を逃す（状況C）。
判断の軸：まず領域を診断してから型を選ぶ。「いつも同じプロセス」はリーダーの安心材料にはなるが、状況適応の失敗を招く。
① 4領域への分類
状況A → Chaotic（混沌）
原因と結果の関係が不明で、被害が進行中。分析している時間的余裕がない。
Act → Sense → Respond：まず行動して安定化
状況B → Complicated（煩雑）
専門知識で分析すれば正解に到達できる。既にシニアエンジニアが答えを持っていた。
Sense → Analyze → Respond：専門分析で正解に到達
状況C → Complex（複雑）
正解は事前に存在せず、やってみて初めてわかる。実験・小さな賭けが必要。
Probe → Sense → Respond：試して学ぶ
（参考）Simple（明白）
誰が見ても正解が明らかで、既存のベストプラクティスをそのまま適用できる領域。
Sense → Categorize → Respond：即実行
② 同じプロセスが問題だった理由
| 領域 | VPが取った行動 | 正しいアプローチ | ギャップ |
|---|---|---|---|
| A: Chaotic | 会議招集→合意形成に30分 | 即座に行動（ロールバック・トラフィック遮断）でまず安定化、その後で原因分析 | 分析より先に行動すべき局面で合意形成を優先し、被害を拡大させた |
| B: Complicated | 3週間の外部コンサル起用 | 社内専門知識で十分分析可能。外部専門家は必要でも短期間で足りる | 既に社内に答えがあったのに、外部依存で時間を浪費した |
| C: Complex | データが揃うまで3ヶ月保留 | 小さく安価な実験（パイロット参入）を先に打ち、結果から学習 | 「待てば正解が見える」という前提が誤り。実験せず機会を逃した |
核心：Chaoticでは「行動が先、分析は後」、Complicatedでは「専門分析で正解に到達できる」、Complexでは「実験が分析の代わりになる」。3つとも異なる型が必要なのに、VPは唯一の型（合意形成プロセス）を機械的に適用した。
③ 具体的な次の一手
状況A（Chaotic）
自動フェイルオーバー・トラフィック遮断・直近デプロイのロールバックなど、影響を止める即時アクションを実行。会議招集は並行して行うが行動は止めない。安定後にポストモーテムでComplicatedな原因究明へ移行状況B（Complicated）
社内シニアエンジニアの提案をベースラインとして採用し、外部コンサルは「妥当性検証」という限定スコープ・短期間（1週間程度）で起用する。3週間のワークショップは過剰投資状況C（Complex）
「3ヶ月待つ」のではなく、限定予算・限定期間（1都市・1四半期）のパイロット参入を即座に設計。規制・決済習慣の仮説を明示し、結果から学習して本格展開の設計を調整実践への応用
実務・キャリアへの展開
- エンジニアリングリーダーシップ：インシデント対応（Chaotic）とアーキテクチャ意思決定（Complicated）と新機能の市場適合探索（Complex）は、根本的に異なる意思決定の型を要求する。
- 新興国・新市場展開：前例のない市場はほぼ常にComplex。「十分な市場調査を経てから」という姿勢は、Complicated用の型をComplexに誤用している。
- 組織設計：優れたリーダーは「今どの領域か」を診断してから型を選ぶメタスキルを持つ。「いつも同じプロセス」は一貫性という美徳に見えて柔軟性を犠牲にする。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
Q3
★★★★★ 応用
意思決定権限が曖昧な組織で「誰が決めるか」を設計する——DACIフレームワークと権力構造の狭間
シナリオ — D2Cフィットネスアプリ企業（従業員200名・シリーズC） / プロダクト部門のシニアPM
大型顧客獲得キャンペーンに合わせた新機能「AIパーソナルトレーナー機能」のローンチが3週間後に迫っている。しかしローンチの可否・タイミング・スコープをめぐって3人のリーダーが異なる主張をしている。CEO「投資家向けの発表があるから予定通りローンチしたい」。Head of Sales「大型顧客が機能デモを条件に契約したがっている。1日でも遅れれば契約が流れる」。Head of Product（あなたの上司）「QAで重大なバグが3件見つかっている。品質を担保せず出せば大規模な信頼失墜を招く」。3人とも「自分が最終決定権を持つ」と思い込んでいるフシがあり、過去にも同様の状況で誰が決めるか揉めたことがある。あなた（シニアPM）は板挟みになっている。ローンチまで残り3週間、意思決定の"内容"以前に、意思決定の"権限"自体が誰にあるかが不明確なまま時間が過ぎている。
問い
- なぜこの組織では「誰が決めるか」自体が問題になっているのか。意思決定権限の設計が存在しない組織で典型的に起きる機能不全を説明せよ
- DACI（Driver/Approver/Contributors/Informed）フレームワークを今回のローンチ判断に適用し、各役割に誰を割り当てるべきかを理由とともに設計せよ
- フレームワークを事後的に導入するだけでは対立は解消しない場合がある。板挟みのシニアPMとして、対立をどう収束させ、将来同様の対立を防ぐ仕組みをどう提案するか、EQ的配慮も含めて述べよ
意思決定"フレームワーク"は、選択肢の分析手法（期待値・マトリクス等）だけでなく、「誰が決めるか」という意思決定権限の設計も含む。DACI/RAPIDのようなフレームワークが存在しない組織では、複数のリーダーが暗黙に「自分に決定権がある」と信じ、対立が"内容"ではなく"権限"のレベルで膠着する。この問題は、①権限設計の欠如がなぜ機能不全を生むかの構造理解、②DACIを実際のケースに適用する実務スキル、③フレームワーク導入そのものが政治的な行為であることを踏まえ、板挟みのシニアPMという非権力ポジションから対立を収束させ、恒久的な仕組みを設計する調整力——を統合的に鍛える。正解のない権力構造の中でも、構造設計によって将来の対立コストを下げられるという発想が核心。
罠：①「みんなで合意すれば決められる」という幻想（実際は声の大きい人・地位の高い人が押し切る）。②Approverを曖昧にしたまま議論を続け、正当性のない決定が生まれる。③権限設計を今回の議題に矮小化し、恒久的な仕組みに昇華させない。
判断の軸：誰が最終責任（結果への説明責任）を負うべきかを起点にApproverを決める。他の全員はContributor/Informedとして関与の質を上げる。
① なぜ「誰が決めるか」自体が問題になるのか
意思決定権限（decision rights）が明文化されていない組織では、地位・声の大きさ・その場の力学によって"事実上の決定者"が変わる。CEO・Sales・Productがそれぞれ「自分の領域だから自分が決める」と信じるのは、いずれも部分的に正当（CEOは会社全体の説明責任、Salesは契約責任、Productは品質責任を負う）だが、「誰が最終的にYES/NOを言うか」が定義されていないため、3人の"部分的な正当性"が衝突したまま解消されない。
(a) 先延ばし
誰も譲らず時間だけが過ぎる
(b) 事実上の押し切り
声の大きい者・地位の高い者が勝つ（最も正当な判断とは限らない）
(c) 決定後の蒸し返し
Approverが不明確でコミットメントの所在も不明確
② DACIの適用設計
Driver
シニアPM（あなた）
ローンチ判断に必要な情報（QAの重大度、契約条件、投資家発表の柔軟性）を集約し、意思決定の場を設計・推進する立場。決定権は持たないがプロセスオーナー。
Approver
Head of Product
ローンチ判断の核心は「品質リスクを許容できるか」であり、製品の中長期的な信頼性に直結する。ビジネス上の圧力はContributorとして重要な入力だが、最終的なGo/No-Go責任は品質説明責任を負う立場に置くのが筋。
Contributors
CEO・Head of Sales・QAリード
それぞれ投資家説明責任・契約責任・品質検証責任という専門知識/懸念を提供。しかし最終決定権は持たない。
Informed
投資家対応チーム・カスタマーサクセス
決定結果を受けて自分たちのアクション（発表内容の調整、顧客への説明）を行う必要がある人たち。
重要なのは「誰をApproverにするか」自体に唯一の正解はなく、事前に1人に決めておくことが機能不全を防ぐという点。今回はQA重大バグ3件という具体的なリスクがある以上、品質責任者をApproverに置く提案が合理的だが、CEOが「投資家発表を優先し自分がApproverであるべき」と主張するなら、それも一つの正当な設計選択——ただし議論の"前に"決めておく必要がある。
③ 対立の収束と恒久的な仕組みの提案
今回の収束
まず3人それぞれの懸念を"正当なものとして"個別に承認する（EQ的配慮）。CEOには「投資家への説明責任は理解している」、Salesには「契約が流れるリスクの深刻さは理解している」、Productには「品質リスクを軽視していない」と伝えた上で、「今回は"誰が最終決定するか"がそもそも決まっていないことが対立の根本原因」という診断を共有し、DACI設計そのものを議題にする（内容の議論の前に、プロセスの議論を先に行う）。3人が同意すればApprover設計の議論に移り、それでも割れる場合はより上位（取締役会等）に最終Approverの指名をエスカレーションする。
QAバグの代替案
対立を単純な二択（ローンチ/延期）にせず第三の道を設計する——「顧客デモに影響する1件のみ修正し残り2件は既知の制約としてリリースノートに明記した限定ローンチ」「大型顧客向けには先行デモ環境を提供し、投資家向け発表は予定通り行うが一般ローンチは1週間ずらす」など、CEO・Sales・Productそれぞれのmust-haveを部分的に満たす選択肢を交渉のテーブルに乗せる。
恒久的な仕組み
①主要な意思決定タイプ（ローンチ判断・予算配分・採用等）ごとに事前にDACIを定義し文書化する。②Approverが複数存在するように見える境界ケースのために「エスカレーションパス」を明文化する。③繰り返し発生する意思決定は判断基準（must-have品質ゲート・契約上のリスク許容度）を事前にプレイブック化——これにより次回は「誰が決めるか」で消耗せず「基準に照らしてどう決めるか」に集中できる。
実践への応用
実務・キャリアへの展開
- プロダクトマネジメント：PM/シニアPMは決定権を持たないことが多いが、DACIのようなプロセス設計を提案する"Driver"としての価値は非常に高い。権力を持たない立場からでも構造設計で組織の意思決定の質を上げられる。
- 組織設計・スケールするスタートアップ：従業員数が増えるにつれ「誰が決めるか」が不明確になる摩擦は指数関数的に増える。DACI/RAPIDの早期導入は組織のスケーラビリティに直結する投資。
- リーダーシップ・キャリア：板挟みのポジションから対立を収束させる経験は、PM→CTO/経営への移行期に極めて重要な訓練。「誰が正しいか」ではなく「誰がどう決める仕組みか」に問題を再定義する視点が対立を建設的な構造議論に変える。
- グローバル文脈：多国籍・多拠点組織では文化によって「誰が決めるべきか」の暗黙の前提が異なる（トップダウン文化 vs 合意形成文化）。DACIは文化差を超えた共通言語として機能する。
自己評価（解答後に記入）
自分の考え・解答メモ：
気づき・メモ：
今日のまとめ・次回へ
次回への接続（明日: EQ-B 対人スキル・関係管理）
今日のQ3で扱った「板挟みのシニアPMが3人のリーダーの懸念をそれぞれ正当なものとして承認する」対応は、まさにEQ-Bの核心。ロジックで設計した権限構造（DACI）を、人間関係を壊さずに導入するための"伝え方"——深い傾聴・共感・影響力の実践を明日は鍛える。