Scrum@Scaleの基本と実装 - Chatworkの実践に学ぶ「スケールするスクラム」の導入戦略
スクラムのスケーリング手法であるScrum@Scale（スクラムアットスケール）の基本的な概念、そして企業内での実践例を粕谷大輔（daiksy）さんが解説します。実践例では、Scrum@Scaleにおいて「だれが」「なにをやるのか」を、1週間のタイムスケジュールとともに解説します。
2001年にアジャイルソフトウェア開発宣言 が発表されてから20年。日本のソフトウェア開発の現場でもアジャイルはずいぶん一般的に扱われるようになってきました。そのうちの手法の１つであるスクラムについても、導入事例を多く見聞きします。
スクラムは原則的に少人数のチームに適用されることを前提としている手法ですが、さまざまな現場で扱われるようになるにつれ、規模の大きなチームへと拡張されるニーズも高まってきました。現在では、大規模にスクラムを実践するための手法も数多く提唱されています。LeSS、Nexus、SAFe、Scrum@Scaleなどが筆者がよく耳にする大規模スクラムの手法です。
本記事では、その中のScrum@Scaleについて取り上げて解説します。また、筆者が勤めているChatwork株式会社での実践の事例を紹介します。それにより、このフレームワークをどのようにして実際の現場に適用するかの一例を皆さんに学んでいただければと思います。
本記事の前提条件
本記事ではスクラムのスケーリング手法であるScrum@Scaleを扱います。「スクラム」を拡張するための手法についての記事になりますので、スクラムについてのある程度の知識があることを前提としています。本記事ではスクラムそのものや、そこで定義されている用語についての解説は行いません。読み進める中でスクラムについての理解が必要と感じられた場合は、スクラムガイドをご参照ください。
また、本記事で取り扱うScrum@Scaleについても公式のガイドが提供されています。
The Official Scrum@Scale Guide
公式サイトからリンクされている日本語版ガイドは本記事執筆時点では少し古い版になっています。日本語の最新版はScrum Inc. Japanが提供しているこちらを参照してください。
本記事でもScrum@Scaleのエッセンスを解説していますが、実践につなげたいという本記事の主旨に即していくつかの要素について解説を省略しているものがあります。本記事でScrum@Scaleについて興味を持たれた方は、是非公式ガイドのほうも読んでください。
スクラムをスケールする場合の注意点
具体的な手法の解説に入る前に、まずスクラムのスケールについて考えてみたいと思います。
リソース効率とフロー効率という考え方があります。
リソース効率は、与えられたリソースを目一杯使って仕事を進めようとする考え方です。5人のチームに5つの仕事があるとすれば、5人それぞれで異なる仕事を担当することで、5つの仕事が同時に進行します。これがリソース効率です。
フロー効率は、1つ1つの仕事に集中して、順番に早く進めようとする考え方です。5人のチームは、5人全員で1つの仕事にとりかかります。こうすることで、1人で進めるよりも1つの仕事が早く終わります。仕事は1つずつ順番に終わっていきますから、顧客はその仕事が終わり次第順番に価値を受け取ることになります。
スクラムは後者のフロー効率を重視する手法です。仕事を1つずつ、順番にチーム全員で片付けていきます。そのため、スクラムチームは職能横断型のチームであることが求められます。バックエンドチーム、フロントエンドチーム、インフラチーム、のように役割でチームが分かれていると、チームで1つの仕事を終わらせる、ということができませんから1つのチームの中でバックエンドもフロントエンドもインフラも扱えるようになっている必要があります。
仕事をするために必要な機能がチーム内にすべて揃っていると、コミュニケーションがスムーズになります。バックエンドとフロントエンドでチームが分割されている状態でエンドトゥエンドのシステムを作ろうとすると、何をするにもチーム間のコミュニケーションが発生してしまい、仕事が遅くなる原因になります。
1つの仕事を複数のチームでまたいで進めるより、1つのチーム内で完結させたほうが仕事は早く終わる。これがスクラムにおける原則的な考え方です。
「スクラムをスケールさせたい」という考えの根底には、チームが増えたほうが同時にたくさんの仕事ができるようになるはずである、という期待があるのだと思います。大勢で仕事をしたほうがより多くの仕事ができる、というのは自然な発想ですが、これはリソース効率を重視する考え方となります。
繰り返しますが、スクラムはフロー効率を重視する手法で、仮にスクラムをスケールしたとしてもこの考えを忘れてはいけません。チームが増えれば増えるほど、チーム間のコミュニケーションによるボトルネックは増えていきますから、安易に「仕事をたくさんするためにチームをたくさん増やそう」と考えるべきではありません。1つの仕事を最も高速に終わらせることができるのは1つのチームに完結している場合です。それを念頭においた上で、自分たちのプロダクトの価値をさらに高めるための手段として、スクラムのスケールが本当に必要であるのかはよく考える必要があります。
Scrum@Scaleの解説
Scrum@Scaleは、スクラムの共同考案者の1人であるJeff Sutherland博士を中心に確立されました。スクラムのシンプルな構造を保ったまま、複数のスクラムチームがフラクタル構造を取りつつ拡張していきます。Scrum@Scaleは開発チームだけでなく、組織全体に適用させることも可能です。そのため、Scrum@Scaleではプロダクト開発のHowを担う「スクラムマスターサイクル」と、Whatを担う「プロダクトオーナーサイクル」の両輪が定義されています。これらについての詳細は後述します。
複数のスクラムチームとスクラムオブスクラム
Scrum@Scaleにおいて、チームがどのようにスケールしていくのか。まずは1つのスクラムチームを起点に見ていきましょう。
ここに1つのスクラムチームがあります。スクラムにおけるチームの構成人数は3～9人程度が良いとされています。以下の図はスクラムマスター（SM）とプロダクトオーナー（以下、PO）、開発者によって構成された、最もシンプルなスクラムチームの状態です。
この単一チームが、デイリースクラム、スプリントプランニング、スプリントレビュー、スプリントレトロスペクティブといったスクラムイベントを実施していきます。
ここからチームが拡張されて複数チームによるScrum@Scaleの構造をとることとします。すると下の図のようになります。
各単体のスクラムチームは自分以外の他のスクラムチームとコミュニケーションをとる必要がありますが、これを担うのが、図の中心に書かれているスクラムオブスクラム(以下、SoS)です。
SoSは、各チームからの代表者が集まって構成されるバーチャルチームです。SoSも単一のスクラムチームと同様にスクラムイベントを実施していきます。単一スクラムチームがスクラムマスターによってファシリテーションされるのと同じく、SoSはスクラムオブスクラムマスターによってファシリテーションされます。
上記の図では5つのチームによってSoSが構成されています。1つのSoSのチーム数は4から5チームが最適とされています。それ以上のスクラムチームで全体を構成したい場合は、複数のSoSチームを束ねるスクラムオブスクラムオブスクラムチーム（以下、SoSoS）を作ります。SoSoSは、単一のスクラムチームがSoSを構成したのと全く同じ形でスケールさせます。
こうしてScrum@Scaleはフラクタル構造をとりながら拡張していきます。
エグゼクティブアクションチームと情報伝達の流れ
SoSや、SoSoSといった形で拡張していくと最終的に組織全体を統括したり、組織内の非アジャイルな部門との接点を担う役割が必要になります。Scrum@Scaleでは、エグゼクティブアクションチーム（以下、EAT）というものが定義されています。
EATは、SoSやSoSoSでは取り除けない障害を取り除いたり、Scrum＠Scale全体の意思統一を担うことになります。そのため、ここには経営的な意思決定が可能な人が配置される必要があります。
図ではとても巨大な組織の中心にEATが配置されていますが、もっと小さな、全体で5チームの単一スクラムチームの中心にEATがいても構いません。
チームの数が増えると、チーム間のコミュニケーションパスが増え、それが組織全体のボトルネックになります。Scrum@Scaleでは、SoSやEATといった構造をとることで、組織間に「実用最小限の官僚機構」をもたらします。この実用最小限の官僚機構によってできるだけ高速な情報伝達を維持します。
さきほど、SoSは単一スクラムチームと同様にスクラムイベントを実施すると説明しました。スクラムイベントの1つであるデイリースクラムを例にScrum@Scaleにおけるコミュニケーションの流れを見ていきましょう。
1日のはじめに、各単一スクラムチームがデイリースクラムを実施します。そこで自分たちだけでは解決できない課題が議論され、SoSに委ねられることになりました。15分間の各チームでのデイリースクラムが終わり、続いてSoSによるスケールドデイリースクラムが開始されます。ここには各スクラムチームの代表者が集まっています。その後、複数のSoSの代表者からなるSoSoSのデイリースクラム。最後にEATによるデイリースクラムへと情報が伝達され、EATに所属しているCEOによって意思決定がくだされます。
このようにして、各15分のデイリースクラムを順番にたどることで、最終的にEATに所属するCEOに15分×3回の45分で情報が到達します。"デイリー"スクラムですから、これが毎日繰り返され、高速な意思決定プロセスを維持することができます。
他のスクラムイベントも同様です。たとえば、スケールドレトロスペクティブによってScrum@Scale全体から単一スクラムチームまでさまざまな階層でふりかえりが定期的に実施され、素早く組織全体の課題が改善されていきます。
ここまでが、Scrum@Scaleにおいて、開発の"How"を担う「スクラムマスターサイクル」のおおよその仕組みになります。
プロダクトオーナーサイクル
Scrum@Scaleでは各チームにそれぞれPOがいます。これは通常の単一スクラムチームの運用と同じです。POがプロダクトバックログアイテムを作り、それをチームが消化していきます。スクラムチームがスケールすると、それがSoSによって連結されます。SoSにはチーフプロダクトオーナーが配置され、SoSによって形成されるスクラムチームのグループ全体のバックログを扱うことになります。
このようにして階層的にチームがスケールしていくと、チーフプロダクトオーナーを含むPOチームによる活動が必要になります。これが、Scrum@Scaleの概念図にも示されている「プロダクトオーナーサイクル」です。POがチームとして活動をすることで、各チームに供給されるバックログの調整と、ステークホルダーや顧客ニーズとの整合が取られることになります。
POチームも、スクラムマスターサイクルによるSoSやSoSoSのように階層的に組織されます。それがメタスクラムや、エグゼクティブメタスクラムです。
プロダクトオーナーサイクルにおけるPOチームの活動そのものは、単一スクラムチームと変わりありません。プロダクトの方向性を決定し、顧客フィードバックを受けて次の戦略を練り、プロダクトバックログをつくったりその優先順位を決定したりします。
Scrum＠Scale全体で見ると次のようになります。まず、最上位のエグゼブティメタスクラムで、プロダクトあるいは組織全体の方針が決定されます。それを受けて、メタスクラムで各SoSに所属するチーフPOが集まり、各スクラムグループのプロダクトバックログを作り込んでいきます。さらにそれは、SoSに所属するチーフPOと単一スクラムチームのPOによって、それぞれの単一スクラムチームが扱える形にブレイクダウンされていきます。
このようにして、Scrum@Scaleでは開発チームによる「スクラムマスターサイクル」とプロダクトオーナーチームによる「プロダクトオーナーサイクル」がスケール化されたそれぞれの活動を繰り返していきます。
ChatworkでのScrum@Scaleの実装
それでは、Scrum@Scaleのガイドに従って実際にどのように実践しているのかの実例を見ていきましょう。ここからは、筆者が勤務しているChatwork株式会社における2021年9月時点での様子をご紹介します。
我々の実践例を読んでいただくとわかると思いますが、チームやプロジェクトの状況にあわせて、Scrum@Scaleの要素すべてを完璧に実装しているわけではありません。また、これらのやり方は我々もスプリントを繰り返しながら改善を続けています。ですから、我々の実践例のとおりに皆さんの現場に適用できるとはかぎりません。しかし、ガイドに書かれている要素が、実際の現場でどのように解釈、運用されているのかの一例として参考にしていただければと思います。
なぜScrum@Scaleを採用したのか
今年でローンチから10年になるChatworkでは、かねてから技術的負債の返済やアーキテクチャの置き換えを継続しています。2014年～2016年にかけて、「Falconプロジェクト」と銘打ち、メッセージ機能の刷新を行いました。その後、すでに刷新が完了したメッセージ機能以外のChatwork全体をリニューアルするプロジェクトが立ち上がり、2019年からPoCに取り組んできました。そして2021年の4月より、具体的なチームを編成しての実際の開発に取り組んでいます。
Scrum@Scaleは、このアーキテクチャ刷新プロジェクトにおける組織編成の手法として採用されることになりました。
Chatworkの新しいアーキテクチャは、各コンポーネントをマイクロサービスとして運用していくことを考えています。そのため、各コンポーネントごとに1つの開発チームを割り当て、長期的に運用していくことになります。
なぜ、スクラムのスケールが必要だったのか
ソフトウェア開発の現場では「コンウェイの法則」としてよく知られた法則があります。それは、システムのアーキテクチャは、そのシステムを開発する組織構造を反映したものになる、という法則です。
チームをまたいだコミュニケーションは時間がかかったり、さまざまな利害関係の調整が必要なため、なるべく仕事は自分たちのチーム内だけで完結させたい、という力学が働きます。すると、当然チームの分割点がそのままアーキテクチャの分割点と一致するような設計が優先して考えられるようになります。結果として、そのプロダクトのアーキテクチャはそのプロダクトを開発するために組織されたチーム編成に強く影響を受けた構成になるのです。
これを逆手にとるのが「逆コンウェイ戦略」と呼ばれる戦略です。つまり、理想とするアーキテクチャを先に考えて、それを実現するための組織編成を採用するのです。
我々Chatworkもこの「逆コンウェイ戦略」をとり、理想的なアーキテクチャを目指したいと考えました。そのためには、我々が考える新しいアーキテクチャの構成要素ごとにチームを分割し、編成する必要があります。分割されたそれぞれのチームがスクラムで運用されることになると、当然新しいChatworkのアーキテクチャを担うチームはスケール化されたスクラムの形を取る必要があります。これが我々がスクラムをスケールして運用したい理由です。
Scrum@Scale採用の背景
スケール化スクラムをつくっていくにあたり、Scrum@Scale以外の手法も含めてどのやりかたを採用するかが検討されました。
PoCを終えているとはいえ、アーキテクチャの刷新プロジェクトの初期段階でマイクロサービスのすべてのコンポーネントを綺麗に設計するのは困難です。おおよその構成は決まりつつも、その詳細は走りながら微調整をしていく必要があります。つまりこれから作られていくアーキテクチャに合わせ、組織そのものを柔軟に変化させる必要があったのです。また、プロジェクトが推進される期間は新アーキテクチャと、現行アーキテクチャのChatworkが同時に運用されることになります。それを混乱なく実現するためには、新アーキテクチャを担うPOと、現行Chatworkを運用しているPMが足並みを揃える必要があります。これらのことを考えると、プロダクト全体を一人のPOが担うのは難しく、中心となるチーフPOが全体を統括しつつ、各コンポーネントごとにそれぞれPOがいて意思決定の権限が委ねられている方がうまくいくと考えました。これがScrum@Scaleを選択した理由です。
Scrum@ScaleはSoSを中心にフラクタルな構造を取ります。組織全体では、SoSといった上位概念でもレトロスペクティブなどの改善ポイントが用意されています。これらの改善サイクルをうまく運用することで、組織全体のリファクタリングも可能であると考えました。
また、プロダクトオーナーサイクルをうまく運用することで、Scrum@Scaleの外側にある現行Chatworkシステムを担うステークホルダーとのコミュニケーションもスムーズにいくはずだと考えました。
こうして、2021年4月からScrum@Scaleによるチーム運用がはじまりました。
これからご紹介するのは、こうして立ち上がったScrum@Scaleチームにおける、2021年9月時点のスナップショットです。前述のように、我々はアーキテクチャの設計にあわせて柔軟に組織そのものを組み替えながらチームを運用しています。最初2チームではじまったこのプロジェクトは現在3チームで運用されています。それぞれのチームの役割も、具体的なアーキテクチャの設計が進むにつれて変化しています。細かい変更箇所を数えると、4月から9月までの間では、ほぼ毎月なにかしらの組織的な変更がとられています。ひょっとしたら、この記事が公開されるころにはまた形を変えているかもしれません。
Chatworkでの組織構造
次に掲載する図は、現在のChatworkにおけるScrum@Scale組織の概要をあらわしたものです。
3つの開発チームがあり、それぞれがオーソドックスなスクラムで運用されています。それぞれのチームに職能横断型の開発メンバーがおり、専任のスクラムマスターとプロダクトオーナーがいます。スクラムマスターはチームを増やす際に都合よく新しい人を割り当てられない場合もあるので、複数のチームでスクラムマスターを兼任することもあります。社員からスクラムマスターを割り当てられない場合、一時的に外部のアジャイルコーチを招聘して支援してもらうこともあります。
これらの3チームは、スクラムオブスクラム(SoS)によってチーム間の連携がとられます。SoSは、各チームの代表者と専任のスクラムオブスクラムマスターで構成されます。少し前まで、筆者がスクラムオブスクラムマスターを勤めていました。2021年9月時点では、新しく3チーム目が立ち上がったばかりで、筆者は新チームのスクラムマスターを担当し、スクラムオブスクラムマスターは外部のアジャイルコーチにおまかせしています。
チームをまたいで解決する必要のある課題や、Scrum@Scale全体の運用についての課題などがSoSで扱われます。
EATはまだ本格的に設置していません。これはプロジェクトの現状が新アーキテクチャの立ち上げ期であるためです。扱われるプロダクトバックログはまだ技術的な要素が大半を占めています。そのため、今の段階では経営的な意思決定が頻繁に必要な局面ではないと考えているからです。プロジェクトが進み、チームが扱うバックログにビジネスや直接的な顧客価値についての観点が増えてきたら改めて設置しようと考えています。
プロダクトオーナーサイクルを担う位置づけで、MetaScrumを置いています。MetaScrumは、各チームのプロダクトオーナー、プロジェクト全体を統括するチーフプロダクトオーナー、現行Chatworkシステムを運用しているPM、そしてCTOで構成されています。プロジェクト全体の方針決定や、プロジェクトの外部とのコミュニケーション、予算やコストに関する課題などがここで扱われます。
スクラムイベントの実装
次の図は、各チームのスクラムイベントをあらわした1週間のカレンダーです。なお、スプリントの期間は1週間で、水曜日に始まり、翌週火曜日に終わります。
Scrum@Scaleにおけるスクラムイベントは、情報の流れがなるべくスムーズに各チームに伝達されるように協調して配置される必要があります。そのため、カレンダーの変更が必要な場合は各チームの独断ではなく、SoSで議論される必要があります。
デイリースクラムは毎日15分ずつ、各チーム、SoS、MetaScrumの順に実施されます。これにより、チーム単独で解決できない課題はチームのデイリースクラムの15分後にはSoSで検討できるようになっています。また、さらにその15分後にプロダクトオーナーサイクルとのコミュニケーションができます。
水曜日に各チームのスプリントプランニングがあります。リファインメントはいつやってもいいのですが、今はSoSのリファインメントが金曜日、各チームは月曜日に置かれています。火曜日に各チームのスプリントレビューと、レトロスペクティブがあり、1スプリントが終了します。翌日水曜日の朝一に、MetaScrumメンバーによる長いMTGがあります。ここで、各チームから前日のスプリントレビューの結果がMetaScrumに報告され、それを受けてMetaScrumが全体方針を決定していきます。これらの方針は、最速でその日のスプリントプランニングに反映され、また次のスプリントが開始されます。
これが、現在のChatworkにおけるScrum@Scaleを手本としたスケール化スクラム組織の全体像です。
導入のポイント
最後に、筆者が考えるスケール化スクラム導入のポイントを書いておこうと思います。
チームを増やすときは「既存チームから分割する」
スクラムは非常にシンプルなフレームワークですが、その実践はなかなか難しいものです。1つのスクラムチームを運用するのにもそれなりの難しさがあるのですから、それが複数のチームともなるとさらに難易度は上がります。
最初から大きい組織を作りたくなる気持ちはたいへんよく理解できますが、未熟なスクラムチームが一気に3つも4つも動き出すとおそらく現場は収拾がつかなくなり、崩壊してしまうでしょう。スクラムチームをスケールする場合は、まずは1つのスクラムチームで充分に練度をあげ、そこに新しく人を入れてチームを分ける、という方法が良いでしょう。
外部のプロに躊躇せず頼る
幸いなことに、日本のアジャイルコミュニティはたいへん成熟しており、プロのコーチもたくさんいます。独学でやることは避け、できるだけプロの手を借りましょう。
ChatworkのScrum@Scaleは2チームからスタートしました。前述した「1つのチームの練度を上げてから分割する」という自らのアドバイスにいきなり反しているのですが、これを実現するために我々は最初期から2人のプロコーチを招き、立ち上げ当初のチームの支援をお願いしました。
また、外部の研修も活用しながら、スクラムそのものの学習や、Scrum@Scaleについての専門家からのレクチャーを受けるなど、常に自分たちの習熟度を高めるための投資をしています。
おわりに
以上、簡単ではありましたが、Scrum@Scaleについての解説と、Chatworkでの実践例をご紹介してきました。
本記事を読んで、Scrum@Scaleについて興味を持たれた方は、ぜひ公式ガイドにもあたって学習を深めてください。また、最近ではScrum@Scaleについての日本語による研修も開催されています。こうした手段を活用しながらプロの支援なども上手に利用して、皆さんの現場での適用を検討してみてください。
粕谷大輔（かすや・だいすけ） 
Chatwork株式会社エンジニアリングマネージャ。SI、ソーシャルゲーム開発を経て、2014年より株式会社はてなにてサーバー監視サービス Mackerelの開発に携わり、2017年1月より同チームのディレクター。2021年5月より現職。認定スクラムマスター / アドバンスド認定スクラムマスター / 認定スクラムプロダクトオーナー / 認定Scrum@Scale Practitionar
ブログ：だいくしー(@daiksy)のはてなブログ
ブログ：だいくしー(@daiksy)のはてなブログ
編集：はてな編集部
