パート2：ロードマップを大規模に構築して管理する方法

ロードマップのブログシリーズのパート1では、C. Todd Lombardoが、ロードマップ作成時に多くのプロダクトマネージャー（PM）が陥りがちな落とし穴、ロードマップがリリース計画と同じではない（または同じであるべきではない）理由、機能横断的なチームがロードマップとプロダクト開発の取り組みを最適化するための戦術的ヒントについて、インサイトを提供しています。

この記事では、優れたロードマップの主要なコンポーネントを探り、PMとプロダクトチームがロードマップを効果的に管理し、適切なステークホルダーに伝えるための戦略について詳しく見ていきます。

優れたロードマップの5つのコンポーネント

Lombardoは、優れたロードマップを構築するためのアートとサイエンスを通じて、プロダクトチームを指導することに精通しています。各プロダクトや企業のロードマップをどの程度詳細に作成すべきか、「画一的な」アプローチはありませんが、ロードマップを可能な限り実用的かつ効果的にするためには、必ず含めるべき核となる要素がいくつかあります。

1. プロダクトのビジョン

パート1でLombardoは、ロードトリップに例えて、プロダクトビジョンの目的を説明しました。彼によると、「ロードマップは、進むべき方向を示すものです」。プロダクトビジョンは、貴社の取り組みの指針となるもの、あるいは貴社が目指す究極の最終状態であると考えましょう。プロダクトビジョンを考えるもう1つの方法は、プロダクトが完全に実現されたときに未来の世界がどのような恩恵を受けるかを想像することです。ビジョンは、1～2文程度のシンプルなものでも構いません（ただし、GitLabのように、より詳細なビジョンを語ることを選択する組織もあります）。また、野心的でありながら達成可能であると感じさせ、組織全体のビジョンやミッションと結びつける必要があります。

2. ビジネス目標

ビジネス目標は、プロダクトの目標を会社のより大きな目標の中に位置づけるものです。ロードマップに含めるビジネス目標や重要業績評価指標（KPI）は、プロダクトが結実したときに何を達成するかを明確に定義する必要があります。また、ビジネスの包括的な目標と一致することが理想的です。

3. タイムフレーム

ロードマップのタイムフレームは、取り組みの優先順位を示し、ステークホルダーが特定の取り組みをいつ実現できるかを示すものです。ここで重要なのは、ロードマップはリリース計画ではないということです。リリース計画は非常に細かく、プロジェクト指向であることを意図していますが、ロードマップはプロダクトの一般的な方向性を示すものであるべきです。Lombardoは、「最も一般的な時間枠は四半期ごとのロードマップですが、中には毎年、半年ごと、あるいは毎月のロードマップを作成する人もいます。月次は少し細かくなりますが、それが非常に理にかなっているビジネスの状況もあります」と述べています。企業によっては、「今、次、その次」というアプローチで、タイムフレームをさらに広くしているところもあります。どのような粒度を選択するにしても、タイムフレームをあまりに具体的にしすぎて、ロードマップと約束したリリース計画の境界線が曖昧にならないようにしてください。

4. テーマ

テーマ（目的または施策と呼ばれることもあります）は、解決しようとしている問題や、プロダクトが解決する課題を明確にしたものです。ここで重要なのは、テーマが機能のリストではないということです。Lombardoは、テーマを問題、ニーズ、目的の組み合わせと表現しています。たとえば、「解決したいことを、大まかにどのような順序で解決するか？」、「それらを解決した場合に期待される結果は？」など、いくつかの問いが交わることでテーマが浮かび上がってくると述べています。また、優れたプロダクトチームは、常に「なぜ？」と問い続け、問題の根本原因を特定するまで問い続けることで、目の前の真の問題に対処するソリューションを構築できるのだと説明しています。

5. 免責事項

最後に、Lombardoは、どのような形式であれ、ロードマップの最後の部分に免責事項を含めることの重要性を強調しました。免責事項とは、変更が可能であること、さらには避けられないことを認識し、約束違反やマイルストーンの未達成から貴社を守る、事前対策的な短い声明です。また、免責事項は、社内外のオーディエンスの期待を管理する上でも重要です（詳細は後述します）。

状況が変わるとどうなるか？

プロダクトの世界では、人生と同じように、常に予期せぬ事態を想定することがベストプラクティスです。確かに、ロードマップは長期的な先見性のあるツールですが、それが少しも変わらないことを期待するのは非現実的です。市場や経済の動向、企業戦略の変更、リソースや優先順位の変化など、外的要因により、ロードマップの変更が必要になる可能性があります。Lombardoは次のように説明しています。

「ロードマップは変化するものです。初期段階の企業であれば、物事が非常に速く変化するため、ロードマップは3週間程度の場合もあるでしょう。まだ発見モードで、ビジネスモデルが何であるかを理解しようとしている段階だからです。しかし、より成熟した企業であれば、はるかに長い期間のロードマップを作成することができます。次に、リリース計画を作成します。リリース計画は、「短期的に何をすることにコミットするか」ということを伝えるものです。その短期間は、1週間、2週間、2か月、3か月などです。もちろん、最初の2〜4週間はかなり自信がありますが、その後のこと. . . さらに先のことを考えると、物事はより不確かになり、少し曖昧になったりもしますが、まったく問題ありません。むしろ、ロードマップは時間とともに変化していくものだと考えるべきです。変化しないロードマップで市場に適切に対応できますか？臨機応変に立ち回れますか？」

Lombardoは、幅広いロードマップを構築する過程で、PMがステークホルダーから構想の具体性について質問を受けることは珍しくないが、こうした質問によってプロダクトチームが方向性を見失ってはならないと指摘します。「私がよく心がけているのは、それを問題として組み立てることです」と彼は述べています。そして、そのような質問を、問題を発見して検証を行う機会とし、ユーザーが直面している課題を知るチャンスととらえることを推奨し、次のような質問をすることを提案しています。

• あなたの世界にも、このような問題はありませんか？
• どの程度の規模の問題なのでしょうか？
• この特定の問題に対して、どのような課題を感じていますか？

また、Lombardoは、ステークホルダーとの会話を通じて、彼らの不満の根本原因を特定し、チームがどのように取り組みに優先順位をつけているかを理解してもらうことも提案しています。彼は次のように述べています。

「『解決策が何であるか、まだ正確にはわからないが、このような形になるのではないか。これがあれば、どのように問題を解決できるだろうか？』と仮説を立てることはできます。問題を検証し、ユーザーやステークホルダーから反応を得られるような、大まかな解決策の方向性を提示するのです。これにより、さらに「それについて他に何を知っておくべきなのか？」「今、他にどのように解決しているのか？」というような新たな質問が生じます。発見したり、戻ったり進んだり、検証したりできる良い機会なのです。」

短期的な優先順位やロードマップの項目が変化したり、方向転換したりするような状況でも、同じようなオープンなコミュニケーションの精神が大切です。彼は次のように述べています。

「何がどう変わったのか、なぜそうなったのかを、正直に話してください。もちろん、顧客によっては細かいことまで開示できない場合もあるので、その点は注意する必要があります。しかし、あなたが謙虚に、正直に、できる限り「なぜ」を説明したとしても、「必要な機能がない」という理由で、最終的に貴社のプロダクトから乗り換えなければならない顧客もいるかもしれませんが、それは仕方ありません。短期的にはベストではないかもしれませんが、通常、長期的には良い結果をもたらします。私の経験では、ステークホルダーに誤解を与えないよう率直に話すだけで、その間に何ができるかを話し合うことができ、発見と開発のプロセスにステークホルダーを巻き込む機会になります。」 

また、明確で整理されたロードマップは、ステークホルダーと対話する際の貴重なリソースとなり得ます。顧客やユーザーから反対意見が出た場合、ロードマップに立ち返って長期的なビジョンと優先事項の背景にある「理由」を説明すれば、実際に信頼を築き、顧客のリテンションを高めることができます。Lombardoは、次のように説明しています。「ステークホルダーが求めていることを、『ご意見は理解しました、これが解決すべき問題であることには同感です。しかし、実際にはより大きな問題であり、私たちは優れたソリューションを提供できると考えています。その理由は次のとおりです』というように、会話の中で再構成することが重要なのです。」

ステークホルダーと大規模なポートフォリオ管理

Lombardoは、ステークホルダーの管理もまた、多くのPMが直面する、摩擦が発生する共通の領域であると指摘しました。「管理されることを好むステークホルダーはいません」と彼は言います。「実際にはステークホルダーの調整役のようなものです。PMは、社内のチームだけでなく、社外のチーム、パートナー、顧客など、すべての人を巻き込むスキルが必要なのです。」

こうしたさまざまなグループすべての期待や意見を管理することは、簡単なことではありません。Lombardoは、「多くの場合、ステークホルダーはそれぞれ全く異なる目標やニーズを持っており、時には互いに対立することもあります」と指摘します。彼は、その場で最も大きな声だけを聞くことを当たり前にせず、静かな声にも耳を傾け、データ（プロダクトアナリティクスのような定量的なものと、顧客フィードバックのような定性的なものの両方）と説得力のある説明を求めることを推奨しました。さらにLombardoは、意思決定の記録を作成し、いつ、なぜ、そのような決定をしたのかを追跡することで、後でその決定が本当にプロダクトの将来にとって正しい選択だったのかどうかを評価できるようにすることを提案しました。

最後にLombardoは、多数のプロダクトロードマップを大規模に管理する企業組織に向けて、次のようなアドバイスを提供しています。

「ポートフォリオにプロダクトを追加するにつれ、そこにある情報量を抽象化する必要があります。人々は限られた量の情報しか消費できないためです。また、（大企業の場合）、経営陣は細部まですべてを求めているわけではありませんが、情報を見て、「この下はどうなっているんだ？詳細を見せてくれないか？」と言うかもしれないので、その準備をしておかないといけません。これは、（2つの別々の物であるべき）ロードマップとリリース計画を組み合わせることが重要な場面でもあります。粒度はさまざまですが、一貫性があり、整合性が取れているよう徹底してください。なぜなら、ロードマップにないものがリリース計画にあると、ロードマップにないものに取り組んでいる理由を聞かれるからです。」

ロードマップの技術スタック

PMがロードマップを作成・管理するために使用する具体的なツールは組織によって（時にはチームによって）異なりますが、Lombardoは、最高のロードマップを作成するために使用すべき基本的なツールがいくつかあると指摘しています。

1. すべてのプロダクトフィードバックを収集して一元管理するツール
   フィードバックデータが複数のプラットフォームやソースに分散していると、インサイトを明らかにすることができません。Pendo Feedbackのように、すべてのデータを一箇所に集め、定量的なプロダクトデータとの相関関係を描けるようなツールを使うようにしてください。
2. プロダクトアナリティクスプラットフォーム
   Pendoアナリティクスのようなプロダクトアナリティクスツールは、プロダクトのパフォーマンスやユーザーとのインタラクションを客観的に把握することができます。アナリティクスデータを顧客からのフィードバックと結びつけることは、データに基づいたロードマップを作成し、次にどこに注力すべきかを決定する上で、非常に重要です。
3. プロジェクト管理ソリューション
   GitLab、Shortcut、またはJiraなどのプロジェクト管理ツールは、一般にエンジニアリングチームが所有していますが、短期的なリリース計画を整理するのに非常に有効です。これらのソリューションは、より包括的なロードマップやフィードバックソリューションと組み合わせて使用する必要があります。

Pendoのプラットフォームでロードマップを活用する準備はできましたか？Pendoロードマップの、使いやすくなった新しいロードマップ機能をご覧ください。