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

アジャイル手法を採用したからといって、行き先が分からなくなるというわけではありません。
行く道を柔軟に選べるということです。

Dan Radigan 作成者 Dan Radigan
トピック一覧

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

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

アジャイルプロダクトロードマップとは?

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

ロードマップの作成

ロードマップを作成するには、プロダクト所有者が市場の動きや価値提案、エンジニアリングの制約を考慮します。これらの要因が大枠で見えてきたら、イニシアチブやタイムラインとしてロードマップに表現します。次に、製品チームのごくシンプルなロードマップを示します。イニシアチブを青、タイムラインを赤のマイルストーンマーカーで示しています。

アジャイルロードマップ|アトラシアンアジャイルコーチ

ロードマップの共有

ロードマップを作成した後、全員がビジョンと方向性を理解できるように、製品チーム全体と共有する必要があります。多くの組織では、プロダクトオーナーが PowerPoint やスプレッドシートを使用してロードマップを作成し、スライドやスプレッドシートを電子メールでチームに送信します。善意とはいえ、この方法には最初から欠陥があります。各チームメンバーがロードマップを持っているため、ロードマップに変更が生じた場合に全員が共通の認識を持つのは (控えめに言って) 困難です。

では、プロダクトオーナーがチームにより適切な情報を提供するにはどうすればよいのでしょうか?簡単です。

この種の目的に作られたコラボレーションツールの大半では、プロジェクトの参加者全員にロードマップの変更が自動的に通知されます (そのような機能がなければ、新しいツールを購入すべきです)。

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

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

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

ロードマップの使用

前述の「コンテキスト」全体を理解するために、チームの作業をロードマップにリンクすることは重要です。そのための確実な方法は、イニシアチブをプロダクトバックログのエピックに分割し、さらに要件とユーザーストーリーに分解することです。このようにすることで、プロダクトオーナーと開発チームは、将来の作業に悪影響を及ぼさない短期的な意思決定を下しやすくなります。例を見ながら考えてみましょう。

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

重要な決定を下す前に一歩下がって調査できる点は、アジャイルロードマップの真髄です。製品や市場についての理解を深めながら、フィーチャーを進化させることができます。

注意すべきアンチパターン
  • 将来の計画が完全に無視される (思い付きで行動している)。
  • チームが従事することに関して、「ビジネスの他の部分」が分からないままになっている。
  • ロードマップが絶えず更新されている (または全く更新されていない)。
  • 細かい要件でロードマップが圧迫されている。

ロードマップの進化

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

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

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

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

「アジャイルコーチ」をさらに読み、アジャイルポートフォリオのロードマップが複数のチームに関連している大規模チーム向けの特別な懸念事項について学びましょう。または、Jira Software のロードマップサービスで詳細をご確認ください。