入門記事単語書籍

プロダクトのロードマップとは。作り方を例を元に解説

あなた
あなた

プロダクト開発でロードマップを作ることになったけど、作り方が知りたい。そもそもロードマップとはなに?

という悩みに記事でお答えしていきます。

この記事を読むことで、プロダクト開発におけるロードマップとはなにか、作り方がわかります。例を元に解説していますので、ロードマップを作るときの参考になればうれしいです。

私は上場企業やスタートアップでプロダクトマネージャとしてマネジメントを行ってきました。その中でロードマップを作る機会もたくさんありました。その経験をもとに、この記事を書いています。

この記事で想定している読者の方

この記事は、プロダクトマネジメントに関わる方、たとえばプロダクトマネージャはもちろんエンジニアやデザイナーの方を想定しています。実務経験が1〜3年目の方を対象に記事を書いています。

ロードマップとは

ロードマップ

ロードマップとは、プロダクトの現在地とゴール、またゴールまでの道すじを明らかにするためのフレームワークです。

ふだんの生活におけるロードマップは『車で移動するための地図』という意味があります。プロダクト開発においては、現在地からゴールまでの道すじ、つまり今後の機能や施策面での計画を記した地図といえます。

ロードマップを作る目的

ロードマップはプロダクトのゴールと、それまでにやるべきことを確認するためにつくります。

あらかじめすべての設計をおわらせるウォーターフォール型の開発手法であれば、今後の計画が分かります。ただ、短い期間で計画を繰り返すアジャイル開発は、将来のことが見えづらいという問題があります。

かんばんでは将来のことは見えづらい

アジャイル開発において、プロダクトをつくる上で必要なひとつひとつのタスクはかんばんなどで管理していると思います。直近で実現できることはかんばんをとおして分かります。

ただ、先のこと、たとえば3ヶ月後や半年後、一年後にプロダクトがどうなっているのか、そのためになにをすべきかはかんばんだけでは見えてきません。

ロードマップをつくることで、細かいタスクではなく、より大きな粒度でゴールまでのプロセスを確認することができます。

まとめ:ロードマップを作る目的

Webサービスやアプリをつくるとき、開発手法としてはほとんどの場合アジャイル開発が採用されると思います。アジャイル開発は継続的にユーザーに価値を届けますが、たとえば半年先や一年先のような将来にプロダクトがどうなっているかは見えづらいです。

変化の大きなプロダクトにとって、未来を明らかにしてくれるのがロードマップというフレームワークです。ロードマップをつくることでプロダクトの未来がわかり、ユーザーに届けられる価値や想定される課題などが見えてきます。

ロードマップを作る5つのメリット

ロードマップでプロダクトのゴールとそれまでの道すじを確認できると書きました。ではなぜこれらを確認すべきなのでしょうか?

この理由は主に次の5つがあげられます。

1. ユーザーにどんな価値を届けられるかがわかる

プロダクトはユーザーに価値を届けてこそ意味があります。長期的にユーザーにどんな価値を届けられるかを確認することで、ユーザーや戦略パートナーなどにプロダクトの今後について説明しやすくなります。

2. 正しい方向に進んでいることがわかる

たとえばロードマップに書かれている道すじがバグ修正ばかりであれば、その計画に問題があると分かります。ロードマップに書かれていることがユーザに期待以上の価値を提供しようとしているかを確認することで、プロダクトの方向性を検証することができます。

3. 課題が見えてくる

ある機能の開発にいくつかのチームが関わるとき、ロードマップで示されることで連携の必要性を確認することができます。あるいは利用規約を変更する必要があるかもしれません。リリース前後でデータの整合性をとる必要もあるでしょう。こういった課題は、ロードマップを見ることで洗い出すことができます。

4. 戦略を共有できる

ロードマップは開発メンバーだけが確認するものではありません。ステークホルダーなど運営上の関係者にも共有することで、コミュニケーションをスムーズに取ることができます。

5. モチベーションが高まる

ロードマップにはプロダクトの現在地とゴールが記されています。ゴールが実現されたところをイメージするとわくわくし、開発のモチベーションも高まることでしょう。

ロードマップの作り方

それではロードマップのつくりかたについて書いていきます。ロードマップは、大きく次の3つの要素で構成されます。

  1. ゴールまでの期間
  2. 期間中にやること
  3. やることの責任者

それぞれについて書いていきます。

1. ゴールまでの期間

まず、どれくらい先までのロードマップをつくるかを決めます。これはいつまでのロードマップを記したいかによります。目安として3ヶ月〜1年先までの期間でつくるとよいでしょう。

期間が短すぎると、プロダクトに変化が少なくロードマップの内容が薄くなりがちです。逆に長くなりすぎると、プロダクトの変化が大きく現実的でなくなるかもしれません。この点に注意して、プロダクトの変化の大きさも考慮しながら期間を設定します。

2. 期間中にやること

次に期間中にやることを記します。かんばんなど、使っているタスク管理ツールをもとにつくります。このとき、ユーザーにとって、チームにとって、あるいはステークホルダーにとってインパクトが大きいもの、プロダクトとして大きな価値をもたらすものを書きます。

細かいバグ修正や、影響範囲の小さい機能のリリースなどはふくめるべきではありません。ロードマップは、ゴールと道すじをわかりやすく伝えることが目的です。一枚の図で収まるようにして、詳細なタスクはかんばんに書くようにします。

3. やることの責任者

最後に、やることの責任者を明示します。チーム開発の場合は、やることにあわせて責任者の顔写真や名前などを書くとよいでしょう。

機能や施策はチーム間の連携が必要な場合が多くなります。この連携は責任者が調整することになります。責任者が明示されることでコミュニケーションが円滑になり、連携がうまく行きやすくなります

また、ロードマップを見たメンバーが、自分が関わりそうな機能の相談を能動的に行いやすくなるというメリットもあります。

わくわくする資料にする

上の3つ以外の要素としては、ロードマップをみたメンバーがわくわくするような、モチベーションが高まるようなものにします。

ロードマップはいわばプロダクトの未来を描いたものです。未来にわくわくすることが、いいプロダクトをつくる原動力になるといえます。

いつロードマップを作るか

ロードマップは、MVPの検証を終えて実際のプロダクト開発に入ったらつくります。ロードマップがあるとユーザにどんな価値を提供できるかがわかり、また課題も見えてきます。モチベーションも高まります。

ロードマップは、プロダクト開発に入ったら常にあり続けるといいツールのひとつです。プロダクトマネージャなど、ロードマップを定期的に更新する責任者がいるとよいでしょう。

まとめ

ロードマップは、ゴールやそこにいたるまでのプロセスを共有するために重要なツールです。ユーザーに届けられる価値がわかり、課題が見え、またモチベーションを高めることもできます。

実際のプロダクト開発に入ったらロードマップをつくり、週に一度など定期的に更新する体制をつくりましょう。

Webエンジニア&プロダクトマネージャ。 プログラミングで『ひとりで働く』を模索中。 三重の山の中で妻とこども、ネコとのんびり暮らしています。

Follow @zenizh
\ 記事をシェアしよう /

この記事を気に入っていただけましたら、ぜひフォロワーの方にシェアしてくださいね

ツイート画面をひらく
関連記事関連書籍
現場で使えるRuby on Rails 5

共著で『現場で使えるRuby on Rails 5(マイナビ出版)』を書きました。

Amazonでみる
© Product Development IO