プロダクト開発でロードマップを作ることになったけど、作り方が分からない、という悩みはないでしょうか。そもそもロードマップとは何かが分からないかもしれません。
私はこれまでプロダクトマネージャとしてプロダクト開発に携わってきました。その中で、ロードマップを作る機会もたくさんありました。この経験を元に、プロダクト開発におけるロードマップとは何か、作り方を解説します。ロードマップを作るときの参考になればうれしいです。
この記事は、プロダクトマネジメントに関わる方、たとえばプロダクトマネージャはもちろんエンジニアやデザイナーの方を想定しています。実務経験が1〜3年目の方を対象に記事を書いています。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
プロダクト開発におけるロードマップとは
ロードマップとは、プロダクトの現在地とゴール、またゴールまでの道すじを明らかにするためのフレームワークです。
ふだんの生活におけるロードマップは「車で移動するための地図」という意味があります。プロダクト開発においては、現在地からゴールまでの道すじ、つまり今後の機能や施策面での計画を記した地図といえます。
ロードマップを作る目的
ロードマップはプロダクトのゴールと、それまでにやるべきことを確認するためにつくります。
あらかじめすべての設計をおわらせるウォーターフォール型の開発手法であれば、今後の計画が分かります。ただ、短い期間で計画を繰り返すアジャイル開発は、将来のことが見えづらいという問題があります。
かんばんでは将来のことは見えづらい
アジャイル開発において、プロダクトをつくる上で必要なひとつひとつのタスクはかんばんなどで管理していると思います。直近で実現できることはかんばんをとおして分かります。
ただ、先のこと、たとえば3ヶ月後や半年後、一年後にプロダクトがどうなっているのか、そのためになにをすべきかはかんばんだけでは見えてきません。ロードマップをつくることで、細かいタスクではなく、より大きな粒度でゴールまでのプロセスを確認することができます。
ウェブサービスやアプリをつくるとき、開発手法としてはほとんどの場合アジャイル開発が採用されると思います。アジャイル開発は継続的にユーザーに価値を届けますが、たとえば半年先や一年先のような将来にプロダクトがどうなっているかは見えづらいです。
変化の大きなプロダクトにとって、未来を明らかにしてくれるのがロードマップというフレームワークです。ロードマップをつくることでプロダクトの未来がわかり、ユーザーに届けられる価値や想定される課題などが見えてきます。
ロードマップを作る5つのメリット
ロードマップでプロダクトのゴールとそれまでの道すじを確認できると書きました。ではなぜこれらを確認すべきなのでしょうか？この理由は主に次の5つがあげられます。
1. ユーザーにどんな価値を届けられるかがわかる
プロダクトはユーザーに価値を届けてこそ意味があります。長期的にユーザーにどんな価値を届けられるかを確認することで、ユーザーや戦略パートナーなどにプロダクトの今後について説明しやすくなります。
2. 正しい方向に進んでいることがわかる
たとえばロードマップに書かれている道すじがバグ修正ばかりであれば、その計画に問題があると分かります。ロードマップに書かれていることがユーザーに期待以上の価値を提供しようとしているかを確認することで、プロダクトの方向性を検証することができます。
3. 課題が見えてくる
ある機能の開発にいくつかのチームが関わるとき、ロードマップで示されることで連携の必要性を確認することができます。あるいは利用規約を変更する必要があるかもしれません。リリース前後でデータの整合性をとる必要もあるでしょう。こういった課題は、ロードマップを見ることで洗い出すことができます。
4. 戦略を共有できる
ロードマップは開発メンバーだけが確認するものではありません。ステークホルダーなど運営上の関係者にも共有することで、コミュニケーションをスムーズに取ることができます。
5. モチベーションが高まる
ロードマップにはプロダクトの現在地とゴールが記されています。ゴールが実現されたところをイメージするとわくわくし、開発のモチベーションも高まることでしょう。
ロードマップの作り方
それではロードマップのつくりかたについて書いていきます。ロードマップは、大きく次の3つの要素で構成されます。
- ゴールまでの期間
- 期間中にやること
- やることの責任者
それぞれについて書いていきます。
1. ゴールまでの期間
まず、どれくらい先までのロードマップをつくるかを決めます。これはいつまでのロードマップを記したいかによります。目安として3ヶ月〜1年先までの期間でつくるとよいでしょう。
期間が短すぎると、プロダクトに変化が少なくロードマップの内容が薄くなりがちです。逆に長くなりすぎると、プロダクトの変化が大きく現実的でなくなるかもしれません。この点に注意して、プロダクトの変化の大きさも考慮しながら期間を設定します。
2. 期間中にやること
次に期間中にやることを記します。かんばんなど、使っているタスク管理ツールをもとにつくります。このとき、ユーザーにとって、チームにとって、あるいはステークホルダーにとってインパクトが大きいもの、プロダクトとして大きな価値をもたらすものを書きます。
細かいバグ修正や、影響範囲の小さい機能のリリースなどはふくめるべきではありません。ロードマップは、ゴールと道すじをわかりやすく伝えることが目的です。一枚の図で収まるようにして、詳細なタスクはかんばんに書くようにします。
3. やることの責任者
最後に、やることの責任者を明示します。チーム開発の場合は、やることにあわせて責任者の顔写真や名前などを書くとよいでしょう。
機能や施策はチーム間の連携が必要な場合が多くなります。この連携は責任者が調整することになります。責任者が明示されることでコミュニケーションが円滑になり、連携がうまく行きやすくなります。
また、ロードマップを見たメンバーが、自分が関わりそうな機能の相談を能動的に行いやすくなるというメリットもあります。
わくわくする資料にする
上の3つ以外の要素としては、ロードマップをみたメンバーがわくわくするような、モチベーションが高まるようなものにします。ロードマップはいわばプロダクトの未来を描いたものです。未来にわくわくすることが、いいプロダクトをつくる原動力になるといえます。
いつロードマップを作るか
ロードマップは、例えばMVPの検証を終えて実際のプロダクト開発に入ったらつくります。ロードマップがあるとユーザーにどんな価値を提供できるかがわかり、また課題も見えてきます。モチベーションも高まります。
ロードマップは、プロダクト開発に入ったら常にあり続けるといいツールのひとつです。プロダクトマネージャなど、ロードマップを定期的に更新する責任者がいるとよいでしょう。
まとめ
ロードマップは、ゴールやそこにいたるまでのプロセスを共有するために重要なツールです。ユーザーに届けられる価値がわかり、課題が見え、またモチベーションを高めることもできます。
実際のプロダクト開発に入ったらロードマップをつくり、週に一度など定期的に更新する体制をつくりましょう。
