今日のフォーカス
発言しない会議の「本当の原因」を5 Whysで掘り下げる（Q1）、不完全なデータと競合プレッシャー下でローンチ判断をType1/Type2で設計する（Q2）、自分が主導した制度の欠陥を認めてIKEA効果・サンクコストバイアスに抗う（Q3）。PM/CTO移行期に最も問われる「解く前に問いを設計する力」を3問で鍛える。
問題の3類型（発生型・設定型・潜在型）
発生型: 基準から外れた問題（会議で誰も発言しない）。設定型: より高い基準を目指す問題（制度の刷新）。潜在型: まだ顕在化していない問題（組織への不信の種）。類型によってアプローチが変わる。
Bezosの「Type1 / Type2意思決定」
Type1（不可逆）: 取り消せない決定→慎重に。Type2（可逆）: やり直しがきく決定→素早く決めて修正。多くの人がType2をType1のように扱い意思決定が遅延する。段階的ローンチで「Type1のように見える判断をType2に変換」できる。
Heifetzの「技術的課題 vs 適応課題」
技術的課題: 既知の解決策がある（定義の明確化、設計修正）。適応課題: 人の信念・価値観・文化の変化が必要（組織の不信、心理的安全の欠如）。適応課題を技術的課題として扱うと失敗する。
毎週月曜日の全体朝会「振り返り」のコーナーで、直近3ヶ月にわたって誰も手を挙げない。司会のVP Engineeringが一人で話して終わる状況が続いている。VP Engineeringは「チームの士気が低い。もっとエンゲージメントを高めよう」と言い、来週から全員1分スピーチを義務付けると発表した。あなたはその義務化に違和感を感じているが、まだ言語化できていない。
- 「誰も手を挙げない」という症状に対して、VP Engineeringが仮定している問題定義（原因）を1つ特定し、その問題定義が誤っている可能性を2つ示せ
- 5 Whysを用いて「誰も手を挙げない」の根本原因を探れ。少なくとも4レベルまで掘り下げること
- ①と②を踏まえて「最初に検証すべき問い」を1文で設計し、検証に必要な情報と収集方法を示せ
① VP Engineeringの問題定義と反証
② 5 Whys（5レベル）
③ 最初に検証すべき問いと収集方法
1on1ヒアリング（非匿名）
「朝会で発言しないのはなぜか？」をチームメンバー3〜5名に率直に聞く。前提: 1on1の心理的安全が確保されていること。直接の理由を言葉で得られる。
匿名アンケート（全員）
「朝会に何を期待しているか」「何があれば話しやすいか」を3択＋自由記述で収集。匿名性が本音を引き出す。士気が低いか構造が悪いかを区別できる。
観察データ（Slack/Notion）
全員が参加しているSlackやNotionの議事録コメントは活発か？エンゲージメントが低いのが会議だけなら構造問題。全体的に低ければ士気問題。
実践への応用
実務・キャリアへの展開
- エンジニアリングリード：チームの「静かな問題（誰も手を挙げない・質問が来ない）」は、士気ではなく会議設計・関係の安全性の問題であることが多い。まず5 Whysで降りてから対策を打つ。
- スタートアップ経営：全体会議の設計は「情報共有ツール」から「組織の心理的安全を醸成する場」まで機能が異なる。目的が変われば設計も変える。
- グローバル文脈：日本・東アジア圏のメンバーは「大人数の前での自由発言」に特に不利。ラウンドロビン・事前コメント・匿名投票などの構造介入が均質化に有効。
モバイルアプリ購入フローのリニューアル「Project Nova」がA/Bテスト4週間（ユーザー5%）を終えた。コンバージョン率+6.3%（p=0.031・有意）だが、平均注文額-2.1%（非有意・p=0.18）、アプリクラッシュ率+0.4pp（修正に2〜3週間）、NPS+8pt（N=180・非有意）。CEOから「競合他社が先週似たフローをリリースした。今週中に全体ローンチを決めてほしい」と圧力。エンジニアリングリードは「クラッシュ率が高いまま100%ローンチはリスクが高い」と言う。あなたには最終決断の権限がある。
- この意思決定に存在する「不確実性の種類」を3つ特定し、各不確実性が意思決定に与える影響を示せ
- Bezosの「Type1/Type2意思決定フレームワーク」を適用し、このローンチ判断の可逆性を評価せよ。さらに「決める時点と情報量の最適バランス」の観点からあなたが取るべきアクションを設計せよ
- CEOへの回答を設計せよ。「今週中に全体ローンチ」に対して即答しない場合、何をどのような順序でどのように伝えるか（最初の3文をセリフ形式で含めること）
100%ローンチ後のロールバックは大規模UX混乱・コスト・信頼損失が伴う。「すぐ戻せる」は楽観的すぎる。
20%→50%→100%の段階的ローンチに設計すれば、判断を可逆にできる。この「変換設計」がPMの腕の見せどころ。
① 不確実性の3種類と意思決定への影響
影響：「全体ではプラスか」に確信が持てない。平均注文額低下が本物なら収益を相殺する可能性。
影響：100%ローンチ後にクラッシュが大規模発生した場合のリカバリー速度・コストが不明。
影響：CEOの圧力が感情的な損失回避バイアスによる可能性があり、急ぐ合理的根拠の検証が先決。
② Type1/Type2評価と最適アクション
大規模UIロールバックはユーザー体験の混乱・開発コスト・信頼への影響が大きく、「すぐ戻せる」は楽観的。クラッシュ大規模化後のリカバリーは遅い。
20%→50%→100%の段階設計なら、問題発生時に即ロールバックできる。「不可逆に見える判断をType2に変換」することがPMの設計力。
- 今週中（2日以内）：クラッシュ率の原因特定と修正見積もりを再確認。競合リリースによる自社流入・CVへの実際の影響データを収集。
- 今週末（5日以内）：20%段階的ローンチを開始。72時間モニタリング実施（クラッシュ率・CVR・AOV）。
- 2週間後：問題なければ50%→3週間後100%。クラッシュ再発時は即ロールバック。
③ CEOへの回答（セリフ形式）
「山田さん、競合の動きに対してすぐ動きたいというのは完全に理解しています。一点だけ確認させてください——新フローでクラッシュ率が+0.4pp増加しており、このまま100%ローンチすると週間GMVの1〜2%に当たる注文が影響を受ける可能性があります。今週中に20%ローンチを開始し、72時間のモニタリング後に段階的に拡大する案があれば、リスクを管理しながら競合へのアクションを今週取れます。この方向で進めてよいでしょうか？」
実践への応用
実務・キャリアへの展開
- PMからCTO移行期：「今週中に決めろ」に対して「もう少し情報が必要」と「今週中に安全な動き方を設計する」は全く異なる。後者がPMとCTOの違い。
- スタートアップ：「完璧なデータが揃うまで待つ」は機会損失。「不完全な情報で最善の判断をするプロセス」を設計することが経営者の仕事。
- グローバル文脈：多地域展開では「段階的ローンチ」が標準。地域ごとのロールアウトで技術的リスクを隔離しながらビジネスを進める方法はグローバルPMの必須スキル。
6ヶ月前から外部コンサルと共同設計した「技術力・影響力・成長・協働」の4軸評価制度を来月から全社展開予定。先週3つのことが同時に起きた：①シニアエンジニアの村上さん（社歴4年・インフォーマルリーダー）が「影響力軸の定義が曖昧すぎて恣意的評価になる。信頼できない」と1on1で言った。②匿名サーベイ（回答率71%）で「納得」32%・「懸念」48%・「どちらでもない」20%。③CEOから「来月ローンチを予定通り進めてほしい。全社人事統一がかかっている」とメッセージ。
- 村上さんの懸念は「技術的課題」か「適応課題」か、またはその複合かを判断し根拠を示せ
- 「予定通りローンチ」「延期して全面見直し」「条件付き部分展開」の3択をリスク・ベネフィット・ステークホルダー影響で比較し、あなたの判断を示せ（IKEA効果・サンクコストにも言及）
- 村上さん・エンジニアチーム全体・CEOにそれぞれ伝えるべき内容と順序、および「あなたが守る一線」を言語化せよ。このプロセスで示したいリーダー像を1文で述べよ
技術的課題 vs 適応課題（Heifetz）
「影響力軸の定義が曖昧」→ ルーブリックの整備・言語化という設計変更で対処できる。解決策は既知。
「評価者への不信」「設計プロセスへの参加感の欠如」→ 組織文化・関係の変化が必要。ルーブリック修正だけでは解けない。
① 技術的課題か適応課題か
| 要素 | 種別 | 根拠 |
|---|---|---|
| 「影響力軸の定義が曖昧」 | 技術的課題 | 定義の言語化・ルーブリック整備という設計変更で対処できる |
| 「上司次第で恣意的に評価される」 | 適応課題 | 評価者への信頼・プロセスの公正さへの信念が変わらないと、定義を明確化しても不信が続く |
| 「信頼できない」 | 適応課題（アイデンティティ水準） | 「正当に評価されるか」はキャリアの尊厳に関わる問いであり、ルーブリック修正だけでは届かない |
| サーベイ48%が懸念 | 適応課題（組織文化） | 1人の懸念でなく組織的懐疑——設計プロセスへの参加感の欠如という文化的問題 |
② 3択の比較と判断
IKEA効果：6ヶ月かけて作った制度は「良いもの」に見えるが、48%懸念という外部データが設計の問題を示している。自分の作品を守る衝動に気づき、データに従う。
サンクコスト：「ここまで投資した」という理由でローンチを急ぐことは、さらに大きなコスト（制度の失敗・組織の不信）を生む。サンクコストは未来の判断基準にしない。
- 「影響力軸」の定義を村上さんら3〜5名のシニアエンジニアと共同で再定義（2週間）
- 共同設計した定義を含む制度を1チーム（30名以内）で試験展開（1ヶ月）
- 試験展開後サーベイを再実施し「納得率65%以上」で全社展開
- CEOには「来月から一部チームで先行展開を開始、全社展開を6週間後に」と伝える
③ コミュニケーション設計と「守る一線」
実践への応用
実務・キャリアへの展開
- PM/CTO移行期：「自分が主導したプロジェクトの問題を認める」能力は、リーダーとしての成熟度を示す最も重要なシグナル。部下はリーダーが「正しさより面子を守る人か」を常に観察している。
- 組織変革：新制度の定着率は「内容の正しさ」より「設計プロセスへの参加感」が決める。エンジニアは特に「自分たちの意見が無視された制度」を受け入れない。
- グローバル文脈：評価制度のグローバル統一では、文化差（個人評価が強い欧米・チーム評価が強い東アジア）を考慮した設計調整が不可欠。「一律展開」がかえって不公平を生む。
今日のまとめ・次回へ
今日のQ3で扱った「村上さんへの率直な受け取り」「懸念を持つチームへの誠実な向き合い方」は、EQ-Bの「深い傾聴・共感・困難な会話設計」と直結する。Thinking-Aで設計した「条件付き部分展開」という判断を、人間関係の信頼構築という文脈でどう伝えるかを意識して取り組んでほしい。