portfolio-roadmapping-bets

ポートフォリオのロードマップにおける賭け

使用しない場合： 優先順位が明確な単一の取り組みの場合（代わりに one-pager-prd または project-risk-register を使用）、戦略的な時間軸を伴わない純粋な運用上の優先順位付けの場合（代わりに prioritization-effort-impact を使用）、またはリソースの制約やトレードオフがない場合。

ワークフロー

このチェックリストをコピーして、進捗を管理してください。

Portfolio Roadmapping Bets Progress:
- [ ] Step 1: Define portfolio theme and constraints
- [ ] Step 2: Inventory and size all bets
- [ ] Step 3: Sequence bets across horizons
- [ ] Step 4: Set exit and scale criteria
- [ ] Step 5: Balance and validate portfolio

ステップ 1：ポートフォリオのテーマと制約を定義する

戦略テーマ（北極星）、時間軸（H1/H2/H3 の定義）、リソースの制約（予算、人員、時間）、ポートフォリオのバランス目標（例：70/20/10 ルール）を明確にします。ガイダンスについては、ポートフォリオのテーマと制約を参照してください。

ステップ 2：すべての賭けを洗い出して規模を見積もる

候補となる取り組みをすべてリストアップし、それぞれの労力（S/M/L/XL）とインパクトの可能性（1x/3x/10x）を見積もり、種類（コア／隣接／変革）に分類し、依存関係を特定します。単純なケースでは resources/template.md を使用してください。15 件以上の賭けや複数のテーマを含む複雑なケースでは、resources/methodology.md を確認してください。

ステップ 3：時間軸に沿って賭けの順序を決める

依存関係、戦略的なタイミング、学習の順序、キャパシティの制約に基づいて、各賭けを H1（今）、H2（次）、H3（後）に割り当てます。順序付けのヒューリスティクスについては、順序付けと依存関係を参照してください。

ステップ 4：撤退と拡大の基準を設定する

各賭けについて、成功の定義（拡大基準：投資を強化する、対象範囲を広げる）と失敗の定義（撤退基準：中止する、優先度を下げる、方向転換する）を定めます。例については、撤退と拡大の基準を参照してください。

ステップ 5：ポートフォリオのバランスを取り、妥当性を検証する

ポートフォリオのバランスを確認し（保守的すぎないか、あるいは積極的すぎないか）、リソース面で実行可能かを検証し（実際に人員を配置できるか）、resources/evaluators/rubric_portfolio_roadmapping_bets.jsonを使って自己評価します。最低基準：平均スコア ≥3.5。ポートフォリオのバランス確認を参照してください。

よくあるパターン

ポートフォリオの種類別

製品ポートフォリオ（複数の機能／製品）：

• H1：すぐに効果が出る施策と重大なバグをリリースする
• H2：製品間の依存関係がある戦略的な機能
• H3：プラットフォーム関連の賭けと R&D の探索
• バランス：60% 漸進的、30% 大幅、10% 飛躍的

技術ポートフォリオ（プラットフォーム、インフラ、技術的負債）：

• H1：安定性、セキュリティ、パフォーマンスに関するすぐに効果が出る施策
• H2：大規模な移行とプラットフォームのアップグレード
• H3：次世代アーキテクチャとツール
• バランス：50% 維持、30% 改善、20% 変革

イノベーションポートフォリオ（R&D、実験、新規事業）：

• H1：検証済みで、拡大の準備が整った実験
• H2：チェックポイントを設けた進行中の実験
• H3：初期段階の探索と研究
• バランス：70% コアビジネス、20% 隣接領域、10% 変革（McKinsey Horizons）

マーケティングポートフォリオ（キャンペーン、チャネル、実験）：

• H1：最適化を伴う実績のあるチャネル
• H2：新しいチャネルの実験とテスト
• H3：ブランド構築と長期的なポジショニング
• バランス：70% パフォーマンスマーケティング、20% 成長実験、10% ブランド

賭けの規模別

小規模な賭け（1～2 週間、1～2 人）：

• 労力が少なく、インパクトは小～中程度
• すぐに効果が出る施策、実験、バグ修正に使用します
• 例：新しい価格ページの A/B テスト（2 週間、コンバージョンの可能性 1.2x）

中規模な賭け（1～3 か月、3～5 人）：

• 労力は中程度で、インパクトは中～大程度
• 機能、改善、小規模な取り組みに使用します
• 例：販売者向けダッシュボードの構築（2 か月、販売者の維持率 1.8x）

大規模な賭け（3～6 か月、5～10 人）：

• 労力が大きく、インパクトも大きい
• 戦略的な取り組み、プラットフォーム作業、主要機能に使用します
• 例：マーケットプレイスの信頼・安全システム（5 か月、不正行為の削減による GMV 3x）

特大規模な賭け（6～12 か月以上、10 人以上）：

• 労力が非常に大きく、変革的なインパクトの可能性がある
• プラットフォームの全面的な書き換え、新しい事業領域、ムーンショットに使用します
• 例：AI を活用したレコメンデーションエンジン（9 か月、エンゲージメントの可能性 10x）

リスクプロファイル別

コアベット（低リスク、段階的なリターン）：

• 既存の製品／チャネルを最適化する
• ROI が明確な、実証済みのアプローチ
• 例：検索の関連性を改善し、精度を 65% から 75% に引き上げる

隣接ベット（中リスク、大きなリターン）：

• 新たなユースケース、セグメント、または機能に拡張する
• アプローチは検証済みで、適用先は新しい
• 例：販売者向け分析機能をリリースする（実証済みの機能を新たなユーザーセグメントに展開）

変革型ベット（高リスク、飛躍的なリターン）：

• 新しいビジネスモデル、テクノロジー、または市場
• 未検証のアプローチで、不確実性が高い
• 例：ブロックチェーンベースの所有権システム（未検証の技術だが、新市場を切り開く可能性がある）

ポートフォリオのテーマと制約

ポートフォリオの戦略的な軸を定義します。

テーマ：全体的な目標（例：「エンタープライズ収益を 3 倍に成長させる」「プラットフォームの同等性を実現する」「APAC でリリースする」）

時間軸：

• H1（現在）：0～6 か月 — 確度が高く、まもなくリリース
• H2（次）：6～12 か月 — 確度は中程度で、計画中／開発中
• H3（将来）：12～24 か月以上 — 確度は低めで、探索／調査段階

リソースの制約：

• 予算：すべての取り組みに充てられる予算は $X
• 人員：エンジニア Y 人、デザイナー Z 人など（職種別のキャパシティ）
• 時間：主要なマイルストーンの期限はいつですか？（リリース日、取締役会、会計年度）

ポートフォリオのバランス目標：

• 例：コア 70%／隣接 20%／変革型 10%（マッキンゼーのスリー・ホライズン）
• 例：製品機能 60%／プラットフォーム 30%／R&D 10%
• 例：H1 50%／H2 30%／H3 20%（将来への投資を行いながら、短期的なリスクを軽減）

順序付けと依存関係

種類：技術（インフラ）、学習（知見）、戦略（検証）、リソース（キャパシティ）

ヒューリスティクス：依存関係を先に解消する、規模を拡大する前に学ぶ、早期にクイックウィンを得る、長期ベットは早く着手する、ポートフォリオでヘッジする

撤退・拡大の基準

撤退（中止）：期間（「90 日」）、指標（「採用率 <5%」）、コスト（「>$X」）、戦略（「市場が変化する」） 拡大（投資を倍増）：採用率（「>20%」）、エンゲージメント（「ベースラインの >3 倍」）、収益（「目標の >1.5 倍」）、効率（「CAC <$X」）

例：AI チャットボットのベット | 撤退：60 日後にデフレクション率 <30%、またはセンチメントスコア <-20% | 拡大：デフレクション率 >50% かつセンチメントスコア >70%

ポートフォリオのバランス確認

リスク：✓ コア約 70%、隣接約 20%、変革型約 10% | ❌ コア >80%（安全すぎる）、または変革型 >30%（リスクが高すぎる） 時間軸：✓ H1 約 50～60%、H2 約 25～30%、H3 約 15～20% | ❌ H1 >70%（将来がない）、または H3 >40%（短期的な成果がない） キャパシティ：工数 ≤ キャパシティ × 0.8（20% の余裕） | 例：エンジニア 10 人 → 6 か月で 48 EM → H1 では最大 38 EM インパクト：ポートフォリオがテーマに結び付いている（リスク調整後） | 例：「収益 3 倍」→ ベットの合計ポテンシャルは 4.7 倍 → 50% が失敗すると期待値は 2.35 倍 → ベットをさらに追加する

ガードレール

課題の設定：

• ❌ 「製品を改善する」のような曖昧なテーマ → ✓ 「12か月で解約率を5％から2％に下げる」のように具体化する
• ❌ 制約がない（リソースが無限） → ✓ 予算、人員、期間の上限を明示する
• ❌ ポートフォリオのバランス目標がない → ✓ リスク許容度を定義する（例：70/20/10）

ベットの規模設定：

• ❌ 文脈のない人日単位の工数 → ✓ 相対的な規模としてS/M/L/XLを使う
• ❌ 「高／中／低」のような曖昧な影響度 → ✓ 倍率（1x/3x/10x）または具体的な指標を使う
• ❌ すべてのベットが「最優先」 → ✓ 強制的に順位を付けるか、種類ごとに分類する

順序付け：

• ❌ 依存関係を特定していない → ✓ 技術面、学習面、戦略面の依存関係を整理する
• ❌ すべてのベットがH1（希望リスト）にある → ✓ 容量の制約を踏まえて現実的に順序付けする
• ❌ 順序の根拠がない → ✓ AをBより先に進める理由（依存関係、学習、早期成果）を説明する

中止・拡大の基準：

• ❌ 基準がない（「様子を見る」だけ） → ✓ 中止／拡大の判断に向けて、具体的な指標と期限を定める
• ❌ 中止基準しかない（悲観的） → ✓ 拡大基準も含める（大成功とはどのような状態か）
• ❌ 測定できない基準 → ✓ ベースラインのある定量的な指標を使う

ポートフォリオのバランス：

• ❌ コアばかり（安全すぎる）、または変革的な取り組みばかり（リスクが高すぎる） → ✓ リスクをバランスよく配分する
• ❌ 工数の合計が容量を超えている → ✓ 工数 ≤ 容量 × 0.8（未知の事項に備えて20％の余裕を確保）
• ❌ 期待される影響が戦略目標を下回る → ✓ リスク調整後のポートフォリオがテーマの実現につながるようにする

クイックリファレンス

リソース：

• resources/template.md - ポートフォリオロードマップの構成とベットのテンプレート
• resources/methodology.md - ホライズン計画、ベットの規模設定フレームワーク、ポートフォリオのバランス調整手法
• resources/evaluators/rubric_portfolio_roadmapping_bets.json - ポートフォリオロードマップの品質基準

成功基準：

• ✓ 戦略テーマが明確で、測定可能である
• ✓ すべてのベットが工数（S/M/L/XL）と影響度（1x/3x/10x）で規模設定されている
• ✓ 依存関係の根拠に基づき、H1/H2/H3にわたってベットが順序付けられている
• ✓ 各ベットの中止・拡大基準が定義されている
• ✓ リスクプロファイルとホライズン全体でポートフォリオのバランスが取れている
• ✓ 工数の合計 ≤ チームの容量（20％の余裕を含む）
• ✓ 期待されるポートフォリオの影響度 ≥ 戦略目標（リスク調整後）

よくある間違い：

• ❌ 戦略テーマがない → ロードマップが無作為な希望リストになる
• ❌ すべてのベットを「大」と規模設定する → 有用な優先順位付けができない
• ❌ 中止基準がない → サンクコストの誤謬やゾンビプロジェクトにつながる
• ❌ ポートフォリオのバランスが悪い → 早期成果ばかり（将来性がない）、または大きな賭けばかり（短期的な価値がない）になる
• ❌ 依存関係を無視する → H1のベットがH2のインフラによって妨げられる
• ❌ 容量超過 → チームが疲弊し、品質が低下する
• ❌ 目標が低すぎる → すべて成功しても、ポートフォリオの影響度が戦略目標を下回る