仮説としてのロードマップ

ロードマップは約束の一覧ではありません。未来に対する仮説の集合です。

もちろん、組織には計画が必要です。営業は顧客と会話する材料が必要ですし、経営は投資判断をしなければなりません。開発チームも、次にどの領域へ向かうのかを知らなければ準備ができません。

問題は、ロードマップを「決定済みの納品計画」として扱うことです。そうなると、状況が変わっても学びが得られても、計画を守ることが目的になります。

ロードマップに書くべきもの

仮説としてのロードマップでは、機能名だけでなく、次の情報を一緒に置きます。

  • 狙っている顧客またはセグメント
  • 解決したい問題
  • 期待しているアウトカム
  • 主要なリスクや不確実性
  • 検証の方法

たとえば「管理者向けダッシュボード」とだけ書くと、作るものが固定されます。一方で「管理者が異常に早く気づき、問い合わせ前に対応できる状態を作る」と書くと、通知、レポート、権限設計、運用フローなど複数の選択肢が見えます。

時間軸の置き方

遠い未来ほど不確実性は高くなります。そのため、ロードマップは細かい日付で埋めるよりも、確度に応じて粗く置くほうが扱いやすくなります。

  • Now: いま取り組んでいるもの
  • Next: 次に検証したいもの
  • Later: 重要だが、まだ学びが足りないもの

このような分け方にすると、チームは「いつ出すか」だけでなく「どれだけ確からしいか」を話せます。

約束が必要なとき

顧客や社内都合で、どうしても期限つきの約束が必要なことはあります。その場合でも、すべてを約束にしないことが大切です。

約束するものは明確に絞り、それ以外は仮説として扱います。約束したものについても、何をもって完了とするのか、どこまでが範囲なのか、前提が崩れたときにどう見直すのかを確認しておきます。

ロードマップは、未来を固定するための道具ではありません。不確実な未来に対して、今どの順番で学ぶかをそろえるための道具です。