プロダクトロードマップ

今後作るものを共有するとき、詳細な作業一覧だけでは、事業として何を変えたいかが伝わりません。
プロダクトロードマップは、製品の戦略を、時間の見通しと段階的な目標に結びつける計画です。
Roman Pichlerの整理では、ビジョン、戦略、ロードマップ、バックログをそれぞれ異なる粒度で結びつけています。

機能の前に目標を置く

たとえば、配送管理サービスで、まず初回設定の負担を減らし、次に日々の配車を安定させ、その後に複数拠点へ展開する案を考えます。
それぞれの時期に、対象顧客と確かめる結果を示します。
初回設定の改善なら、設定画面を公開することに加えて、担当者が自力で初回の配送を登録できるかを確認します。
そのための手段として、データの取り込みや案内の改善を検討します。

目標を置くと、調査で不要とわかった機能を別の方法に置き換えられます。
一方、特定の連携が契約上の条件なら、手段も含めて約束しているため自由には変えられません。
顧客との確約、社内の目標、探索中の候補を区別して表します。
すべてを同じ確度の日付に載せると、将来の案まで納期として伝わります。

時間の見通しと依存関係

近い時期は具体的にし、遠い時期は幅のある見通しにする方法があります。
時期を示す際は、技術の準備、顧客の契約更新、販売支援など、前提となる条件を記録します。
配送の例なら、複数拠点への展開の前に、権限管理と問い合わせ体制が必要かもしれません。
顧客に見える機能だけで計画すると、提供を支える作業が抜けます。

ロードマップと詳細な開発計画は、更新の粒度を分けます。
作業の分解や順序を変えただけで、事業の目標まで変えたことにしないようにします。
逆に、顧客の問題自体が違うとわかったなら、目標と戦略へ戻って見直します。
変更の理由と影響を残すと、関係者が新しい判断を理解できます。

更新と評価

更新の担当者と、見直す機会を決めます。
予定日を過ぎたかだけでなく、得られた証拠によって見通しが変わったかを確認します。
公開した機能の数と、顧客の仕事が改善したことを別々に測ります。
期限が決まっている仕事では、達成する結果と、必要な最低範囲の調整も行います。

ロードマップは未来を保証する文書ではありませんが、説明のない変更を正当化する道具でもありません。
約束の範囲を明確にして、変更が必要になったときに適切な相手へ共有します。
機能中心の表示は機能ロードマップ、技術の準備は技術ロードマップ、投資の配分はポートフォリオ管理を参照してください。

参考資料