アジャイルロードマップ: 作成、共有、使用、発展

要約: 製品ロードマップとは、製品やソリューションを時間の経過とともにどのように進化させるかを決める活動計画のことです。製品チームはロードマップを使って今後の製品機能や新機能のリリース時期を計画します。アジャイル開発の場合は、ロードマップを使ってチームにおける日々の重要な背景を伝えます。また、競合他社の状況の変化にも素早く対応できるようにします。

アジャイル開発では長期の計画が不要になるという考えは、ネス湖の怪物以来最大の伝説かもしれません。アジャイル チームにとってもウォーターフォール チームにとっても、ロードマップは同じように重要です。ロードマップはチームの日常業務や長期的なビジョンに関するコンテキストを提供し、競争環境の変化に対応できるからです。しかし、ネス湖の伝説の怪物とは違い、アジャイル ロードマップはすぐに見つかり、簡単に理解できます。

プロダクト ロードマップとは、製品またはソリューションを、時間の経過とともにどのように進化させるかを決める行動計画です。製品チームはロードマップを使って今後のプロダクト機能や新機能のリリース時期を計画します。アジャイル開発の場合は、ロードマップはチームの日常業務や将来のビジョンに重要なコンテキストを提供し、競合他社の状況の変化にも素早く対応できるようにします。複数のアジャイル チームが 1 つの製品ロードマップを共有することもあれば、各チームが独自の製品ロードマップを持つこともあります。

ロードマップを作成するために、 製品チームは市場の動き、会社の目標、顧客からのフィードバックとインサイト、およびエンジニアリングの制約を考慮します。これらの要因が大枠で見えてきたら、イニシアチブやタイムラインとしてロードマップに表現します。次に、製品チームのごくシンプルなロードマップを示します。一般的に言って、製品ロードマップは、特定の日付ではなく、数か月や数四半期といったより大きな時間枠で設定するのが最適です。優先順位付けの会話をタイムラインではなく目標と戦略に集中させるために、イニシアチブを現在、次回、後日にマッピングしてみることもできます。

ロードマップを作成した後、それを製品チーム、リーダーシップ、デリバリー チーム全体と共有し、全員がビジョンと方向性を理解できるようする必要があります。多くの組織では、製品所有者が PowerPoint やスプレッドシートを使用してロードマップを作成し、スライドやスプレッドシートを電子メールでチームに送信します。善意とはいえ、この方法には最初から欠陥があります。チーム メンバーがそれぞれロードマップを持っているため、ロードマップが変更された場合に全員がその情報を把握できるようにすることは、(控えめに言っても) 時間がかかり、困難です。

では、どうすれば製品チームは組織に情報を周知できるのでしょうか?簡単です。

ほとんどのコラボレーション ツールは、プロジェクトの参加者全員にロードマップの変更を自動的に通知します。

ロードマップにイニシアチブを追加する場合は、次の点を考慮しましょう。

動的な予測ソリューションについて説明する前に、家を建てるという例を使用して、長期的なアジャイル計画を作成する手順について説明します。

• 各イニシアチブの相対的な優先順位はどうなっているか?
  • 各イニシアチブは製品や会社の目標にどのような影響を及ぼしますか?
  • 各イニシアチブにはどのくらいの労力が必要ですか?
  • イニシアチブの推進をサポートするのに十分なインサイトとデータがありますか?
• それぞれのイニシアチブにいつ取り掛かるか?
  • チームが守らなければならない具体的な日付はあるか?
  • 問題にどのような依存関係があるか? (内部、他のチーム)
• 各イニシアチブにどのチームが取り組むか?
  • 現在のチームにスケジュールの空きと十分な処理能力があるか?
  • 現在のアジャイルチームを安定維持できるか?
    • できない場合...
      • チームをどのように再編するか?
        • チームの新設をプロジェクトのタイムラインに組み込めるか?

チームのデリバリー作業を製品ロードマップにリンクすることが重要であり、そうすることで前述の「コンテキスト」全体を把握できます。そのための実証済みの方法は、製品マップで優先順位を付けた製品のアイデアを計画し、それらのアイデアをエピック、要件、ユーザー ストーリーに分解してデリバリー ロードマップを作成します。多くの場合、各アイデアには対応するエピックがあり、それを小さなタスクに分割して実行する必要があります。製品ロードマップ上のアイデアと、デリバリー ロードマップ上のエピックを結び付けることで、エンジニアはユーザーからのフィードバックや調査など、優先順位の高いイニシアチブの背後にあるコンテキストを得られます。さらに、製品チームと開発チームは、将来の作業に悪影響を及ぼさない短期的な意思決定を下しやすくなります。

例えば、Web サイトに詳細なユーザープロファイルフィーチャーを展開するとします。顧客がこのフィーチャーを使用しない場合、投資を続けるべきでしょうか？止めた方がよいのかもしれません。判断を下す前に、なぜエンゲージメント率が低いのかを把握する必要があります。このように、前進する前に、A/B テストを行ってエンゲージメント率を調べるという選択も可能です。もし余計な機能の追加を進めれば、さらに困難 (あるいは不可能) な方向に向かう恐れもあります。

重要な決定を下す前に一歩下がって調査できる点は、アジャイル ロードマップの真髄です。そして、理想的には、インサイトとデータを収集するディスカバリー プロセスは、何らかの決定を実行に移すことを決定する前に行う最初のステップとなります。製品や市場についての理解を深めながら、機能を進化させることができます。

ウォーターフォールプロジェクトには多額の事前投資が必要です。その結果、チームメンバーはロードマップに感情的に執着します。行った作業が無駄になるのを嫌がるあまり、適切な決定が行われません。これは人間ゆえの過ちです。

これに関して、アジャイル開発には 3 つのリスクがあります。

• ロードマップの更新が頻繁すぎると、リーダーの戦略的意思決定の能力に対する信頼が失われる恐れがあります。
• ロードマップの更新頻度が低すぎると、市場への製品投入が遅れ、累積需要を逃す可能性があります。
• 長期的な取り組みは短いイテレーションに対して「壮大すぎて達成困難」に見える可能性があります。チームはその反動で作業を細かく分割し、短期的な成果を偏重することになります。

「スラッシュ」、陳腐化、近視眼的な見方に対抗するには、ロードマップにおいて短期的戦術および戦略と長期的ゴールに均等に労力を配分します。そのための最善の方法は、ロードマップを四半期に 1 度見直し、必要に応じて調整を行って共有することです。これは組織の規模にかかわらず有効です。ただし、1 つのロードマップに複数のアジャイルチームが関連していることもあるため、点検、適合、伝達を適切に行う必要があります。

「アジャイル コーチ」をさらに読み、アジャイル ポートフォリオのロードマップが複数のチームに関連している大規模チーム向けの特別な懸念事項について詳細をご確認ください。製品チーム向けに作られた Jira Product Discovery で、独自のロードマップを無料で作成することもできます。