なぜ「単発の新規事業管理」では限界があるのか
大企業の新規事業推進部門が陥りやすい罠がある。複数の事業案件を「個別に」管理し、それぞれの担当者が「自分の事業を守る」行動をとる構造だ。その結果、リソース配分の最適化は起きず、失敗した事業からの学習は組織に蓄積されず、経営層には「どの事業に賭けるべきか」という全体最適の視点が欠如する。
13年以上260社以上の新規事業支援の現場で観察される共通点は、成果を出している組織は必ず 「ポートフォリオとして」イノベーション投資を管理している という点だ。個別最適ではなく全体最適。単発の成否ではなく、分散投資の戦略的設計。この発想の転換が、新規事業の成功率を構造的に変える。
本記事では、イノベーション・ポートフォリオ管理の基本フレームワーク、リソース配分の設計原則、評価指標の実装方法を体系的に解説する。
「三つの地平線」フレームワークの正しい使い方
地平線フレームワークの構造
McKinseyが1999年に提唱した「三つの地平線(Three Horizons)」は、イノベーション投資を時間軸で分類するフレームワークだ(Baghai, Coley & White, 1999)。H1(現在の事業の改善・拡大)、H2(新しい収益の芽)、H3(未来の可能性の探索)という3層に分けて管理する。
このフレームワークが日本企業で誤用されるパターンが繰り返し観察される。 H1のリソース配分が90%を超え、H2・H3は名目上存在するだけで、実質的な投資がない。 この状態では「ポートフォリオを持っている」とは言えない。
適切なリソース配分の基準
Harvard Business Reviewの研究によれば、持続的なイノベーションを実現している企業のリソース配分の中央値はH1に70%、H2に20%、H3に10%だ(Nagji & Tuff, 2012)。この比率は業種・成長フェーズによって変わるが、H3への投資比率が5%を下回る組織はほぼ例外なく、5年後に事業機会の枯渇に直面している。
問題はH3が「少ない」ことではなく、H3への投資判断基準が存在しない ことにある。何を基準にH3案件を採択・継続・撤退するかが不明確なまま、予算の有無だけで管理される。
地平線を超えるパイプラインの設計
三つの地平線を静的なカテゴリとして使うだけでは不十分だ。H3の探索がH2の事業モデルに進化し、H2がH1の収益基盤になる「パイプライン」として動態的に管理する視点が必要だ。
どのH3案件がH2に移行する条件は何か、どのH2案件がH1に移行するマイルストーンは何か を事前に定義することで、ポートフォリオは単なる分類表から戦略的な投資管理ツールになる。
ポートフォリオ管理の5つの実装原則
原則1:案件の「類型化」ではなく「ステージゲートの統一」
ポートフォリオ管理の実装で最初につまずくのが、案件の分類だけに終始することだ。H1・H2・H3に振り分けた後、それぞれのステージで「何を確認し、何を判断するか」が定義されていなければ、分類は形式に終わる。
各ステージゲートで確認すべき仮説(顧客仮説・価値仮説・成長仮説)と、それぞれの検証方法を統一する。 評価基準の統一は、経営層が複数案件を比較して投資判断を下すための必要条件 だ。
原則2:撤退基準の事前設計
「撤退判断が遅れる」問題は、撤退基準が事前に定義されていないことに起因する。「〇ヶ月後に顧客獲得数が〇件以下であれば撤退」という定量基準を、事業採択時に合意しておく。
事後的に撤退基準を設定しようとすると、担当者・事業責任者・経営層それぞれの利害が絡まり、基準が歪む。 事前設計された撤退基準は、ゾンビ事業の延命とサンクコストバイアスを構造的に防ぐ。 撤退基準の設計詳細は「撤退基準の設計法——ゾンビ事業を防ぎリソースを最適配分する実践ガイド」で論じている。
原則3:学習指標の標準化(イノベーション・アカウンティング)
H2・H3案件をPLで評価することは、初期フェーズの新規事業に短距離走の基準でマラソンを評価するようなものだ。段階に応じた評価指標を設計する必要がある。
イノベーション・アカウンティングの考え方に基づき、仮説検証の進捗(インタビュー数・プロトタイプ実施数ではなく、「棄却できた仮説の数」と「確認できた仮説の数」)を評価軸に加える。 学習の進捗を組織的に可視化することで、投資対効果の判断が「PLゼロ」以外の軸で可能になる。
原則4:リソース配分の動的調整
年度初めに一括でリソースを案件に割り当てた後、年度末まで評価しない運用では、市場変化への適応が遅れる。四半期ごとの「ポートフォリオレビュー」を制度化し、進捗・市場環境・競合状況に応じてリソースを動的に再配分する仕組みを設ける。
重要なのは、増額・減額・撤退の三択だけでなく、「一時停止」の選択肢を持つこと だ。完全撤退でも継続でもなく、リソースを最小限に保ちながら市場の変化を観察する「休眠状態」の設計が、オプション価値を保持する。
原則5:ポートフォリオ全体のリスク分散の可視化
個別案件の評価だけでなく、ポートフォリオ全体のリスク分布を可視化する。「全案件が同一市場への参入を目指していないか」「全案件のターゲット顧客が既存顧客に偏っていないか」「全案件の時間軸が短期に偏っていないか」を定期的にチェックする。
分散されていないポートフォリオは、単一リスクへの過度な集中を意味する。 一つの外部変化で複数案件が同時に影響を受ける構造は、ポートフォリオの意味を失わせる。
経営層向けのポートフォリオレビューの設計
レビュー頻度と参加者の設計
ポートフォリオレビューを経営会議の一部として年1回開催する組織では、機能しないことがほぼ確実だ。四半期ごとの専用セッション(2〜3時間)を設け、全ポートフォリオを俯瞰する場を制度化する。
参加者は経営層(CEO・CFO・事業部長)と全案件の責任者。 経営層が全案件を横断的に評価することで、個別案件の「庇護」と「干渉」の両方を防ぐ 構造になる。案件責任者が全案件を把握することで、横断的な学習も起きやすくなる。
レビューで問うべき5つの問い
効果的なポートフォリオレビューで必ず問うべき問いを5つ示す。
第一に「前回から何を学んだか(仮説の棄却・確認)」。 活動報告ではなく、学習の報告を求める。
第二に「撤退基準に照らして現在地はどこか」。 事前に設定した基準との乖離を確認する。
第三に「このポートフォリオに欠けているリスクカテゴリはあるか」。 分散の観点からの問い直し。
第四に「次の四半期に最もリソースを増やすべき案件はどれか、その根拠は何か」。 積極的な再配分を促す。
第五に「新たに追加すべき探索テーマはあるか」。 ポートフォリオを動的に更新する視点。
イノベーション・ポートフォリオ管理の成熟度モデル
ポートフォリオ管理の成熟度は4段階で評価できる。 レベル1(案件の一覧が存在する)、レベル2(分類と基本的な進捗管理がある)、レベル3(撤退基準と動的リソース配分が機能している)、レベル4(全体のリスク分散と学習指標が経営判断に組み込まれている)。
多くの日本大企業はレベル1〜2の間にある。レベル3への移行で最も重要な変化は、撤退判断が「例外」から「制度」に変わることだ。撤退が制度化された組織では、ゾンビ事業の平均寿命が劇的に短縮する。
イノベーション評価指標の設計については「ROIを超えるイノベーション評価指標の設計」、ポートフォリオ管理の前提となる組織設計については「コーポレート・ベンチャービルダーの構造的優位性」も参照してほしい。
関連するインサイト
参考文献
- Baghai, M., Coley, S. & White, D. The Alchemy of Growth: Practical Insights for Building the Enduring Enterprise, Perseus Books (1999)
- Nagji, B. & Tuff, G. “Managing Your Innovation Portfolio,” Harvard Business Review (May 2012)
- Ries, E. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Crown Business (2011)
- McGrath, R. G. & MacMillan, I. C. “Discovery-Driven Planning,” Harvard Business Review (July–August 1995)
- 経済産業省「新規事業創造の推進に関する研究会 報告書」(2022年)
INNOVATION VOYAGE 編集部
関連記事
フレームワーク
撤退基準の設計法——ゾンビ事業を防ぎリソースを最適配分する実践ガイド
「まだ可能性がある」で延命し続けるゾンビ事業が組織のリソースを圧迫する。感情に依存しない撤退基準の設計と運用の実践ガイド。
2026年4月12日
フレームワーク
ムーンショット型新規事業のガバナンス設計
10年単位の不確実性を抱えるムーンショット型新規事業に、既存事業の管理手法を適用することは設計ミスだ。長期投資に適したガバナンス・評価・撤退基準の設計原則を解説する。
2026年4月6日
フレームワーク
バックキャスティング×SFプロトタイピング——未来から逆算して事業を設計する技法
現状の延長線上にしかアイデアが出ない組織が、「あるべき未来」から逆算して非連続な事業を設計する。バックキャスティングとSFプロトタイピングの実践法。
2026年4月5日