2年間の組織伴走を振り返る
この記事は、丸井グループ・marui unite ・Mutureの有志メンバーによるアドベントカレンダー13日目の記事になります。
Mutureでは、DXを通じて丸井グループのインパクト最大化を実現していくために、現場のチームに根ざしながら、会社の構造（システム）の変革と、その変革を体現していく現場プロダクトチームの開発支援をしています。
私は2年前より一つのプロダクトチームに対する伴走支援を行なってきました。今回は2年間でどのような変化が生まれたのか？を振り返りたいと思います。
2年間での変化：チームとビジネス
22年8月より組織伴走を開始しました。
それから2年の間に、アジャイル開発を目指し、システムの一部見直しを行ったり、プロダクト開発のプロセスを段階的に変更していったり、（時にPdMが変更する事態が起こりつつも）、一度獲得したプロセスを準えることに満足せず改めてユーザーとビジネスに向き合おう、という変遷を辿ってきました。
2年を経て、チームが変化したポイントは下記の3点になります。
①当初はリリース後にプロダクトの継続的な改善の流れを作り出せず、毎回試行錯誤しながら課題に取り組んでいました。今はスクラム開発の手法を取り入れ、スプリントを軸に仮説検証を進められるようになりました。
②当初は企画として何をやりたいかを検討した後は、制作会社にデザイン・実装を丸っとお願いする形でした。今は自分たちがやりたいことの言語化〜ワイヤフレーム作成までを一気通貫してできるようになり、デザイナー・エンジニアと連携しながらプロダクト開発を進められるようになりました。
③当初は上位職者のフィードバックがあればそれを優先して実現する流れでした。今は現場プロダクトチームへの権限委譲が進み、「ビジョンとユーザーとビジネス」の観点から優先順位を判断するPdMがいる組織になりました。
チームがアジャイル化していくことで、学習を重ねながらリリースを繰り返せるようになり、成果であるプロダクト指標の成長に繋げることができています。
2年間と決して短くない期間でしたが、この過程でどのような取り組みを行なったのかをこの機会に振り返りたいと思います。
チームの変化の目標：自己組織化
そもそもですが、プロダクトチームに伴走する際の目標に「自己組織化」を掲げていました。
自己組織化とは、『正しいものを正しく作る』には下記の定義があります。
ミッションの実現に向かうための選択を自分たちで決定し、行動できる度合い。
それをプロダクトチーム内では次のように表現をしました。[プロダクトの成長のための継続的な仮説検証を当事者意識を持ってチームで主導できる組織]。
チーム伴走を始めるに際し、「チームはどう変わりたいか？」の方向性をチームリーダーと対話し、課題感やありたい姿のイメージを揃えました。そこで、Before/Afterをわかりやすく受け取れるような言葉を入れて、自分ごとになりやすいようにしています（例えば、「継続的な」・「主導できる」はチームリーダーとの対話から見えた表現だったりします）。
そして、自己組織化を目指す上で重要な要素を「選択の自己決定」・「探索と適応」・「機能横断的」の３テーマに据え、段階的に組織変革をサポートしていきました。
ひとつのテーマごとに主だった取り組みを紹介していきます。
選択の自己決定
一つ目のテーマは、「選択の自己決定」です。
誰かが唯一の正解を持っているならばその正解に従う。このスタイルでももしかしたら良いのかもしれません。しかし、自分たちが相対する市場・ユーザーにおいてはなかなかそのような状況は少ないのではと思います。
正解がわからないので、素早く学習を重ねて、勝ち筋を見極めていく。この速度を早める上でも、自分たちで自己決定することで、「納得感」を持ち・「ゴールイメージ」を揃えることが不可欠です。
ちなみに、『正しいものを正しく作る』では、アジャイル開発を下記のように記載しています。
確実性を上げるアプローチが通じない、不確実性が荒ぶるプロダクトづくりで求められるのは、「誰も正解がわからないのであたりをつけながら、間違う前提を念頭におきつつ、関係者の間で合意形成をしながら進める」というやり方だ
しかし、エンタープライズ企業においては、自己決定が想像以上に難しいこともあるかもしれません。決裁者の階層が多段的になり、マネジメントのポジションと言っても予算もほぼない状況下も珍しいことではないように思います（個人的には）。
そのため、「わからないから小さくトライをしてみたい、、。」という選択肢がそもそも頭に浮かびづらい。まずは、上位職者の決裁をもらうための資料を作り出し、FBコメントを細かく反映させていくと、いつの間にか「WHY」の部分がぶれていき、仮に実施できたとしてもその学びがクリティカルでなくなることもあるかもしれません。
そのような環境下で、最もユーザーと市場に近い現場のプロダクトチームが自己決定をしていけるように行ったことは下記の３点になります。
健康診断
まずは、チーム自身が「いま自分たちが置かれている状況をできる限り正しく把握できるようになる」こと。この習慣作りから取り組みました。
そこで、ビジネスとプロダクトを繋げるためにKPIツリーを共に整理し、ウィークリーで観測する指標を決めました。
今は、リファインメント時に「健康診断」として重要指標の傾向を踏まえ、今スプリントで取り扱うべきかの優先度（緊急度）をチームで判断するようにしています。
リファインメント
次に、リファインメントの習慣化です。リファインメントを通じて、本スプリントで実現したいゴール（現状の課題と優先度付け）を明確にし、ゴールを実現するためのプロダクトバックログを実行可能な状態にしています。
そもそもリファインメントについては、CSM研修で次のように教わりました。
リファインメントの目的は、プロダクトバックログアイテムを詳細に検討し、それらを次のスプリントで取り組むのに十分に明確かつ実行可能な状態にすること
「実行可能な状態にする」ためにも、「何を・なぜ」取り組む必要があるのか？の背景をプロダクトチーム全員が理解する必要があります。そこで、リファインメントが正しく機能するためにアジェンダを定期的にメンテナンスするようにしてきました。
実際に、当初始めた時と直近のアジェンダの違いです。
リファインメントを通じて、プロダクトチームの目線を合わせ、スプリントでのアウトカムを最大化するためにも、前提となるロードマップの確認及び課題分析をまず行うようにしています。リファインメントのステップを細分化することで、リファインメントが終わった後に各ステークホルダーへの説明をチーム全員ができるような状態になることを目指しています。
ロードマップ
最後に、ロードマップの作成です。これが上位職者と現場のチームをつなぐ架け橋として機能します。
事業として達成したい数値目標とそのためにプロダクトを通じてユーザーにどのような価値を提供するか？そのためにどのような機能が必要となってくるのか？
ロードマップ作成を通じて、大きな方針感や課題感を上位職者と認識を共にすることで、現場のチームの取り組みに対する透明性と信頼を育むことで、権限委譲を行いやすくなっています。
とはいえ、ロードマップ作りは、ビジネス視点とユーザー視点、かつ抽象と具体を行き来しながら計画に落としていく、難易度の高い取り組みです。
こちらは、グッドパッチさんがわかりやすくステップ化してくれています。
半期ごとにビジネス×ユーザー軸でこれまでの施策内容を振り返り、これからの取り組みがプロダクトビジョンの実現と事業数値に貢献するための取り組みとなるように、ロードマップを通じて上位職者・関係者・チーム内での対話を深めています。
ロードマップ、作って終わり？
しかし、ロードマップを「作って終わり」という状況も起きました。プロダクトやプロダクトチームを取り巻く状況が変わった際に、期初に考えていたテーマ感や優先度の意味が薄れてしまったこと。その際に、ロードマップを作る「重さ」を踏まえると、作り直すという判断をチームとしてもしづらかったことが原因の一つと捉えています。
ただ、本来は『プロダクトレッドオーガニゼーション』に記載があるように、ロードマップは「 リビングドキュメント」であり、学習した内容に応じて更新を図るべきです。
プロダクト主導型組織は変化に応じてロードマップを書き換える
そこで、直近ではロードマップを作るためのステップを見直し、決めるまでにダラダラとやらず、まず決めることを重視し、進め方の「軽量化」に取り組んでみました。
本noteではステップの具体には触れませんが、最終アウトプットは下記のようなものとなりました（上と比べるとだいぶシンプルになりました）。
では、課題となっていた「作って終わり」を脱することはできたのか？
直近では、期中にユーザーインタビューの内容を踏まえた「向き直り」を実施でき、プロダクトチームが目指すものの解像度を上げるための取り組みを実施できました。
また、向き直りを通じた上位職者との定期的な目線合わせも重要です。チームが学んだこと・これから何を目指すために何を変えるのか？をロードマップを作った後も調整することで、上位職者にとっては信頼、そしてプロダクトチームにとっては自信を持って、その後の仮説検証に取り組めることができることを期待しています。
探索と適応
二つ目のテーマは、「探索と適応」です。
『組織を芯からアジャイルにする』では、「探索と適応」こそがアジャイルの本質であると記載がありました。
アジャイルの本質には、「探索」と「適応」がある、
わからないこと、わかっていない状況から、目を逸らすことなく、
わからないからこそ少しずつ「探索」的に仕事を進める。
そうした実践によって得られる学びでもって、
その後の判断や行動を変えていくようにする（＝「適応」）。
「運営」として上から与えられたお題をこなすのではなく、自ら思考し壁を越えるために行動をし続ける「探索と適応」モードへ組織を変革していくために、主に取り組んだことは下記の３つです。
ユーザーリサーチ
まずは、ユーザーを知りにいくということ。
実は、顧客に向き合うために、インタビューをする・声を聴き商品／サービスに反映する。こういった文化自体はそもそも丸井グループには深く根付いているものでした。
この文化をデジタルプロダクト上における継続的な改善プロセスとして再適応させる。「顧客との対話の文化のDX」として、UXリサーチャーがリサーチの設計〜実査〜分析の過程に伴走することで、Mutureが去ってもプロダクトチームがユーザーを知りにいくためのアクションを継続的に行えるように支援を行いました。
「対話の文化のDX」について記載したMuture CPOの兼原の登壇レポートが下記になります。
少なくとも半期に一度はユーザーリサーチを行い、その結果を再利用しやすいようにドキュメント化することで、プロダクトチーム内のユーザーに対する共通理解を蓄積しています。
検証キャンバス
また、毎回のスプリントの取組みがどのような仮説のもと実行され、結果どうだったのか？これらが振り返ることができる形になっていることも学習を活かすために不可欠です。
そこで、検証キャンバスを用いて、施策の狙いや振り返りもドキュメント化するようにしています。
検証キャンバスによって、チーム内だけではなく、他担当のチームとの連携も促進されることも観測しました。（これはまた別のメンバーからのnoteで紹介予定）。
学習した内容を振り返りやすい形にすることで、学習内容をもとに向き直りをするためのチームの共通認識が蓄積されていきます。そして、最後は向き直りの実施です。
向き直り
『アジャイルなプロダクト作り』では、向き直りを下記のように表現しています。
また、向き直りのステップは、下記の３ステップと紹介をされています。
今ではプロダクトチームのメンバーから「向き直りをしないといけないのでは？」と自然と声が上がるようになっています。
その背景には失敗の経験があります。ある連続したテーマに基づいたリリース計画があったのですが、途中でなかなか成果に繋がらない状況になりつつも、「続けるか否か」の判断が遅れてしまい、チームとしても貴重なリソースを有効活用できず、かつ良い学習機会にならなかったことがありました。
その経験を糧にすることで、今は「向き直り」を意識し、定期的に実施ができるチームになりました。各スプリントでの施策からわかったこと、そして定期的に取り組むユーザーリサーチの結果。定量と定性での学びをベースに、向き直りを１〜２ヶ月に一度行うことでより成果に向き合えるプロダクトチームになったと感じています。
機能横断的
最後のテーマは、「機能横断的」組織作りです。
『スクラムブートキャンプ』では機能横断的について下記のような記載がありました。
開発チームは、プロダクトを作るために必要なすべての作業ができなければなりません。例えば、要求の分析をする、設計する、コーディングする、サーバを構築する、テストをする、ドキュメントを書くといった能力が開発チームの中に必要です。これを機能横断的なチームと呼びます。
「プロダクトの改善を主導したい！」この想いを持ったプロダクトチームが、企画〜実装までの一連のプロセスをチーム内でなるべく完結できるように環境整備やコミュニケーション手段の獲得をサポートしていきました。
主に行ったサポートは下記の取り組みになります。
これら取り組みについては、プロダクトチーム側の声を下記リンクで紹介をしていますので、ぜひこちらをご覧ください！
チームの変化は最大のインパクトになったか？見えてきた、縦の壁の高さ
こういったテーマに基づく取り組むを続け、自己組織化を目指してきました。その結果は2年で冒頭に記載したような変化が生まれています。
ビジネスの成果としても拡大しており、一見「うまくいった・成功した」、とみなしても良いのかもしれません。しかし、私は大きな壁を感じています。それは、ボトムアップ的にチーム変革を始めたからこそ見えてきた「縦の壁」です。
変化したチームの取り組みがインパクトの最大化につながるには何が必要か？
それは、チームに閉じない、課＜事業部＜事業会社＜グループ会社との重なりです。
その重なりをチームの変化と共に濃くしていけなければ、何が起きるのか？
プロダクトチームが変化しても、、、最終目標は同じでもその時々の優先度の判断軸や背景の共通理解が醸成できていないままでは、連携を密に取りたくとも担当間のコミュニケーションコストが肥大化し全員で最大の成果を目指す歩みが重たくなる
プロダクトチームが変化しても、、、事業戦略上の位置付けが不明瞭のままでは、本来は不得意な範囲の期待も降ってきてしまい、プロダクトと事業の重なる最大の成果がぶれていく
プロダクトチームが変化しても、、、会社が大きく目指す方針との重なりが曖昧なままでは、プロダクトへの投資の意義性が薄れ人員の配置や開発予算を調達が難しくなる
では、どうしたら「縦の壁」を越えられるのか？Muture内では、システムの再構築をリードするシステムパートナーとしてその役割を定義しています。
そして、システムにアプローチした変革の事例として今年10月にマルイユナイトという新会社の設立に至りました。
実現したいことは、「内から」の組織の変革。それによりMutureが卒業しても、自ら進化し続けられる強い組織をつくること。そのためにMutureは、その企業が持つ歴史・価値観・強みを最大限に理解・尊重し、経営・事業・プロダクトといった様々なレイヤーや、ユーザー視点・ビジネス視点と縦横無尽に動き回り、その接続性を再翻訳していくお手伝いをしている、と感じています。
ボトムアップからのプロダクトチームの変革は一定の手応えを感じつつも、まだまだ道半ばです。
不安・戸惑い・プレッシャー・混乱と様々な負を感じつつも、前を向きプロダクトの成長に取り組み続けたプロダクトチームのメンバーに最大限の尊敬と感謝を持ちつつ、見えてきた「縦の壁」に対して私自身もシステムとチームの両面での組織変革のアプローチやプロセスを実践を通して研究し続けます。
ここまで読んでいただきありがとうございました。