ジンジャー給与のPdM(プロダクトマネージャー)のmurakoです。
弊社では毎月プロダクトチーム全体が集まって行う社内イベントがあり、そこで直近プロダクトロードマップについて考える機会が増え、この機会にプロダクトロードマップについて整理したいなと思い本テーマで記事を書くことにしました。
弊社でもプロダクトチームごとにそれぞれロードマップを作成するのですが、プロダクトチームによって多かれ少なかれアウトプットが異なっていることに気づき、おそらく人によってロードマップに対する認識が異なるのではないかと思いました。
そこでなぜロードマップが必要なのかという観点にフォーカスし、PdMの役割やプロダクトチームのミッションについて考えてみたいと思います。
プロダクトロードマップとは？
プロダクトロードマップの定義について、書籍でも紹介されていますし、少し調べれば多くの記事がヒットしますが、ここではあえて私自身のプロダクトロードマップの解釈について定義してみたいと思います。
私はプロダクトロードマップとは、「プロダクトが目指すビジョンを達成するまでの道筋や戦略を、開発チームを含めた様々なステークホルダに伝えるための”白地図”のようなもの」だと考えています。
白地図とは輪郭だけ書いて、細部や文字の書いていない地図のことを指します。
※画像は生成AIにて作成
ロードマップを作成することは、まっさらな白地図の上に、目的地に到達するための道筋や戦略、方法を仮説立てるようなもので、ステークホルダーに対してゴールに到達できるイメージの共通理解を得られるようにすることに意味があります。
一方で、ロードマップがゴールに到達するための道筋や手段であるとするならば、当然ゴールがなくてはロードマップを引くことができないはずです。
プロダクトロードマップを作る前にプロダクトビジョンが必要である理由
プロダクト開発でいうゴールとは多くの場合、プロダクトビジョンの達成を指します。
プロダクトビジョンとは「プロダクトを通して提供したい世界観の実現であったり、どのような価値を提供し、何を実現するか簡潔にまとめたもの」です。
プロダクトビジョンが必要である理由について、イソップ寓話の言説(諸説あり)として広まっている「3人のレンガ職人」というストーリーを例に考えてみます。
※画像は生成AIにて作成
3人のレンガ職人の物語
ある旅人が、建設現場でレンガを積んでいる3人の職人に出会いました。旅人はそれぞれの職人に「何をしているのですか？」と尋ねました。
1人目の職人
「見ればわかるだろう。ただレンガを積んでいるんだ。生活のために仕方なくやっているんだよ。」
2人目の職人
「レンガを積んで壁を作っているんだ。この仕事のおかげで給料がもらえ、家族を養えるんだ。」
3人目の職人
「私は、人々が集まり、祈り、安らぎを得られる大聖堂を建てているんだ！」
ビジネスでよく引用される有名なストーリーですが、プロダクト開発においても通ずるものがあると思います。
上記のストーリーは、あくまでレンガ職人個々人の意識の話に留まっていますが、「歴史に残る大聖堂を作る」の部分がプロダクトビジョンに該当します。
もし「歴史に残る大聖堂を作る」という明確なビジョンが共有されていなければ、3人目の職人も、1人目、2人目のように闇雲にレンガを積み重ねることになり、ただ巨大な石垣ができてしまうかもしれません。
歴史に残る大聖堂を作るという目的、ビジョンがあって初めて大聖堂を作るためのロードマップを作ることができるというわけですが、そう考えると、プロダクトビジョンはロードマップに先立つものでなくてはならないと考えることができます。
プロダクトロードマップから考えるプロダクトマネージャーの役割
よく話題にあがるPdMの役割についてロードマップ観点で少し触れたいと思います。
ここまでの話を整理すると
- プロダクトビジョンを決めることは「目的地を決めること」
- ロードマップを作成することは「目的地に到達するための道筋や方法を整理すること」
になります。
目的地までの途中途中の経過地点がマイルストーンに当たります。
プロダクト開発では、バックログを元に機能開発や改善を行っていきますが、その先にはロードマップの途中経過地点であるマイルストーンが存在するはずです。もしマイルストーンが存在しなければ方向性を見失っていることになります。
それぞれのマイルストーンを結んでいった延長線上にあるビジョンに到達する構想、戦略をより具体的な形に落とし込んだものがプロダクトロードマップになります。
一般的にロードマップを作成することは、PdMの業務の一つであると言われます。
その前提を元に、PdMの役割について掘り下げて考えていくと「マイルストーンに到達するための具体的な要求や手段をプロダクトバックログに落とし込み、整理し続けること」がPdMのミッションであると言えるのではないでしょうか。
プロダクトロードマップはステークホルダーや目的に合わせて使い分ける
冒頭で述べた通り、プロダクトロードマップとは開発チームで共通認識を持ったり、その他のステークホルダーの理解を得ることでプロダクト開発を円滑に進めるためのものです。
プロダクトロードマップの種類について調べると、リリースロードマップやステータスロードマップなど目的に応じた様々なロードマップが存在することがわかります。
※画像は生成AIにて作成
その種類についてはそれを紹介している記事がネット上でも見つかりますので、本記事での詳細は割愛しますが、ここまでの話を踏まえると、なぜ同じロードマップでも多様なフォーマットがあるのかという理由も想像しやすいです。
ゴールに辿り着くための詳細な道筋を知りたいのか、マイルストーンレベルで大まかに向かう方向を知りたいのか、ステークホルダーの目的に応じて適切な形が選択されることが望ましいからだと思います。
例えば、経営陣のようなエグゼクティブ層には事業戦略に基づいた大局的なロードマップが求められることが多く、実際にプロダクト開発に携わっている人たちには詳細機能レベルのバックログアイテムを整理したロードマップを説明する機会が増えるはずです。
また「3人のレンガ職人」のストーリーのところでも触れた通り、開発チームにプロダクトビジョンを含めたロードマップを共有できていなければ、プロダクトは思わない方向に向かうことになりかねません。
歴史に残る大聖堂を作るという目的を、開発チーム内で共通認識を持てていなければ、想定と違うものができてしまう可能性が高まります。
そういった意味でも開発チームを含めた各ステークホルダーがロードマップを通して共通理解を持てるようにすることはプロダクトチームにとって非常に重要度の高いミッションであるはずです。
まとめ
目的地に辿り着く方法は一つではなく、プロダクトチームの数だけロードマップが存在します。
ビジョンを達成するためにどのような道筋を描くかはPdMないしはプロダクトチーム次第ですが、可能な限りゴールに”最速”で到達するための戦略を考え、ロードマップに落とし込むことが求められます。
とはいえ、ただロードマップを定義しただけでは絵に描いた餅になりかねません。
ロードマップを絵に描いた餅で終わらせないためには、ビジョンを達成するための機能要求や手段を具体的なタスクに落とすことが必要になります。
それ自体がプロダクトバックログを整理するということに当たりますが、それを実行するには市場環境や技術、UIUXなど様々な観点を踏まえた上で「何を作るか」「どのような順番で作るか」といった意思決定を行っていくことになります。
弊社PdMの業務としても、上記のバックログを適切な状態に保つことが普段のメイン業務になりますが、実際に何を作るかを決めたり、優先順位を検討をする方法にもさまざまなやり方があります。
こちらも機会があれば別の記事で書きたいと思います（他のPdMの誰かが書いてくれるかも）が、「何を」「どのように」「どういう優先順位」で開発を進めていくかは、これまで述べてきた通り、その前提となるゴール設定が必要です。
プロダクトビジョンを元にロードマップを作成することで、芯の通った一貫性のある意思決定に繋がり、結果的に、ステークホルダーからの理解も得られ、プロダクト開発を円滑に進めていくことができるのではないかと思います。
Discussion