プロダクトロードマップのテンプレートと記入例

プロダクトロードマップのテンプレートには、施策名だけでなく、誰の何を良くしたいか、今どの段階か、何が分かれば見直すかを記入します。予定をきれいに並べるより、読み手が判断の背景を確かめられることを目指します。

この記事では、社内の関係者が共有するための空欄テンプレートと、記入済みの架空例を用意します。形式の選び方から知りたい場合は、プロダクトロードマップの作り方を参照してください。

テンプレートを埋める前に、読み手を決める

同じロードマップでも、経営側は事業目標とのつながりを、開発側は依存する作業を、営業・CSは顧客へ説明できる範囲を知りたいかもしれません。誰に何を判断してもらう表なのかを、表の上に一文で書きます。

たとえば「企画・開発・CSが、月末集計の改善で次に確かめることを共有するための表」とします。この段階では社内向けです。顧客名や内部の見積もりを入れた表を、そのまま外部公開するものではありません。

GOV.UKのロードマップ作成ガイドは、目指す価値や優先順位を伝え、変化に合わせて調整できる、分かりやすいロードマップを勧めています。以下はその観点を参考にした本記事の記入様式で、特定の開発手法に必須の様式ではありません。

コピーして使える空欄テンプレート

最初に表全体の前提を置きます。更新する人と正本の場所を決めておくと、古い資料だけが残るのを防ぎやすくなります。

次の表を、改善テーマごとに複製します。最初は一つのテーマで構いません。

欄が埋まらないときは、確認できていない内容を想像で補いません。「対象者は確認済み、発生する頻度は未確認」のように書くと、次の調査を選べます。

記入例：月末集計の手作業を減らす

以下は、架空の申請管理ツールを想定した社内向けの例です。根拠ID、担当の役割、機能、期間は説明用で、アーコレ！や実在企業の計画・実績を示すものではありません。

この表の用途は「企画・開発・CSが、月末集計の改善で次に進める作業を共有すること」。目指す変化は「担当者が同じ条件を入力し直す手間と、結果を確認し直す手間を減らすこと」とします。

この例では、次の順序と確かめ方も添えます。順序は機能の公開順を約束するものではなく、今の段階で進める調査や設計の関係です。

根拠の欄にIDを置くのは、詳しい記録に戻れるようにするためです。「多くの顧客が希望」のように広く書くより、どの記録から考えたテーマなのかを残します。

時期は、決まったことと見込みを分ける

上の表に時期を加えるなら、別の列や補足表で前提を示します。「来月」とだけ書くと、調査の予定なのか公開予定なのか分かりません。

日付を書いてはいけないわけではありません。契約上の期限などがある場合は、その条件を社内で確認し、単なる見込みと区別します。遠い将来の項目まで同じ精度の公開日を置く必要はありません。

項目を増やす前に、状態の意味をそろえる

「検討中」「進行中」といった状態は、チーム内で意味をそろえます。たとえば「調査中」は判断材料を集める段階、「実装中」は実装作業を進めると決めた段階、と区別できます。これは本記事の例であり、すべての会社に同じ状態名が必要なわけではありません。

状態だけでなく、次の判断も添えます。「調査中」のまま止まっているなら、調査の担当や確認時点が決まっているかを見直してください。候補を比べる必要がある場合は、機能の優先順位の決め方に戻れます。

外部向けに見せる場合は、社内の表から公開用を別に作り、顧客情報、内部の判断、約束に見える表現を確認します。公開ロードマップの運用方法では、見せる範囲と更新の考え方を扱っています。

まずは一つのテーマを埋め、見直して使う

最初の一枚では、テーマを多く並べるより、一つについて「目的・根拠・次の行動・見直す条件」を書いてみましょう。別の担当者に読んでもらい、次に誰が何をするか分かるかを確認します。

機能を提供した後は、項目を完了に変えるだけで終えず、目指した変化を確かめます。機能改善の効果を確かめる方法も参考に、結果を次のロードマップ更新へ戻します。テンプレートは一度完成させる書類ではなく、判断の変化を残すための表として使いましょう。