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

今後チームでデュアルトラックアジャイルを取り入れることになりました。まず自分の理解を固めるために、その考え方を整理してみます。

デュアルトラックアジャイルとは、プロダクト開発を「何を作るか」を探索するディスカバリートラックと、「それを実際に作る」デリバリートラックの2本の軸で並行して進める開発スタイルです。Marty Cagan が著書 Inspired の中で広めた考え方で、スクラムやカンバンなどの既存フレームワークを置き換えるものではなく、それらに重なるかたちで機能します。

ディスカバリーで「作るべきもの」を絞り込みながら、デリバリーで「作ると決まったもの」を着実に届ける——この2本立てが基本の構造です。

なぜ必要なのか

「ものを正しく作る (build it right)」というのはエンジニアリングの問いです。テストを書く、設計を整える、バグを出さない。

一方「正しいものを作る (build the right thing)」というのはプロダクトの問いです。ユーザーが本当に困っていることを解決できているか、そもそも必要とされているものを作っているか。

従来の開発では、この2つが混ざりやすい状態でした。要件定義をして、作って、リリースしてみたら誰も使わなかった——というケースがアジャイル以前にも以後にも繰り返されてきたのは、「正しいものを作る」という探索が後回しにされてきたからです。

デュアルトラックアジャイルはこの問題に正面から向き合うために、探索と実装を別のトラックとして意識的に分離します。

2つのトラックの役割と流れ

ディスカバリートラック

ディスカバリートラックの目的は、「デリバリーに渡してよいと確信できるアイデア」を作ることです。確信とは、次の4つが揃った状態を指します。

  • 価値 (Value): ユーザーが欲しいと思うものか
  • ユーザビリティ (Usability): ユーザーが使いこなせるか
  • 実現可能性 (Feasibility): エンジニアリング的に実現できるか
  • 事業適合性 (Viability): ビジネス・法律・倫理の観点で問題がないか

これらが揃うまでアイデアを検証し、揃ったものだけをデリバリーに流します。

デリバリートラック

デリバリートラックは、ディスカバリーで承認されたアイデアを実際のソフトウェアとして届けることに集中します。スプリントを回し、テストを書き、ステークホルダーに動くものを見せる。ここでの「作る」に全力を注ぎます。

2つのトラックは並行して走ります。デリバリーがスプリントを回している間に、ディスカバリーは「次に届けるべきもの」を準備し続けます。これにより、デリバリーがアイデア枯渇で止まることを防ぎます。

ディスカバリーで行うアクティビティ例

ディスカバリーは抽象的なリサーチではなく、具体的な検証アクティビティの積み重ねです。自分が理解した範囲でいくつか挙げると次のようなものがあります。

ユーザーインタビューは最も基本的なアクティビティです。作ろうとしているものの前提となる課題認識が正しいかを確かめます。「このボタンを追加したいのですが使いますか?」と聞くのではなく、ユーザーの行動・状況・困りごとを引き出すかたちで行うのが重要です。

プロトタイプ検証では、実装せずにモックや紙の画面でユーザーに触ってもらい、操作できるか・意図が伝わるかを確認します。Figma などで作った試作物を数人に触ってもらうだけでも、実装後に発覚するはずの問題を事前に潰せます。

**スパイク (技術調査)**は実現可能性を確かめるためのものです。「この機能を実現するには既存のアーキテクチャをどう変える必要があるか」を短期間で調べ、デリバリーに流せるかどうかを判断します。

よくある誤解

ウォーターフォールのリサーチフェーズとは違う

「先に要件定義・調査フェーズを設ける」というのは、デュアルトラックアジャイルとは別物です。ウォーターフォールのリサーチは一度きりで、その後の実装フェーズには戻りません。

デュアルトラックアジャイルのディスカバリーは継続的に動き続けます。デリバリーが1つの機能を届けている間にも、ディスカバリーは次の仮説を検証しています。探索と実装が常に並走している状態が正常です。

ディスカバリーはプロダクトマネージャーだけの仕事ではない

もう1つよく聞く誤解として「ディスカバリー = PM の仕事」という分業があります。実際には、エンジニアもデザイナーもディスカバリーに参加することが推奨されています。技術的な実現可能性の判断や、UX の視点からの洞察は、PM 単独では得られません。チームが一体となって探索するところにデュアルトラックアジャイルの強みがあります。

取り入れようと思った理由と感想

正直なところ、これまでは「作るべきものはすでに決まっている」という前提でスプリントを回すことが多かったように思います。バックログを消化していくリズムはある種の安心感を与えてくれますが、「それは本当にユーザーに届いているのか」という問いは後回しになりがちでした。

デュアルトラックアジャイルを整理してみて、自分が一番刺さったのは「確信を持ってデリバリーに流す」という発想です。作ることに集中するためにこそ、何を作るかを先に十分に検証する。そのための構造を明示的に設けるのがこのスタイルの本質だと理解しました。

実際に運用してみないとわからないことは多いですが、まずはディスカバリーの習慣をチームに根付かせることから始めてみようと思っています。

まとめ

  • デュアルトラックアジャイルはディスカバリー(何を作るか探索)とデリバリー(それを実装)を並走させる開発スタイル
  • 「正しいものを作る」と「ものを正しく作る」の両方を、別のトラックとして意識的に扱う
  • ディスカバリーはウォーターフォールの要件定義フェーズではなく、継続的な仮説検証のプロセス
  • PM だけでなく、エンジニア・デザイナーも含めたチームで探索することが大切