見出し画像

デュアルトラックアジャイルを実践するコツ

atama plusでスクラムマスターをしている河口です。前回、デュアルトラックアジャイルについてnoteを書いてから1年以上が経ちました。

atama plusのアジャイル開発もどんどん進化しており、たくさん学びもありました。今回は前回のnoteに引き続き、デュアルトラックアジャイルを実践していく上でのコツを改めて自分なりにまとめてみました。

開発プロセスの整理や組織づくりのヒントになれば幸いです。

デュアルトラックアジャイルについてのおさらい

改めて、「デュアルトラックアジャイル」とは、プロダクトチームで仮説検証(ディスカバリー)と価値提供(デリバリー)を分断することなく、両輪(デュアルトラック)を回すためのプロダクトマネジメントの考え方でありプラクティスの集合体です。

「デュアルトラック」という通り、ディスカバリートラックデリバリートラックという2つのトラックがあり、その両輪を回しているプロダクトチームの様子を「デュアルトラックアジャイル」と呼んでいます。

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

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

デュアルトラックアジャイルの全体像

そして、必ずしもディスカバリーとデリバリーを並列に回し続ける必要もありませんし、プロダクトのフェーズによって動き方(ディスカバリートラックとデリバリートラックのバランス)は変わってきます。

スプリントごとにDiscoveryとDeliveryの注力バランスは異なる

ではデュアルトラックアジャイルとスクラムをどう組み合わせるのか?

デュアルトラックアジャイルの事例をお話する中でよく、スクラムとの組み合わせについて聞かれます。

注意したいのは、デュアルトラックアジャイルはスクラムのようなプロセスフレームワークではないということです。

スクラムは「現状を把握するためのフレームワーク」であり、スプリントというタイムボックスをベースに作業の透明性を高め、スクラムイベントを通して検査・適応を行う方法論です。一方、デュアルトラックアジャイルはプロダクトづくりの考え方プラクティス集になります。

デュアルトラックアジャイルのディスカバリートラックでは、ユーザーインタビュー、ペルソナ、ユーザーストーリーマッピング、インパクトマッピング、デザインスタジオなど様々なプラクティスがあります。どういうリスクを潰したいかによって使うプラクティスも異なり、またそこを過度にプロセス化しようとすると失敗しやすくなるので、それぞれのフレームワーク、プラクティスの目的が何なのかを意識して、組み合わせを検討することが重要です。

従って、デュアルトラックアジャイルを考える上では、スクラムのプラクティスにこだわることなく、メタにスクラムを捉えることが重要です。

「見積もらなかったらスクラムじゃない!」「DoDがないとスクラムじゃない!」「動くものがないとスクラムじゃない!」などと言わずに、スプリントをどう活用して、何をどう検査・適応するかを考えることがコツだと思います。(もちろんスクラムにおいて何のために見積もるのか、DoDは何のためにあるのか、インクリメントとは何なのかを理解しておくことも重要です。)

atama plusでは、スクラムイベントとして「スプリントプランニング」「スプリントレビュー」「スプリントレトロスペクティブ」「デイリースクラム」を実施しており、スプリントというタイムボックスを活用して、1週間に1回は立ち止まりスプリントでの成果・活動に対して検査・適応をしていこうぐらいのスタンスでスクラムを捉えています。

スプリント内でのディスカバリートラックの考え方

特に、ディスカバリートラックについてはスプリント内での動き方を意識する必要があります。

具体的には、ディスカバリートラックでは、リーン・スタートアップで語られているような「リーンな顧客価値開発」の考え方がベースになります。「構築→計測→学習」のサイクルをスプリントのタイムボックスよりももっと短い間隔で高速に回す必要があります。スプリント内で方向転換が高頻度に発生するため、先々の見通しが立てにくいのも特徴です。

従って、スプリントのように一定のタイムボックスに載せてプロセス設計することが難しいのがディスカバリートラックです。

具体的にはスプリントプランニングにおいて、一定のデリバーの目標を持ちながらも、そこにこだわらずスプリントを通して学習・価値提供したいことの全体を意識して、ディスカバリーとデリバリーのバランス(優先順位やリソース配分)をチーム全体で調整することが必要です。

ベロシティといった、デリバリートラックのスピードばかりに目を向けすぎると、アウトプットが見えやすいデリバリートラックにリソースを張りたくなる力学が働き、ビルドトラップに陥る可能性が高くなるので、一定の緩さをもちつつ、常に何を目指すのかを意識することが重要です。

言うは易く行うは難しなので、atama plusでもOKRなどを活用しながら試行錯誤をしています。

ディスカバリーとデリバリーのバックログアイテムの扱い方

ディスカバリーのバックログアイテムとデリバリーのバックログアイテムを同じプロダクトバックログで扱う工夫も必要です。

デュアルトラックアジャイルのプラクティスの中ではディスカバリーバックログとデリバリーバックログを分けるといったプラクティスも紹介されています。

もちろん管理上、ディスカバリーバックログとデリバリーバックログを分けてもいいですが、個人的にはデュアルトラックアジャイルになれるまでは1つのバックログで管理したほうがチームが同じ目的意識を持ちやすく、コラボレーションが生まれやすいと思っています。

atama plusも2年前はディスカバリーバックログとデリバリーバックログを分けていました。それによりチームの分断が起きてしまい、バックログを1つにするチャレンジをしています。

具体的には1つのプロダクトバックログ上で、ディスカバリーのバックログアイテムとデリバリーバックログアイテムを色で分けて管理しています。

またディスカバリーのバックログアイテムについてはアイテムの粒度にはこだわらないようにしています。ディスカバリーバックログアイテムについてはDoDも特に設けていません。(スクラムの理論上設けることもできますが・・・。)

コラボレーションを意図した組織設計により、自律的な調整を促す

デュアルトラックアジャイルを機能させるにはディスカバリーの進め方、デリバリーの進め方、そのバランスについて、プロセス化しきれない部分を自律的に調整するスキルが求められます。

特にチームがディスカバリー、デリバリーのそれぞれをチームとして回せるスキルがあることが前提となります。

あくまでワンチームでディスカバリー〜デリバリーをする高度な開発戦術であるため、これを過度にプロセス化して、役割分担してしまうと、ミニウォーターフォール化のリスクが出てきます。

ワンチームでの戦術としてディスカバリーを中心にやる人とデリバリーを中心にやる人でわけることはありだと思いますが、完全にプロセスとして分けてしまうと、コラボレーションが生まれなくなります。

開発プロセス作りとしては、はじめからガチガチにプロセスを設計するのではなく、チームが共同責任を負う体制作りと意識付けをすることで、振り返りを通じて活動改善を促します。

組織学習をどう促していくかもポイントになると思います。

atama plusでは読書会などを通して、プロダクトチームとしてどうありたいか、どういう戦術があるかなどの目線合わせを大切にしています。

例えば僕がスクラムマスターとして一緒に活動している新規事業のオンライン模試を作っているチームでは、チームを組成したばかりの2020年7月はとにかくデリバリーをするチームでした(当時はそれがミッションでした)。

その後、デリバリーチームからプロダクトチームを目指して、みんなでINSPIREDの読書会を通して目線合わせをして、次のフェーズではチーム全員でディスカバリーをしていきました。

https://note.com/takuroenami/n/n648cbb865b8b

そこでディスカバリーのプラクティスを学び、最近ではチーム内で状況に応じて、ディスカバリー側に軸足を置くメンバーとデリバリー側に軸足を置くメンバーがいたり、役割を入れ替えたりしながら、お互い背中を預けながらワンチームでプロダクトづくりをしています。

すべてはプロダクトビジョン・プロダクトゴールを達成するための戦略・戦術

プロダクトディスカバリーは不確実性の高い中で、ソリューション仮説をあの手、この手で検証していくので、とにかく意思決定の回数が多く、俊敏性が重要です。

そのときに、大上段の戦略、プロダクトゴールの認識がチームで揃っていないと軽やかに意思決定ができません。目指す方向性とそこに向かうための意思決定の軸(or 判断基準)がクリアに揃っているほどチームが自律的に判断できるので、プロダクトマネージャーは日々チームと戦略の目線合わせ、そしてその中でどういう戦術をとるのかを議論することが大事です。

atama plusでは2020年12月からOKRを導入し、運用を試行錯誤してきました。目指すゴールを明確にし、戦略についても常に目線合わせをすることで戦術をより柔軟に変えることができます。

プロダクトゴールがなくデュアルトラックアジャイルのプラクティスやプロセスだけはめようとしてもうまくいく可能性は非常に低いです。プロダクトチームとして何を実現したいのかを常に目線合わせをしていくことが最も重要だと思います。

まとめ

今回はデュアルトラックアジャイルを実践する上でのコツを自分なりに整理してみました。

まだまだ言語化しきれておらず、わかりにくい部分も多々あったかと思います。ご質問やフィードバックがありましたらいつでもお待ちしております!

また、atama plusでは各職種仲間を募集しておりますので、ご興味があればぜひお話しましょう!

最後までお読みいただきありがとうございました!

Twitterでの情報発信も始めました!atama plusの開発に関する発信を取りまとめてお届けします。フォローいただけたら幸いです。


よろしければサポートお願いします!活動費に使わせていただきます!