プロダクトの未来を見える化する『ロードマップ』のつくりかた

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

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

この記事ではこのロードマップについて、概要やつくる目的、つくりかたについて書いていきます。

ロードマップとは

ロードマップ

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

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

なぜロードマップをつくるのか

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 課題が見えてくる

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

4. 戦略を共有できる

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

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

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

ロードマップのつくりかた

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

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

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

1. ゴールまでの期間

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

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

2. 期間中にやること

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

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

3. やることの責任者

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

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

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

わくわくする資料にする

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

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

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

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

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

まとめ

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

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

Hiroki Zenigami

Webサービスとアプリづくりが趣味。 ふだんは会社員をしつつ、副業でWebサービスを運営。 プロダクト開発や転職、副業を中心に書きます。

Twitterでフォローする
記事を読んだことを共有しよう

あなたがどんなことに興味をもっているかをフォロワーに知ってもらうきっかけになります

ツイート画面をひらく
関連記事関連書籍
ゼロから始めるプロダクトマネジメント

ゼロから始めるプロダクトマネジメント

わかりやすいストーリーとやさしい文体で学べる、プロダクトマネジメント学習の最初の一冊におすすめの本です。

レビューをみる
パーフェクトRuby on Rails【増補改訂版】

パーフェクトRuby on Rails【増補改訂版】

Railsの新しいライブラリやデザインパターンなどの設計について実践的に学べる、Railsエンジニアの必読書です。

レビューをみる
現場で使えるRuby on Rails 5

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

Amazonでみる
product-development.io
エンジニアのための技術情報サイト
© product-development.io