プロダクトロードマップのイノベーション阻害——既存製品改善が探索投資を食い尽くす構造

新規事業のアイデアが生まれ、チームが動き始め、プロトタイプができる。ここまでは順調だ。しかし次のフェーズで何かが起きる。「この機能を本番に組み込むには、開発チームのリソースが必要だ。ただ、開発チームは次の2四半期でロードマップの案件を消化しなければならない。後ろは詰まっている。」

こうして新規探索は「優先度が下がる」ではなく、「ロードマップが埋まっている」という理由で止まる。これは個人の判断ではなく、ロードマップという計画ツールが持つ構造的な重力だ。

ロードマップがコミットメントになる瞬間

プロダクトロードマップが問題を引き起こすのは、それが「計画」ではなく「約束」として扱われ始めるときだ。

営業チームが顧客に「次の四半期でこの機能が入ります」と伝えた瞬間、ロードマップのその項目は対外的なコミットメントになる。開発が遅れれば顧客からのクレームになり、優先順位を変えれば営業との摩擦が生じる。ロードマップの硬直化は、顧客への約束が積み重なることで静かに進行する。

同じプロセスが四半期ごとに繰り返されると、ロードマップは常に「直近の顧客コミットメント」で埋まり、探索的な活動のための空白が生まれない。これは担当者が探索を怠っているわけではなく、ロードマップを管理する仕組みが探索への投資を物理的に排除する構造になっているということだ。

「確定」と「探索」の同一フレームでの管理

プロダクトロードマップが探索を阻害する第二の理由は、確定した開発案件と探索的な実験を同一の管理フレームで扱おうとするときに生じる。

確定した機能開発には、工数見積もり・デリバリー期日・リソース割り当てが必要だ。探索的な実験には、これらが定義できない。探索の本質は「何が価値を持つか分からない状態で動く」ことだからだ。

この二つを同一のロードマップ管理プロセスに通そうとすると、探索案件は「工数・期日・ROIが書けない」として会議に出てこられなくなる。確定案件の管理に最適化されたプロセスは、定義できない探索を自動的に排除する。 テクノロジーロードマップの幻想で論じた長期計画の問題と構造は同じだ——計画できるものだけが計画の中に入る。

既存製品の「技術負債返済」が探索を駆逐する

大企業の開発チームが抱えるもう一つの重力は、技術負債の返済だ。既存製品が成長するにつれ、過去の設計判断の蓄積による技術的負債が積み上がり、新機能追加のたびに「リファクタリング」が必要になる。

技術負債の返済はロードマップに記載されないことが多いが、開発速度を下げる形でリソースを消費する。探索的なプロジェクトに回せるエンジニアリング・キャパシティは、見えないコストによってさらに圧縮される。

これは両利きの経営の実装落とし穴で指摘した「活用が探索のリソースを食う」構造と同根だ。ロードマップは活用（既存製品改善）を可視化し管理するが、その管理の精度が高いほど、探索への余地が見えにくくなる。

ロードマップの「先を空ける」設計

ロードマップとイノベーション探索を両立させるための実践は、ロードマップの時間軸に意図的な「空白」を設けることだ。

ある企業では、ロードマップを3層に分けて管理する。直近3ヶ月は「確定層（Committed）」として詳細な工数・担当が決まっている。3〜9ヶ月先は「方向層（Directional）」として機能の方向性のみ示す。9ヶ月以降は「探索層（Exploratory）」として空白のままにし、ロードマップの外でのプロトタイピング・実験に使える期間として確保する。

この設計は、先の期間ほど不確実性が高いという現実を反映している。そして「空白」という明示的な設計がなければ、その期間は他のコミットメントで自然に埋まる。

エンジニアリング・スラック（余白）の制度設計

探索のためのリソースをロードマップ管理の外に確保するもう一つのアプローチは、エンジニアリングリソースの一定割合を「探索専用枠」として制度設計することだ。

Googleの「20%ルール」は有名な事例だが、大企業での実装は難しい。より現実的なのは、チーム単位ではなく「四半期ごとの開発スプリントの中に探索スプリントを義務付ける」設計だ。10本のスプリントのうち1本を「ロードマップに縛られない実験」に使うというルールを、プロセス設計として組み込む。

これがない状態では、探索活動は「業務時間外にやる」か「稟議を通してリソースを確保する」しかない。いずれも持続可能ではなく、イノベーション推進担当の孤立トラップの温床になる。

ロードマップが「視野」になる問題

プロダクトロードマップの最も深い問題は、それが計画ツールを超えて「組織の視野」になることだ。

ロードマップに載っていない活動は「存在しない」として扱われ始める。チームの会話は「ロードマップの中の何をどう進めるか」になり、「ロードマップの外に何があるか」という問いが立たなくなる。

新規事業の機会は、定義上、まだロードマップに載っていない。ロードマップが組織の視野を構成するとき、その外にある機会は「見えない」ではなく「存在しない」として処理される。これはロードマップが機能しすぎることによる失調であり、ツールの適用範囲の設計問題だ。