プロダクトロードマップの作り方｜機能の優先順位を決めて共有する手順

プロダクトロードマップの作り方を調べている人の多くは、「やりたい機能が多すぎて、どれから作ればよいか決められない」「営業や経営の人に、なぜその順番なのかを説明できない」という悩みを抱えています。プロダクトロードマップとは、製品やサービスをこれからどの方向に育てるのか、そのために何をどの順番で手がけるのかを、時間の流れに沿って1枚に整理した計画のことです。大切なのは、機能を日付つきで並べることではなく、なぜその順番なのかが伝わる形にすることです。この記事では、目的と種類の決め方、書く項目、機能の優先順位の付け方、関係者への共有と見直しの手順を、小さな例を使いながら順に説明します。チームで同じロードマップを更新し続ける道具の1つとして、ボードとガントを使い分けられるPinatecaも紹介します。

プロダクトロードマップとは何か

プロダクトロードマップは、製品の行き先と道筋を示す計画です。デザイン会社のグッドパッチは、プロダクトロードマップを次のように説明しています。

プロダクトロードマップとは、プロダクト開発の目標や戦略、スケジュールなどをまとめたものです。 出典: goodpatch.com

ここで押さえておきたいのは、ロードマップには「目標」と「戦略」が含まれていることです。機能の名前とリリースの日付だけが並んだ表は、ロードマップというより開発の予定表です。予定表は、開発チームが作業を進めるためには役立ちますが、「なぜその機能を作るのか」は伝わりません。

ロードマップとよく混同されるものに、プロジェクトの工程表があります。違いを整理すると次のようになります。

比べる点	プロダクトロードマップ	プロジェクトの工程表
主な問い	何を、なぜ、どの順番で	誰が、いつまでに、どの作業を
時間の幅	数か月から1年以上	数週間から数か月
書く単位	解決したい課題、大きな機能のまとまり	個々の作業
読む人	経営、営業、開発、利用者	主に作業を担当する人
変わる頻度	学んだことに合わせて見直す	遅れや変更に合わせて細かく直す

ロードマップは、工程表より粗い単位で、長い時間を扱います。そのため、先の予定ほど確かさが下がることを前提に作ります。半年先の機能に日付まで書き込むと、その日付が約束として受け取られ、計画を変えたいときの足かせになります。

ロードマップを作る目的は、主に次の3つです。1つ目は、チームの判断の基準をそろえることです。新しい要望が来たときに、ロードマップの目標に合うかどうかで受けるかを決められます。2つ目は、関係者に説明することです。営業や経営の人に、今期は何に力を入れ、何を後回しにするのかを伝えられます。3つ目は、利用者との約束の範囲をはっきりさせることです。外に公開するロードマップでは、作る予定のものと、検討しているだけのものを分けて伝えます。

ロードマップの種類を目的で選ぶ

プロダクトロードマップには、いくつかの型があります。誰に何を伝えたいかで、使う型を選びます。

型	中心に書くもの	向いている場面
戦略ロードマップ	目標、狙う成果、大きなテーマ	経営や出資者への説明
リリースロードマップ	リリースの時期と含まれる機能	営業やサポートとの連携
ステータス型ロードマップ	今やっていること、次、その後	変化の大きい初期の製品
ポートフォリオロードマップ	複数の製品をまたいだ計画	製品が2つ以上ある会社
公開ロードマップ	利用者に伝えてよい予定	利用者の要望を集めたいとき

初めて作るなら、ステータス型の形がおすすめです。ステータス型とは、日付の代わりに「今（Now）」「次（Next）」「その後（Later）」の3つの列で整理する形のことです。今の列には取りかかっているもの、次の列には今が終わったら手がけるもの、その後の列には方向として考えているものを並べます。

この形の利点は、先の予定ほど確かさが下がることを、見た目のまま表せることです。今の列は細かく、その後の列は大まかに書けば、読む人は自然に「その後の列はまだ変わりうる」と受け取ります。日付を書かないので、遅れがそのまま約束違反に見えることもありません。

一方で、営業や大きな取引先との約束がある場合は、リリースロードマップのように時期を書く必要があります。その場合でも、時期は「10月から12月」のように幅で書き、日付までは書かないのが一般的なやり方です。

1つの製品で、型を複数持つこともよくあります。社内向けには細かいステータス型を、経営向けには戦略ロードマップを、利用者向けには公開ロードマップを作る、という形です。ただし、元になる情報は1つにしておきます。型ごとに別々に作ると、どれかを直し忘れて内容が食い違います。社内向けの1枚を元にして、見せる範囲を絞ったものを他の人向けに出す、と考えると管理が楽になります。

ロードマップに書く項目

ロードマップに書く項目は、多くしすぎると読まれなくなります。最初は次の6つにしぼります。

1. ビジョン：この製品で、誰のどんな状態を実現したいか
2. 目標：今期に達成したい成果と、それを測る指標
3. テーマ：目標に向けて取り組む課題のまとまり
4. 施策：テーマの中で手がける機能や改善
5. 時期：Now・Next・Laterの列、または四半期などの幅
6. 担当：テーマごとに責任を持つ人

ビジョンは、ロードマップの一番上に1文で書きます。グッドパッチは、ビジョンを考えるときの型として次の文を紹介しています。

現在、（設定したペルソナ）が（ペルソナの願望）と望むとき、彼らは（ペルソナの状況）をしなければならない。この状況は（ペルソナが抱えるであろう課題）のため、受け入れられない。我々は（プロダクトの提供価値によって実現できる状況）を夢見ている。 出典: goodpatch.com

ペルソナとは、製品を使う人の代表的な姿を、名前や状況まで具体的に描いた人物像のことです。この型に当てはめると、たとえば家計簿のアプリなら「今、共働きの夫婦が毎月の出費を2人で把握したいと望むとき、彼らはそれぞれのレシートを週末に持ち寄って入力しなければならない」といった書き方になります。

目標は、測れる形で書きます。「使いやすくする」ではなく、「登録した人のうち、2週間後も使っている人の割合を30%から40%に上げる」のように書くと、施策を選ぶ基準になります。

テーマは、施策をまとめる箱です。「初めて使う人が迷わないようにする」「2人で使う場面を楽にする」のように、課題の形で書きます。機能の名前でテーマを作ると、その機能を作ること自体が目的になってしまいます。

施策は、テーマの下に並べます。1つのテーマに3つから5つ程度にとどめ、細かい作業は工程表やタスク管理の道具に任せます。ロードマップに細かい作業まで書くと、毎週のように書き直す必要が出てきて、ロードマップとしての見通しが失われます。

作り方の手順1：目的と読む人を決める

ここからは、プロダクトロードマップの作り方を手順に沿って説明します。全体の流れは次の6つです。

1. 目的と読む人を決める
2. 課題と要望を集める
3. 優先順位を付ける
4. Now・Next・Laterに並べる
5. 関係者と合意して共有する
6. 決まった間隔で見直す

最初に、このロードマップを何のために作り、誰が読むのかを決めます。開発チームが次に何をするかを決めるためなのか、経営の人に投資の判断をしてもらうためなのか、利用者に今後の予定を伝えるためなのかで、書く粒度も言葉づかいも変わります。

読む人が決まったら、その人が知りたいことを書き出します。経営の人なら「この計画で売上や利用者数がどう動くか」、営業の人なら「次に顧客へ案内できる機能はいつ頃か」、開発チームなら「何をどの順番で作るか、なぜその順番か」が知りたいことです。

あわせて、ロードマップが扱う期間を決めます。初期の製品なら3か月から6か月、ある程度育った製品なら1年を目安にします。期間が長すぎると、その後の列に何でも入ってしまい、整理の意味が薄れます。

この段階で、ビジョンと今期の目標も書いておきます。目標が決まっていないと、次の手順で集めた要望を比べる物差しがありません。目標がまだ決められない場合は、その目標を決めること自体を、最初のテーマにします。

作り方の手順2：課題と要望を集める

次に、ロードマップに載せる候補を集めます。候補の出どころは、主に次の4つです。

• 利用者の声：問い合わせ、アンケート、利用者への聞き取り
• 利用の数字：どの画面で離れる人が多いか、どの機能が使われていないか
• 社内の声：営業、サポート、開発チームが感じている課題
• 事業の都合：法律の改正への対応、契約上の約束、競合の動き

集めるときに大切なのは、要望を「機能」ではなく「課題」として書き留めることです。利用者が「CSVで書き出したい」と言ったとき、その裏には「会計ソフトに取り込みたい」「上司に月ごとの報告を出したい」といった課題があります。課題で書き留めておけば、CSVの書き出し以外の解決方法も検討できます。

集めた候補は、1つの表にまとめます。列は、候補の名前、元になった課題、出どころ、要望の件数、関係するテーマ、の5つから始めると扱いやすくなります。同じ課題から出た候補は1行にまとめ、要望の件数を数えます。

候補の数は、最初は多くても構いません。50件、100件と集まっても、次の手順で優先順位を付ければ、今期に手がけるものは自然に絞られます。むしろ、集める段階で「これは無理だろう」と外してしまうと、大事な課題を見落とすことがあります。

作り方の手順3：機能の優先順位を付ける

ロードマップづくりで最も悩むのが、優先順位の付け方です。感覚だけで決めると、声の大きい人の要望や、作る人が作りたいものが先に来てしまいます。数字で比べる方法を使うと、判断の理由を説明しやすくなります。

広く知られている方法の1つが、RICEという計算です。RICEは、顧客とのやりとりの製品を作るIntercom社が考えた方法で、Intercom社の解説では次の4つの要素で候補を比べるとしています。

要素	意味	数え方の例
Reach（届く人数）	一定の期間に、その施策が影響する人数	四半期あたり何人か
Impact（効き目）	1人あたりにどれだけ効くか	3＝非常に大きい、2＝大きい、1＝中くらい、0.5＝小さい、0.25＝ごく小さい
Confidence（確かさ）	上の見積もりにどれだけ自信があるか	100%＝高い、80%＝中くらい、50%＝低い
Effort（手間）	作るのにかかる人数と期間	1人が1か月働く量を1とする

計算は「届く人数×効き目×確かさ÷手間」です。小さな例で計算してみます。

候補	届く人数	効き目	確かさ	手間	点数
A：初回の案内画面を作り直す	1,200	1	80%	2	480
B：2人で同じ家計簿を見られるようにする	300	3	50%	4	112.5
C：CSVで書き出せるようにする	200	1	100%	0.5	400

Aは、1,200×1×0.8÷2で480点です。Bは、300×3×0.5÷4で112.5点、Cは、200×1×1.0÷0.5で400点になります。この計算だけで見ると、Aが先、次にC、Bは後回しという順番になります。

ただし、点数はそのまま答えにするものではありません。Bはビジョンに直結する機能で、確かさが低いのは「まだ試していないから」かもしれません。その場合は、Bを丸ごと作る前に、小さく試して確かさを上げる施策を「次」の列に入れる、という判断ができます。点数は、話し合いの出発点として使うと効き目があります。

ほかにも、候補を「必ず要る」「あるとよい」「今回は入れない」に分ける方法や、効き目と手間の2つの軸で4つのマスに分ける方法もあります。どの方法を使う場合でも、「何を基準に順番を決めたか」を残しておくことが大切です。後から「なぜこれが後回しなのか」と聞かれたときに、基準を示せば説明できます。

作り方の手順4：Now・Next・Laterに並べる

優先順位が決まったら、候補をNow・Next・Laterの3つの列に並べます。並べ方の目安は次のとおりです。

• Now：今取りかかっているもの。担当と、終わったと判断する基準が決まっている
• Next：Nowが終わったら手がけるもの。課題と大まかな解決の方向が決まっている
• Later：方向として考えているもの。課題だけが書かれていればよい

それぞれの列に入れる数には上限を設けます。Nowはチームが同時に進められる数まで、たとえば3つから5つにします。Nextも同じくらいの数に抑えます。Laterに上限はありませんが、20を超えるようなら、本当に検討するものだけを残します。

並べたら、各列の施策がどのテーマと目標につながっているかを書き添えます。読む人は、「この施策は、どの目標のためにあるのか」が分かると、順番に納得しやすくなります。テーマごとに色を分けると、どのテーマに力を入れているかが一目で分かります。

日付が必要な場合は、Nowの列にだけ「11月中」のような幅を書き、NextとLaterには書かないのが無難です。営業との約束などでNextにも時期が必要なら、四半期の単位で幅を持たせて書きます。

最後に、ロードマップに載せなかった候補も、別の一覧として残しておきます。載せなかった理由を一言添えておけば、同じ要望がまた来たときに、前に検討した経緯を示せます。

作り方の手順5：関係者と合意して共有する

ロードマップは、作った人だけが分かっていても意味がありません。関係者に見てもらい、合意を得てから共有します。

合意の場では、施策の順番そのものより、目標と優先順位の基準について話し合います。基準に納得してもらえれば、個々の施策の順番は自然に受け入れられます。逆に、基準を示さずに順番だけを見せると、「自分の要望がなぜ後回しなのか」という議論が施策ごとに始まり、話がまとまりません。

共有するときは、読む人ごとに見せる範囲を決めます。

読む人	見せる範囲	伝えること
開発チーム	すべての列と施策、担当	何をどの順番で作るか
営業・サポート	Now と Next の施策、時期の幅	顧客に案内できる時期
経営	ビジョン、目標、テーマ	力を入れる分野と期待する成果
利用者	Now と一部の Next	改善の方向と、要望の受け付け先

利用者にロードマップを公開する場合は、「予定は変わることがあります」と必ず書き添えます。公開した内容は、利用者にとって約束に近いものとして受け取られます。検討の段階にあるものは、公開しないか、検討中であることをはっきり書きます。

共有の方法は、資料を配るより、いつでも同じ場所で最新を見られる形にするのが理想です。資料を配ると、古い版が手元に残り、「前に聞いた話と違う」という行き違いが起きやすくなります。

作り方の手順6：決まった間隔で見直す

ロードマップは、作って終わりではありません。学んだことに合わせて見直していくものです。グッドパッチも、作り方の最後の段階に「定期的なレビューと改善」を挙げています。

見直しの間隔は、初期の製品なら2週間から1か月ごと、育った製品なら四半期ごとが目安です。見直しでは次の4つを確かめます。

1. Nowの施策は進んでいるか、終わったものは目標にどう効いたか
2. 新しく集まった課題や要望の中に、順番を変えるべきものはないか
3. 確かさが低かった施策について、試して分かったことはあるか
4. 目標そのものを見直す必要はないか

終わった施策は、ロードマップから消すのではなく、「終わったもの」の列に移して結果を書き添えます。何を作り、どれだけ効いたかが残っていれば、次の優先順位を付けるときの確かさの見積もりに使えます。

見直しで順番を変えたときは、変えた理由を関係者に伝えます。理由を伝えずに順番が変わると、ロードマップへの信頼が下がり、誰も見なくなります。「利用者への聞き取りで、Bの課題の方が深刻だと分かったため、Bを次に上げました」のように、1文で構いません。

完成したロードマップの例

ここまでの手順を、先ほどの家計簿アプリの例に当てはめて、完成した形を見てみます。文章で書くと次のようになります。

ビジョンは「共働きの夫婦が、週末にレシートを持ち寄らなくても、毎月の出費を2人で把握できる状態を作る」です。今期の目標は「登録した人のうち、2週間後も使っている人の割合を30%から40%に上げる」と、「2人で使っている世帯を全体の10%から20%にする」の2つです。

テーマは3つ立てます。1つ目は「初めて使う人が迷わないようにする」、2つ目は「2人で使う場面を楽にする」、3つ目は「ほかの道具とつなぐ」です。

Nowの列には、1つ目のテーマから「初回の案内画面を作り直す」と、2つ目のテーマから「2人で使う機能の小さな試作を、希望した20世帯に試してもらう」を入れます。後者は、RICEの計算で確かさが低かった候補Bを、丸ごと作る前に確かめるための施策です。

Nextの列には、3つ目のテーマから「会計ソフトへの取り込みを楽にする（CSVで書き出せるようにする）」と、試作の結果がよければ「2人で同じ家計簿を見られるようにする」を入れます。Laterの列には、「レシートを撮影して自動で入力する」「月ごとの振り返りを自動で作る」など、方向として考えているものを課題の形で並べます。

この例で大切なのは、Nowの施策がどちらも目標に直結していることと、確かさの低い大きな施策を、小さく試す施策に置き換えて先に進めていることです。読む人は、なぜ候補Bがすぐに作られないのかを、この並びから読み取れます。

ロードマップづくりでよくある失敗

ロードマップを作っても、うまく使われないことがあります。よくある失敗と、その対処を整理しておきます。

1つ目は、要望の一覧がそのままロードマップになってしまうことです。集めた要望を全部並べただけでは、何を後回しにするのかが分かりません。ロードマップの役目は、やることを決めることと同じくらい、やらないことを決めることにあります。手順3で優先順位を付け、載せなかったものは別の一覧に移します。

2つ目は、日付が約束になってしまうことです。営業の人が、ロードマップに書かれた日付をそのまま顧客に伝え、遅れたときに信頼を損ねる、という形です。外に出る可能性のある場所には日付を書かず、幅で書くか、Now・Next・Laterで示します。時期を伝えるときは、社内で「顧客に伝えてよい時期」を別に決めておきます。

3つ目は、作った人しか更新しないことです。担当者が忙しくなると更新が止まり、実際の開発とロードマップがずれていきます。テーマごとに担当を決め、担当が自分のテーマの施策を更新する形にすると、1人に負担が集まりません。

4つ目は、見直しの場がないことです。決まった間隔で見直す会議が予定に入っていないと、ロードマップは作ったときのまま放置されます。最初に作った時点で、次の見直しの日を決めておきます。

5つ目は、終わった施策の結果を確かめないことです。作った機能が目標にどれだけ効いたかを確かめないと、次の優先順位を付けるときの確かさが上がりません。手順6のとおり、終わった施策には結果を書き添えます。

表計算で作るか、ツールで作るか

プロダクトロードマップは、専用のツールがなくても作れます。始めるときは、表計算のシートで十分なことも多いです。

表計算で作る場合は、次の2つのシートを用意します。1つは候補の一覧で、手順2と手順3の表を兼ねます。候補の名前、課題、出どころ、要望の件数、テーマ、RICEの4つの数字と点数の列を作り、点数の列に計算式を入れておけば、数字を入れるだけで順番が出ます。もう1つはロードマップの本体で、Now・Next・Laterの3つの列に施策を並べます。

表計算の利点は、無料で始められ、誰でも扱えることです。計算式で点数を自動で出せるのも便利です。一方で、次のような場面では負担が大きくなります。

• 複数の人が同時に書き換えて、どれが最新か分からなくなる
• 施策を列から列へ動かすたびに、行を切り取って貼り直す必要がある
• 施策ごとの話し合いが、メールやチャットに散らばって追えなくなる
• 時期の重なりを見たいときに、別に工程表を作る必要がある

チームで同じロードマップを更新し続けたいときの候補

表計算での管理が負担になってきたときの選択肢の1つが、Pinatecaです。公式サイトによると、Pinatecaにはカンバン、ガント、カレンダー、リスト、ディスカッション、グリッド、時間割、リソースの8種類のボードがあり、すべての種類が無料のプランから使えます。カンバンのボードに「Now」「Next」「Later」の列を作って施策をカードとして並べれば、順番が変わったときもカードを動かすだけで済みます。時期の重なりを見たいときは、期間を横棒で並べるガントのボードを使えます。

カードごとにコメントを残せるので、施策についての話し合いを、その施策のすぐ隣に残せます。権限のロールを自作でき、社外のゲストには見せる範囲を絞れるため、読む人ごとに見せる範囲を分けたいときにも使えます。料金は、5人までのチームならボード10個まで無料で、6人目または11個目のボードからはスタンダードプラン（1人あたり月額500円、税抜。年払いなら1人あたり月額400円）になります。閲覧だけのゲストは人数に数えません。

Pinatecaは、@SOHOを運営する株式会社ライフスケープが開発・提供しています。

どの道具を使う場合でも、ロードマップの中身は、ここまでの手順で決めた目標、テーマ、優先順位の基準が支えています。道具を替えても、基準がなければロードマップは定まりません。

プロダクトロードマップを作るときのポイント

最後に、作り方の手順を通して気をつけたいポイントを整理します。

1つ目は、機能ではなく課題で書くことです。施策の名前を「CSV書き出し」ではなく「会計ソフトへの取り込みを楽にする」と書くと、解決の方法を後から選び直せます。

2つ目は、詰め込みすぎないことです。1枚に収まらないロードマップは、読まれません。Nowの列は3つから5つ、全体でも1画面で見渡せる量を目安にします。

3つ目は、先の予定ほど粗く書くことです。その後の列に細かい仕様まで書くと、変えにくくなります。

4つ目は、今のチームの人数と技能で実現できるかを確かめることです。優先順位の高い施策でも、必要な技能を持つ人がいなければ進みません。足りない技能がある場合は、外部の人に頼むことも含めて計画します。

5つ目は、ロードマップを1つにすることです。部署ごとに別々のロードマップがあると、どれが正しいのか分からなくなります。元になる1枚を決め、そこから見せる範囲を絞ったものを配ります。

6つ目は、読む人の言葉で書くことです。開発チームの中だけで通じる略語や機能の内部の呼び名を使うと、営業や経営の人には何の話か分かりません。施策の名前は、利用者に説明するときと同じ言葉で書きます。たとえば「認証の改修」ではなく「ログインの手間を減らす」と書けば、誰が読んでも目的が伝わります。言葉をそろえておくと、利用者向けの公開ロードマップを作るときにも、書き直す手間がほとんどかかりません。

外部の人とロードマップを共有するとき

小さな会社や個人の製品では、開発やデザインを外部のフリーランスに頼むことがよくあります。外部の人と働くときこそ、ロードマップが役立ちます。

外部の人は、社内の会議に毎回出ているわけではありません。何を、なぜ作るのかを口頭で伝えるだけでは、意図が伝わりきらないことがあります。ロードマップを見せれば、依頼する施策がどの目標につながっているかが伝わり、細かい判断を任せやすくなります。

アプリの開発を外部に頼むときの仕事の中身は、アプリケーション開発のお仕事で、依頼される作業の種類や求められる技能とあわせて紹介しています。画面の設計を頼む場合は、デザイナーの年収・単価相場で、デザインの仕事の相場を確かめられます。予算を組むときの目安になります。

外部の人に共有するときは、手順5の表のとおり、見せる範囲を決めます。依頼する施策と、それにつながるテーマと目標までを見せ、ほかの施策や社内の事情は見せない、という分け方が一般的です。

また、製品の方向性そのものを外部の専門家と一緒に考える場合もあります。AIを使った機能を検討するときの相談相手については、AIコンサル・業務活用支援のお仕事で、どのような支援が依頼されているかを紹介しています。事業の計画全体を見直したい場合は、経営の助言を行う国家資格である中小企業診断士の仕事の中身も参考になります。

外部の人と製品を育ててきた現場から見えること

フリーランスや在宅ワークの仲介を2004年から続けてきた運営者として見てきた限りでは、外部の人と長く良い関係を続けている発注者ほど、作業の指示より先に「何のために作るのか」を共有しています。ロードマップのように目標と順番の理由が1枚にまとまっていると、受ける側は依頼された作業の前後まで考えて提案できるようになり、仕事の質が上がります。逆に、作業だけを切り出して頼み続けると、受ける側は言われたことだけをこなすようになり、発注者が細かく確かめる手間が増えていきます。

もう1つの実感は、仲介の手数料がかからない直接の取引のほうが、こうした関係を育てやすいということです。同じ予算でより多くの作業を頼め、受ける側も手取りが厚くなるので、1回限りではなく、ロードマップの次の施策まで続けて担当してもらう関係を作りやすくなります。プロダクトロードマップは、社内の計画であると同時に、外部の人と同じ方向を向いて働くための道具でもあります。

まずは、ビジョンを1文で書き、今の候補を課題の形で一覧にするところから始めてください。

よくある質問

Q. プロダクトロードマップは誰が作るものですか？

一般にはプロダクトマネージャーが中心になって作りますが、専任の人がいない小さなチームでは、製品の責任者や代表者が作ることも多くあります。どの場合でも、開発、営業、サポートなど関係する人から課題や要望を集め、優先順位の基準について合意を得ながら作ると、作った後に使われるロードマップになります。

Q. ロードマップに日付は書くべきですか？

初めて作るなら、日付の代わりに「今」「次」「その後」の3つの列で整理する形がおすすめです。先の予定ほど確かさが下がるため、日付を書くと約束として受け取られ、計画を変えにくくなります。営業との約束などで時期が必要な場合も、日付ではなく「10月から12月」のように幅で書くのが一般的です。

Q. 優先順位はどうやって決めればよいですか？

感覚だけで決めず、基準を数字にすると説明しやすくなります。よく使われるのがRICEという方法で、届く人数、1人あたりの効き目、見積もりの確かさを掛け合わせ、作る手間で割って点数を出します。点数はそのまま答えにせず、目標との関係も見ながら、話し合いの出発点として使います。

Q. ロードマップはどのくらいの間隔で見直せばよいですか？

初期の製品なら2週間から1か月ごと、ある程度育った製品なら四半期ごとが目安です。見直しでは、進んでいる施策の状況、新しく集まった要望、試して分かったこと、目標そのものの妥当性を確かめます。順番を変えたときは、変えた理由を1文で関係者に伝えると、ロードマップへの信頼を保てます。