どうもこんにちは、PM/事業開発 の中村（ゆーぶん）です。
この記事は、estie PM Blog Week 6日目の記事です。estie の PM が持ち回りでブログを書いています。前日はPM勝田の 「立ち上げフェーズのプロダクトにおいてライトパーソン特定が営業だけでなく開発にも寄与するレバレッジポイントな説」 でした。<< 前回の記事はこちら>>
今日はロードマップを作ったり更新するのが億劫になってしまい、義務感で作業している方に向けて、私なりの考えを伝えられたらと思います。
みなさん、ロードマップ作ってますか？
プロダクトを保有している会社のプロダクトマネージャー、ないし経営者の皆様、ロードマップは作られていますでしょうか？
ロードマップを作っていないという方、ドキッとする必要はありません。作っていないことは全く悪いことではありません。いろんな書籍やブログにロードマップと出てきており、ロードマップを作ることが重要な仕事のようになっておりますが、ロードマップはただのツール、つまりHowのひとつなので、結果としてプロダクト開発が進んでいれば全く問題ないのです。
実際にestieの各プロダクトもロードマップが整備されているわけではありません。
と言いつつお前ロードマップの記事書いてるじゃねーか（ぼくのかんがえたさいきょうのロードマップかんりツール - estie inside blog）となる人は相当estieのブログを読んでいただいている方だと思いますが、これはロードマップが好きだからというわけではなく、ロードマップがあると仕事が非常に楽になるからです。（ロードマップは好きですが）
本ブログで伝えたいのは、ロードマップ作成が負荷になるケースがあるので、ロードマップがないことに漠然とした不安を覚えている方がいたら、「別にロードマップはなくてもいいんだよ」と安心してほしいということです。
実際にロードマップがあったほうが仕事が楽になるケース、逆にロードマップを作ると仕事が大変になるケースを説明していきたいなと思います。
シンプルにロードマップを作るのが大変なのであれば、頑張って作る必要はない
具体的に私の経験上、下記のケースのときはロードマップ作るのが億劫であり、実際に作っていなかったなと思います。
- 取り組むEpic（大まかなユーザーストーリー）の単位が小さく、1週間以内で検証が完了する事が多いフェーズ
- 新規事業で説明責任の範囲が狭い/小さい
- 更新を行うツールなどの整備ができていない（都度新しく作る際と同等なコストがかかる）
取り組むEpicの単位が小さく、1週間以内で検証が完了する事が多いフェーズ
主にMVP前後の初期フェーズのプロダクト開発に多い状態かと思います。
このフェーズにおいてはどういうジョブがコアとなりうるのかを探索する事が多く、日々の発見の中で次々に新しい仮説が生まれます。
その観点で言えば、このフェーズでロードマップを整備・更新していたらほとんど毎日ロードマップとにらめっこすることになるでしょう。
わざわざロードマップにしなくてもGitHubやJiraのチケット、PRで十分だと思います。このフェーズでロードマップで管理できるスピード感であれば、逆に良くない状態なのかもしれません。
新規事業で説明責任の範囲が狭い/小さい
1点目同様MVP前後の初期フェーズが多いかと思います。
安定した売上がなく、いい意味で計算されていないフェーズにおいては、どういう顧客に対してどういう機能仮説を当てたかの説明よりも、実際に顧客は何と言っているのか、チームはポジティブな状態なのかを説明するほうが経営陣は新規事業の状態を把握しやすいです。
ロードマップで説明するより、商談の議事録をベースに直接の対話形式で説明するのが適していると感じます。
更新を行うツールなどの整備ができていない（都度新しく作る際と同等なコストがかかる）
上記に当てはまらず、後述するロードマップがあったほうが便利な状態でも、ロードマップの更新に丸1日かかってしまう場合にはロードマップは不要だと考えております。
理由としては、実際のロードマップ（頭に描いてあるもの）とアウトプットとして共有されているロードマップに差分が出てしまう状態であれば、逆にステークホルダーを惑わせてしまう可能性があるからです。
加えて、ロードマップを作ることだけでは事業の検証は進まないため、更新のたびに1日使ってしまうのは個人的には時間がもったいないとも思います。
特段お金を掛ける必要はないとは思いますが、個人的にはパワーポイントですら面倒で正直全然更新できませんでした。最終的にはFigmaでフォーマットを組み、それを使うことで10分もあれば更新できるようになりました（あと構造がシンプルなのでエンジニアが自ら検証したい項目を追加してくれたりします）。
上記のFigmaのロードマップについては下記の記事で以前公開しておりますので興味ある方はご一読ください。
結論をいうと、ロードマップを作ったり整備する時間に追われ、プロダクトについて向き合う時間が減るならば作らないほうがいいと思います。
ロードマップを作る時間だけを切り取ると、事業を進めているわけではありません。あくまでロードマップは事業を進めるための加速器として使うものなので、上記のような場面ではロードマップは不要と割り切って目の前のお客様に向き合いましょう。
誰かに何かを伝えたいとき、ロードマップがあるとめっちゃ楽
ここまでロードマップ不要論者みたいになっておりますが、私はここ1年以上はロードマップにすごく時間をかけており、他のPdMにも「ロードマップ作ろうぜ」と啓蒙活動を行うほどロードマップ大好き人間です。
ではどういう場面でロードマップが役立だったのかを具体的な例でご紹介します
- 週次の開発定例（スクラムイベントでいうリファインメント、プランニング）
- 事業責任者との月次チェックイン
- ロードマップ作成会
週次の開発定例（スクラムイベントでいうリファインメント、プランニング）
基本的に3ヶ月先までのEpicが作られ、優先度順に並んでいます。なので開発定例ではEpicと完了させたい時期から逆算してチケット化を詳細化し、ベロシティをみながら積んでいくだけです。
またもし想定よりも早く開発が進んだ場合にはロードマップの先のものに取り組めばいいですし、もし遅れた場合にもロードマップを再度見直し、検証を遅らせても問題ないことはないかを考え更新していけばスムーズに開発が進みます。
実際にロードマップがあったらプロダクトマネージャーのわたしはほぼ必要ないのでは？というくらい開発は円滑に進んでいきました。
事業責任者との月次チェックイン
estieはかなり現場に裁量があるために多くの説明を求められることはないですが、月次で事業責任者とのプロダクト状態のチェックインがあります。その際にロードマップがあれば先月時点の計画と実績を説明しやすく、オンスケなので健康的なのか、ビハインドしているのでリカバリーが必要なのか、もしくは人手を増やすことができないかなど建設的な議論をすることができます。
ロードマップには必要最小限の情報があるので、わざわざチェックインのために時間をかけて準備する必要がなく、非常に仕事を楽にしてくれます。
ロードマップ作成会
私のチームでは四半期に一度、がっつりとロードマップを作る会を設定しているのですが、その会ではチームでの会話がどんどん生まれて非常に楽しいです。
estieでのロードマップはプロダクトマネージャーがこもって1人で作るのではなく、チームみんなでアイデアを出し合って作ります。
作り方の流れを説明すると、プロダクトマネージャーから今期で達成すべき数値（売上など）を提示し、それらを達成するのに必要なレバーを提示します。例えば売上100万円が目標だった場合に、新規顧客獲得が80万円、既存顧客からのアップセルが20万円、新規顧客のうち〇〇セグメント40万円、△△セグメント40万円、アップセルのうち10万円はベースアップ、10万円は課金プランの追加といった具合に細分化するところまでをやります。
その先の〇〇セグメントで40万円を獲得するにはどういう機能やアクションが必要なのかというのはエンジニアを含めてみんなでアイデアを出し合って固めていきます。
私はこの過程によって、自然とメンバー全員が同じ方向を向き、さらに自分事として開発を楽しむことができると考えております。この過程こそがロードマップの本質なのです。
ちなみに私のチームでは小田原のキャンプ場まで赴いてロードマップを作り、終わったあとはそのままキャンプを楽しんだりしています。
ロードマップがあったほうがいい状態は、エンジニアや経営者などプロダクトに多くのステークホルダーが存在し、事あるごとにプロダクト状態を説明することが多いケースです。
いちいち説明したり都度資料を用意するくらいなら、ロードマップみてくれ！で終わらせるほうがよっぽど効率的です。
またキャンプ上で作成すれば自然を楽しみつつチームと楽しい時間も過ごせるので一石二鳥です。
ロードマップはあくまでツールなので、ロードマップがないことは悪ではない
ロードマップはプロダクトの機能のようにただのHowの1つに過ぎません。
本当に大切なことは手を止めずに毎日一歩ずつ、できるならたくさん歩ずつ変化を生んでプロダクトに必要な価値を探してお客様にデリバリーすることなのです。
上記を達成するためにロードマップが有効なときはありますが、必ずしも有効とは限りません。
なのでロードマップに囚われてロードマップにプロダクトマネジメントされるのではなく、ロードマップを飼いならしてプロダクトマネジメントしていきましょい。
おわりに
estieでは、一緒にプロダクトや事業を作る人を募集しています。興味がありましたら、カジュアルにお話ししましょう！
PM Blog Weekの記事は、こちらもあわせてお読みください。
PM Blog Week カテゴリーの記事一覧 - estie inside blog
2025年1月31日（金）に、estieのプロダクトマネージャーと直接話せるイベントを開催します！！！
ブログを読んで、estieのメンバーと話してみたいと思った方、他社の事例も含めてプロダクトマネジメントの学びをもっと得たいと思った方、ぜひご参加ください！
皆様とお会いできるのを楽しみにしています！
