Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

ChatworkにおけるScrum@Scale導入への挑戦

こんにちは、id:daiksy です。

今回はぼくがChatworkで取り組んでいるスケーリングスクラムについて書いてみようと思います。

先日開催された Chatwork DevDayでもお話したのですが、現在我々はChatworkのリアーキテクティングプロジェクトにおいて、Scrum@Scaleの導入を進めています。

www.youtube.com

Scrum@Scaleとは?

Scrum@Scaleは、スクラムの作成者の1人でもあるジェフ・サザーランド氏によって考案されたスクラムをスケーリングするための考えかたです。

詳細は公式のガイドが各国語版の翻訳も含めて公開されているので、そちらをご参照ください。本稿では簡単な概要だけにとどめます。

www.scrumatscale.com

以下の図 *1 に示すように、Scrum@Scaleは単一のスクラムチームをそのままスケールすることにより拡張していきます。単一のスクラムチームの最適な構成人数が4, 5人程度であると言われているように、複数のスクラムチームの最適な構成数は4つか5つをまずは上限と考えます。これがScrum of Scrumチームです。

f:id:daiksy:20210607122801p:plain
スクラムチームの拡張

このScrum of Scrumチームは、仮想的なスクラムチームとして振る舞います。つまり、Scrum of Scrumチームはスプリントの終わりに統合されたインクリメントに対して責任を持ちます。また、仮想的なスクラムチームとして、各スクラムイベントを執り行います。Scaled Daily Scrum (SDS)、Scaled Retrospectiveなどです。

実装の規模によって、さらに大きな拡張が必要な場合、次の図のように複数のScrum of Scrumチームから構成されるセットをつくります。

f:id:daiksy:20210607122818p:plain
SoSの拡張

このように、Scrum@Scaleはフラクタル的な構造をとり、理論上は無限にスケールします(スケールフリー)。

Scrum@Scaleでは、以下の全体概要図に示されているとおり、2つの特徴的なプロセスに言及されています。Howを担う、スクラムマスターサイクルと、Whatを担う、プロダクトオーナーサイクルです。

f:id:daiksy:20210607122436p:plain
Scrum@Scaleの全体概要

スクラムのような開発プロセスについて検討する場合、どうしても「How (どのようにやるか)」に重点がおかれがちです。その点、Scrum@Scaleでは「What (なにをやるか)」にも焦点が向くような構造としてフレームワークが考えられており、プロダクト開発を行う組織全体に伝播させていくべきフレームワークとして個人的にこの点が気に入っています。

そもそもなぜスケールしたいのか

スクラムにおいてスケーリングを検討する場合、まず最優先に考える必要があるのは「スケールせずに済む方法はないのか」です。試しに、お近くのアジャイルコーチに「スクラムチームをスケーリングしたい」と相談してみてください。10人中9人は「スケールを考える前にまだやることはあるのではないですか」と答えるでしょう。ぼくも基本的に単一のスクラムチームを維持できるならそれにこだわるべきだと思っています。

その一方で、プロダクトがビジネス的な成功を収め、さらなる成長が期待される場合、組織は拡大する方向にベクトルが向きます。開発チームに限らず、カスタマーサクセスや営業など、さまざまな人々の力が結集して事業は前に進みます。こういった成長の波にうまく乗れた場合、いかに組織を大きくしていくかが事業の関心事のひとつになるでしょう。

我々Chatworkも、幸運にもその波に乗り組織が急拡大しています。

会社全体で、プロダクトに携わるあらゆる分野で組織が大きくなっていく過程において、その事業の中核を担うプロダクト開発の現場をスケールさせるのは、必然の流れではないかと思うのです。

なぜScrum@Scaleを選んだのか?

ChatworkでのScrum@Scaleの導入は、Chatworkの次世代アーキテクチャを構築しようとしているプロジェクトを皮切りにスタートしています。

たとえばコンウェイの法則などに代表されるように、プロダクトのアーキテクチャと組織構造は切り離して考えるべきではありません。これからChatworkが新しいアーキテクチャに移行するにあたって、常に組織構造を改善しつつ、それへの移行と連動する形で会社全体へ新アーキテクチャおよび組織体制を浸透させていく、というのが中期的な目標となります。

会社全体で新しいアーキテクチャに対応する組織へ転換していくために、Scrum@Scaleの以下のような特徴が都合が良いと考えています。

  • スクラムマスターサイクルとプロダクトオーナーサイクルの両輪を整えることで、開発チームに閉じることなく事業全体を巻き込めるのではないか
  • 複数チームで1つのPBIを共有する他のスケーリング手法と異なり、各スクラムチームが独自にPBIを持つことができ、事業のあらゆる分野でスクラムチームを形成することができるのではないか

以上が、Scrum@Scaleが今のChatworkに適していると考えた理由となります。

どのように取り組んでいるか?

将来的な目標は前述のように壮大なものですが、現在導入のチャレンジはスタートしたばかりです。現在Chatworkのリアーキテクティングプロジェクトでは2つのスクラムチームが動いています。

この2つのスクラムチームから、Scrum of Scrumチーム(以下SoS)という仮想的なスクラムチームが構成されており、ぼくはそこのスクラムマスター。つまり「スクラムオブスクラムマスター」の役割を担っています。

始業の朝10時から、それぞれ2つのスクラムチームのデイリースクラムが行われ、その後10:30からSDS(Scaled Daily Scrum)が行われます。SoSは現在1週間スプリントで動いており、週の頭にSoSのスプリントプランニング、週の最後にSoSのスプリントレビューやレトロスペクティブが行われます。各スクラムチームも1週間のスプリントで、各スクラムイベントをこなしていきます。

プロダクトオーナーサイクルでは、MetaScrum *2という仮想的なチームが置かれており、ここにCTOやPMが名を連ねています。ここで、経営的なビジョンに基づいた、各チームにおけるプロダクトバックログの基幹となる意思決定が行われます。

今後の展望と課題

ChatworkにおけるScrum@Scaleの導入チャレンジはまだスタートしたばかりです。前述のように、スクラムマスターサイクルの仕掛けは少しずつ整ってきました。次は、プロダクトオーナーサイクルをどのように整えていこうか、というのがぼくの目下の課題です。

また、2チームでスタートしている体制も、プロジェクトの進行度に応じて増員が見込まれています。達成すべきプロジェクトのマイルストーンと、自分たちの練度のバランスを取りながら、どのように安全にチームを大きくしていくか、というのも大きな課題です。

困難な道のりではありますが、やりがいのある大きな仕事でもあります。 一緒にこのチャレンジをやってみたい、という方がいらっしゃったら、ぜひお力添えをお願いします。

recruit.chatwork.com

*1:いずれも https://www.scrumatscale.com/scrum-at-scale-guide-online/ からの引用。図のライセンスはCC BY-SA4.0。

*2:MetaScrumやEATといった概念についての詳細は公式ガイドを参照してください