今日のフォーカス
リソースが有限な組織・個人が成果を出すには「どこで戦うか」を選び、「今日から何をするか」を逆算で導く力が不可欠。そして選択の正しさを組織の意思に変えるには、論理・信頼・感情を統合した説得設計が必要になる。
Where to Play
「どこで戦うか」を選ぶことが戦略の出発点。全セグメントを同時に追うと「Stuck in the Middle」になり、どこでも勝てなくなる。
バックキャスティング
3年後のゴールから逆算して「1年後に何が真でなければならないか」「今月何をするか」を導く。フォアキャスト（今から積み上げ）とは異なる思考法。
SCQA説得構造
Situation / Complication / Question / Answer で結論を先に提示し、相手の思考に乗って論理を展開する。不完全なデータ下でも証拠に基づいて動かす技術。
あなたは個人向け英語学習アプリのCPO。現在3つのセグメントを同時ターゲットにしているが、リソースが限られており「選択と集中」を迫られている。
- A（就活生 18〜24歳）：学習継続率が低く、競合多数
- B（グローバル転職希望の会社員 20〜35歳）：意欲高いが競合が最も多い
- C（海外赴任予定のビジネスパーソン・企業福利厚生枠）：法人営業が必要だが単価高・継続率安定
- 3セグメントをポーターの競争戦略の観点から比較分析せよ
- 推奨する集中セグメントを選び、理由を述べよ
- 「Where to Play を決める」ための最低限の3つの問いを示せ
思考プロセスのヒント
「勝てる場所はどこか」「価値を最大化できるのはどこか」を3セグメントで比較せよ。
- セグメントごとのLTV（顧客生涯価値）・競合密度・参入障壁の違いは何か？
- セグメントCの「企業福利厚生」は通常のBtoCとどう異なるか？
- 全部追うと「Stuck in the Middle」になる理由は何か？
模範解答を見る
3セグメント比較分析
| セグメント | 特徴・ニーズ | 競合密度 | LTV | 推奨度 |
|---|---|---|---|---|
| A（就活生） | 学習意欲は高いが継続率低い。費用感度も高い | 高 | 低 | ✗ |
| B（転職希望会社員） | 意欲は高い。ただし汎用競合と差異化困難 | 最高 | 中 | △ |
| C（海外赴任・法人枠） | ビジネス英会話に特化したニーズ。企業が費用負担 | 低 | 高 | ◎ 推奨 |
推奨：セグメントCへの集中
理由① 差異化の余地が最大
企業福利厚生枠は法人営業・ビジネス英会話特化が必要。汎用競合（Duolingo等）との差別化ポイントが明確で「専用のツール」として位置づけられる。
理由② LTVが高い
企業契約は単価高・継続率安定。就活生（A）は学習継続率が低くLTV低。会社員（B）は競合が多く顧客獲得コスト（CAC）が高くなりやすい。
理由③ 参入障壁を築ける
法人契約・人事担当者との関係・カスタマイズ機能は模倣されにくい。競合が参入しにくいポジションを早期に確立できる。
Where to Play を決める3つの問い
① 勝てるか？
そのセグメントで競合より価値を提供できるか（差異化可能性）。強みを活かして「専門性」「独自性」を訴求できるか。
② 価値があるか？
LTV・市場規模は投資に見合うか。顧客一人当たりの価値と全体市場規模の積が十分か。
③ 持続可能か？
参入障壁を設けられるか。競合に模倣されにくいか。勝ち続けられる構造を作れるか。
A・B・C全部を追うと機能が中途半端になり、どのセグメントからも「私たち専用のツールではない」と評価される。ポーターの競争戦略において、「コストリーダーシップ」でも「差別化」でも「集中（フォーカス）」でもない中途半端なポジションは最も不利な状態。
実践への応用
- 新機能の優先順位を議論するとき「これはどのセグメントの課題を解くか」を先に合意する
- 「全ユーザーに使ってもらいたい」という要望は「Stuck in the Middle」のシグナルとして疑う
- Where to Playの3問（勝てるか・価値があるか・持続可能か）を意思決定の前に確認する
自己評価
エンジニア歴3年のリードエンジニア。「3年以内にEMかPMになりたい」とイメージしているが、具体的な戦略がない。上司に「次のキャリアステップはどうしたいか？」と聞かれた。
- バックキャスティングの手法で「3年後のゴール」→「1年後の前提条件」→「今月のアクション」を設計せよ
- 今月取るべきアクションを1つ特定し、その理由を述べよ
- 「やらないことを決める（戦略的省略）」の観点から、今やらないことを3つ挙げよ
思考プロセスのヒント
「3年以内にEM/PMになりたい」を逆算するとき、EMとPMでは求められる実績が異なる。
- EM：チームを動かした実績・採用・評価・1on1の経験が評価軸になる
- PM：プロダクトの意思決定への関与・ユーザーリサーチ・ステークホルダー調整の経験
- 「1年後に上司から認識されるために」今何が必要か？
- 今やることと、エネルギーを分散させてはいけない行動は何か？
模範解答を見る
バックキャスティング：3段階の設計
② チームメンバーの成長に貢献した実績（メンタリング・1on1）がある
③ 上司・経営層から「マネジメントポテンシャルがある」と認識されている
このアクションを選ぶ理由：EMに求められる最重要能力は「他者を通じて成果を出す力」。技術力の向上よりも、「人の成長を支援した実績」が1年後の認識に直接つながる。今すぐ始められ、コストが低く、インパクトが継続的に蓄積される。
やらないことを決める（戦略的省略）
- 新しいプログラミング言語の学習：今は技術力の横展開より縦の影響力強化が優先。RustやGoを学ぶ時間はEM/PMになった後でも遅くない
- 副業での個人開発：エネルギーをチームへの貢献に集中。個人の成果物よりチームの成果が今の評価軸
- 社外の技術勉強会への多参加：知識インプットより組織内でのアウトプット・実績が今は価値が高い。インプットは自社文脈でのアウトプットに変換できる量だけに絞る
フォアキャスト（今から積み上げ）では「今できること」に引きずられる。バックキャスティングは「3年後に必要な状態」から逆算するため、今やるべきことが今できることとズレていることに気づける。そのズレを埋めるアクションが戦略になる。
実践への応用
- 上司に「キャリアステップ」を聞かれたとき、「3年後の状態→1年後の前提条件→今月のアクション」の3段階で答えると具体性と論理性が伝わる
- 「やることリスト」と同時に「今やらないことリスト」を作る習慣をつける
- 1ヶ月に1回、「今月のアクションは1年後のゴールに本当に直結しているか」を確認する
自己評価
開発速度が目標の60%しか出ていない。原因仮説：
- a. 要件定義が曖昧：開発中の仕様変更が多い
- b. コードレビュー待ち平均3日以上：個別タスクの遅延要因
- c. テストが書かれておらずデグレ多発：再作業コストの問題
「まず要件定義プロセスの改善が最優先」と判断しているが、PMは「テストを先に整備すべき」、CTOは「どちらも重要だが速度改善の数字を見せてくれ」と言っている。
- 3つの仮説の優先順位付けプロセスを設計せよ（検証コスト・インパクト・検証方法）
- CTOへの提案をSCQA構造で組み立てよ。Logos/Ethos/Pathosも示せ
- PMの反論（「テストを先に」）への対処を設計せよ
思考プロセスのヒント
「速度改善の数字を見せてくれ」というCTOの要求に応えるためのデータをどう集めるか？
- GitHubのPRメトリクスで即計測できるデータは何か？
- 「要件変更の発生率」はどう計測するか？
- 「データ収集中でも動ける小実験」を並行で走らせる設計は？
- PMの主張（テストを先に）の論理を理解した上で、それでも要件定義が先である理由は？
模範解答を見る
仮説の優先順位付け
| 仮説 | 特定コスト | インパクト仮説 | 検証方法 |
|---|---|---|---|
| a. 要件定義の曖昧さ | 低（過去バックログの分析） | 高（上流の問題は下流すべてに影響） | 直近10件で「要件変更の発生率」を集計 |
| b. コードレビュー待ち | 低（GitHubのPRメトリクスで即計測） | 中（個別タスクの遅延要因） | PRのopen→mergeの平均時間を抽出 |
| c. テスト未整備 | 中（デグレの発生頻度を調査） | 中（再作業コストの問題） | バグチケットの「デグレ起因」分類を集計 |
データ収集中も「暫定として1番インパクトが高そうな仮説（a）に向けた小実験」を並行で走らせる。次の1スプリントだけ「要件をチェックリスト形式で確認してから開発に入るルールを試す」。これにより「データを待ちながら何もしない」状態を避けられる。
CTOへの提案：SCQA構造
S（Situation）
チームの開発速度が目標の60%。CTOも改善を求めている
C（Complication）
データ分析の結果「要件定義の曖昧さによる手戻り」が最多——直近10タスクの67%で要件変更が発生し、1タスクあたり平均1.8日の手戻りが生じている
Q（Question）
では今最初に何を直すべきか？
A（Answer）
要件定義の入口にチェックリストと5分のアライメント会を導入。コスト：週5分×10タスク=50分。効果：手戻り1.8日のうち1日相当を削減できれば速度は15〜20%改善
Logos / Ethos / Pathos の設計
PMの反論への対処
「テストを先にやるべき。デグレが多いのが根本原因だ」
「おっしゃる通りで、テスト整備も重要です。ただ、要件が曖昧なまま書いたコードのテストを書いても、テスト自体が間違っている可能性があります。上流を直してから下流を整備する順番の方が、テストの品質も上がります。まず1スプリントで要件プロセスの改善効果を測らせてください」
① 相手の主張を肯定する（「おっしゃる通り」）→ ② 前提の問題を指摘する（「ただし…」）→ ③ 小実験で検証する提案（「1スプリントだけ試す」）。反論を否定するのではなく、「より上位の視点」から包含する。
実践への応用
- 改善提案をする前に「特定コストが低くインパクトが高い仮説」から検証する順序を設計する
- CTOや経営陣への提案は必ずSCQA構造。「データ + 行動実績 + 感情的文脈」の3点セットで説得力を設計する
- 反対意見への対処は「否定→説得」ではなく「肯定→上位視点の提示→小実験の提案」の順番で設計する
自己評価
今日のまとめと次回への接続
今日の3つのキーポイント
次回への接続
今日の「論理的な説得設計（Logos/Ethos/Pathos）」に続き、次回は「感情と自己認識」を深める。論理的に正しい提案が組織で通らないとき、その理由の多くは感情・関係性・自己認識の問題に起因する。戦略思考と感情知性を統合することが真のリーダーシップの基盤になる。