あえて非IT系の大企業でデュアルトラックアジャイルを採用した理由とその現在地
これはプロダクトマネージャー Advent Calendar 2023 13日目の記事です。
私の所属するMutureは2022年4月に丸井グループとGoodpatchが立ち上げたジョイントベンチャーであり、現在は主に丸井グループに対するDX支援として組織デザインから事業支援まで幅広い支援を行っています。
今回は、丸井グループのプロダクトグロース支援プロジェクトを題材に、アジャイル導入をどのように進めていったのかについて紹介をしていきます。
丸井グループについて
丸井グループは基本的に新卒一括採用を中心とする会社であり、そのため社員のほとんどが「総合職」という位置づけとなります。
グループ内には多様な事業ドメインが存在しており、グループ間職種変更という仕組みによって特有のドメインに閉じない横断的な知識を獲得できることを強みとし、独自性のある事業を多数展開しています。
その一方で、ソフトウェアプロダクトに関してはIT企業のような「専門職」は存在せず、大企業的プロセスはそのままに外部開発パートナーを頼りながら開発を行っていくという体制を長らく取ってきました。
しかし、この体制のままではソフトウェアビジネスの競争力を高めることは難しく、多様化するニーズへ適応し続けることを困難にしていました。
このような課題感も踏まえ、Mutureとしてアジャイルなものづくりを実践するためのプロダクトグロース支援を行っていくことになります。
アジャイルなものづくりに向けた体制構築
本プロジェクトにはプロダクトコーチのような形で伴走支援を行っており、先述の課題感も踏まえて以下の観点より体制構築を行っていきました。
1. 部門を横断したストリームアラインドチームの組成
従来の開発体制としては、おおよそ以下のような流れとなっていました。
(これは大企業によくある体制ではないでしょうか?)
大企業における機能別組織をベースとしたウォーターフォール型のプロセスに由来する構造ではありますが、今回目指していくアジャイルな取り組みにおいてこれは適しません。
そのため今回はチームトポロジーの考え方を用いて、あるべきプロジェクト体制について検討を行うところからスタートすることにしました。
ストリームアラインドチームを組成するには、とにもかくにも
「ビジネスドメインや組織の能力に沿った仕事の継続的な流れ」
を作ることが重要となります。
今回は、現在の業務フローに沿う形で部門横断型組織となるようにストリームアラインドチームを組成することにしました。
本来であれば開発機能も内包できているのが理想ではあるのですが、丸井グループ内に開発機能を有していない以上、ここはどうしても外部開発パートナーに頼らざるを得ない領域となります。
故に現実的に同一チーム内に含めることが難しく、これについては外部開発パートナーに開発機能としてのストリームアラインドチームを組成していただき、コラボレーションモードで整理をすることにしました。
ここにMutureによる支援体制も合わせると、チームトポロジー的表現としては以下のようになります。
2.ストリームアラインドチームに不足する専門性の支援
1で構造としては価値の流れに沿う形となりましたが、ストリームアラインドチーム全員が総合職という役割のままではチームに専門性を織り込んでいくことが難しいため、
「プロダクトチーム全体でBTCトライアングルを成立させていく」
という方針を元に、プロダクトチーム内に仮想のスクワッドを形成し、それぞれに求められる専門性をMutureが支援していくことで、ストリームアラインドチームを有効化していくという方向性で整理をしました。
3. デュアルトラックアジャイルの導入
「アジャイル開発」という言葉の弊害として、「開発」という言葉に引っ張られることで開発プロセスのための手法のように誤認し、企画側には関係のないことだと蓋をされることがままあります。
「アジャイル」にしていく対象はそもそもプロダクトでありビジネスですし、「スクラム」についてもこれが持つ理論や価値基準は決して開発だけに閉じるものではありません。
あくまで今回実現したいのは、丸井グループにおけるアジャイルなものづくりの実践であり、このような環境下においても誤認のない明瞭なモデルを示す必要がありました。
踏まえ、今回はアジャイル開発とUXデザインを一体のものとしてモデル化したデュアルトラックアジャイルを採用することにしました。
とはいえウォーターフォールの経験しかない組織に対して導入するにはちょっと複雑すぎるかな…という懸念はありつつも、
Discovery Track: アジャイルな価値探索
Delivery Track: アジャイルなソフトウェア開発
の2つのサイクルを有機的に回していくことがアジャイルなものづくりにおいて重要であり、特に開発機能を持たない丸井グループにおいては、
「アジャイルな価値探索」のスキルを獲得することが重要である
ということを表しやすいモデルであると判断し、導入に踏み切りました。
先程の表現にこれを重ねると以下のようになります。
ここまで整理ができれば、丸井グループとして獲得していくべきケイパビリティについても以下のように具体化することが出来ます。
デュアルトラックアジャイルを進めていく中で見えてきた新たな課題
プロジェクト開始から半年程度経過した現在も変わらずこの体制は維持しており、変更しないことが最善であると今もなお判断しています。
一方で、2つのトラック間のコラボレーションが増えていくにつれて、コラボレーション像への誤認が生じやすい側面があることも分かってきました。
課題1: デュアルトラックアジャイルを "プロセス" と捉えてしまう
デュアルトラックアジャイルは素晴らしい "モデル" であることに間違いはないのですが、これを "プロセス" として捉えてしまうことがあります。
ウォーターフォールという "プロセス" に慣れている状態で、デュアルトラックアジャイルも同様に "プロセス" として捉えてしまうと
Discovery Track: 企画/要件定義 (企画チーム担当)
Delivery Track: 開発/実装 (開発チーム担当)
のように誤った形で重ね合わせをして、これを認識をしてしまいます。
こうなると、本来両輪となるべきところが無自覚的に上流下流へと分断されていってしまいます。
この問題については、どうやら特定の環境に依存した話でもないようで、事実同じような理由によってINSPIREDをV2へ改訂する際に「デュアルトラックアジャイル」という言葉を使うのをやめています。
課題2: 社内外の関係が異なる責任範囲としてトレースされてしまう
社内に開発機能を有していない以上、アジャイル開発以前に「ソフトウェアの実装」という領域について外部から専門性を借りていくことになります。
このような場合において、「社内」と「社外」という極めてわかりやすい区分によって「専門知識」や「責任範囲」も同様に区別ができてしまいます。
作るものが明確であるウォーターフォール型のプロジェクトにおいてこれは問題となりませんが、今回のような継続的な価値探索を目的とする場合においては、異なる「責任範囲」が厄介な遠心力として作用していきます。
一般的に、チームトポロジーにおける「コラボレーションモード」は責任分界点が不明確になりやすいことが弱点であるとされています。
が、今回のように良くも悪くも明瞭な責任分解点を定めやすいことによって、「コラボレーション」そのものを困難にしていきます。
このような遠心力が働く環境下において、「私考える人、あなた作業する人」の関係性を脱することは極めて困難です。
トラック間の分断を生まないようにするために
これらの課題に対し、どのような打ち手を取っていくのがよいでしょうか。
処方箋1: デュアルトラックアジャイルを "プロセス" と捉えてしまう
この課題に対する愚直なアプローチとしては、INSPIRED v2同様この表現を廃止し「Continuous Discovery」を用いるというのが考えられます。
ですが、本プロジェクトにおいてこの方向性は採用しないと思います。
Dual-track agile and continuous discovery: What you need to knowによると、デュアルトラックアジャイルとの差分として以下が挙げられます。
これら全てに賛同するところではあるのですが、
本プロジェクトにおいては、一歩目として「アジャイルな価値探索」のスキルを獲得することをゴールに設定していた
このとき、UXデザイン(Discovery) × アジャイル開発(Delivery)をベースにモデル化されたデュアルトラックアジャイルの方が、習得すべきスキル領域が明確でわかりやすい
Continuous Discoveryに加えられたコンセプトはどれも熟達したプロダクトチームとこれを実行できる環境があって成立するモデルだと考えている
などの観点より、現時点の練度と照らし合わせるとデュアルトラックアジャイルに分があると思っています。
が、モデルはあくまでもモデルでしかないため、あるべきプロセスについて明確化出来ていないという点を課題としたうえで、これについて対話を深めていくことが現実解となるでしょう。
処方箋2: 社内外の関係が異なる責任範囲としてトレースされてしまう
この問題について事前に予見出来ていなかった点に個人的な反省があるのですが、打ち手としては以下の2つを考えています。
1.責任範囲を正しく再設定し目線を合わせる (中長期)
「トラック毎に異なる責任範囲を持つ」という暗黙的な認識が遠心力を生み出す原因となっていましたが、「トラック毎に異なる責任範囲を持つ」というのがそもそもの誤りです。
トラックはあくまで1つのチーム内における仮想の活動を表したものであり、分断のために存在するものではありません。
「トラック問わず全員が1つの共同責任を有するものである」ということを共通認識にしていくことで、無自覚的に生じていた遠心力は引力へと転換していくのではないでしょうか?
2.トラック横断の仮想の組織体を編成する (短期)
1はチーミングの類の話でしたが「プロダクトチームは一日にして成らず」というのもありますので、並行して短期的な手当となりうる構造的なアプローチについても検討をします。
1つのプロダクトチーム内で、トラック毎に2つのチームへ分断をしているという現実に基づくならば、取るべき手段は自ずとトラックを横断した仮想の組織体を編成するという打ち手となります。
この組織体の形としては大きく2つの方向性がありそうです。
1を実行するためには、とにもかくにもプロダクトトリオが必要ですが、
現状のまま実現する場合、3名全員が社外専門人材で構成せざるを得ないが、これはプロジェクトの目的としていた専門性の内部化に反する
仮に社内人材でプロダクトトリオを組成する場合、外部人材がこれを支援するという体制に変えるという方法もなくはないが、プロジェクトの途中でドラスティックに体制を変えるほどのメリットはない
のような背景より、今回は2を採用するのが良いと考えています。
なお、この仮想の組織体はあくまでも両輪が一体となるまでの一時的なものであり、ゆくゆくは発展的解消を前提とするのが良いと思っています。
まとめ
以上が、アジャイルなものづくり推進プロジェクトにおける現在地です。
今回は進行中のプロジェクトを題材としていたため、全体的に抽象的な内容に留まってしまいましたが、具体の取り組みについても少しづつ発信を行っておりますので、併せてぜひご覧ください!
最後に宣伝
来年開催されるリクルート様主催のPdM Daysで登壇をしてきます🎤
タイムテーブルやセッション内容についてはこれからですが、「プロダクトのみならず、組織や人を変えようとするPdM」というテーマに対する話をする予定です。
参加は無料ですので、ぜひぽちっとご参加ください!
おいしいごはんでも食べて次の活力にします!