デュアルトラックアジャイルって結局何なの？

こんにちは、河口です。
atama plusというAI×教育のスタートアップでスクラムマスターをしています。会社と私の紹介については、以下のスライドとnoteを参照ください。

みなさん、「デュアルトラックアジャイル」という言葉をご存知ですか？

デュアルトラックアジャイルとは、「事前に最小コストで最大のリスクをつぶしながら、価値あるプロダクトを作っていく」ための開発プラクティスです。

atama plusでは創業当初からデュアルトラックアジャイルを実践しようと取り組み、たくさんの失敗と成功を重ねてきました。ディスカバリーバックログとデリバリーバックログを分けてプロセス化してしまったことによるミニウォーターフォール化など・・・。

今年のはじめに弊社のデザイナーも、atama plusのデュアルトラックアジャイルの取り組みを紹介していました。今回は、プロダクトオーナー、スクラムマスターの視点から、私がデュアルトラックアジャイルを実践する中で学んだことをお伝えしたいと思います。

今回お伝えしたいこと

今回のnoteでは、「デュアルトラックアジャイルはなんとなく知っているけれど、実践にあたって何がポイントになるの？」という疑問をお持ちの方向けに、下記をお伝えできればと思います。

1. デュアルトラックアジャイルを実践するにはマインドセットとプラクティスを理解することが最も重要である
2. デュアルトラックアジャイルはスクラムのようなプロセスフレームワークではない

※atama plusのデュアルトラックアジャイルの失敗と成功は、また改めてnoteに書く予定です。

※デュアルトラックアジャイルの詳細に興味のある方は、「ユーザーストーリーマッピング」「Lean UX」「INSPIRED」などの本がおすすめです。

デュアルトラックアジャイルを実践するにはマインドセットとプラクティスを理解することが最も重要である

そもそもデュアルトラックアジャイルというのは、「事前に最小コストで最大のリスクをつぶしながら、価値あるプロダクトを作っていく」ための開発プラクティスです。「デュアルトラック」という通り、ディスカバリートラックとデリバリートラックという2つのトラックがあります。

ディスカバリーとは「最小コストで最大の学びを得る」ために行うトラック。

デリバリーは「一定の規模（ユーザーにプロダクトを当てて）で学びを得る」ために行うトラック。

この2つのトラックはそれぞれのマインドセットとプラクティスを理解することが大切です。

特にディスカバリーでは、デリバリーする際の最大のリスク、すなわち検証すべき仮説を絞って小さく検証することを目的とする一方、デリバリーでは、商用レベルの品質で一定の規模のユーザーにプロダクトを当てて検証することを目的としています。

また、その際に用いるプラクティスも異なります。特にデリバリーに関してはスクラムの「出荷可能なプロダクト」を、イテレーティブかつインクリメンタルに作ることをベースにしていますが、ディスカバリーにおいては仮説に対して解像度を上げていく方法は多岐に渡ります。

プロダクトディスカバリーで検証する仮説とその手法（一例）

「INSPIRED」の著者であるMarty Cagan氏も語っていますが、ディスカバリートラックでは4つのリスクに対応します。

・ビジネス的な価値があるかどうか（我々のビジネスに貢献するか）
・顧客（お金を出す人）にとって価値があるかどうか
・ユーザー（実際にサービスを使う人）にとって価値があるかどうか
・実現可能性があるかどうか

上記のリスクを検証する方法には、例えばユーザーストーリーマッピング、Lean Canvas、プロトタイピング、ユーザーインタビュー、ペルソナの作成など様々プラクティスが存在します。

それぞれの検証方法の引き出しを持って、必要に応じて発動することが大切です。またディスカバリーではマインドセットが重要になります。誰も必要としてないものにムダなコストかけて商品レベルで作り込んでしまう前に、重要なリスクから検証し、間違ってることに早く気づこうとすることが最も大切なのです。

デュアルトラックアジャイルは「デザインプロセス→実装プロセス」ではない

よくデュアルトラックアジャイルを、デザインプロセスと実装プロセスを組み合せたものと捉えられることがあります。ですが、実はそれは大きな勘違いです。

前述の通り、ディスカバリーは様々な仮説に対して検証するプロセスであり、デザインをするプロセスではありません。よくあるのは、「ユーザーにとって価値があるか」に注目してディスカバリーをしすぎた結果、UXデザイナーがデザインのワイヤーフレームを作り込むプロセスになってしまうケースです。

上記の場合、例えば技術的な実現可能性のリスクが最も高いにも関わらず、UXデザイナーが詳細なワイヤーフレームを作成し、デリバリーしようとした際に「こんなの作れないよ」という問題が起きてしまいます。

ユーザーにとって価値があるかを最小コストで検証するのであれば、ラフのワイヤーフレームでも十分。どういう目的でワイヤーフレームを書くのかを理解していることが大切です。

「Lean UX」の著者のJeff Gothelf氏も言うように、俯瞰すると、商用レベルでのプロダクトの価値をユーザーに検証する意味で、最終的にはデリバリー自体も大きなディスカバリーの一種になり得ます。

毎回仮説は変わっていきますし、仮説に対する解像度も変わります。ディスカバリー→デリバリーとただ単にプロセスを分けるのではなく、プロダクトオーナーを中心に、チーム全体でどの仮説に対して、どう検証するかの共通理解を持ち、それを最も効率的に検証する布陣で取り組むことが大切になります。

つまり、ディスカバリーとデリバリーは2つの考え方であって、「デザインプロセス」「実装プロセス」という2つのプロセスではないのです。

なぜデュアルトラックアジャイルが難しいのか

ここまでデュアルトラックアジャイルは、プロセスフレームワークではなくマインドセットが大切であること、そしてそれを実践するためのプラクティスがあること、を説明してきました。

では、なぜデュアルトラックアジャイルの実践は難しいのでしょうか？

それは、プロダクトオーナーを含めたチームメンバー全員が、上記のマインドセット及びプラクティスを理解した上で行う高度な開発戦術だからです。

私がデュアルトラックアジャイルの実践が難しいと考える点は主に2つあります。

プロダクトディスカバリーの方法は過度にプロセス化できない

1点目は、プロダクトディスカバリーの方法は過度にプロセス化できないという点です。

以前「スクラムは方法論？プラクティス？」という記事をnoteで書きましたが、スクラムはスプリントをこなすことで学習が促進されるプロセスフレームワークになっています。

一方、プロダクトディスカバリーは都度状況に応じて検証方法を考え、前述のユーザーストーリーマッピングなどのプラクティスを選択しながら、取り組む必要があります。従って、デュアルトラックアジャイルを一連のプロセスに落とそうとすると、失敗する可能性が高い、と個人的に考えています。

プロダクトオーナーをはじめ、チームメンバーと相談しながら仮説に応じてどう検証していくかのプラクティスを試しつつ、自分たちの成功パターンをたくさん作っていくことが重要です。

そして、成功パターンができてくるとプロセス化（仕組み化、組織化）したくなりますが、そのときに、組織の自己組織化が阻害されることのないように、組織論の観点を意識することも大切です。

例えば、プロダクトディスカバリーを少数のメンバーで実施してうまくいったために、スクラムチームとは別にプロダクトディスカバリーチームを作ってしまうなどです。このように、組織として別チームを作ってプロダクトディスカバリーを仕組み化してしまうと、デリバリーチームとディスカバリーチームに分かれてしまい、デュアルトラックアジャイルのアンチパターンである「ミニウォーターフォール化」が起きてしまいます。

一定程度プロセス化していくことも必要ですが、スクラムの範囲を超えて新たに権限と責任を作ってしまうと、チームからプロダクトディスカバリーのマインドセットがなくなり、プロセスが形骸化し、自己組織化が阻害される可能性があるので注意が必要です。

「ディスカバリー」と「デリバリー」のバランスが非常に重要

2点目は、「ディスカバリー」と「デリバリー」のバランスが非常に重要であるという点です。

アジャイル開発は「リスクの最適化」を行っていく開発手法です。デュアルトラックアジャイルでは、プロダクトオーナーが、ある仮説に対してどのくらいディスカバリーに投資をし、どのタイミングでデリバリーするか、という最終的な判断の鍵を握ります。

この投資タイミングは、チームの状況・事業概況なども踏まえてリスクを最適化しなければいけません。ここに正解はありません。プロダクトオーナーは、チームと協力して常にバランスを考える続ける必要があります。

デュアルトラックアジャイルはスクラムのようなプロセスフレームワークではない

上述の通り、デュアルトラックアジャイルは高度な開発戦術であり、銀の弾丸ではありません。またスクラムのようなプロセスフレームワークでもないと考えています。

私にとってはドイツのプロサッカーチームであるバイエルンミュンヘンの戦術のようなイメージ。いきなりプロセスを導入したからといって、うまくいくものではありません。（参考：サッカー漫画「アオアシ」）

デュアルトラックアジャイルとは、スクラムを通して自己組織化された組織を作りつつ、またデュアルトラックアジャイルのマインドセット、プラクティスを試しながら最も良い開発方法を探し続けるものではないでしょうか。

まとめ

今回はデュアルトラックアジャイルを実践する上でのポイントについて書きました。

・デュアルトラックアジャイルを実践するにはマインドセットとプラクティスを理解することが最も重要である
・デュアルトラックアジャイルはスクラムのようなプロセスフレームワークではない

次回は、atama plusがデュアルトラックアジャイルを行いながら、どういう失敗と成功を繰り返してきたのかを書く予定です。

私たちのデュアルトラックアジャイルもまだまだ試行錯誤中ですが、その中で私たちなりの成功パターンを増やしていきたいと思います。

（2022/01/25追記）
1年越しに続きの記事を書きました！

atama plusはミッション実現のためにメンバーが集まっている会社で、アジャイル開発はミッション実現の大事な手段です。もしよろしければミッション実現のために一緒にトライしませんか？