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

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

Dan Radigan Dan Radigan

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

What is an agile product roadmap?

A product roadmap is a plan of action for how a product or solution will evolve over time. Product owners use roadmaps to outline future product functionality and when new features will be released. When used in agile development, a roadmap provides crucial context for the team's everyday work, and should be responsive to shifts in the competitive landscape. Multiple agile teams may share a single product roadmap.

ロードマップの作成

To build a roadmap, product owners take into account market trajectories, value propositions, and engineering constraints. Once these factors are reasonably well-understood, they are expressed in a roadmap as initiatives and timelines. Below is a very simple roadmap for a product team. The initiatives are in blue and timelines are indicated by the milestone-markers in red. 

Agile roadmap | Atlassian agile coach

ロードマップの共有

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

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

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

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

Before we talk about dynamic forecasting solutions, let's talk about the steps to build a long-term agile plan using the metaphor of building a house:

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

ロードマップの使用

It's important to link your team's work back to the roadmap so you get that whole "context" thing I mentioned above. A tried-and-true way of doing this is to break initiatives down into epics in the product backlog, then further decompose them into requirements and user stories. Tying it all together like that makes it easier for product owners and the development team to make near-term decisions that don't compromise future work. Let's look at an example to see how this plays out.

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

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

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

ロードマップの進化

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

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

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

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

Keep reading The Agile Coach to learn about special considerations for larger teams who manage agile portfolios which have roadmaps across several teams.