こんにちは、エンジニアのちぎらです。先日 開発組織にはじめてのスクラムを導入する という記事を公開しました。先日の記事にも課題として記述した通り、組織の一つのチームにスクラムを導入した後は、他のチームにどのようにスクラムを展開していくか、全社的な開発体制をどうやって変えていくかということを考えていく必要があります。
ミラティブでは、その後の半年弱の期間で3つの開発チーム全てにスクラムを導入しました。さらに、LeSS Huge を参考にした開発体制を敷くことで、チーム横断の開発施策の把握や、全社的な開発施策の透明化を推進しています。
スクラムを他チームに展開する
先日の記事を書いた時点では、ひとつの開発チームにスクラムを導入したのみでした。いずれかのチームでスクラムの導入経験があれば、他のチームへのスクラムの展開は比較的簡単です。一方でチームへのスクラム導入のタイミングは重要で、メンバーの混乱を招くので、大きな施策開発の途中などは開発体制の変更は避けるべきです。当時は比較的大きな施策開発も走っていましたから、その期間は体制変更のためにチームのバックログを整備する時間に充てていました。スクラムの導入を進めるのは一度に1チームまでとし、計約5ヶ月の期間で他の2つのチームにもスクラムの導入を完了しました。
各チームにスクラムを導入した後は、チーム同士のコミュニケーションの経路について、また、スクラムのスケーリングについて考える必要があります。ミラティブではひとつのプロダクトに複数の開発チームが関わっている構成ですから、他のチームがなにをしているか見えない状態が続くと、プロダクトの開発に混乱が生じることは容易に想像できます。
スクラムのスケーリングフレームワークにはバリエーションがあり、開発組織にあったフレームワークを選ぶ必要があります。
スクラムのスケーリングフレームワークの比較
比較対象として、Scrum of Scrums, LeSS, LeSS Huge を考えました。他のフレームワーク（Scrum@Scale や SAFe など）も一応検討はしましたが、仕組みが複雑でエンジニア以外の組織へのコストが大きくかかるものは現時点では導入が難しく、早い段階で対象外としました。結果的には、ミラティブでは LeSS Huge を参考にした体制を選びました。ここではその経緯について書いていきます。
Scrum of Scrums
Scrum of Scrums では各チームの代表者からなる会議体を設置し、チーム間のコミュニケーションを図ります。
Scrum of Scrums は開発チームの代表者を集めれば開催でき、導入は比較的簡単です。複数開発チームで連携しながら開発を進める必要がある場合などは話すべきテーマが明確だろうと思います。一方で各チームが独立して開発を進めているような場合では、有意義な会議体を維持するのは難しいだろうという見立てをつくりました。*1
ミラティブの開発組織においては、スケーリングによって開発チームが関与する領域を大きくしていく、具体的には、プロダクト全体に係る戦略的な意思決定にアプローチできる経路を作る、開発の内容について全社的な透明性を推進していきたいという思いがありました。
LeSS
LeSS はプロダクト全体のバックログが1つと、1人のプロダクトオーナーが存在し、複数の開発チームがバックログアイテムを消化していきます。
ミラティブではそれぞれの開発チームは異なる領域の開発を担当しており、各開発チームが運用しているバックログには、チーム外部からくる運用タスクも管理されています。運用タスクは少なくはなく、新規の施策と優先度を比較して、開発チームにいる各 PM が最終判断をして開発を進めていました。
LeSS においては全体のバックログを管理する PO が1人だけ存在します。その構成にするのであれば最終判断は PO がすべきですし、バックログも1つにまとめられているべきです。各チームが持っているバックログは一定の複雑さがあり、各領域における判断は開発チームの PM がしていたので、LeSS が求める体制とミラティブの現状の開発体制には組織的な乖離があり、LeSS に向かうと長期的な混乱が生じるだろうという懸念がありました。
LeSS Huge
LeSS Huge はエリアプロダクトオーナー(APO)とエリアプロダクトバックログ(APB)という概念を含んでおり、プロダクト全体を把握するプロダクトオーナー(PO)と複数の事業ドメインに対応するバックログがある構成になっています。
LeSS Huge は一般的には 8~10 チーム以上から適用されるという話があります。一方で、LeSS と LeSS Huge にはエリアプロダクトオーナー(APO)やエリアプロダクトバックログ(APB)など構造上の大きな違いがあり、チーム数だけを基準にして LeSS から LeSS Huge に移行できるとは思えません。
ミラティブの開発体制では、それぞれのチームのバックログはプロダクトの異なる領域を扱っていましたし、各開発チームの PM は裁量を持って動いていました。つまり、チーム数は8~10 に満たないものの、構造的には LeSS Huge にかなり近いものがあり、従って LeSS Huge を参考にした開発体制が作れるのではないかと考えました。
LeSS Huge（もしくは LeSS）ではスプリント計画はパート1とパート2に分かれていて、パート2は開発チームごとに、パート1はチーム横断で話します。パート1の会議体にはプロダクト全体の判断をする PO も出席するので、各開発チームの代表者はより上流における施策の状況が把握できるようになります。また、チーム横断の施策を集約する場ができることで、その情報を全社的に共有しやすくなります。
実際ミラティブでは、開発を進めることが確定した施策について、施策に関する情報が半自動で全社の Slack チャンネルに流れ、開発チーム以外の人も含めて、どのような施策が開発予定なのかをキャッチアップできるようになっています。
スプリント内のミーティングの変化
ミラティブではスプリント計画のパート1に相当するミーティングを「事前プランニング」と呼んでいて、開発の着手前に、施策の優先度や開発上の懸念について話す場を設けています。元々 PM が実施予定の施策について話しているミーティングが週に2回あり、その頻度に合わせて週2回の事前プランニングを実施しています。
事前プランニングには、プロダクトオーナー、各開発チームの PM と代表のエンジニアが出席しています。時間は30分確保しているものの、事前プランニングでは大まかな共通認識を持つことと懸念を洗い出すことが目的で、施策の細かい仕様について話す想定はないので、15分程度で切り上げるくらいの気持ちで開催しています。
課題と展望
事前プランニングをより有意義な場にしていくために、開発の着手前にエンジニア目線で危険を察知するだったり、他チームの施策との依存関係を解決したり、ミーティングの中で成功体験を積み上げていく必要があると思っています。全社的な施策の透明性など開発以外の効果についても、事前プランニングや開発チームの動きによってより改善できることがないか常に考えていく必要があります。
この記事では3つの開発チームからなる LeSS Huge を参考にした開発体制の移行について書きました。しかし、事業の状況に変化があった場合には開発組織もそれに追従していく必要があります。事業ドメインも中期的には変わるでしょうし、一度できた開発体制に執着せずに、環境に適した体制かどうかを定期的に見直して必要なら構造を変えていく柔軟な姿勢を維持したいと考えています。
We are hiring!
ミラティブではユーザーにより価値を届けるためにチームを巻き込んで共に成長していける方を募集中です！
*1:たとえば記事 面倒なスクラム・オブ・スクラムに取って替わる７つの方法 では、ケン・シュエイバーの SoS に対する批判について書かれています。また、スクラムのスケーリングについて書かれた書籍 Scaling Lean & Agile Development では、「SoS に対する誤解は、SoS が調整の為のミーティングを開くためのベストな、もしくは唯一の方法だと思われていることだ」といった言及もあります。
