製造業に携わる人にとって、市場に求められる製品を開発することは生命線です。市場はどのような課題を抱えているのか、自分たちはどのような課題を解決すべきなのかを明確にし、自分たちの目指すべきゴールを定めなければなりません。そしてゴールを定めたら、実現に向けて計画を立てます。
半世紀以前の製造業は、製品を作ること自体が価値となっていました。そこに、日本の製造業は製造工程に付加価値を見出し、大量生産と効率化された工場体制によって高度成長を遂げました。しかし、市場に製品が飽和する時代を迎え、製造業は顧客のニーズに適合した新しい製品の開発が付加価値を生む時代となりました。
顧客のニーズに応え、問題解決を提供する新製品の開発のためには、技術部門だけでなくマーケティングの要素も重要になってきます。技術部門、マーケティング部門、組織の経営部門が一体となって、新しい物づくりに取り組むことが求められています。
どのようなものを作るかという未来のビジョンを組織全体で共有し、自分たちがどこに向かおうとしているのか、今現在自分たちがどこにいるかを共有するためのツールが「プロダクトロードマップ」です。
この記事では、製品開発に必要なビジョンと実際の工程を視覚化し、共有するためのプロダクトロードマップをテンプレートと併せてご紹介します。
プロダクトロードマップとは？
プロダクトロードマップについて、例え話を用いて解説してみます。まず、どこかに旅行すると想像してみてください。最初に決めるのは目的地ですね。気軽な1人旅なら目的地さえ決めればそのまま出立するのもいいかもしれませんが、大勢が参加する旅行となると話は変わってきます。
日程、予算、参加者の把握、移動手段、ルート、途中での宿泊、宿泊先の手配、到着してからのアクティビティなど、旅行というプロジェクトの管理者が考慮し、検討しなければならないことが山のように出てきます。
管理者は、計画を立て、参加者全員に計画を知らせるだけでなく、参加者の意見を聞きながら、全員が満足できるように計画を何度も練り直していかなければなりません。
しかも、それだけ入念に計画したにも関わらず、旅行に出たところで予期しない出来事が次々に起こってきたとします。管理者は全員に満足してもらえるよう情報を集め、計画を何度も練り直しながら旅行を続けていかなければなりません。
プロダクトロードマップは、この「旅行しながら変更を重ね、全員が満足できるように共有する旅行計画書」のようなものです。ここからは例え話ではなく、具体的に見ていきましょう。
プロダクトロードマップとは「プロダクトマネジメントを可視化した」もの
プロダクトロードマップは、マップと言っても実際の地図ではなく、思考を可視化するためのツールです。プロダクトロードマップとは何かを理解するには、歴史的な経緯を振り返ってみるのが分かりやすいでしょう。
なぜ「ロードマップ」と呼ぶのか？
ロードマップは、もともとは車で移動するための道路地図を意味します。ロードマップが一般的な地図と異なるのは、単に道路や目印が記載されているだけでなく、移動途中で必要なガソリンスタンドや食事のできる場所、休憩場所などの情報を盛り込んだものです。
1990年代、アメリカで半導体開発が行われていた時期、開発に加わっていた人々は誰も見たこともないものを作ろうとしていました。そのため、組織も違えば立場も違う人々の間での合意形成は困難なものでした。そこで、ビジョンと目的、そこへ行くまでの道筋を視覚化し、検討し共有するために、目的へと至る筋道を「ロードマップ」になぞらえて検討していったのです。
プロダクトマネジメントを可視化したプロダクトロードマップ
道路地図は、実際に存在する目的地に向けて実在の道路やガソリンスタンドを地図上に記しますが、製品開発のためのロードマップは、未来のターゲットが目的地であり、マップに記載されるのも、仮説やシナリオ、目印となるマイルストーンも、現実には存在しないものです。そのため、ロードマップは「未来予想図」でもあります。マイルストーンに到達する時期を定め、データを取り、仮説検証しながら、ロードマップに従って先へ進みます。
このようなロードマップには、経営計画に基づいたビジネスロードマップや技術開発に基づいたテクノロジーロードマップ、マーケティングに基づいたマーケティングロードマップなど、さまざまなロードマップがあります。
プロダクトロードマップもそのひとつです。プロダクトロードマップが基づいているのはプロダクトマネジメントです。
新しい製品を開発し、事業化するためには、市場が何を求めているかを見極めた上で、適切な人材、材料、場所、設備を用意し、適切なタイミングで市場に導入しなければなりません。この製品開発の一連の流れであるプロダクトマネジメントを責任を持って管理する人が、プロダクトマネージャーです。そして、プロダクトマネジメントを可視化し、プロダクトマネジャーだけでなく、チーム全体や経営陣も含めて合意形成したり、進捗度合いを管理したりできるようにするのがプロダクトロードマップです。
2種類の開発モデルとプロダクトロードマップ
ソフトウェア開発の世界では、20世紀末から21世紀初頭にかけて従来とは異なる新しい開発の手法が生まれました。それがアジャイル開発です。「素早い」という意味を持つアジャイル開発に対して、従来型の開発手法はウォーターフォール開発と呼ばれます。
ウォーターフォール型の開発手法は長年にわたり多くの企業で活用されてきましたが、今日ではソフトウェア開発を中心にアジャイル開発が増えつつあります。プロダクトロードマップもそれぞれの開発手法に基づいて、ウォーターフォールロードマップとアジャイルロードマップがあります。この項では、それぞれの開発手法のメリットとデメリット、そしてそれぞれのプロダクトロードマップを見ていきます。
ウォーターフォール開発モデル
ウォーターフォール（滝）モデルとは、6つの工程が進行していく様子を上から下へ落ちていく滝の水になぞらえたものです。
《ウォーターフォール開発のモデル図》
システムやソフトウェアを開発するために、実装する機能などを明確にする段階から始まって、プロセスをひとつずつ確実に進行させていく開発手法です。もともとは建設業や製造業で取られていた手法で、事前に入念な要求定義と設計を行うのが特徴です。
この手法のメリットとしては、
- 計画的に進行するためにリソースの無駄がない
- 現在、開発工程はどの段階にあるかを関係者全員が把握できる
を挙げることができます。
一方、デメリットとしては
- 完成までに時間がかかる
- 途中で変更することが難しい
ことが挙げられます。
アジャイル開発モデル
アジャイルモデルとは、1～4週間の短い時間枠の中で1つの機能を構築していく開発手法です。アジャイルモデルでカギとなるのが「反復・繰り返し」を意味するイテレーションという言葉です。アジャイル開発では、1～4週間の短いサイクルでイテレーションしながら開発を進めていくやり方を取ります。
《アジャイル開発のモデル》
アジャイルモデルは、個別に対処しなければならない製品を開発する際に強みを発揮する開発手法です。イテレーションごとにチームと顧客は話し合いを持ち、共同作業を通じてプロダクトを進化させます。
「要求」は、顧客が何を解決したいかを聞くプロセスです。ここで検討に加わってもらい、試作品（MVP）ができた段階で評価してもらいながら再度「要求」を出してもらいます。アジャイル開発は、要求定義などではなく「ユーザーストーリー」と呼びます。
このひとつのサイクルを1～4週間で回し、1～2週間後に次のステージに入ります。これを繰り返しながら（イテレーション）プロダクトを完成に近づけます。
アジャイル開発のメリットとしては、
- ユーザーと合意形成しながら進んでいくため、真のニーズに合致するプロダクトの製作ができる
- 柔軟で変更に対処しやすい
- 開発期間を短くすることができる
- 変更が起こってもコスト面での負担が少ない
を挙げることができます。
一方、デメリットとしては、
- 変更が頻繁に行われるため、工程の管理がむずかしい
- 試作品であっても短期間で製作するのはむずかしい
- 変更を受け入れて改良を続けるのはむずかしい
など、チーム全体がある程度のスキルを持っていることが前提となっていることです。
2種類のロードマップ
ウォーターフォールとアジャイルの2種類の開発手法を踏まえて、それぞれのプロダクトロードマップを見ていきます。
ウォーターフォールプロダクトロードマップ
ウォーターフォールロードマップは、通常年間ベースで作成され、予算とリリースの日程は固定されています。
上記は通常のウォーターフォールマップの例で、リリースまでの1年間のタイムラインとして各セクションのスケジュールが管理されています。
アジャイルプロダクトロードマップ
Communicating Your Product Strategy with an Agile Product Roadmap
ウォーターフォールプロダクトロードマップが「全員が把握しておくべき今後の計画表」といった性格が強いのに対し、アジャイルプロダクトロードマップは、ロードマップそのものよりも、ロードマップを製作する過程が重要な開発プロセスの一環です。
そこで、アジャイルプロダクトロードマップ作成については、次の項で詳しく検討していきましょう。
アジャイルプロダクトロードマップの構成要素
今日、ソフトウェア開発やシステム開発を行う上で、アジャイル開発は非常に重要になっています。ガードナージャパンの統計によると、従業員2,000人以上の大企業の40％がアジャイル開発を現在採用していると回答し、さらに今後採用する予定だと答えた企業も30％に上りました。
現在、製品開発を行っているスタートアップも、今後新たな製品開発をしようと考えているスモールビジネスも、アジャイルプロダクトロードマップについてしっかりと理解し、作成できるようになっておく必要があります。
アジャイルプロダクトロードマップを作成するためには、まずロードマップを構成する8つの構成要素について検討します。プロダクトマネジャー、顧客（新製品の場合は、予算を確保した人や開発の意思決定をした人が顧客役を務めます）、開発者が提示したアイデアや提案をホワイトボードに記載します。
その際に検討すべき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. プロダクトロードマップを確認する
プロダクトロードマップは完全なものではありません。予期しない障害が起こるたびにチームを集め、プロダクトロードマップを検討し直します。
- この問題は予期されたものか？
- 短期的・長期的な解決策はあるか？
- 問題を解決するにはどのようなリソースが必要か？
以上の点を検討し、プロダクトロードマップを調整し、プロダクトが予定通りリリースされるようにすることができます。
以上の手順で、実際にプロダクトロードマップを作成していきましょう。
プロダクトロードマップ作成にオススメのテンプレートまとめ
ロードマップはエクセルやパワーポイントで作ることも可能ですが、既存のテンプレートを活用すれば、ロードマップ作成にかかる時間を検討や開発に回すことができます。
特定のニーズに焦点を当てたテンプレートが豊富にあるので、目的に合ったテンプレートをダウンロードして活用してください。
30+ Product Roadmap Templates, Examples and Tips
シンプルでカラフルなテンプレートが31種類用意されています。Webチーム、モバイル設計チーム、マーケティングチームのロードマップを統合したものや、企業カルチャーに焦点を当てたものなど、自社に必要なものが見つかるかもしれません。
Product Roadmap Templates from Aha
フィーチャーに焦点を当てたもの、エピックに焦点を当てたものなど、アジャイルプロダクトロードマップのそれぞれの面に焦点を当てたロードマップが豊富に用意されています。アジャイル開発を初めて行う場合にも使いやすいロードマップです。
Free Product Roadmap Template from Smartsheet
アジャイルプロダクトロードマップのテンプレートのほかに、リリースロードマップやテクノロジーロードマップなど、さまざまな分野のロードマップが利用できます。
HubSpotプロダクトロードマップ
四半期、月単位、担当者別にロードマップ管理を可能にします。「摩擦の原因」や「解決種別」「解決方法」を整理し、具体的な行動内容の把握と進捗の共有できます。
プロダクトロードマップを活用し、付加価値を高めよう
プロダクトロードマップを作成することのメリットは、製品のゴールと自分たちの現在地を視覚化し、合意形成を行えることだけではありません。
ユーザーストーリーを出し合い、優先順位を定め、タスクをグループ化し、色分けして配置することを通じて、プロダクトマネジャー、開発者、顧客、その他の役割を担うチーム全員のコミュニケーションが加速されます。そして、イテレーションごとに進捗度合いを振り返り、修正を加えます。こうしたコミュニケーションと合意形成、振り返りを通じて、開発しようとするプロダクトの価値が深化されるのです。
この機会にテンプレートをダウンロードし、プロダクトロードマップの作成に着手し、アジャイル開発の助けにしてください。
元記事発行日： 2020年6月09日、最終更新日： 2023年1月19日
トピック：:
組織運営関連記事
