ロードマップとスケジュールの違いとは？

ロードマップは、製品をどの方向へ、どんな順序で改善するかを共有する計画です。スケジュールは、具体的な作業をいつ進めるかを共有する計画です。どちらも将来を扱いますが、答えたい問いが異なります。

例えば「ロードマップを見せてほしい」と言われて作業日程を渡しても、相手が知りたかったのは「製品をどう良くするのか」かもしれません。計画の話がかみ合わないときは、見たい情報を確かめます。

この記事では、製品開発で使う2つの計画を、同じ架空例で比べます。会社によって呼び方や書式は違うため、名前だけでなく、何を伝える資料なのかを確かめましょう。

大きな違いは「何を説明するか」

ロードマップで伝えたいのは、目指す変化と、そのために取り組むことのつながりです。「この機能を作る」という項目だけでなく、誰のどんな困りごとを減らしたいかが分かると、取り組む理由を共有できます。

英国政府のGOV.UKのロードマップ作成ガイドも、達成したいことと、そこへ向かう段階を分かりやすく示す方針を説明しています。優先順位が変わったときに調整できることも重視されています。

一方、作業を進める段階では、「確認はいつまでか」「前の作業が終わらないと何が始められないか」など、日程の情報が必要です。そのためにスケジュールを使います。英国のプロジェクトマネジメント専門団体APMも、スケジュールの解説で、作業や出来事の開始・終了の見込みを表すものと説明しています。

これは使い分けのための整理です。ロードマップに担当者を書くことも、スケジュールに目的を添えることもできます。含める項目だけで、二者を機械的に分類する必要はありません。

同じ改善計画を、2つの見方で表す

ここからは、架空の予約管理サービスの例です。実在する企業やアーコレ！の開発予定ではありません。

受付担当者から「予約を変更するとき、空いている時間を探しにくい」という声が届きました。チームは、予約変更の作業を分かりやすくする方向で検討しています。

ロードマップでは、例えば次のように表せます。

この表では、「まず困る場面を調べ、次に画面案を試す」という考え方が見えます。下にある項目ほど必ず実装する、という意味ではありません。調べた結果によって内容も順序も見直します。

そのうち「画面案を試す」作業を具体化したら、スケジュールは次のようになります。

こちらは作業の段取りを確認する表です。第1週から第3週という日程も説明用の仮定で、標準的な所要期間を示すものではありません。

同じ改善を、ロードマップでは「目的と順序」、スケジュールでは「実行する作業と日程」から見ています。どちらか一方が正しく、もう一方が不要という関係ではありません。

日付があるかどうかだけでは決まらない

「日付がないのがロードマップ、あるのがスケジュール」と覚えると、実際の資料で迷いやすくなります。ロードマップにも四半期などの時期を載せる形式があります。GOV.UKのガイドでも、取り組みを時間軸上に置く方法を扱っています。

大切なのは、書かれた時期の意味です。「検討を始めたい時期」「試したい時期」「提供を目指す時期」を、同じ表示でまとめないようにします。

また、スケジュールに書いた日付も、すべて確定とは限りません。担当者の確認前なのか、他の作業の完了を待っているのかで、変わる可能性は違います。見込みなら、その前提を添えておきます。

外部へ時期を伝える際は、社内で置いた仮の日付を、そのまま提供日の約束として案内しないことが必要です。公開する情報の範囲は、公開ロードマップの運用方法で詳しく説明しています。

まず、相手の質問を一文にする

どちらを作るか迷ったら、「相手は何を知りたいのか」を一文で書いてみてください。

• 「今後どんな業務を便利にするのか知りたい」なら、改善の方向を示すロードマップが入口になります。
• 「画面の確認をいつ頼まれるか知りたい」なら、作業の日程が分かるスケジュールを見せます。
• 「なぜ遅れ、その後の計画がどう変わるか知りたい」なら、両方を使って説明します。

担当者は、まず一つの改善候補を選び、「良くしたいこと」と「次に行う作業」を別々に書くだけでもかまいません。作業だけが並ぶなら目的を、目的だけで動けないなら日程や担当を補います。

ロードマップの形式を選んで作る段階では、プロダクトロードマップの作り方へ進めます。実装する作業を具体化したい場合は、改善要望を開発チケットにする方法が参考になります。

まとめ

ロードマップは改善の方向と順序を、スケジュールは具体的な作業と日程を共有します。違いは日付の有無だけではなく、どんな問いに答えるかです。まず相手の知りたいことを確かめ、必要な詳しさの計画を選びましょう。