あえて非IT系の大企業でデュアルトラックアジャイルを採用した理由とその現在地
これはプロダクトマネージャー Advent Calendar 2023 13日目の記事です。
私の所属するMutureは2022年4月に丸井グループとGoodpatchが立ち上げたジョイントベンチャーであり、現在は主に丸井グループに対するDX支援として組織デザインから事業支援まで幅広い支援を行っています。
今回は、丸井グループのプロダクトグロース支援プロジェクトを題材に、アジャイル導入をどのように進めていったのかについて紹介をしていきます。
丸井グループについて
丸井グループは基本的に新卒一括採用を中心とする会社であり、そのため社員のほとんどが「総合職」という位置づけとなります。
グループ内には多様な事業ドメインが存在しており、グループ間職種変更という仕組みによって特有のドメインに閉じない横断的な知識を獲得できることを強みとし、独自性のある事業を多数展開しています。
その一方で、ソフトウェアプロダクトに関してはIT企業のような「専門職」は存在せず、大企業的プロセスはそのままに外部開発パートナーを頼りながら開発を行っていくという体制を長らく取ってきました。
しかし、この体制のままではソフトウェアビジネスの競争力を高めることは難しく、多様化するニーズへ適応し続けることを困難にしていました。
このような課題感も踏まえ、Mutureとしてアジャイルなものづくりを実践するためのプロダクトグロース支援を行っていくことになります。
アジャイルなものづくりに向けた体制構築
本プロジェクトにはプロダクトコーチのような形で伴走支援を行っており、先述の課題感も踏まえて以下の観点より体制構築を行っていきました。
1. 部門を横断したストリームアラインドチームの組成
2. ストリームアラインドチームに不足する専門性の支援
3. デュアルトラックアジャイルの導入
1. 部門を横断したストリームアラインドチームの組成
従来の開発体制としては、おおよそ以下のような流れとなっていました。
(これは大企業によくある体制ではないでしょうか？)
大企業における機能別組織をベースとしたウォーターフォール型のプロセスに由来する構造ではありますが、今回目指していくアジャイルな取り組みにおいてこれは適しません。
そのため今回はチームトポロジーの考え方を用いて、あるべきプロジェクト体制について検討を行うところからスタートすることにしました。
ストリームアラインドチームを組成するには、とにもかくにも
「ビジネスドメインや組織の能力に沿った仕事の継続的な流れ」
を作ることが重要となります。
ストリームアラインドチームとは、ひとつのビジネス機能のソフトウェアを担当するビジネス機能中心のチームです。 チームの寿命は長く、自分たちはビジネス機能を強化するソフトウェアプロダクトを提供すると考えています。
各ストリームアラインドチームは、フルスタックであり、フルライフサイクル（フロントエンド、バックエンド、データベース、ビジネス分析、機能の優先順位付け、UX、テスト、デプロイ、モニタリングといった、ソフトウェア開発全般）を担当します。 ストリームアラインドチームはアウトカム指向であり、 アクティビティ指向のチームのようにビジネス分析、テスト、データベースなどの機能にフォーカスするのではなく、ビジネスの結果にフォーカスします。
今回は、現在の業務フローに沿う形で部門横断型組織となるようにストリームアラインドチームを組成することにしました。
本来であれば開発機能も内包できているのが理想ではあるのですが、丸井グループ内に開発機能を有していない以上、ここはどうしても外部開発パートナーに頼らざるを得ない領域となります。
故に現実的に同一チーム内に含めることが難しく、これについては外部開発パートナーに開発機能としてのストリームアラインドチームを組成していただき、コラボレーションモードで整理をすることにしました。
💡 後ほど触れますが、会社を横断した「コラボレーションモード」という関係性の難しさが後々浮き彫りとなっていきます。
ここにMutureによる支援体制も合わせると、チームトポロジー的表現としては以下のようになります。
2.ストリームアラインドチームに不足する専門性の支援
1で構造としては価値の流れに沿う形となりましたが、ストリームアラインドチーム全員が総合職という役割のままではチームに専門性を織り込んでいくことが難しいため、
「プロダクトチーム全体でBTCトライアングルを成立させていく」
という方針を元に、プロダクトチーム内に仮想のスクワッドを形成し、それぞれに求められる専門性をMutureが支援していくことで、ストリームアラインドチームを有効化していくという方向性で整理をしました。
3. デュアルトラックアジャイルの導入
「アジャイル開発」という言葉の弊害として、「開発」という言葉に引っ張られることで開発プロセスのための手法のように誤認し、企画側には関係のないことだと蓋をされることがままあります。
「アジャイル」にしていく対象はそもそもプロダクトでありビジネスですし、「スクラム」についてもこれが持つ理論や価値基準は決して開発だけに閉じるものではありません。
あくまで今回実現したいのは、丸井グループにおけるアジャイルなものづくりの実践であり、このような環境下においても誤認のない明瞭なモデルを示す必要がありました。
踏まえ、今回はアジャイル開発とUXデザインを一体のものとしてモデル化したデュアルトラックアジャイルを採用することにしました。
とはいえウォーターフォールの経験しかない組織に対して導入するにはちょっと複雑すぎるかな…という懸念はありつつも、
Discovery Track: アジャイルな価値探索
Delivery Track: アジャイルなソフトウェア開発
の2つのサイクルを有機的に回していくことがアジャイルなものづくりにおいて重要であり、特に開発機能を持たない丸井グループにおいては、
「アジャイルな価値探索」のスキルを獲得することが重要である
ということを表しやすいモデルであると判断し、導入に踏み切りました。
先程の表現にこれを重ねると以下のようになります。
ここまで整理ができれば、丸井グループとして獲得していくべきケイパビリティについても以下のように具体化することが出来ます。
■ 丸井グループのメンバーはDiscovery Trackに属する
→「アジャイルな価値探索」のために求められるスキルについて内製化していく必要がある。
(e.g. Lean UX, DDDM, Product Roadmap)
■ Delivery Trackとは "Collaboration" の関係性にある
→ Delivery Trackとのコラボレーションを円滑なものとしていくためのスキルを獲得していく必要がある。
(e.g. Scrumの知識, POの明確化, 開発会社との共創関係構築)
デュアルトラックアジャイルを進めていく中で見えてきた新たな課題
プロジェクト開始から半年程度経過した現在も変わらずこの体制は維持しており、変更しないことが最善であると今もなお判断しています。
一方で、2つのトラック間のコラボレーションが増えていくにつれて、コラボレーション像への誤認が生じやすい側面があることも分かってきました。
課題1: デュアルトラックアジャイルを "プロセス" と捉えてしまう
デュアルトラックアジャイルは素晴らしい "モデル" であることに間違いはないのですが、これを "プロセス" として捉えてしまうことがあります。
ウォーターフォールという "プロセス" に慣れている状態で、デュアルトラックアジャイルも同様に "プロセス" として捉えてしまうと
Discovery Track: 企画/要件定義 (企画チーム担当)
Delivery Track: 開発/実装 (開発チーム担当)
のように誤った形で重ね合わせをして、これを認識をしてしまいます。
こうなると、本来両輪となるべきところが無自覚的に上流下流へと分断されていってしまいます。
この問題については、どうやら特定の環境に依存した話でもないようで、事実同じような理由によってINSPIREDをV2へ改訂する際に「デュアルトラックアジャイル」という言葉を使うのをやめています。
UPDATE: Starting with the publication of INSPIRED V2, I stopped using the term “Dual-track Agile” because the phrase made people focus far too much on process, and not enough on the principles. I wrote why this is the case here. So instead I started using the terms Continuous Discovery and Continuous Delivery.
---
(以下DeepL訳)
---
UPDATE：「INSPIRED V2」を出版したときから、私は「デュアルトラックアジャイル」という言葉を使うのをやめた。その理由はここに書いた。その代わりに、私はContinuous Discovery（継続的発見）とContinuous Delivery（継続的デリバリー）という言葉を使い始めた。
Moreover, it’s important to realize that it’s not about process. It’s much more about putting in place the necessary culture, and training your team on the critical techniques.
In his recent (must read) shareholder update, Jeff Bezos spoke to some of these same issues: “Good process serves you so you can serve customers. But if you’re not watchful, the process can become the thing. This can happen very easily in large organizations. The process becomes the proxy for the result you want. You stop looking at outcomes and just make sure you’re doing the process right.”
As long as you’re tackling the risks up front; truly collaborating with engineering and design on coming up with good solutions; and making sure you are solving the underlying business and customer problem, and not just shipping features, then you’re focused on what you need to be doing.
---
(以下DeepL訳)
---
さらに、重要なのはプロセスではないということだ。 それよりも、必要な文化を整え、重要なテクニックをチームにトレーニングすることの方がずっと重要なのだ。
ジェフ・ベゾスは最近の（必読の）株主アップデートで、これらと同じ問題のいくつかを語っている： 「良いプロセスがあれば、顧客にサービスを提供できる。しかし、注意深くなければ、プロセスが物になってしまう。これは大きな組織では非常に起こりやすい。プロセスが、あなたが望む結果の代理になってしまうのです。結果を見るのをやめて、ただプロセスを正しく行っているかどうかだけを確認するようになる」。
前もってリスクに取り組み、エンジニアリングやデザインと真に協力して良い解決策を考え、単に機能を出荷するだけでなく、根本的なビジネスや顧客の問題を解決していることを確認している限り、あなたはやるべきことに集中している。
課題2: 社内外の関係が異なる責任範囲としてトレースされてしまう
社内に開発機能を有していない以上、アジャイル開発以前に「ソフトウェアの実装」という領域について外部から専門性を借りていくことになります。
このような場合において、「社内」と「社外」という極めてわかりやすい区分によって「専門知識」や「責任範囲」も同様に区別ができてしまいます。
作るものが明確であるウォーターフォール型のプロジェクトにおいてこれは問題となりませんが、今回のような継続的な価値探索を目的とする場合においては、異なる「責任範囲」が厄介な遠心力として作用していきます。
一般的に、チームトポロジーにおける「コラボレーションモード」は責任分界点が不明確になりやすいことが弱点であるとされています。
が、今回のように良くも悪くも明瞭な責任分解点を定めやすいことによって、「コラボレーション」そのものを困難にしていきます。
このような遠心力が働く環境下において、「私考える人、あなた作業する人」の関係性を脱することは極めて困難です。
トラック間の分断を生まないようにするために
これらの課題に対し、どのような打ち手を取っていくのがよいでしょうか。
以降の内容は、いずれもプランニングのステータスであり、まだ評価には至っていないのですが、せっかくですので現時点のスナップショットとしての考えを記していくことにします。
処方箋1: デュアルトラックアジャイルを "プロセス" と捉えてしまう
この課題に対する愚直なアプローチとしては、INSPIRED v2同様この表現を廃止し「Continuous Discovery」を用いるというのが考えられます。
ですが、本プロジェクトにおいてこの方向性は採用しないと思います。
Dual-track agile and continuous discovery: What you need to knowによると、デュアルトラックアジャイルとの差分として以下が挙げられます。
・より顧客中心のアプローチを重視
・DiscoveryとDeliveryは不可分であることを強調
・プロダクトトリオという概念の追加
これら全てに賛同するところではあるのですが、
本プロジェクトにおいては、一歩目として「アジャイルな価値探索」のスキルを獲得することをゴールに設定していた
このとき、UXデザイン(Discovery) × アジャイル開発(Delivery)をベースにモデル化されたデュアルトラックアジャイルの方が、習得すべきスキル領域が明確でわかりやすい
Continuous Discoveryに加えられたコンセプトはどれも熟達したプロダクトチームとこれを実行できる環境があって成立するモデルだと考えている
などの観点より、現時点の練度と照らし合わせるとデュアルトラックアジャイルに分があると思っています。
が、モデルはあくまでもモデルでしかないため、あるべきプロセスについて明確化出来ていないという点を課題としたうえで、これについて対話を深めていくことが現実解となるでしょう。
たとえば…
・要求ツリーの上位から下位までの関係性を可視化
・要求の粒度についてチーム内で共通認識を形成
・バックログ上の表現方法やタスクマネジメントについてのルール化
・スクラムイベントと照らし合せた一連のプロセスについての可視化
処方箋2: 社内外の関係が異なる責任範囲としてトレースされてしまう
この問題について事前に予見出来ていなかった点に個人的な反省があるのですが、打ち手としては以下の2つを考えています。
1. 責任範囲を正しく再設定し目線を合わせる (中長期)
2. トラック横断の仮想の組織体を編成する (短期)
1.責任範囲を正しく再設定し目線を合わせる (中長期)
「トラック毎に異なる責任範囲を持つ」という暗黙的な認識が遠心力を生み出す原因となっていましたが、「トラック毎に異なる責任範囲を持つ」というのがそもそもの誤りです。
トラックはあくまで1つのチーム内における仮想の活動を表したものであり、分断のために存在するものではありません。
「トラック問わず全員が1つの共同責任を有するものである」ということを共通認識にしていくことで、無自覚的に生じていた遠心力は引力へと転換していくのではないでしょうか？
たとえば…
・トラック横断した全体で認識を合わせるワークショップの実施
・共通の責任範囲に対し、それぞれの立場からどのようなことができるのか。またありたいコラボレーション像について対話を深める。
・スクラムイベントの出席者の変更や、コミュニケーションパスの見直し
・インセプションデッキのアップデート
2.トラック横断の仮想の組織体を編成する (短期)
1はチーミングの類の話でしたが「プロダクトチームは一日にして成らず」というのもありますので、並行して短期的な手当となりうる構造的なアプローチについても検討をします。
1つのプロダクトチーム内で、トラック毎に2つのチームへ分断をしているという現実に基づくならば、取るべき手段は自ずとトラックを横断した仮想の組織体を編成するという打ち手となります。
この組織体の形としては大きく2つの方向性がありそうです。
1. 価値探索を両輪で推進していくコアとして、プロダクトトリオを組成する
(≒ Continuous Discovery体制へのシフト)
※ プロダクトトリオ = プロダクトマネージャー + デザイナー + エンジニア
2. 共通の責任範囲に対し、両トラック間の動きをアラインメントさせていく役割としてPO, SMでこの組織体を形成する
1を実行するためには、とにもかくにもプロダクトトリオが必要ですが、
現状のまま実現する場合、3名全員が社外専門人材で構成せざるを得ないが、これはプロジェクトの目的としていた専門性の内部化に反する
仮に社内人材でプロダクトトリオを組成する場合、外部人材がこれを支援するという体制に変えるという方法もなくはないが、プロジェクトの途中でドラスティックに体制を変えるほどのメリットはない
のような背景より、今回は2を採用するのが良いと考えています。
なお、この仮想の組織体はあくまでも両輪が一体となるまでの一時的なものであり、ゆくゆくは発展的解消を前提とするのが良いと思っています。
まとめ
以上が、アジャイルなものづくり推進プロジェクトにおける現在地です。
今回は進行中のプロジェクトを題材としていたため、全体的に抽象的な内容に留まってしまいましたが、具体の取り組みについても少しづつ発信を行っておりますので、併せてぜひご覧ください！
最後に宣伝
来年開催されるリクルート様主催のPdM Daysで登壇をしてきます🎤
タイムテーブルやセッション内容についてはこれからですが、「プロダクトのみならず、組織や人を変えようとするPdM」というテーマに対する話をする予定です。
参加は無料ですので、ぜひぽちっとご参加ください！
おいしいごはんでも食べて次の活力にします！