デュアルトラックアジャイル

デュアルトラックアジャイルは、探索（Discovery）と提供（Delivery）を並行して進める考え方です。開発チームがスプリントで実装している間に、プロダクトマネージャーやデザイナーが次に作るものを調べる、という単純な分業の話ではありません。

本質は、作る前の不確実性と、作るときの不確実性を分けて扱うことにあります。

Discovery と Delivery

Discovery は「何を作るべきか」を学ぶ活動です。顧客の課題を調べ、仮説を立て、プロトタイプやデータで検証します。

Delivery は「どう作り、届けるか」を扱う活動です。設計、実装、テスト、リリース、運用を通じて、実際に利用できる形にします。

この2つは、直列にすると詰まりやすくなります。Discovery が大きな仕様書づくりになれば、Delivery は受け身になります。Delivery だけが先行すれば、チームは価値が不明なものを作り続けます。

よくある失敗

デュアルトラックを導入するときによくある失敗は、Discovery を「上流工程」として扱うことです。そうなると、プロダクトマネージャーが要件を固め、デザイナーが画面を作り、エンジニアが実装するという古い流れに戻ります。

もうひとつの失敗は、Discovery をイベント化することです。四半期の最初に調査をして、その後はひたすら作るだけになると、学びが途切れます。

チーム全員で関わる

Discovery には、エンジニアも関わるべきです。技術的な実現可能性を早く見極められるだけでなく、解決策の選択肢が増えるからです。カスタマーサクセスや営業も、顧客の状況を知る重要な情報源になります。

ただし、全員が常にすべての活動に参加する必要はありません。重要なのは、発見したことがチームの意思決定に流れ込むことです。

実践のコツ

  • 次のスプリントで作るものだけでなく、数週間先の仮説も見ておく
  • 大きな要件ではなく、検証可能な仮説としてバックログに置く
  • Discovery の学びをスプリントレビューでも扱う
  • Delivery の実装中に出た気づきを Discovery に戻す

デュアルトラックアジャイルは、速度を上げるためだけの仕組みではありません。チームが「正しく作る」と「正しいものを作る」を同時に学び続けるための仕組みです。