-1.jpeg?width=48&height=48&name=DSC_2387%20(1)-1.jpeg){kind=small}
製品開発において、どのようなものを作るのかというビジョンを組織全体で共有し、自分たちがどこへ向かおうとしているのかを示すものが「プロダクトロードマップ」です。プロダクトロードマップがあることで、技術部門だけでなくマーケティング部門や経営部門も一体となり、問題解決のための製品開発につながります。
【無料テンプレート】プロダクトロードマップ
設計や開発、マーケティングのスケジュール管理や、摩擦の原因と解決種別を把握し、プロダクトマネジメントの可視化にロードマップをお役立てください。
特にソフトウェア開発においては、20世紀末から21世紀初頭にかけて登場した「アジャイル開発」を知っておくことが重要です。
この記事では、製品開発に必要なビジョンと実際の工程を視覚化し、共有するためのプロダクトロードマップをテンプレートと併せてご紹介します。
プロダクトロードマップとは？
プロダクトロードマップとは、製品を開発するためのフローをロードマップにたとえて作成したものです。ゴールに到達するまでに必要なものを順序立てて記載しておくことで、プロダクトに関わるすべてのメンバーが迷わずに作業できるようになります。
プロダクトロードマップとは何かを理解するには、歴史的な経緯を振り返ってみるのが分かりやすいでしょう。
なぜ「ロードマップ」と呼ぶのか？
ロードマップは、もともとは車で移動するための道路地図を意味します。ロードマップが一般的な地図と異なるのは、単に道路や目印が記載されているだけでなく、移動途中で必要なガソリンスタンドや食事のできる場所、休憩場所などの情報を盛り込んだものです。
1990年代、アメリカで半導体開発が行われていた時期、開発に加わっていた人々は誰も見たこともないものを作ろうとしていました。そのため、組織も違えば立場も違う人々の間での合意形成は困難なものでした。
そこで、ビジョンと目的、そこへ行くまでの道筋を視覚化し、検討し共有するために、目的へと至る筋道を「ロードマップ」になぞらえて検討していったのです。
プロダクトマネジメントを可視化したプロダクトロードマップ
ビジネスにおいて何かを達成したいときに作成するロードマップは、道路地図とは違い、まだ誰も完成を見たことがない「未来のターゲット」をゴールとします。はじめから完璧なロードマップを作ることは難しく、仮説を立てて検証し、必要があれば修正しながらゴールを目指します。
このようなロードマップには、経営計画に基づいたビジネスロードマップや技術開発に基づいたテクノロジーロードマップ、マーケティングに基づいたマーケティングロードマップなど、さまざまなロードマップがあります。
プロダクトロードマップもそのひとつです。プロダクトロードマップが基づいているのはプロダクトマネジメントです。
新しい製品を開発し、事業化するためには、市場が何を求めているかを見極めた上で、適切な人材、材料、場所、設備を用意し、適切なタイミングで市場に導入しなければなりません。この製品開発の一連の流れであるプロダクトマネジメントを責任を持って管理する人が、プロダクトマネージャーです。
このプロダクトマネジメントを可視化し、チーム全体や経営陣も含めて合意形成したり、進捗度合いを管理したりするために作るのがプロダクトロードマップです。
プロダクトロードマップの重要性：優先順位を明確に
プロダクトロードマップを用いて管理することで、開発の中で何を優先するべきかを迷うことが少なくなります。大規模な開発になればなるほど、一人ひとりのコミュニケーションは難しくなるため、プロダクトロードマップが開発を順調に進めるための道しるべとなります。
プロダクトロードマップの重要性：コミュニケーションを活性化
プロダクトロードマップは、チーム内のコミュニケーションを媒介するツールとしての役割もあります。特に他部署のステークホルダーとの間には、日頃から頻繁にやり取りすることが少なくても、プロダクトロードマップを通じて目標を共有できます。
また、何か確認を取りたい場合にも、意図がスムーズに伝わりやすくなるでしょう。
プロダクトロードマップの重要性：クライアントの利益を最大化
プロダクトロードマップを用いて開発を進めることは、計画のとおりに進められるだけでなく、クライアントの課題を解決するという点でも大きな役割を果たすでしょう。クライアントの利益を最大化するためにも、プロダクトロードマップを用いることが重要です。
2種類の開発モデルとプロダクトロードマップ
特にソフトウェア開発の世界で主に用いられてきた手法が、工程をひとつずつ完了していくことを目指した「ウォーターフォール開発モデル」です。
一方で、20世紀末から21世紀初頭にかけて、ウォーターフォール開発に代わる手法として「アジャイル開発モデル」が生まれました。
ウォーターフォール型の開発手法は長年にわたり多くの企業で活用されてきましたが、今日ではソフトウェア開発を中心にアジャイル開発が増えつつあります。プロダクトロードマップもそれぞれの開発手法に基づいて、ウォーターフォールロードマップとアジャイルロードマップがあります。
この項では、それぞれの開発手法のメリットとデメリット、そしてそれぞれのプロダクトロードマップを見ていきます。
ウォーターフォール開発モデル
ウォーターフォール（滝）モデルとは、6つの工程が進行していく様子を上から下へ落ちていく滝の水になぞらえたものです。
《ウォーターフォール開発のモデル図》
システムやソフトウェアを開発するために、実装する機能などを明確にする段階から始まって、プロセスをひとつずつ確実に進行させていく開発手法です。もともとは建設業や製造業で取られていた手法で、事前に入念な要求定義と設計を行うのが特徴です。
この手法のメリットとしては、
- 計画的に進行するためにリソースの無駄がない
- 現在、開発工程はどの段階にあるかを関係者全員が把握できる
を挙げることができます。
一方、デメリットとしては
- 完成までに時間がかかる
- 途中で変更することが難しい
ことが挙げられます。
アジャイル開発モデル
アジャイルモデルとは、1～4週間の短い時間枠の中で1つの機能を構築していく開発手法です。アジャイルモデルでカギとなるのが「反復・繰り返し」を意味するイテレーションという言葉です。
アジャイル開発では、1～4週間の短いサイクルでイテレーションしながら開発を進めていくやり方を取ります。
《アジャイル開発のモデル》
アジャイルモデルは、個別に対処しなければならない製品を開発する際に強みを発揮する開発手法です。イテレーションごとにチームと顧客は話し合いを持ち、共同作業を通じてプロダクトを進化させます。
「要求」は、顧客が何を解決したいかを聞くプロセスです。ここで検討に加わってもらい、試作品（MVP）ができた段階で評価してもらいながら再度「要求」を出してもらいます。アジャイル開発は、要求定義などではなく「ユーザーストーリー」と呼びます。
このひとつのサイクルを1～4週間で回し、1～2週間後に次のステージに入ります。これを繰り返しながら（イテレーション）プロダクトを完成に近づけます。
アジャイル開発のメリットとしては、
- ユーザーと合意形成しながら進んでいくため、真のニーズに合致するプロダクトの製作ができる
- 柔軟で変更に対処しやすい
- 開発期間を短くすることができる
- 変更が起こってもコスト面での負担が少ない
を挙げることができます。
一方、デメリットとしては、
- 変更が頻繁に行われるため、工程の管理がむずかしい
- 試作品であっても短期間で製作するのはむずかしい
- 変更を受け入れて改良を続けるのはむずかしい
など、チーム全体がある程度のスキルを持っていることが前提となっていることです。
2種類のロードマップ
ウォーターフォールモデルとアジャイルモデルでは、プロダクトロードマップの作り方も異なります。
以下は違いを把握するために簡易的に用意した両者のプロダクトロードマップです。わかりやすいようにガントチャートの形にしましたが、特にアジャイルプロダクトロードマップでは軸を何に置くかによってさまざまなタイプがあります。
【ウォーターフォールモデル】
【アジャイルモデル】
ウォーターフォールモデルでは、事前に立てられた計画に基づいて1つひとつのタスクをこなしていきます。基本的には前の工程に戻らず、1つが終わってから次のステップに進みます。
一方、アジャイルモデルではフェーズごとに時期が被っていることがわかります。これは一例ですが、このように複数のイテレーションを同時に走らせることで開発の速度を早めることも可能です。
なお、ウォーターフォールプロダクトロードマップは「全員が把握しておくべき今後の計画表」といった性格が強く、アジャイルプロダクトロードマップはマップそのものよりも作成の過程が重要な開発プロセスです。どのフェーズを優先させて開発するのか、ユーザーストーリーごとにどんなタスクが考えられるのかをロードマップに落とし込んでいくことで、良質なプロダクトの設計を目指していきます。
そこで、アジャイルプロダクトロードマップ作成については、次の項で詳しく検討していきましょう。
ウォーターフォールとアジャイルのさまざまな違い
2つの開発モデルを理解するために、もう少し具体的な違いを比較してみましょう。
クライアントへの対応
ウォーターフォールモデルでは、ローンチまでの計画が事前に固まっているため、リリースまでクライアントはほとんど関与しないといえます。
一方、アジャイルモデルでは小さいイテレーションを繰り返すことから、都度クライアントの要望を聞き、対応していきます。これにより、市場の変化や競合他社の動きも加味した開発が可能になります。
リリースの早さ
アジャイルモデルでは、優先順位をつけてクライアントの必要としている機能を先に完成させることから、「使える」状態のリリースまでは早くなります。その後、残りの開発や改善を繰り返し、完成を目指します。
ウォーターフォールモデルでは、すべてのプロセスが終了しなければリリースされないため、長期プロジェクトになりがちです。
改善点の発見
原則として前の工程に戻ることがないウォーターフォールモデルでは、改善点が判明するのはテスト段階、あるいは完成してからになります。
一方、アジャイルモデルではイテレーションごとにテストを行うことから、都度改善点を見つけ、よりよいプロセスで開発を進めることができます。
アジャイルプロダクトロードマップの構成要素
今日、ソフトウェア開発やシステム開発を行う上で、アジャイル開発は非常に重要になっています。ガードナージャパンの統計によると、従業員2,000人以上の大企業の40％がアジャイル開発を現在採用していると回答し、さらに今後採用する予定だと答えた企業も30％に上りました。
現在製品開発を行っているという場合や、今後新たな製品開発を行おうと考えている場合も、アジャイルプロダクトロードマップについて理解し作成できるようになっておくといいでしょう。
ここでは、アジャイルプロダクトロードマップを構成する8つの要素について解説します。
1. プロダクト
開発するプロダクトの形態は、商品の形を取っているものだけでなく、サービスやメソッドなどさまざまな種類がありますが、いずれも顧客が今、抱いているニーズを満たすものです。
メリット、特徴、機能、用途などの点から検討します。
2. ゴール
プロダクトロードマップのゴールは、ビジョンを盛り込んだものであると同時に、計測可能で、ゴールに到達するまでの時間的なリミットを設けたものです。
成功したかどうかの評価基準は明確に定義される必要があります。
3. リリース
リリースは、実際に顧客にプロダクトを使ってもらうことです。
顧客に使ってもらいながら要求を出してもらい、修正を続けることを前提としていますが、それでもなおリリースの段階でプロダクトは実際に作動し、顧客の利用目的を満たし、価値を届けるものでなくてはなりません。
4. エピック
エピックとユーザーストーリーは、アジャイル開発において重要な要素です。エピック（epic）は「叙事詩（英雄の生涯を描いた壮大な詩）」という意味を持つ単語です。
つまり、ユーザーの人生に関わるような長期に渡って解決したいことや求めているものを指します。
5. フィーチャー
ユーザーに価値を提供する特色や機能のことです。
作り手にとっての特色や機能ではなく（例：「従来品より20％性能アップ」「多機能搭載」など）、ユーザーにとっての価値（例：ストレスなく使えるアプリを使えるインターフェース）を表現したものです。
6. MVP
Minimum Viable Productの略で、「最小限の実行可能なプロダクト」という意味です。
アジャイルトレーナーのHenrik Knibergは、上記の図でMVPを説明しています。
顧客が実現したい根本的なニーズは「速く移動する」ということです。そのために、顧客が実際に使用して確かめることのできる最小のものを提供し、迅速にフィードバックを得ることのできるものがMVPです。
図でMVPに相当するのは、下段の「スケートボード」です。
7. ユーザーストーリー
ユーザーストーリーは、エンドユーザーの視点からプロダクトを定義したものです。
「〇〇（ユーザーの種類）として、～のような機能がほしい。それは△△のためだ」という形で記述されます。
8. タイムライン
プロダクトロードマップにはかならず必要なものです。新製品のリリース、リリースした既存の製品の更新が完了する日時を盛り込みます。
上記の8つの要素について最終的なアイデアをまとめ、誰もがアプローチできるようにまとめておきます。
プロダクトロードマップを作成するには？
実際にアジャイルプロダクトロードマップを作成するには、まったくのゼロから作成するのは現実的ではありません。ここでは、テンプレートを用いてプロダクトロードマップを作成する方法を解説します。
なお、実際のテンプレートについても後の章にてご紹介します。
手順1. プロジェクトの目的を定義
プロダクトロードマップを作成する場合、プロダクトの目的を明確化する必要があります。
- なぜそのプロダクトを作るのですか？
- そのプロダクトを通じて何を達成しようとしていますか？
- ユーザーのどのような問題を解決するのですか？
目的を明確にしたら、次にMVPを定義し、優先順位を定めます。
例えば、ユーザーがプラットフォームにアクセスするためのログインページを制作しようとしているのであれば、MVPは「メールID」や「パスワード」などのログインフィールドは重要なMVPに相当します。
反対に、「パスワードを忘れた場合」機能のようなMVPはより低い優先度となり、後で取り組むことになります。
手順2. プロダクトロードマップをシンプルで理解しやすいものにする
製品開発をスムーズに進めるためには、ロードマップをチーム全体が理解し、把握していなければなりません。そのために、ロードマップはできるだけシンプルで理解しやすいものにする必要があります。
ロードマップはシンプルな状態に保ち、計画の詳細はバックログで管理します。
手順3. ユーザーストーリーをマッピングする
目標を設定したら、ユーザーストーリーのマッピングから始めます。
How to prepare for User story mapping session — tips and tricks(英語)
ユーザーストーリーマッピングの手順
ユーザーストーリーマッピングは、一種のブレーンストーミングです。全員でホワイトボードの前に立って、以下の手順で進めていきます。
- 参加者は付箋紙にユーザーストーリーを書き出す
- そのユーザーストーリーを時間軸に沿って並べる
- 優先順位を高い順に並べる
例えば「製品を見つける」という目標があるとします。そこで、「ユーザーは製品カテゴリーツリーを参照する」「ユーザーはフリーワードで検索する」「ユーザーは広告を見る」など、どんどん付箋紙に書き出していきます。
次に、ユーザーストーリーに記された行動は、ユーザーがどんな流れでその行動を取るかに焦点を当て、時系列に沿って付箋紙を並べていきます。
縦方向には、「どのような行動をユーザーに提供したいか」に焦点を当て、優先順位に沿って並べていきます。そのとき、「ユーザーはカテゴリーツリーを参照する」というアプローチを取り上げるとします。ユーザーがカテゴリーツリーを参照するためには、ユーザーはどのようなタスクを実行する必要があるでしょうか。このタスクは記録され、ソフトウェア開発用のユーザーストーリーに変換されます。
ユーザーの視点から考え、プロダクトに何が実行できるか、どのタイムラインで実行できるかについて、全員が意見を出し合います。
手順4. プロダクトのフィーチャーと優先順位の決定
プロダクトロードマップを構築する際には、コアプロダクトに接続する可能性のあるすべてのフィーチャーを考慮しなければなりません。
そのため、フィーチャーの優先順位を定める必要があります。優先順位付けに必要な要素は以下の4つです。
- フィーチャーの金銭的価値
- フィーチャーの開発およびサポートにかかるコスト
- フィーチャーの開発を通じて学べること
- フィーチャーの開発によって低減できるリスク
ほとんどのプロジェクトにおいては最初の2つの要素が重視されますが、後半の2つも重要な要素です。
例えば、アプリケーションにおけるセキュリティのフレームワークを考えてみてください。アプリにおいてセキュリティは重要ではありますが、ユーザーの購買動機にはつながりません。そのため、価値だけを考えればセキュリティの優先順位はさほど高いとはいえません。そこで、セキュリティ以前にアプリケーションとしてのフィーチャーが必要とされます。
さらに、コスト面を検討します。セキュリティフレームワークは後で行うよりも、早期に解決しておいた方がコスト面で安くつくかもしれません。コストの検討では、そのような面も考慮する必要があります。
セキュリティフレームワークを構築することで新たに学べることはないかもしれませんが、例えば経験のないメンバーがいる場合に学びの場とすることができるかもしれません。
また、後回しにすることで起こってくるリスクがないかも検討する必要があります。
手順5. ユーザーストーリーをタスクに分割する
ゴールが決まり、優先順位が決まったら、ユーザーストーリーをひとつ選び、ストーリーをタスクに分割します。タスクのサイズは、開発者が平均して1営業日に1つ完了できるくらいのものを目安にします。
タスクを決定したら、チームにコミットできるかどうかをたずね、担当者がそのタスクにコミットできるかどうかを確認します。これでイテレーションのプランニングは完了です。
手順6. 全員が確認可能なボードを作成する
次のステップは、関係者全員がアクセスできるボードに手順5までで決定したことを記載します。
ボードといっても物理的な掲示板に限るわけではなく、グループウェアなど何かしら全員がアクセスできることが重要です。そうすることで、全員がプロダクトの開発状況を追跡することができます。
アジャイルプロダクトロードマップでは各イテレーションでテストが行われ、プロダクト全体が完了するのを待つ必要がありません。これにより、途中の段階でリソースの追加が必要かどうかがわかります。
アジャイルプロダクトロードマップでは想定外の変更に対処することが可能だし、実際に対処する必要があります。
手順7. プロダクトロードマップを確認する
プロダクトロードマップは完全なものではありません。予期しない障害が起こるたびにチームを集め、プロダクトロードマップを検討し直します。
- この問題は予期されたものか？
- 短期的・長期的な解決策はあるか？
- 問題を解決するにはどのようなリソースが必要か？
以上の点を検討し、プロダクトロードマップを調整し、プロダクトが予定通りリリースされるようにすることができます。
以上の手順で、実際にプロダクトロードマップを作成していきましょう。
プロダクトロードマップ作成にオススメのテンプレートまとめ
ロードマップはエクセルやパワーポイントで作ることも可能ですが、既存のテンプレートを活用すれば、ロードマップ作成にかかる時間を検討や開発に回すことができます。
特定のニーズに焦点を当てたテンプレートが豊富にあるので、目的に合ったテンプレートをダウンロードして活用してください。
Smartsheet
Smartsheetでは、ビジネスに役立つExcelテンプレートを無料で多数公開しています。
プロジェクトロードマップ以外にも、アジャイル開発に関する「リリース計画」「スプリントバックログ」「テスト計画」などのテンプレートも利用できます。
Boardmix
Boardmixは、マインドマップやフローチャート、プロジェクト管理などを行えるオンラインホワイトボードツールです。
アジャイル開発に関するコラボレーションツールも多数備えており、リッチな機能を利用するには有料プランへの登録が必要ですが無料でも試せます。
Notion
プロジェクト管理を始め、チームコラボレーションに便利なメモツールであるNotionでは、プロジェクトロードマップに関するテンプレートも多数用意されています。
Notionはカスタマイズ次第で自社に合わせたさまざまなコラボレーションツールを開発できるメリットもあります。
HubSpotプロダクトロードマップ
四半期、月単位、担当者別にロードマップ管理を可能にします。「摩擦の原因」や「解決種別」「解決方法」を整理し、具体的な行動内容の把握と進捗の共有できます。
プロダクトロードマップを活用し、付加価値を高めよう
プロダクトロードマップを作成することのメリットは、製品のゴールと自分たちの現在地を視覚化し、チームやクライアントと状況を共有できることだけではありません。
ユーザーストーリーを出し合い、優先順位を定め、タスクをグループ化し、色分けして配置することを通じて、プロダクトマネージャー、開発者、顧客、その他の役割を担うチーム全員のコミュニケーションが加速されます。
アジャイルプロダクトロードマップでは、イテレーションごとに進捗度合いを振り返り、修正を加えます。こうしたコミュニケーションと合意形成、振り返りを通じて、開発しようとするプロダクトの価値が深化されるのです。
この機会にテンプレートをダウンロードし、アジャイルプロダクトロードマップの作成に着手し、アジャイル開発の助けにしてください。
