機能ロードマップ

複数の機能を予定表に並べると、関係者は将来の提供内容を確認できます。
機能ロードマップ（Feature roadmap）は、追加、変更、終了する機能の方向と順序を時間軸で示す計画です。
ただし、機能名だけを並べると、何の成果を目指して順序を決めたかが伝わりません。

機能ごとに目的を結びつける

たとえば、文書共有サービスで、全文検索、権限管理、更新通知を順に提供する案を考えます。
どれも要望があるとしても、探せないことが問題なのか、権限が不安で文書を置けないことが問題なのかで優先順位は変わります。
各機能に対象者、解く問題、確認する変化を添えます。
全文検索なら、検索回数の増加より、必要な文書を見つけて仕事を終えられるかを確かめます。

Roman Pichlerの戦略フレームワークでは、ロードマップに製品の目標と主要機能を結びつけています。
この関係を保つと、目標に役立たないとわかった機能を、別の手段へ置き換えられます。
機能の名前を約束したか、解く問題を約束したかによって、変更の説明も異なります。

順序と依存関係を示す

権限管理の前提として、組織と利用者のデータを整える必要があるかもしれません。
こうした依存関係を省くと、目に見える機能だけが開発対象に見え、必要な基盤作業が遅れます。
利用者に見せる図とは別に、開発と運用の担当者が確認できる依存関係を残します。
他社サービスとの連携なら、相手の提供時期も自社の確定日と区別します。

遠い将来まで月日を確定すると、不確実性の高い案まで納期の約束として受け取られやすくなります。
調査中、方針決定、開発中などの状態を示し、日付が目安か契約上の期限かを明確にします。
見込みが変わったら、日付だけを後ろへずらさず、理由と対象顧客への影響を説明します。

公開前に変える余地を確認する

営業がロードマップを使う場合、何を顧客に約束できるかを合わせます。
特定顧客への契約上の約束がある機能と、候補段階の機能を混ぜると、後から中止できなくなります。
公開範囲と更新責任者を決め、古い版が使われ続けないようにします。
ロードマップの更新頻度は、判断に必要な情報が変わる速さに合わせます。

機能の完成率だけで進展を測らず、提供後に問題が軽くなったかを確認します。
詳細な作業の管理とは分け、プロダクトロードマップで事業上の目標と整合させます。
技術の準備期間が順序を左右する場合は技術ロードマップとも結びつけます。

参考資料