今日のフォーカス
KPI悪化に対して「与えられた問いをそのまま解く」という罠を破り（Q1）、リソース制約下で勝てる順序を選ぶ意思決定を設計し（Q2）、倫理・スピード・会社生存の三角ジレンマで全員が正しいという前提から第三の解を導く（Q3）。PMからCTOへの移行は「解く人」から「何を解くかを決める人」への移行だ。
問いの再定義
「MAU −18%」に対して「オンボーディング改善」という指示が来る。しかし「登録完了は横ばいで休眠急増」というデータは、問題がオンボーディングではなく定着・チャーンにあることを示す。問いの質が解の質を決める。
制約下の選択と集中
10名で12名分のプロジェクトは回せない。「全部を80%でやる」は全て失敗するリスク。不可逆リスク・外せないデッドライン・収益インパクトの3軸で評価し「勝てる順序」を設計する。
第三の解（And Stance）
CEO・セキュリティエンジニア・電力会社は全員正しい。「Yes か No か」という二択から脱出し、「手段（APIセキュリティ緩和）」と「目的（データ統合）」を分離することで、より安全な別の解が現れる。
先週のダッシュボードで、月次アクティブユーザー（MAU）が前月比 −18% と大幅悪化。直属の VP Product から「オンボーディングフローを全面改善せよ。ステップ数が多すぎる」という指示が来た。しかし、MAU の内訳を見ると 登録完了ユーザーは横ばい、過去90日以上ログインしていないユーザーが急増 している。
① VP Productの指示に潜む「前提の誤り」を1つ特定し、その根拠を示せ。
② 「MAU −18%」という症状に対してあり得る病因を、ユーザージャーニーの5段階（認知→獲得→オンボーディング→定着→復帰）に沿って最低3つずつ分類せよ。
③ このデータが示す「最初に問うべき問い」を1文で設計せよ。
思考プロセスのヒント
「MAU = 新規獲得 × 定着率 × 復帰率」の積として考えると、どのバケツが崩れているかで打ち手が変わる。
- 問いの分岐：「誰が来なくなったか（新規 vs 既存）」を先に特定することで打ち手の方向が決まる
- VP指示の構造：「オンボーディング全面改善」はすでに獲得フェーズを問題と仮定した解決策。データが示すのは定着フェーズの崩れ
- Solutionism の罠：問いを受け取った瞬間に「どう解くか」へ飛ぶ。「何を解くか」を先に確認する習慣が最初の問題解決スキル
模範解答を見る
① VP Productの前提の誤り
② ユーザージャーニー別の病因分類
| フェーズ | 病因の例（最低3つ） |
|---|---|
| 認知→獲得 | 広告チャネル変化で低品質ユーザーが流入 / オーガニック検索流入が低下 / ターゲティングの精度低下 |
| 獲得→オンボーディング | 登録フォームの摩擦増加 / 認証エラー上昇 / メール認証の到達率低下（ただし今回は影響小） |
| オンボーディング→定着 | Aha Momentまでの時間が長くなった / コア機能入口が変更された / チュートリアルのスキップ率が上昇 |
| 定着（エンゲージメント） | コア機能の価値が競合サービスと逆転 / 通知設定変更で再訪率が低下 / 価格改定で解約・休眠が増えた |
| 休眠→復帰 | リテンションメールのCTR低下 / 競合プラットフォームへの移行 / リエンゲージメント施策の欠如 |
③ 最初に問うべき問い（1文）
この問いへの答えで打ち手の方向性（獲得強化 vs エンゲージメント改善 vs 復帰施策）が絞り込まれる。
実践への応用
- PM・プロダクトリード：「○○を改善せよ」という指示が来たとき「その指示が前提としているデータは何か」を1つ問い返す。改善すべき問いは「承認するかしないか」ではなく「その問いは正しいか」。
- スタートアップCTO：KPIダッシュボードの単一指標を見て判断する前に「コホート×ファネル」の2軸で分解する習慣を組織に根付かせる。週次レビューがこの分解の場になると問題定義の精度が組織全体で上がる。
- グローバルPM：国・地域別でユーザー行動が異なるため、MAUの悪化が特定地域のチャーン増加に起因している可能性がある。グローバルPMは「全体」と「セグメント別」を常に並べて見る。
自己評価
ARR 12億円、社員80人のB2B SaaSスタートアップのCTO。エンジニアチームは10名で、以下3つのプロジェクトが同時進行中。採用は最短で2ヶ月かかる。
| プロジェクト | 現状 | ビジネスインパクト |
|---|---|---|
| A: SOC2 Type II取得 | 70%完了、残り2週間見込み | エンタープライズ（ARR 3億）の契約前提。11月末デッドライン（現在9月） |
| B: K8s移行 | 40%完了、残り6週間見込み | 現行インフラが来年3月にEOL。移行しないと本番リスク増大 |
| C: AIレポート開発 | 25%完了、残り8週間見込み | 競合が先月リリース済み。既存顧客5社がチャーン示唆（ARR 4.5億に影響） |
① 3プロジェクトを「インパクト×リスク×時間的緊急性」の3軸で評価し、優先順位を決定せよ。
② リソース制約下で「最悪のアウトカムを避けながら最大のビジネス価値を守る」配分案を具体的に設計せよ（人数・期間も示すこと）。
③ 取締役会（CEO・CFO・セールス責任者）にこの判断を伝える際の「フレーミング」を設計せよ。
思考プロセスのヒント
3プロジェクトを同時に最大化しようとすると全て失敗する。「外せない制約」と「不可逆リスク」を先に特定し、勝てる順序で集中する。
- 外せない制約を先に特定：A（11月末デッドライン）は固定制約。これを落とすと3億の新規ARRが確実に消える
- 不可逆リスク：B（来年3月EOL）は「サービス停止」という不可逆リスク。ただし3月まで余裕があるため完全停止は不要
- Cは代替手段がある：チャーン示唆の5社に対しては「ロードマップ共有+暫定対応」で時間を買える
模範解答を見る
② リソース配分案（10名、8週間）
- A（SOC2）に7名集中投下：残2週間見込みを4週間で完全完了。バッファを持たせる
- B（K8s）に3名：クリティカルパスのみ継続。進捗を40%→55%へ
- C（AIレポート）は一時停止：チャーン示唆5社には個別でロードマップ共有+暫定ウォークスルー対応でチャーンを防ぐ
- A完了後（11月中旬目標）、全10名をBとCへ振り向け
- B：6名：K8s移行を加速させ来年3月の安全マージンを確保
- C：4名：AIレポートの最小限MVP（レポート生成のみ、カスタマイズなし）を先行リリースし競合との差を最小化
- 採用：即日JD公開。11月中旬に2名がオンボードできればCの本格開発が加速
③ 取締役会へのフレーミング
実践への応用
- CTO・エンジニアリングリード：「何を後回しにするか」を明文化し、ステークホルダー全員に伝える。暗黙の優先順位は後で「言ってたじゃないか」という対立を生む。
- スタートアップ経営：「採用が完了するまで待つ」という選択肢はなく、「今の10名でどう最善を尽くすか」という問いに向き合うのが経営者の仕事。
- グローバルプロジェクト管理：優先順位変更を複数ステークホルダーに伝える際は「何を止めるか」ではなく「何を守るか」という言葉で伝えるとコンフリクトが少なくなる。
自己評価
再生可能エネルギー向けIoTプラットフォームを開発するスタートアップ（シード調達2億円、18ヶ月）。大手電力会社からPoC打診。成功すれば本格導入5億円の契約。PoCの要件は「自社システムとのデータ統合のためにセキュリティを一部緩和したAPIエンドポイントを用意すること」だ。
① この状況に存在する「価値観の衝突」を最低3つ特定し、それぞれの正当性を認めよ。
② 「Yes（要求通り実装）」「No（要求拒否）」の二択を超えた「第三の解」を設計せよ。設計に使ったフレームワーク・思考プロセスを明示すること。
③ ②の解を実行するとき「セキュリティエンジニア」「CEO」「電力会社」それぞれに伝えるべき内容とその順序を設計せよ。また自分が守ろうとしている「一線」を言語化せよ。
思考プロセスのヒント
三者が対立しているように見えるが、全員「正しいこと」を言っている。鍵は「電力会社の要求の背後にある本当のニーズ」を分離すること。
- 手段と目的の分離：「APIセキュリティ緩和」は手段。電力会社の目的は「データ統合の実現」。目的に対する別手段を探す
- セキュリティエンジニアの懸念は客観的リスク：「実装したくない」は個人的好みではなく、発電所系統への具体的リスクの指摘。技術的判断として正しい
- And Stance：CEO・セキュリティエンジニア・電力会社は全員正しい。「誰かを説得して負かす」のではなく「全員が勝てる設計」を考える
模範解答を見る
① 価値観の衝突（3つ）と正当性
CEOは会社の生存（18ヶ月のランウェイ・シリーズA）を守る責任を持つ。セキュリティエンジニアは「悪影響を承知で実装しない」という職業的誠実性を持つ。どちらも正しい。
今の契約を取れば資金は安定するが、セキュリティインシデントが起きたとき「電力インフラへの攻撃を招いた会社」というレピュテーションは壊滅的で不可逆。短期利益と長期信頼が今ここでトレードオフになっている。
IoTデバイス5万台が電力系統に接続されているという文脈では、この判断は会社内部の話を超え公共インフラへの影響を含む。社会的責任は競争論理の外側にある。
② 第三の解の設計
使ったフレームワーク: 手段と目的の分離（Underlying Need Analysis）+ 条件付き合意（Conditional Proposal）
電力会社の要求「APIセキュリティ緩和」を分解すると、背後の目的はデータ統合の実現であり、手段（セキュリティ緩和）は固定されていない。
電力会社のシステムが必要とするデータのみを読み取り専用で提供。書き込み権限は与えない → 制御データへの書き換えリスクがゼロになる
電力会社のサーバーからのみアクセス可能な専用エンドポイント。「セキュリティ緩和」ではなく「アクセス制御の強化」として設計
最初の1ヶ月を設計フェーズとし電力会社エンジニアとセキュリティ仕様を共同設計。「より安全な統合」を電力会社にとってもメリットとして提示
③ コミュニケーション設計と順序
→ 技術的判断を先に取り込み、実装可能な設計の共同オーナーにする。CEOに話す前にやるべき最初のステップ。
→ CEOが恐れているのは「契約を失うこと」。第三の解を「より強いYes」としてフレームし、「Noを言っている」ではなく「別の方法で勝ちにいく」と見せる。
→ 電力会社自身も社会インフラを守る責任がある。セキュリティ強化を「自社のメリット」として提示することで「要求を断られた」ではなく「より良い提案をもらった」という体験にする。
自分が守ろうとしている「一線」
実践への応用
- テックリード→CTO移行期：「倫理と経営の両立」は経営者として避けられない課題。「全員正しい」という前提から始めると、和解不可能に見えた対立が構造的に解ける場合がある。
- スタートアップ資金調達期：「今の契約か、長期の信頼か」という二択は偽の二択であることが多い。条件付き合意・段階的合意・代替案の提示で「選ばなくていい場面」を増やす交渉スキルが必要。
- 規制産業との取引：電力・医療・金融などの規制産業では、セキュリティ要求は法的・社会的義務を伴う。「お客様のご要望」という枠を超えた判断基準を自社が持つことが、長期的なエンタープライズ信頼の基盤になる。
自己評価
今日のまとめ
「問題を解く前に問いを疑う」「リソース制約の中で勝てる順序を選ぶ」「全員が正しいという前提で第三の解を設計する」——この3つは全て、問題の「定義権」を自ら持つ力だ。PMからCTOへの移行は、解く人から「何を解くかを決める人」への移行でもある。
今日の「セキュリティエンジニアへのコミュニケーション設計」で触れた「相手の懸念を先に取り込む傾聴」「全員への個別フレーミング」というスキルは、EQ-Bの深い傾聴・共感・影響力の実践そのものだ。今日の思考を人間関係の文脈に応用するとどう変わるかを意識して取り組んでほしい。