今日のフォーカス
「与えられた問いをそのまま解く」という罠を破り（Q1）、技術リスクとビジネスインパクトをリスクの非対称性で判断し（Q2）、Head of Productとして全員が正しい多軸ジレンマで前提を疑い第三の解を設計する（Q3）。問題解決の本質は「解く前に正しく問うこと」にある。
症状 vs 病因
「カート放棄率が増えた」は症状。上司の「チェックアウトフロー見直し」はすでに仮説込みの指示。課題定義の精度が解の质を決める——ソリューション先行思考の罠に気づく力が最初の問題解決スキル。
リスクの非対称性
「失注（¥3億）」と「本番データ破損（全顧客・信頼崩壊）」は損失の質が違う。前者は回復可能、後者は不可逆。不確実性下の意思決定は「どちらの間違いの方が取り返しがつくか」を問う。
第三の解（And Stance）
CEO・CTO・CSリード3者は全員正しい。OR（どれか選ぶ）ではなくAND（どう両立させるか）を問う。前提（「同時進行不可能」）を疑うことで縮小版並行案が見えてくる。
上司から「すぐにUX改善チームと協力してチェックアウトフローを見直せ」という指示が来た。しかし、その指示にはすでに「チェックアウトフロー＝問題」という仮説が含まれている。
① カート放棄率+12%という「症状」の背後にある可能性のある「病因」を最低5つ、MECE的に構造化せよ。
② 上司の仮説が正しい場合と正しくない場合を分けて、最初に確認すべきデータを1つずつ述べよ。
③ 「問題を正しく定義する」ために最初に問うべき問いを1つ設計せよ。
思考プロセスのヒント
「カート放棄率が増えた」を構造化するには、放棄が「どのタイミング」で起きているかをまず分解する。
- 問いの二分岐：「いつ放棄しているか」を先に特定することで、病因の空間が半分になる
- 上司指示の構造：「チェックアウトフロー見直し」はすでにB（チェックアウト後）を前提にした解決策。検証なしに動けばAが原因だった場合に無駄になる
- MECE分解：ユーザー側要因 / プロダクト側要因 / 外部要因の3軸で病因を整理すると漏れが少ない
模範解答を見る
① 病因の構造化（MECE的分類）
| 分類 | 具体的な病因 |
|---|---|
| UX（プロダクト側） | チェックアウトフローのUI/UXが劣化（ステップ増加・ボタン位置変更など） |
| 価格・コスト認知 | 送料・手数料などが最終確認画面で初めて表示（コスト開示タイミング） |
| セグメント変化 | 新規ユーザー比率が増加し、ユーザー構成が変化した |
| 外部競合 | 競合サイトでの同一商品価格が下落し、比較購買が増えた |
| 技術・パフォーマンス | ページ読み込み速度の低下・決済APIエラー率の上昇 |
② 仮説別の確認データ
特定ステップで急増があれば、UX問題の仮説が支持される
チェックアウトを開始する前に放棄しているなら、問題はチェックアウト外にある。価格・競合・意思決定の問題を調査すべき
③ 最初に問うべき問い
この問いへの答えで問題空間が半分になる。上司の仮説は後者を前提にしているが、検証なしに施策を進めれば前者の場合に完全に的を外す。問いの質が解の質を決める。
実践への応用
- PM・プロダクトリード：ステークホルダーから「すでに解決策が含まれた依頼」が来ることは日常。「承知しました」の前に「どのデータがそのアプローチを示唆していますか？」と問い返す習慣を持つ
- スタートアップのピボット判断：「売れない」という症状に対して why not buying を5段階（認知・理解・評価・購買意欲・決済摩擦）で分解してから解決策を選ぶ
- グローバルチームでの問題解決：定義フェーズを「共同ドキュメント」にし、「私たちが解こうとしているのは何か」を1文で書き出す練習が文化差による問題定義のズレを防ぐ
自己評価
① 意思決定の選択肢を3つ以上列挙し、リスク・メリット・前提条件を整理せよ。
② 情報価値が最も高い「確認すべき情報1つ」を特定し、理由を述べよ。
③ ①から最善策を選び、リスクの非対称性の観点から根拠を説明せよ。またA社への1文（英語）を書け。
思考プロセスのヒント
「リスクの非対称性」を考えるには、各選択肢の最悪シナリオを比較する。どちらの間違いが取り返しがつかないか？
- 最悪シナリオの非対称性：失注は¥3億の損失。データ破損は全顧客・信頼・法的リスクへの波及——質が違う
- 情報価値の評価：「バグが本番でデータ破損を起こすか、リトライで回復可能な失敗か」を知ることで、判断の重みが根本的に変わる
- フィーチャーフラグという第三案：「リリース vs 延期」の二択に囚われず、バグを含む機能だけ無効化してリリースという選択肢を考える
模範解答を見る
① 選択肢の整理
| 選択肢 | リスク | メリット | 前提条件 |
|---|---|---|---|
| 予定通りリリース | 本番でデータ競合→全顧客データに影響。不可逆的損失の可能性 | A社の契約更新に間に合う | バグが本番で発生しないことの証明 |
| 3週間延期 | A社との更新交渉に影響・失注リスク | データリスクを排除した安全なリリース | 3週間で確実に修正できる見通し |
| フィーチャーフラグで部分リリース | A社が期待する機能が提供できない可能性 | スケジュール維持＋リスク局所化 | バグを含む機能を切り離せるアーキテクチャ設計であること |
| 段階ロールアウト（A社除外→修正後→A社） | 段階運用の複雑さ・工数増加 | A社への影響最小化しつつリスク管理 | 2週間以内に段階ロールアウトを実装できる余力 |
② 情報価値最大の確認事項
「データ破損」なら延期一択。「リトライで回復可能な失敗」なら監視強化でリリースを検討できる。この1点で判断の方向が180度変わるため、情報価値が最大。
③ 最善策とリスクの非対称性による根拠
リスクの非対称性：失注（A社¥3億）は「1顧客の損失」であり痛いが回復可能。一方、本番データ破損は「全顧客・信頼・ブランドへの不可逆的損失」でスケールが桁違いだ。スケジュールを守るためにデータリスクを取ることは、非対称なギャンブルになる。
実践への応用
- EMのリスク判断：「急いでリリースせよ」という圧力が来るとき、最悪ケースの損失を定量・定性で並べて見せることで感情的議論を論理的にする
- Concentration Riskへの気づき：A社1社の依存度が高い状態は構造的問題。今回の判断がA社依存度に左右される状況自体をリスクとして認識する
- グローバル顧客への透明性：遅延理由を「品質確保のため」と伝えることはネガティブに見えるが、実際には信頼を高める。特に欧米企業では透明性を高く評価する
自己評価
① 3つの要求を「緊急度・インパクト規模・不可逆性」で評価し、優先度マトリクスを作成せよ。
② 「12名で3つは同時にできない」という前提を疑い、並行可能な設計を考えよ。
③ Head of Productとして判断を下し、CEO・CTO・CSリードそれぞれへのコミュニケーション設計を述べよ。
思考プロセスのヒント
3者はそれぞれ「自分の視点から正しい」。HoPの仕事は誰かの肩を持つことではなく、「全体最適」を論理で示すこと。まず各要求を「放置した3ヶ月後・6ヶ月後」で考える。
- 不可逆性の比較：技術負債の複利悪化は見えにくいが確実。チャーンは一度始まると連鎖。エンタープライズ契約は交渉余地が残る
- 前提を疑う：「SSO/SCIMをフルスクラッチで作る」が本当に必要か？Auth0/Okta統合で工数を1/3に圧縮できる可能性がある
- 重複効果を探す：「技術負債の最重要箇所」と「検索/フィルタ改善に必要なバックエンド改修」が重複するなら、同じチームで両方を前進させられる
模範解答を見る
① 優先度マトリクス
| 要求 | 緊急度 | インパクト規模 | 不可逆性（放置時） | 総合評価 |
|---|---|---|---|---|
| SSO/SCIM（CEO） | 高（Q1リミット） | 大（¥8億契約） | 中（交渉余地あり可能性） | 高 |
| 検索/フィルタ（CS） | 高（来月更新シーズン） | 中（チャーン防止） | 中〜高（連鎖チャーン） | 高 |
| 技術負債（CTO） | 低（即時影響なし） | 大（長期開発速度） | 高（複利的に悪化） | 中〜高 |
② 前提を疑った並行設計
規格準拠のライブラリ統合で工数を最大70%削減。「フルスクラッチ前提」を外すことで必要人員が4名→2名になる可能性
検索/フィルタに直接影響するデータモデル改修から着手すれば、1チームが技術負債返済と機能改善の両方を前進させられる
全社が拒否しない可能性がある。「3ヶ月内に完成」でなく「段階的に価値提供」という交渉が時間を生む
縮小版並行案（3チーム×4名）
③ 3者へのコミュニケーション設計
内容：「SSO/SCIMは最優先で進める。ただしOktaベースで工数を70%削減した実装方式を採用し、Q1内完成は維持するがスコープを単一IdP対応から開始し複数IdPは来Q2にする。エンタープライズ3社への段階提供交渉のサポートをお願いしたい」
トーン：解決志向・数字ベース / タイミング：本日中に1on1
内容：「技術負債の問題は深刻に受け止めている。今Qは全面着手はできないが、検索/フィルタチームが手を付けるデータモデル部分と重なる箇所から着手し、来Q2には技術負債フォーカスのクォーターを設ける。ロードマップに正式に入れる」
トーン：技術的な深刻さへの共感＋明確なコミットメント / タイミング：CEO対話の翌日、設計の詳細をセットで話す
内容：「検索/フィルタ改善は今Q内でUI層を中心に着手する。更新シーズン前に改善版をβとして主要顧客に見せ、スコア改善のシグナルを伝えることを優先する」
トーン：顧客への緊迫感を共有しつつ具体的な行動コミット / タイミング：今日のうちにSlackで「検索改善は今期優先します」と先行メッセージ
実践への応用
- Head of Product → CTO/CEO：「全員の要求は正しいが全てはできない。HoPの役割は最良判断を論理で示すこと」——この姿勢がリーダーへの信頼を築く
- スタートアップの資源制約：制約は創造的設計のトリガー。「できない」を言う前に「前提を変えれば何ができるか」を常に問う
- グローバル組織のコミュニケーション：ステークホルダーへの伝達は「誰が何を最も気にしているか」でカスタマイズする。全員に同じメッセージは誰も腹落ちさせない
自己評価
今日のまとめ
明日（木曜日）はEQ-B（対人スキル・関係管理）。今日のQ3で設計した「CEO・CTO・CSリードへの個別コミュニケーション設計」は、相手の感情・立場・利益を読む対人スキルと直接つながる。「何を言うか（思考）」と「どう言うか（感情知性）」の統合が明日のテーマの核心だ。