こんにちは。
id:daiksyです。
昨年の6月に、ChatworkではScrum@Scaleを用いたスケーリングに取り組んでいる、という記事を書きました。
上記の記事では、Scrum@Scaleの簡単な解説と、なぜこの手法を選択したのかについて書きましたが、2021年の4月からはじまった取り組みだったため、記事執筆の時点ではまだ実践をはじめて2ヶ月、という状況でした。
そこから継続的に取り組みを続け、組織構造にいくつかの変遷があったので、9ヶ月間の道のりを今日は書いていこうと思います。
Scrum@Scaleそのものの解説は上記で紹介した記事か、または公式ガイドなどをご参照ください。
2021年4月~6月
将来的には複数チームにスケールしていくことを目指していますが、最初期は2チームからのスタートでした。
Scrum@Scaleを採用しているのは、Chatworkの次世代アーキテクチャを担うチームです。
次世代アーキテクチャへのリライトプロジェクトの動機や、ゴールについては昨日藤井さんが書いてくれた記事がありますのでこちらをご参照ください。
この次世代のアーキテクチャはCQRSをキーアーキテクチャとして採用しています。
コマンドとクエリを担う双方のサービス間はイベントソーシングによって連携されることを想定しています。
アーキテクチャの詳細については、かとじゅんさんのエントリやスライドをご参照ください。
これらのようなキーアーキテクチャを採用したことで、チームをアーキテクチャにあわせて組成していくこととなります。 一般的にシステムのアーキテクチャは、そのシステムを維持・運用する組織構造に大きく影響を受けることが知られています。これを「コンウェイの法則」と呼びます。アーキテクチャが組織構造の制約を受けるのであれば、それを逆手にとり、理想とするアーキテクチャにあわせた組織を最初からつくる、という戦略が考えられます。これを「逆コンウェイ戦略」と呼びます。
最終的に理想とするアーキテクチャを実現するため、まずはCQRSのコマンドとクエリとで大きく責務を分割したチーム編成としてチームをスタートさせました。
まずはこのようにキーアーキテクチャに沿った大まかな分割から開発を開始し、開発が進むにつれて見いだされた関心事にチームごとサービスを分割していく、というやり方を継続的に目指していきます。
2021年7月~8月
開発が進むにつれ、クライアントサイドを進めるには認証基盤を無視することができない状況であることがわかってきました。
また、認証基盤といっても自前で作り込んでいくのか、IDaaSを採用するのか、といった調査・検証も必要になります。IDaaSを採用するのであれば、新アーキテクチャだけではなく、現行Chatworkもできるならそれに置き換えていきたい、というニーズも生まれ、従来のチーム構成のまま取り扱うには認知負荷が高い状況となりました。
そこで、認証部分を関心事として切り離し、新しいチームを組成することになります。
こうして3チームに拡張された体制へ移行していきました。
2021年9月~10月
もともとはCQRSのクエリとコマンドで責務を分離した体制でスタートした開発でしたが、開発を進めていくうちに問題として扱うには少し大きすぎるという懸念が生じてきました。そこで、少しスコープを狭めて、まずはバックエンドのみに注力して、現行Chatworkでも大きくシステム的な負荷がかかっている箇所にフォーカスをあて、本番稼働を早めようということになりました。
当初はクライアントからバックエンドまで一気通貫で置き換えていくことを狙っていましたが、このスコープ調整によって現行Chatworkのままの運用を長期間継続しつつ、負債の大きい箇所から重点的に潰していく、という戦略に変更。
Xチームと呼ばれていたクライアントサイドのチームをいったん休止して、そのメンバーを別の役割に再編することにしました。具体的には、サーバーコンテンツをつくっているチームが従来の活動を続け、そのチームから現行Chatworkからのデータ移行などを新しいチームに担わせることで、もともとのチームがより本来的な開発に注力できるような体制をつくりました。
また、Scrum@Scale全体の方針について議論する場としてEMS(Executive Meta Scrum)を立ち上げました。
2021年11月~現在
Scrum@ScaleにおけるSoS (Scrum of Scrum)はチーム間の同期をとり、統合されたデリバリーについて責任を担う機関です。つまり、関心事が強く結びつかないのであればSoSそのものを分割してコミュニケーションパスをシンプルに保つことが推奨されます。
これまでの活動の中で、認証を担うチームは他の2チームとはさほど密に連携しなくても良いという発見がありました。逆に認証チームはIDaaSの採用などの観点で現行Chatworkとの結びつきが強くなってきていました。
そこで、SoSを用いたチーム間連携の構造に手を入れ、Aチームを従来のSoSから切り離しました。
また、アーキテクチャ移行というプロジェクトの性質上、どうしても議論がHowを中心としたものが多く、まだプロダクトとしてのWhatに注力するのは少し時期が早そうである、という判断もあり、EMSをEAT (Executive Action Team)に再編しました。
その後、チーム体制はこの形のまま現在まで続いています。
今後
今後はもう少し開発が進んでいくと、扱いたい関心事からBチームが分割されていくだろうと考えています。また、現行Chatworkのプロダクトマネージメントを担当する人たちと協調しつつ EMSの再立ち上げを狙っていきます。
さらに半年後くらいには、またここから状況が変わったチームの状態をお知らせできるかもしれません。
