今日のフォーカス
課題定義の精度が意思決定の質を決める。「解決策が先に出ている問題定義」を疑い、評価軸を自分で設計し、二項対立を第三の解で崩す——三層の思考スキルを今日は統合的に鍛える。
問題 vs 症状の分離
「採用増が遅さを解決する」は症状への対処。真の課題定義には根本原因の層（技術的負債・プロセスボトルネック・要件変更頻度）の特定が必要。解決策が先に出ているときは常に疑う。
リスクの非対称性
「コスト・期間・技術リスク」以外に「可逆性」を加えると選択肢の見え方が変わる。失敗したときに元に戻れるかどうかがダウンサイドの大きさを決める。
問いの再設計
「受けるか断るか」→「どんな条件なら受けられるか」。問いを変えると解空間が広がる。二項対立の多くは「問い方の問題」で生じており、第三の解は問いを変えることで現れる。
「新機能の開発スピードが遅すぎる。競合がどんどんリリースしているのに、うちは四半期に2〜3機能しか出せていない。エンジニア採用を倍にして解決したい。」— CEO from Slack
あなたは「本当の問題はそれか？」という疑問を抱いた。
- CEOが「問題」と定義していることと「真の課題」が異なる可能性がある理由を、課題定義の観点から説明せよ
- 「エンジニア採用を倍にする」という解決策が機能しない可能性のある5つの仮説（真の原因）を挙げよ
- 「真の問題」を特定するために、今週中に収集すべき情報を優先順位付きで3つ挙げよ
思考プロセスのフロー
模範解答を見る
問1: 課題定義のズレが生じる理由
CEOの発言は「症状（開発が遅い）→ 診断なし → 解決策（採用増）」という構造になっている。真の課題定義には「なぜ遅いのか」の根本原因の特定が必要だが、CEOは現象レベルで止まり解決策と問題を混同している。
また「競合が速い」という比較は表面的なアウトプット量の比較であり、競合の技術的負債・品質・チームサイズを無視している可能性が高い。問題定義の解像度が低いと、コストをかけて誤った方向に進む。
問2: 採用増が機能しない5つの仮説
| # | 仮説（真の原因） | なぜ採用増で解決しないか |
|---|---|---|
| 1 | 技術的負債の蓄積で変更コストが高い | 人を増やしても既存コードのリードタイムは改善しない |
| 2 | 要件が週次で変わり手戻りが多い | エンジニア増でも要件定義プロセスが変わらなければ手戻りが増える |
| 3 | コードレビュー・QAがボトルネック | 開発者が増えるとレビュー待ち行列が増大するだけ |
| 4 | プロダクトバックログの優先度が不明確 | 機能スコープが拡散し「全員が高優先度タスク」を抱える状態が悪化 |
| 5 | オンボーディングコストが高い | 採用初年度は生産性が低く、既存メンバーのコストが増加する（Brooks's Law） |
問3: 今週中に収集すべき情報（優先順位付き）
- スプリントサイクルタイム分析：タスク着手〜完了のリードタイムと、どのフェーズ（開発/レビュー/QA/デプロイ）が最長かを計測。根本原因の仮説が絞られる
- 要件変更頻度の記録：スプリント途中でスコープが変わった件数。高ければ採用より要件定義プロセス改善が先
- 競合のリリース頻度の根拠：技術ブログや採用人数から推計し「真に速いか」を検証。主観的印象を数字で確認する
実践への応用
- スタートアップCTO: 創業者から「エンジニアを5人増やしたい」と言われたとき、先に「何がボトルネックか」を計測することで採用判断の質が上がる
- グローバルチーム: 複数拠点チームでは非同期レビュー待ちがリードタイムの最大要因になることが多い。採用より勤務時間帯の重複設計が有効なケースが多い
- PM/PMO役割: 「CEOが解決策を先に持ってくる」状況は常態。問題定義の再フレームを関係性を壊さずに行う構造的質問スキルが必須
自己評価
主力APIのレイテンシが月次で15%悪化しており、このままでは6ヶ月後にSLAを違反する。原因の50%は「認証サービス」の処理遅延と特定された。アーキテクチャの方向性を来週の取締役会で決定する必要がある。
候補: ①認証のみMS化（3ヶ月）②DB最適化のみ（1ヶ月）③完全MS化（12ヶ月）④クラウド変更（6ヶ月）
- 「意思決定マトリクス（評価軸 × 選択肢）」を構築し、最善の選択肢を論証せよ（評価軸は自分で設計）
- 「リスクの非対称性」を考慮するとはどういうことか、このケースで具体的に説明せよ
- 取締役会の「方向性決定」に必要な情報と「詳細設計」に必要な情報を切り分け、今週準備すべき資料の優先度を述べよ
思考プロセスのフロー
模範解答を見る
問1: 意思決定マトリクス
| 評価軸 | 重み | 選定理由 |
|---|---|---|
| SLA制約を6ヶ月以内に解決 | ×3 | ハード制約（満たさない選択肢は失格） |
| 実装リスク（技術的複雑性） | ×2 | 失敗時のダウンサイドが大きい |
| 可逆性（元に戻せるか） | ×2 | リスクの非対称性で重要 |
| 期間（ビジネスへの影響） | ×1 | 開発期間中の機能停止リスク |
| 長期アーキテクチャとの整合性 | ×1 | 将来の負債にならないか |
| 組織の学習価値 | ×1 | 次の意思決定に使えるか |
| 選択肢 | SLA解決(×3) | 実装リスク(×2) | 可逆性(×2) | 期間(×1) | 長期整合(×1) | 学習(×1) | 合計 |
|---|---|---|---|---|---|---|---|
| 認証のみMS化（3ヶ月） | 5 | 3 | 3 | 4 | 4 | 4 | 39 |
| DB最適化のみ（1ヶ月） | 4 | 5 | 5 | 5 | 2 | 3 | 38 |
| 完全MS化（12ヶ月） | 1 | 1 | 1 | 1 | 5 | 5 | 17 |
| クラウド変更（6ヶ月） | 3 | 1 | 1 | 3 | 3 | 3 | 22 |
問2: リスクの非対称性（このケースでの適用）
リスクの非対称性の原則：「完全な情報がない状況では、ダウンサイドが小さく可逆的な選択肢を優先する」。完全MS化は失敗時に回復不可能な損失を生む——これが非対称性のコアだ。
問3: 取締役会向け vs 詳細設計の情報分離
- 現在のレイテンシ劣化トレンドと6ヶ月後の予測（数字付き）
- 選択肢の比較（コスト・期間・リスクの3軸、2ページ以内）
- 推奨案と理由（1スライド）
- 認証サービスの依存関係マップ
- 段階的移行計画とロールバック戦略
- チーム体制と工数の詳細見積もり
実践への応用
- 資金調達中のスタートアップ: 投資家へのアーキテクチャ説明は「方向性 + リスク + コスト」の3点のみ。詳細は聞かれたら答える
- 異文化チーム: 欧米の取締役会は「選択肢の比較と根拠」を好む。アジアの意思決定文化では「全員の合意形成プロセス」が重視される——誰に向けてどう説明するかを変える
- リスク非対称性の応用: 新規事業の実験設計においても「小さく試せる実験を先にやる」のは同じ原理
自己評価
エンタープライズ顧客1社から「独自カスタマイズ版を6ヶ月で開発してほしい、契約金は年間$2M」という話が来ている。しかし、現エンジニア4名の6ヶ月フルタイムが必要であり、メインプロダクトの進化が止まる。
CEOは「$2Mは断れない」。共同創業者（CPO）は「カスタマイズはアーキテクチャを汚染する。長期的に価値を破壊する」と反対。
- CEOとCPOの主張をそれぞれ「強い版（スティールマン）」で再構成せよ
- この意思決定において「問いを変えると解が変わる」例として、少なくとも3つの「問いの再設計」を示せ
- CTOとしてこの意思決定に関与するとしたら、何をどの順番でやるか。「情報収集→問題定義→選択肢→決定」の各フェーズで具体的な行動を述べよ
- 最終的にどの方向を推薦するか。推薦しない選択肢の最大の反論も含めて論述せよ
思考プロセスのフロー
模範解答を見る
問1: スティールマン再構成
- $2Mは現ARRの大きな割合で、収益安定性は採用・投資家・チームモチベール全てに直結する
- 「PMF後の最初のエンタープライズ実績」という参照事例を失うと次の大口案件の信頼性が下がる
- エンタープライズ1社の深い要件は、SMB 10社より製品設計の洞察が多い場合がある
- カスタマイズが「汚染」になるかどうかは設計次第——プラットフォーム型設計で吸収できる可能性がある
- カスタマイズ開発はエンジニアのメンタルモデルを「特定顧客のニーズ」に最適化させ、汎用プロダクトの設計判断を歪める
- SMBロードマップ停止による解約は金銭損失だけでなく「NPS低下・参照事例喪失・採用ブランド毀損」を生む
- この意思決定が通例化すると「大口案件が来るたびにメインプロダクトが止まる」という組織パターンが定着する
- 長期的には2つの異なるコードベースの維持コストが指数関数的に増大する
問2: 問いの再設計（3例）
問3: CTO としての行動順序
- 顧客との要件ヒアリング：「$2Mに含まれる機能のうちメインプロダクトに汎用化できるものは何か」を直接聞く
- エンジニアへの技術的見積もり：「モジュール設計でカスタマイズを分離できるか」の実現可能性
- SMB解約リスクの定量化：CSMと協力して「ロードマップ停止3ヶ月で解約確率が高いSMB顧客の現ARR」を算出
- 「エンジニアリソースの制約」か「アーキテクチャ哲学の対立」かを分離する
- 本当の制約は「4名×6ヶ月」か？ 一部を外部パートナーや追加採用で補えないかを検証
- 「全受注」「全拒否」以外に「スコープ縮小版を$1.2Mで3ヶ月・2名」「プラットフォーム型で共同開発」「3ヶ月延長して採用後に開始」などの第三の案を設計
- CEOとCPOを同席させた場で、選択肢と各シナリオの数字（SMB解約損失・採用コスト・アーキテクチャ負債の見積もり）を提示
- CTOが数字と選択肢の設計者になり、最終決定者をCEOに渡す——権限の明確化が信頼構築になる
問4: CTOとしての推薦
顧客の中核要件が「ドキュメント分類精度の向上」と「エンタープライズ認証統合（SSO）」の2点に集約される場合——SSOはメインプロダクトに還元できる汎用機能であり、全顧客に価値がある。ドキュメント分類はプラグイン型で設計すれば本体コードを汚染しない。
最善案: 2名×3ヶ月でSSOと分類プラグインを開発、$1.2Mで合意
全拒否の最強の根拠は「組織パターンの毀損」だ。一度受けると「CTOが断れないこと」が社内外で認知され、次の大口案件でも同じ圧力がかかる。これは根拠ある懸念だ。
しかし、条件交渉なき全拒否は「交渉の余地を試さずに$2Mの機会を失った」という意思決定プロセスの問題を残す。試みた上で顧客が条件を飲まなければ、断る判断を全員で共有できる。
実践への応用
- PM/CTO役割の境界: CTOは「何が技術的に可能か」の選択肢設計者。「何を選ぶか」の最終決定をCEOに渡すことで信頼関係を構築しつつ技術的視点を組織に埋め込む
- グローバル交渉: 欧米のエンタープライズ顧客は「Noと言えるベンダー」を信頼する。条件交渉は「関係を壊す」のでなく「パートナーとしての地位を確立する」行為として機能する
- スタートアップ初期の原則: 「オプションを閉じない」——今の決定が将来の選択肢を最大化するかどうかを常に確認する
自己評価
今日のまとめ・次回へ
問題 vs 症状
「解決策が先に出ている問題定義」は常に疑う。5 Whysで原因の層を掘り、情報収集の優先順位を情報価値で決める。
リスクの非対称性
「可逆性」を評価軸に加えると選択肢の見え方が変わる。ダウンサイドが小さく回復可能な選択肢を不確実性下では優先する。
問いの再設計
二項対立の多くは「問い方の問題」。「受けるか断るか」→「どんな条件なら受けられるか」で解空間が広がる。
今日の「CEOとCPOの対立構造を扱うCTO」というシナリオは、明日のテーマ「衝突解消と信頼構築」に直結する。技術的に正しい選択肢を提示しながら、感情的対立を収束させる対人スキルを鍛えていく。