チームで結束して製品作業にあたるためのロードマップの作成
ロードマップは、製品の現在の (そして絶えず変化する) 今後の方向性についてチームの意識を合わせるために共有する動的なツールです。
ロードマップで、リーダーシップから顧客対応チームに至るさまざまなグループに、優先度とどのようにそれが選択されたかを伝えます。これらのグループにはそれぞれ、製品ロードマップが独自のビューで示されるため、今後の作業を具体的かつ視覚化しやすくなります。
優先度は常に変化します。このため、ロードマップは生きたドキュメントとして常にアップデートされます。計画が変更されても、これは製品ジャーニーの唯一の信頼できる情報源として機能し、どのアイデアをいつ実行に移すかについての現在のビジョンが共有されます。
ロードマップを作成する方法
ロードマップを作成する正しい方法は 1 つではありません。ロードマップに関する多くの課題の 1 つは、それが包括的な用語であり、コラボレーション、コミュニケーション、優先事項の決定、優先事項の伝達、期待の設定など、さまざまなタスクを表せるということです。
ロードマップの作成にはチームや社内の多くの人、そして場合によっては顧客やパートナーなどの外部の関係者が関与します。誰が関与するかによって、必要な形式やアプローチが異なる可能性があります。
それでも、有用なロードマップのベスト プラクティスはあります。このセクションでは、ロードマップの手法と戦略のうち、これまで効果的だったものと、不十分になりがちなものを共有します。
優れたロードマップの要素
Jira Product Discovery で作業を開始して以来、多くのロードマップを目にしてきました。
成功している企業には、いくつかの共通点があります。
- 常に最新状態が保たれている: これは必須条件です。他の人々がロードマップに基づいて自分の作業方針を立て、重要な決定を下すからです。
- 誰もが理解できる言葉を使っている:「ビジネスへの影響」や「リスク レベル」など、すべてのフィールドと値を明確に定義する必要があります。これにより、会話が脇にそれず、生産性が保たれます。
- 全体像を示す: 効果的なロードマップには、共有する優先度の背後にある理由の説明が伴っています。タスクやその実行の詳細ではなく、全体像に焦点が当てられています。
- 結果と目的に基づく: 優れたロードマップは、最終目標を示すことで、個別のリリース予定などではなく、全体像に向かって会話を導きます。
- 現実的な期待を設定する: ロードマップにはそれぞれのアイデアに対するコミットメントのレベルについて正直に記載され、過度な約束をしません。
- 簡潔: 1 ページに収まります。
ロードマップが機能しているかどうかを見分ける方法
ロードマップが機能していれば、将来の製品計画に向けたセルフサービスの信頼できる唯一の情報源になります。
- ロードマップはセルフサービスの情報源であるため、何がいつ行われるかを担当者が管理者に直接尋ねる必要がありません
- チーム メンバーは、専用のチャンネルを通じて新鮮なインサイトやアイデアを独自に共有しています
- 関係者が理解するためにアドホックなプレゼンテーションを要求しなくなり、代わりに専用のロードマップ ビューを参照します
誰もがロードマップを直接参照して疑問を解決できるので、言い直したり、優先事項を繰り返したりするために時間を費やす必要がありません。
会話がより戦略的で生産的になります。製品チームが自主性を獲得するため、インパクトを与えるという本来の職務に割く時間を取り戻せます。
ロードマップは計画とどのように違いますか?
Jira Product Discovery のロードマップと Jira のプラン機能の関連。
ロードマップは製品バックログで作成されます。これは各アイデアの優先順位とその理由を伝達するものです。顧客、パートナー、社内の全員と簡単に共有できます。
→ ロードマップは Jira Product Discovery で管理します。
次に、これらのアイデアの実行を Jira で計画します。
Jira プラン機能では、アイデアはエピックまたはイニシアチブ内のフィールドとして表示されます。それぞれのアイデアをユーザー ストーリー、タスク、サブタスクに分け、依存関係、制約、見積もりを考慮して、すべてをどのように組み合わせるかを計画します。
→ デリバリーの計画は Jira で管理します。
Jira プラン機能のアイデア フィールド。
Jira プラン機能のタイミングと依存関係。
Jira プラン機能の依存関係。
Jira Product Discovery と Jira のプラン機能の連携の仕組み
Jira Product Discovery と Jira のプラン機能の連携の仕組みについて説明した Loom 動画をご覧ください。
関係者グループ別のロードマップ
リーダーシップから顧客に至る関係者グループのそれぞれが抱く疑問や懸念はそれぞれ異なります。製品チームが関係者と効果的にコミュニケーションするためには、複数のロードマップが必要になります。
Jira Product Discovery を使用すればこれが簡単になります。毎回ゼロから始めたり、変更を加えるたびにすべてをアップデートしたりすることなく、ロードマップの複数のバージョンを作成できます。
データを細かく切り分けて、各関係者グループに関連するカスタムビューを設定します。ビューは動的にアップデートされるため、1 つのアイデアを変更すると、ロードマップのすべてのバージョンに自動的に反映されます。
また、たとえば、ある製品のリリース予定を何度も聞かれないようにしたいなら、ロードマップをセルフサービス方式にすることも必要になります。全員に独自のロードマップへのリンクを設定し、簡単にアクセスできる方法で必要な情報を共有するようにしてください。
Jira Product Discovery でロードマップを共有する 2 通りの方法があります。
社内の関係者をプロジェクトのコントリビューターとして招待します。Jira アカウントが必要になりますが、コントリビューター役割でのみアクセスする場合は、有料ライセンスは必要ありません。
ビューを公開すると、社内の関係者、パートナー、顧客、エンドユーザーなど、誰とでも共有できます。このビューは読み取り専用で、1 つのリンクで社内外で簡単に共有できます。
各グループのビューをデザインするときは、利用者とって重要だとわかっている問いに前もって対処するようにします。対象者によっては、次のことを強調すると有益です。
- 使用した優先順位付けフレームワーク (インサイト、RICE スコア、影響と労力の比較など)
- どのように分野の間で投資のバランスをとったか
- それぞれのアイデアに対するコミットメントと確実性のレベル
- 項目のステータスに関する情報 (順調、逸脱、リスクあり)
- 労力のレベルと能力の指標
- 順序付けの一般的な考え方 (特定の日付なし)
リーダーシップのロードマップ
リーダーシップと製品チームは通常、中心的な懸念事項が異なり、状況把握の詳細度も異なっています。
製品チームの階層のレベルに応じたロードマップ。
リーダーシップレベルの会話では、通常、目的、投資分野、利用可能なリソースと戦略的目標に基づいて各アイデアに割り当てられるキャパシティが中心になります。
リーダーシップ ロードマップでは、自分自身の確信度も伝えるようにします。たとえば、結果に確信のない先進的なアイデアを試そうとしている場合、そのロードマップ項目を確実な事項と区別しやすくする必要があります。
リーダーシップと共有するロードマップでは、これらの情報をすべて明確にする必要があります。
関係者が特定の機能のリリースの期日に強い関心を示す場合
機能をリリースする正確な日付を約束すると、失敗につながります。ソフトウェア エンジニアリングのプロセスには不測の事態がつきものです。ロードマッピングの会話が特定の日付に集中すると、無理な期待を設定し、約束した日付に間に合わずリーダーシップ チームの信頼を失うリスクがあります。
このダメージは修復が難しいうえ、最終的には、日付を確定することはそれほど重要ではありません。重要なのは、自分の作業がどのような影響をもたらし、会社の成功にどのように貢献するかです。
リーダーシップとの会話では、実行の詳細について議論するのではなく、全体像に集中するようにします。
次のような問いについて考えます。
- 確実に勝算があるか。
- 会社の目的を考慮すると、他の分野に投資すべきか。
- これらの計画は、利用可能なリソースと制約から考えて現実的と思われるか。
新しいロードマップを作成するときはいつでも、期待を再設定し、関係者全員にとって生産的な方法で議論を組み立てる機会になります。
すべての関係者グループには異なる優先順位があります。優れたロードマップでは、関係者にとって何が重要かを中心に会話が構成されます。たとえば、関係者にとっての目標は何か、どのような成果を達成しようとしているのか、などです。
そうすれば、チームがどこで、どのようにその実現を支援できるかについて、話し合いを進めることができます。
Jira Product Discovery のリーダーシップ ロードマップ
Jira Product Discovery を作成していたとき、2024 年半ばにアトラシアンのリーダーシップ チームと次のロードマップを共有しました。
Jira Product Discovery のリーダーシップ ロードマップ
Jira Product Discovery のリーダーシップ ロードマップの 1 項目
このロードマップでは、いくつかの重要な懸念事項が強調されています。
- 期間: 今後 6 か月間に確実に果たすコミットメントのみ
- 想定される影響: リスクのある大きな決定事項とそれらが選ばれた理由
- 投資レベル: チームがそれぞれのアイデアにどれだけのリソースを投入するか
重要なのは、このロードマップにはどのアイデアにも日付についての言及がないことです。
製品チームとスクワッド向けのロードマップ
製品チームのロードマップでは、何に対して「イエス」「ノー」と言っているのかを明らかにし、順序を明確にする必要があります。製品チームが取り組んでいる問題と、それらがどのように機能に変換されるかを示して、物事を概要レベルに保ちます。
このビューの目的は、(Jira で行われる) チームの日常業務をガイドすることではなく、チームが自分たちのミッションを明確にし、特定の問題を効果的に解決できるようにすることです。
Jira Product Discovery の製品チーム ロードマップ
これは、Jira Product Discovery に取り組むあるスクワッドが共有しているロードマップです。
Jira Product Discovery のスクワッド ロードマップ
Jira Product Discovery のスクワッド ロードマップの 1 項目
ご覧のように、Jira Product Discovery では 2 つのレベルのロードマップを使用しています。1 つ目のロードマップは製品全体に関するもので、リーダーシップと共有されます。そして 2 つ目のロードマップでは、各スクワッドのスコープが示されます。
Jira Product Discovery の 2 つのレベルのロードマップを作成する方法については、次の 2 つのビデオを参照してください。
2 つのレベルのロードマップの作成 - パート 1
2 つのレベルのロードマップの作成 - パート 2
顧客対応チーム向けのロードマップ
顧客対応チームには、顧客と何を共有できるかをすぐに把握できるロードマップが必要です。つまり、以下の点が明確になっている必要があります。
- どのアイデアを実行するか
- どんな機能やアイデアがいつ登場するのか
- そのコミットメントの達成に関する確実性レベル
コミットメントは、その確実性レベルとともに詳細に説明する必要があります。そうしないと、顧客は、結局は守られない期日や期限を期待したり、いつまでもリリースされない機能の提供が約束されていると思ったりする可能性があります。
顧客対応チーム向けの Jira Product Discovery ロードマップ
顧客とエンド ユーザー向けのロードマップ
公開ロードマップは、製品の将来の計画を共有し、有益なフィードバックを促すことで、顧客の信頼を高め、関係を強化することができます。
特に企業顧客はこの情報を期待しています。製品を購入するときは長期的な旅になることを知っており、旅の目的地がどこなのかを知る必要があると考えているからです。
ただし、このオープンさにはマイナス面もあります。製品チームがより厳しい監視とプレッシャーにさらされることになるからです。ロードマップが変更されると、顧客はその変更を優先順位の変更や予測不可能な問題ではなく、約束が破られたと考えて失望する可能性があります。
これは、製品とその開発チームへの信頼を損なう可能性があります。したがって、シナリオの長所と短所を必ず比較検討してください。
Jira Product Discovery を使用して顧客やエンド ユーザーとロードマップを共有するには、いくつかの方法があります。
- 完全に公開するのではなく、特定のユーザー リストと安全に共有されるビューを作成する。
- 誰もがアクセスできるようにオンラインで公開される、真の公開ロードマップ ビューを作成する。
- 別のツールを使用してロードマップを公開する一方で、公開されたコミットメントを製品バックログで追跡する。こうすることで、優先順位を見直す際にどのイニシアチブがコミットされたかを知ることができます。
Atlassian Cloud の公開ロードマップ
アトラシアンでは、厳選されたクラウド製品の公開ロードマップを公開しています。
Atlassian Cloud 公開ロードマップ (2024 年 5 月)
Atlassian Cloud セキュリティ チームは、このロードマップに大きく貢献しています。このチームの Jira Product Discovery プロジェクトでは、特定のビューを使用して、どのコミットメントが公開されたかを追跡しています。
考慮すべきロードマップ形式
厳密に直線的なロードマップは誤解を招きます。将来を見据えるほど、コミットメントの確実性は低くなります。効果的なロードマップには確実性が反映されている必要があります。
代わりに、ロードマップを正直かつ戦略的なものにすることを目指してください。
誤解を招くロードマップ、正直なロードマップ、戦略的なロードマップ。ソース: @spavel.bsky.social🐀 on Twitter / X
データを使用して、チームが何を繰り返し、何に向かって取り組んでいるのかを伝える、独自の最適なロードマップ形式を設計します。
ただし、インスピレーションを得るために頼りになるロードマップ形式がいくつかあります。ここでは、アトラシアンのお客様のためによく使用しているものをいくつかご紹介します。
成果ベースのロードマップ
優れたロードマップは、製品チームがどのような成果を達成しようとしているのかを明確にし、そこにどのように到達しようとしているのかを伝えます。
例としては、Jira Product Discovery のリーダーシップ ロードマップが挙げられます。これは、すべてのスクワッドにわたって、製品全体に対する投資についてどのように考えているかを説明しています。
この形式は、アトラシアンにとってはうまく機能していますが、正しく行うための唯一の公式はありません。いろいろ試して、ロードマップが会話をどのように導くかを確認して、ご自身に合ったものを見つけてください。
Jira Product Discovery の成果ベースのリーダーシップ ロードマップ
現在/次回/後日のロードマップ
現在/次回/後日のロードマップは、チームの取り組みや、各取り組みの確実性のレベルについて全員の足並みを揃え、順序付けのアイデアが得られる効果的な方法です。
このロードマップ スタイルは、成果、不確実性、キャパシティに関する会話に焦点を絞ることができるため、製品チームの間で非常に人気があります。ただし、ガント チャートなどの他の一般的な形式とは異なり、現在/次回/後日のロードマップでは、デリバリーの詳細や日付にとらわれることはありません。
Jira Product Discovery チームは、スクワッド固有のロードマップごとに次の形式を使用します。
Jira Product Discovery の現在/次回/後日のスクワッド ロードマップ
現在/次回/後日のロードマップでよくある落とし穴は、ロードマップを「最初にこれを実行し、次にあれを実行し、後でこれを実行する」と解釈してしまうことです。これは、すべてのアイテムが最終的にリリースされるというコミットメントを表していますが、過度に物事を単純化しています。
代わりに、次のように考えてください。
- 現在: チームが積極的にソリューションを検証したり、検証済みのソリューションを実装したりしている、検証済みの機会。アイデアは Explore (探索)、Make (開発)、または Impact (影響) の段階。
- これらのアイデアはリリースされるか、ソリューションが検証できない場合は「次回」列に戻されるか、学習に基づいて完全に放棄される可能性があります。
- 次回: チームが潜在的な解決策を十分に理解している検証済みの機会。アイデアは Explore (探索) の段階。
- これらのアイデアは、「次回」列に進むか、より有望な解決策を優先して「後日」列に戻されるか、学習に基づいて完全に削除される可能性があります。
- 後日: チームが潜在的な解決策をまだ評価している検証済みの機会。アイデアは Wonder (構想) または Explore (探索) の段階。
- これらのアイデアは、「現在」や「次回」に進むか、「後日」に残るか、学習に基づいてロードマップから削除される可能性があります。
時間ベースのロードマップ
ガント チャートは製品ロードマップでは絶対に避けるべきものです。成果 (すなわち、「そもそも、私たちはなぜ X に取り組んでいるのか?」) に会話の焦点を当てるのではなく、出力 (すなわち、「X はいつリリースされるのか?」) に焦点を当てるものですが、これは適切ではありません。
しかし、だからといって、時間ベースのロードマップを完全に無視すべきだというのではありません。他のチームがあなたの仕事に関連している場合、またはマーケティング チームや顧客対応チームと情報を共有する場合には、時間ベースのロードマップが役に立ちます。ロードマップにアクセスするすべての人が、それぞれのアイデアに対するあなたの自信とコミットメントのレベルを理解していることを確認する必要があります。
Jira Product Discovery チームでは、時間ベースのロードマップを使用していません。日付に関する会話は、製品の意思決定において最も生産性が低いものだということがわかっているからです。もし、時間ベースのロードマップを使用していたら、次のようになってしまうでしょう。
時間ベースのロードマップの例
時間ベースのロードマップを設計するときは注意してください。遠い将来に対して、確信を抱いたり、不当な期待を抱いたりしがちだからです。
次のロードマップは、まるでチームが 6 か月から 1 年後に何が起こるかを明確に把握しているかのように見えるため、誤解を招く可能性が高くなります。
関係者が時間ベースのロードマップを要求している場合は、より正直なストーリーを伝えるために、現在/次回/後日のロードマップとタイムラインを組み合わせることをお勧めします。
- 現在/次回/後日のロードマップにより、チームがコミットするのに十分な確信を持っている点が明確になります。
- タイムラインの「現在」列にアイデアのみをプロットして、どの月または四半期に実施するかを大まかに示します。
- 「次回」列と「現在」列のアイデアは、達成できない約束をするのではなく、一般的な計画の範囲内に位置付けます。
現在/次回/後日のロードマップ内のタイムライン ビュー
タイムライン ビューは詳細にしすぎないようにし、特定の日付やタスクではなく、重要なアイデアに焦点を当てます。目標は、関係者に目指す方向性を大まかに示すことであり、日々の業務の詳細を示すことではありません。
Jira Product Discovery のタイムライン ビューと日付
異なる期間のロードマップを作成する 2 つの方法のデモを以下に紹介します。私たちが好んで使っているのは 2 つ目のビューです。
日付を設定する際の問題は、デリバリーで学んだことを基に日付が簡単に変わる点です。このビューでは、アイデアに対応するデリバリー チケットができたら、アイデアの日付フィールドがエピック/イニシアチブの日付フィールドで自動的に上書きされるように設定できます。
こうすることで、作業中にエピックに加えられた変更は、すぐにロードマップに反映されます。
Jira Product Discovery のロードマップ内の動的なタイムライン ビュー
Jira Product Discovery で Jira エピックの日付を取得するように設定された 1 つの日付フィールド
製品イニシアチブのダッシュボード
この製品全体のロードマップ形式では、計画済みまたは進行中のすべての製品イニシアチブの全体像を把握できます。エンジニアリング リーダーシップと協力する際に特に役立ちます。
このロードマップを常に製品バックログに保持することをおすすめします。ディスカバリーとデリバリーの作業は関連しているものの、明らかにディスカバリーの領域 (潜在的なソリューションの評価中) にあるものもあれば、デリバリーの領域 (スプリントの実行中) にあるもの、この 2 つを橋渡しする領域 (技術的負債と新機能をどのように優先化するかを決定中) にあるものもあります。
このロードマップ形式は、製品バックログを優先化する際に、これらのカテゴリー全体での投資を視覚化する良い方法です。
