開発チームを自己組織化するために取り組んだ5つのTRY

開発チームを自己組織化するために取り組んだ5つのTRY

はじめに

こんにちは、ZOZOMO店舗在庫取り置きサービスの開発を担当しているZOZOMO部OMOブロックの木目沢です。

現代のソフトウェア開発において、変化の激しい環境に柔軟に対応できるチーム作りは重要な課題です。特に複数のプロダクトを扱う開発チームでは、メンバー全員が自律的に動き、状況に応じて適切な判断ができる「自己組織化されたチーム」の実現が求められます。

ZOZOMO部OMOブロックでは、ZOZOMO店舗在庫取り置きを取り扱ってきましたが、現在は別のサービスの開発も行っています。そこで2つのプロダクトを扱う開発チームの自己組織化を目指し、昨年度に様々な取り組みを実施しました。結果的に、主要な取り組みは5つに整理されます。

本記事では、これらの取り組みがどのような背景から始まり、具体的にどのような方法で実践され、どのような成果をもたらしたかを詳しく紹介します。同じような課題を抱える開発チームの参考になれば幸いです。

目次

なぜチームの自己組織化を目指したのか

私たちが自己組織化という目標を掲げた背景には、主に以下の理由があります。

複数プロダクトへの対応力強化

まず、OMOブロックは、現在開発中であるサービスとZOZOMO店舗在庫取り置きという2つのプロダクトを扱っています。現状では、この別サービスの開発に注力しており、ZOZOMO店舗在庫取り置きの開発はほぼ停止している状況です。いずれZOZOMO店舗在庫取り置きの開発も再開するため、各プロダクトに専用のチームを設けることが理想的だと認識していますが、当面の間は1つのチームで両方のプロダクトに対応する必要があります。そのため、今後どのような状況でも、チームが柔軟に動けるようにしたいという強い意図がありました。

ボトルネックの解消

次に、これまでの開発体制では、上長による細かい指示で開発を進めることとなっており、そのため、上長自身がボトルネックになる可能性がありました。より迅速かつ効率的に開発を進めるためには、この体制を改善する必要があったのです。

チーム全体の知識レベル向上

そして何より、チームメンバー全員がプロダクトを深く理解し、自ら考えて動けるようになることが不可欠だと考えました。経験の浅いメンバーや育休から復帰したメンバーなどチームには様々な背景をもったメンバーがおり、そのため、個々人の成長とチーム全体での知識共有が強く求められていました。

これらの課題を解決し、どんな変化にも対応できるチームとなるため、私たちは自己組織化という目標を掲げました。

5つのTRYによる具体的な取り組み

自己組織化を実現するために、OMOブロックでは昨年度に様々な取り組みを行いました。振り返ってみると、主要な取り組みは以下の5つに整理されます。

TRY 1: 理想のチームの定義と計測

まず、チーム全員で「理想のチーム」とは何かを定義するワークを開催しました。この定義には、人材開発ブロックのメンバーにファシリテーションの協力を依頼しました。普段ファシリテーションを担当するメンバーも他の参加者と同じ目線で参加し、不要なバイアスがかからないようにするためです。

理想のチームワークショップ

定義するだけでなく、毎週点数をつけてチームの成長を計測しました。これにより、チームの目指す方向性を明確にし、具体的な改善活動(カイゼン)につなげられました。この計測により、自分たちが考えた理想像に向かおうとする姿勢を得点の推移から伺えるようになりました。

理想のチーム計測

TRY 2: 状況に応じた開発プロセスの選択

開発の「HOW(どのように)」を既知のフレームワークやプラクティスを採用することで見える化し、状況に応じた開発プロセスの選択による継続的な改善を図りました。チームは自分たちの状況に合わせて、開発の進め方を柔軟に変えるようになりました。

具体的には、昨年度のZOZOMO店舗在庫取り置き開発期には「スクラム(1週間スプリント)」を採用しました。昨年度上期の別サービスのモック開発期には「スクラム(1日スプリント)」、昨年度下期には「Kanban」、そして現在は「スパイラル型」を採用しています。これは、柔軟な転換の必要性、モック開発の迅速化、時間的制約などの理由によります。

採用プロセス

TRY 3: モブプログラミングとソロプログラミングとNo issue, no work.

単独作業のタスクを除いて、原則としてモブプログラミングで実装を進めました。これにより、チーム全員がプロダクトの仕様を深く理解し、誰でも対応できる状況を作り出すことを目指しました。

モブプログラミングでは、Gatherというツールを使って実施され、ドライバーとナビゲーターの役割を交代しながら作業を進めます。

Gatherでのモブプログラミング

モブプログラミングのチーム内でのルールはチームで議論をした上でチームメンバー全員の合意を取っており、ワーキングアグリーメントという文書にまとめられています。その一部を紹介します。

Gatherでのモブプログラミング

また、すべての作業において"No issue, no work."を徹底し、プログラミングに限らず設計や調査、会議準備なども含めたあらゆる作業を見える化して改善の対象としました。上長の仕事ももちろん"No issue, no work."を徹底しています。これらの取り組みにより、タスクが特定の個人に集中することがなくなり、チーム全体で改善の対象として考えるようになりました。

TRY 4: レトロスペクティブとワーキングアグリーメント

開発プロセスが変化しても、毎週レトロスペクティブ(振り返り)を欠かさず実施しました。レトロスペクティブの結果、カイゼンした習慣をワーキングアグリーメントに文書化しました。また、ワーキングアグリーメント自体もカイゼンの対象とすることで、チーム自らが改善のサイクルを回せるようにしました。

カイゼンサイクル

先程はモブプログラミングのワーキングアグリーメントを紹介しましたが、他にもいくつか紹介します。

以下はレビューに関するワーキングアグリーメントです。

レビューでのワーキングアグリーメント

こちらはチームの活動に関するワーキングアグリーメントです。

その他のワーキングアグリーメント

TRY 5: 仕様の調整から開発チームに任す

これまで上長が細かく指示を出したり外部からの依頼を受けたりするやり方から、開発チームが自ら調整依頼を受けて素早く対応できる方針へと変更しました。

なぜやるのかというところや優先順位を含め、最終的な責任は引き続き上長が持ちます。一方で上長はあれこれ指示をする代わりに開発チームへの支援を強化し、チームの動きを観察したりコーチングを行ったりする役割を担うようになりました。時には改善を提案することもあります。この変化により、外部との調整にかかる時間や伝言ゲームによる伝達ミスが減り、開発チームはプロダクトについてより深く理解するようになりました。

結果、チームは自ら考えて動けるようになるという大きなメリットを得られました。その反面、開発チーム自身が調整業務を担うことで、純粋な開発にかけられる時間が多少減るというデメリットも生じています。しかし現時点では、メリットの方が上回っているためこの取り組みを継続しています。

チームでできることが増えていけばメンバーもさらに輝く

まだまだ途上で今後も多くの挑戦が必要ですが、チームの自己組織化は進み、状況に応じ柔軟にチームで対応できる力が付いてきました。また、これまで紹介してきた内容は、チームが自らでできる幅を広げ(広さ)経験をさらに深める(深さ)施策でした。これらをプロダクト開発のライフサイクルにマッピングさせてみると、ただものを作るだけのチームではなく、プロダクトとして全体を捉えるようになってきていると言えます。

これらのことはさらにチームメンバーがそれぞれやりたいこと・実現したいことの発見に繋がり、自己実現の場としてもチームを捉えることもできそうです。

さらに

自己組織化による新たな課題と今後の展望

自己組織化により多くの成果を得られた一方で、新たな課題も見えてきています。このままさらに開発チームへの権限委譲を進め、チームの活動を広げていくと純粋な開発に集中できる時間の減少という問題を生じる可能性があります。

このジレンマを解決するために、以下のようなアプローチが有効だと考えています。

まず、直近で対応する課題のみを仕様の調整の対象とすることで、調整業務の範囲を限定し開発時間への影響を最小化します。長期的な課題や将来的な要件については詳細な整理や調整を遅らせることで、開発チームが日常的に対処する調整業務から切り離すことができます。

これはスクラムで採用されるプラクティスの一部です。つまり、プロダクトを扱うようになりより複雑化していく状況においては、スクラムの適用が特に有効になっていきます。スプリント単位で開発サイクルを区切り、リファインメントを別途行うこと、直近で対応する課題のみを扱うことで開発に集中できます。

加えて、昨今話題の生成AIエージェントの活用により、効率的にソースコードを書く時間を削減できそうです。さらにテストコード、ドキュメント、バグ修正など開発における幅広い領域での活用が期待できます。これにより、チームとしてよりコアとなる部分に多くの時間を割けるようになります。

スクラムをはじめとしたアジャイルの追求と生成AIエージェントの活用により、チームはさらに自己組織化を進めていくことでプロダクトにコミットできていくと考えています。

おわりに

自己組織化への挑戦は、OMOブロックに大きな変化と成長をもたらしました。チームメンバー全員がプロダクトの理解を深め、自律的に動くことで、変化の激しいプロダクト開発に柔軟に対応するようになっています。私たちはこれからも、変化に対応できる強くしなやかなチームを目指して、挑戦を続けていきます。

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com

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

カテゴリー