プロダクトロードマップの例:6つの形式と、それぞれの失敗パターン

参考にする価値のあるプロダクトロードマップの例は、6つの形式に分かれる。Now/Next/Later、四半期のタイムライン、テーマ型、アウトカム型、公開ロードマップ、そして社内のリリースロードマップだ。それぞれ違う読者の違う問いに答えるので、選ぶべき例は、自分のロードマップを読む人に合うものになる。見た目のレイアウトを決めるのは最後でいい。

以下の例はすべて、小さなチーム向けタスク管理アプリという架空のプロダクトのもので、項目もすべて作り話だ。注目してほしいのは形のほうである。各スロットに何を書くか、実際のエントリはどんな見た目か、そしてその形式が一四半期後にどこで破綻するか。

良いプロダクトロードマップの例とは

良いロードマップの例は、短く、読者が決まっていて、約束の種類が一つに絞られている。守れる約束に合わせて形式を選ぶ。方向性、日付、取り組みのテーマ、成果、公開のコミットメント、提供スケジュールのどれかだ。

プロダクトロードマップの例は実際どんな見た目か

以下では各形式を現実的なエントリで示し、続けて、誰に向いているか、いつ持ちこたえるか、そしてたいていどう失敗するかを書く。

Now/Next/Later

NOW (今月、開発中)
  受信トレイの保存ビュー
  大規模アカウントで動くCSVエクスポート
NEXT (決定済み、順番は未定)
  Teamプラン向けSSO
  Slack通知
LATER (方向性のみ、約束なし)
  モバイルアプリ
  監査ログ

日付を約束したくない会社に向いており、初期段階のチームの多くに当てはまる。3つの列が確度の違いを表しているので長持ちする。「now」は進行中、「next」は決定済み、「later」は願望だ。破綻するのは、「later」が断りたくないアイデアの置き場になったときと、「next」がいつの間にか順番と日付を持ち、誰もそれをタイムラインと呼ばないまま運用されるときだ。

タイムライン(四半期)ロードマップ

2026年 Q4
  10月  受信トレイの保存ビュー
  11月  デザインパートナー5社とSSOベータ
  12月  SSO一般提供
2027年 Q1
  1月   Slack通知
  3月   監査ログ(エクスポートのみ)

何かに合わせて計画を立てる必要がある営業、サポート、経理に向いている。契約、カンファレンス、コンプライアンスの期限のように、日付が本物の制約であるときに機能する。日付が推測にすぎないと破綻する。ロードマップ上の「何月」は、数週間のうちに営業資料の中で約束に変わってしまうからだ。この形式を使うなら、各四半期に「確定」か「見込み」かを明記し、2四半期目は1四半期目よりはっきりと曖昧に見えるようにする。

テーマ型ロードマップ

THEME: 最初の1週間の体験
  CSVとTrelloからのインポート
  スターターテンプレート
THEME: 大きなチームへの対応
  SSO
  監査ログ
  ロール権限
THEME: 手作業を減らす
  Slack通知
  繰り返しタスク

作業を並べる前に、その作業がなぜあるのかを説明するので、経営層への報告や新入社員向けに向いている。各テーマが顧客の関心の理由に対応しているなら持ちこたえる。テーマが「成長」「品質」のように広すぎて、どの項目もどのテーマにも入ってしまうと破綻する。そうなると、グルーピングは何も説明していない。

アウトカム型ロードマップ

GOAL: セットアップを終える新規チームを増やす
  指標: 7日以内にセットアップ完了、40%から55%
  施策: CSVインポート、スターターテンプレート
GOAL: エクスポート関連のサポート問い合わせを減らす
  指標: 週あたりのエクスポート問い合わせ、30件から10件
  施策: 大規模アカウントのエクスポート修正、エクスポート状況ページ

数字は説明用のものであり、ポイントはレイアウトだ。目標が一つ、開始値と目標値のある指標が一つ、そして試す施策。解決策の選択を任されているプロダクトチームとエンジニアリングチームに向いている。指標が存在し、担当者がいれば機能する。目標が測定できないとき、または「施策」が以前と同じ機能リストに成果の一文を載せただけのときに破綻する。

公開向けの顧客ロードマップ

PLANNED
  受信トレイの保存ビュー
BUILDING
  Slack通知
SHIPPED
  大規模アカウント向けCSVエクスポート

最も小さい形式で、最も強い約束をする。自分の要望が届いたかどうかを知りたい顧客に向いている。項目がごく少なく、日付がなく、タイトルが顧客の言葉で書かれていれば持ちこたえる。バックログの捨て場になると破綻する。載せた「かもしれない」項目は、あとで誰かに問われる約束になる。課題トラッカーから運用する仕組みは3つの列で作る公開ロードマップにあるので、ここでは繰り返さない。

社内リリースロードマップ

何が同時に出荷され、何が何をブロックしているかを知る必要があるエンジニアリング、QA、サポートに向いている。週単位で正確で、各行に担当者がいれば機能する。誰かが戦略と取り違えたときに破綻する。提供スケジュールは、何がいつ出ていくかを示すだけで、そのリリースが正しい賭けだったかどうかについては何も語らない。

どのプロダクトロードマップ形式を選ぶべきか

まず読者で選び、次に実際にどれだけ確度があるかで選ぶ。誰が読み、それがどんな判断に役立つのか答えられないなら、上のどの例を使っても立て直せない。

• 顧客が「私の声は届いた?」と聞いている。 公開形式を使い、項目は数個に絞る。
• 営業とサポートが「顧客に日付を言っていい?」と聞いている。 四半期タイムラインを使い、確定と見込みをはっきり分ける。
• 経営層が「なぜこの作業?」と聞いている。 テーマ型、データがあるならアウトカム型を使う。
• 毎月方向が変わるチーム。 Now/Next/Laterを使い、日付を付けるのを我慢する。
• エンジニアが「何がいつ出る?」と聞いている。 リリースロードマップを使い、戦略のロードマップとは分けておく。

多くのチームは、最終的に2つに落ち着く。最初の4つの形のどれかによる戦略ロードマップと、その下にあるリリーススケジュールだ。公開ロードマップは、戦略ロードマップから、自分たちが責任を持てるものだけを取り出したフィルタ済みのビューになる。

プロダクトロードマップはどう書くか

読者に名前を付け、その人の問いに合う形式を選び、会議で擁護できる項目だけを並べ、各項目にステータスと担当者を付けて書く。そして公開する前に、どのくらいの頻度で見直すかを決める。

1. 読者と判断を決める。「サポートがSSOについて顧客に何と伝えるかを決める」は理由になる。「全員がロードマップを見られるように」では、設計の手がかりがない。
2. すでに知っていることから始める。 未対応の要望を、説明できるルールで順位付けしたものは、ブレインストーミングよりも良い素材になる。
3. 各項目を顧客の成果として書く。「よく使うフィルタを保持する」は「保存ビューの永続化を実装」より読みやすく、それが自分の問題かどうかを顧客に伝える。
4. ロードマップに含めないものを決める。 日付、見積もり、アイデアのバックログが、よくある3つの除外対象だ。
5. 見直しの日を決める。 見直しの予定がないロードマップには、予定のない葬式が待っている。

プロダクトロードマップを最新に保つには

作業が動いたときに、作業を追跡している同じ場所から項目を動かし、項目がリリースされたり取りやめになったりしたときに何が起きたかを記録する。別のツールで手作業で更新するロードマップは、誰の日常業務でもないので古くなる。

最も安上がりな信頼できる情報源は課題トラッカーだ。ロードマップの各列が課題のラベルに対応していれば、ラベルが変わるとロードマップも変わり、何も打ち直す必要がない。Changeloopの方式では roadmap:planned、roadmap:building、roadmap:shipped のラベルを使い、課題に2つ付いている場合は、より進んでいるほうが優先される。カードをshippedに動かすのは、やはり独立したラベル変更なので、チェンジログのエントリを承認するレビューの一部にしておく。

そのエントリが、もう半分だ。項目がリリースされたとき、チェンジログは顧客の言葉で何が変わったかを伝え、それを求めた人にも知らせることができる。このループを閉じることがカスタマーフィードバックループの目的であり、ロードマップは、リリースの前に顧客が見られるそのループの一区間だ。項目を取りやめるなら、そう伝える。公開の「やらない」という答えも、そのリクエストを閉じる。その書き方は機能リクエストを断るで扱っている。完成したエントリがどう読めるかを見たいチームは、チェンジログの例を参照してほしい。

FAQ

最もシンプルなプロダクトロードマップの形式は何か? Now/Next/Laterだ。列は3つで、日付は不要、項目を確度でグループ化する。頻繁に方向を変える小さなチームにとって、恥ずかしい形で大きく間違えにくい形式でもある。

プロダクトロードマップには何項目あるべきか? 思ったより少なくていい。公開ロードマップなら全列を合わせて10項目未満で足り、社内の戦略ロードマップも12項目を超えることはまずない。それ以上は、見出しだけ立派なバックログだ。

プロダクトロードマップに日付を入れるべきか? 日付が本物の制約である場合に限り、それも直近の四半期だけにする。それより先は列かテーマを使う。ロードマップ上の日付は、意図したかどうかにかかわらず、営業の会話の中でコミットメントになる。

プロダクトロードマップとリリース計画の違いは何か? ロードマップは何をなぜ作るつもりかを示し、リリース計画はどのビルドをいつ出荷し、誰が担当するかを示す。ロードマップは戦略が変わると変わり、リリース計画は作業が変わると変わる。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： 開発者向けドキュメント, changelogの例