スケールする大規模スクラム開発「LeSS」の実践例＠Timers

はじめに

CTOのあまど ( @amado_tech )です。 Timersでは2013年頃から長らくスクラム開発を中心に据えてプロダクトを作ってきました。初期の頃はなんちゃってスクラムだったり、人が増えるにあたって自己組織化するのが難しくなったり、たくさんの課題や問題を乗り越えてきました。

現在16名程度のアプリ開発チームが2つのスクラムチームと1人のプロダクトオーナーの体制で、2週間のスプリントを効果的に回しながら生産性高く＆納得度高くプロダクト改善が出来ており、我々のコアプロダクトである「家族アプリFamm」は順調に改善され事業成長もしています。

そんな開発体制を支えているのが、「LeSS(Large Scale Scrum)」という大規模スクラムのフレームワークです。本記事ではLeSSの紹介と実践する上でのノウハウを共有します。

LeSS(Large Scale Scrum)とは

f:id:timers-tech:20200527171650p:plain:w800

Less(Large Scale Scrum)とはその名の通り「大規模スクラム」、つまり複数チームで協調しながら同じプロダクトをスクラム開発するための手法です。チームごとには普通のスクラムチームとしての手法に則りながら、複数のスクラムチームが同じPBL(プロダクト・バックログ)に向き合い同じプロダクトを開発できるためにいくつかの取り決めやイベントが付加されて構築されたフレームワークです。

この公式サイトが非常に優秀なので体系的知識として知るべきものは全てここに書いてあります。が、内容がかなり多いのと「理論としてはわかったけど実際やってみてどうなの？」というところに答えるため本記事で実体験をシェアすることにしました。

なぜLeSSか

なぜLeSSが必要かについては公式サイトからのこの引用文が良い説明になっています。

2001年、アジャイル開発、特にスクラムは、ソフトウェア開発に革命を起こしてきました。
しかし、大規模なグループにアジャイル開発を適用する方法について尋ねると、「知らない」、「小さいチームにしか使うな」、「スクラムはチームレベルで行え」のような答えしか返ってきません。
どの解答も有用とは言えません。開発に人員を追加することを避けられればベストであるのは事実ですが、大規模なプロダクト開発がなくならないのもまた事実です。
そのため、我々はなんとかうまくやる方法を見つけないといけません。
...
スクラムは、その一方で、単一チーム開発に関する適切な方法に感じられました。そのため、疑問は「スクラムの強みを失わずにスケールするにはどうしたらいいか」となりました。

「大規模なプロダクト開発」と言っても、LeSSが必要になるのはあくまで「大規模な人数で一つのプロダクトを開発する場合」です。例えば組織＆プロダクトの区切りが明確で、それぞれのスクラムチームが一つのプロダクトを背負って自己組織化されていれば、スクラムチームがたくさんあっても円滑に市場に価値を提供できるはずなのでLeSSのようなフレームワークを導入する必要はありません（他の組織課題は出てくるとは思いますが）。

一つのプロダクト、そして一つのプロダクトオーナーがいる（プロダクトを区切ることが出来ない）中で人数が増えてきた際に開発体制をスケールさせていくのがLeSSを導入する主な目的になります。

Timersではこの直前まで一つの大きなチームで開発をしており、人も増えてきていよいよ開発体制がスケールの限界を迎えていました。昔は2つのスクラムチームで開発していた時期もありましたが、同じプロダクトなのに別々のPO&バックログで運用していてそれも課題が多かったため、LeSSの導入に踏み切りました。

LeSSでのロール

LeSSでの各人の役割は通常のスクラムとほぼ同じですが、LeSSの文脈に当てはめた時の理解の仕方を書いていきます。

PO(プロダクトオーナー)

スクラムと同じく「ROIを最大化させるためにバックログを作る役割」です。LeSSにおいては複数チームがバックログから開発していくのでバックログも量も多く、考えることが多くなります。そのため、1チームスクラムの際に比べてより中長期視点に立ち広い視野で見渡しながら優先順位付けをしていく事に時間を割くことになります。逆に、バックログアイテムは一定の粗さを許容し、「より細かいユーザーストーリーに分解する」や「個別バックログアイテムを明確化する」といった作業はチームに委ねることが多くなります。

Timersでは自分(CTO)がアプリ開発チームのPOをやっています。1チームスクラムではよりチームに寄り添ったPO像があったのに対し、現在では「手段は問わないからとにかくこの課題を解決したい！あとはチームで考えて！」と言うことが多いかなと思います。これは信頼できる自己組織化されたチームが活躍してくれてるから出来る事でもあります。

SM(スクラムマスター)

スクラムマスターも通常のスクラムと同じく、組織として正しく＆効果高くスクラム開発できるためチーム内外に働きかける役割になります。LeSSにおいては、チームが通常のスクラムを超えてLeSSの構造を理解できているか？効果的にLeSSが行えてるか？の責任を負うことになると思います。

Timersでは現在はフルタイムのスクラムマスターは在籍していません。スクラムマスターのロールをPMやエンジニアが一部担うようになっております。これはバッドプラクティスなのかもしれませんが、現在ではチーム全員にスクラムやLeSSを理解・習得・改善することを求めており、それが結果としてより強い自己組織化されたチームにつながっているという実感を持っています。

チーム代表者

「チーム代表者」というロールはスクラムには存在せず、LeSS独自のロールになります。後述しますがLeSSでは「Sprint Planning 1」と「Overall Retrospective（全体振り返り）」というチーム横断イベントがあります。その際にチーム全員が出席すると、イベントの人数が非常に大きくなり運営が困難になります。そのためチームの中で1人がチームを代表して出席し、バックログアイテムを掴んだり振り返りを行なったりという活動を行います。このロールに就く人間は「イベント出席の際は自分だけじゃなくチーム全員のことを考え、彼ら彼女らの立場に立って代弁する」という意識と責任を負います。が、このロールは固定ではないので、「今Sprintは誰々さんが代表者をやる」というのもOKだと思っています。

加えて、LeSS公式サイトには

2チームしかいないなら、全員でもOK。3チーム以上なら、1人か2人、（SM以外の）代表者をチームごとに送り出しましょう。

このように書かれています。Timersでは現在2チームでLeSSを行なっており、代表者が存在しつつ、イベント自体は全員参加にしています。これについてはまた後述。

チーム

これはスクラムと同じ、職種横断的・自己組織化された（＝そのチームの力だけでプロダクトを開発＆出荷することができる）チームを指します。 LeSSでは複数チームで開発を行いますが、それぞれのチームは独立して上記定義に当てはまる必要があります。なので、LeSSになったからといって「複数チーム掛け持ちしてる人」は出来る限り無い方が良いです。

TimersにおけるLeSS体制

現在家族アプリFammのアプリ開発チーム体制は1PO、2スクラムチームで運営しています。それぞれのスクラムチームには責任領域があるわけではないので、名前もシンプルに識別しやすいよう Dog Team , Cat Team という名前です（本当はいぬさん🐶 ねこさん🐱 チームらしいですが自分は頑なにDog,Catと呼んでいます...）。

LeSSの良いところは、今後事業＆組織が成長しても同じようにもう1チーム増やせばほぼ問題なくスケールするというところです。公式サイトによると、最大8チームまではこのフレームワークに耐えうるらしいです。

f:id:timers-tech:20200527173025p:plain:w400

LeSSでの1スプリントの流れ

ここからはTimersで行なっているLeSSの1スプリントの流れを紹介します。だいたいが教科書通りですが、独自のスタイルを取り入れているところは補足していきます。スプリントは2週間、月曜から翌週金曜までで行なっています。

バックログ・リファインメント

月曜の朝はバックログ・リファインメントから始めています。主にPO(自分)から

この先こういう開発に力を入れていき事業成長をさせていきたい
みんなからもらったバックログ追加依頼の中でこれは特筆して確認したい
現在あるバックログアイテムはこの優先順位で良いか確認したい

などのバックログ整理の議論を、チーム全員＆ステークホルダー（社長含む）を入れて行います。長期戦略に関するプロジェクトの頭出しももちろんですが、エンジニアやカスタマーサポートから来るバックログ追加依頼をここで議論することもします。例えば：

「xxxのライブラリをアップデートしたい」というバックログ追加依頼をエンジニアから事前にもらっており、自分が「これについてちょっと詳細聞かせてもらえますか？」と起票したエンジニアに尋ねる
「アップデートしておかないと後々こういうところが辛くなりそう」という意見を話してもらう（社長などビジネスサイドのステークホルダーもその場にいる）
自分が「なるほど、それは後々厄介そうだから早めにやっちゃおう」と言って優先度を上げる

と言った話し合いがされます。売上直結じゃないバックログアイテムの意思決定経緯をこういう場できちんと透明性高く議論しておくことで、開発メンバー＆ビジネスサイドともに出来る限り納得度の高い状態を保つようにしています。

※ちなみに自分はPOになってから「バックログに入れたいリスト」というものを用意しており、エンジニア・デザイナー・QAなどチームメンバー全員が誰でもいつでも気軽にバックログに追加したいものを自分に投げられるようにしてあります。デザイン調整やリファクタリングなど、「やりたいんだけどいつ相談すればいいかわからない……」というモヤモヤを無くす目的です。みんないつもたくさん改善案をくれていてプロダクト改善につなげられています。

スプリント・プランニング 1

f:id:timers-tech:20200527174541p:plain:w400

月曜の朝、リファインメントに続いてスプリント・プランニング1（通称SP1）を行います。 SP1は全チーム（代表者か全員）とPOで集まり、そのスプリントでどのチームがどのバックログアイテムに着手するかを決め、それぞれのチームがスプリントバックログを作っていくイベントです。プロダクトバックログを上から見ていき、各々のチームの代表者orチームメンバーで：

これは我々のチームでもらいます
これはそっちでやった方が最適かもしれません
我々がこのバックログをやっててそっちがそれをやるとコンフリクトする可能性があるので、どちらかに寄せましょう

などの議論が交わされます。

SP1の終わりには、それぞれのスクラムチームがそのスプリントで取り組むユーザーストーリーがスプリントバックログ上に乗っていて完全に明確になっているし、チーム同士がお互いのチームが何をやってるかが明確になっています。

スプリント・プランニング 2

SP1の次はSP2です。SP2はそれぞれのチームが個別に行い、POは参加しません。ここでは通常のスクラムのように、「やる」と決めたユーザーストーリーを細かく見積もったり、詳細なタスク分解をしたり、着手順序を話し合って決めていきます（デザイン確定に時間かかりそうなユーザーストーリーはエンジニアは後回しにする、など）。抽象的なユーザーストーリーの詳細仕様を決めたり簡単な設計を決めるのもここでやってしまいます。目的はとにかくそのスプリントでやると決めたユーザーストーリーを完遂させるため認識齟齬や曖昧さを無くすことです。

このイベントは長いと2時間などかかりますが、全員その覚悟で臨みます。 SP2が終わると、月曜日のLeSSイベントは全て終了です。ここまで来たら、あとは2週間開発に集中していきます。

※月曜は朝からイベント尽くしでなかなか疲れますが、2週間のスプリントを円滑＆納得度高く過ごすために必要な大事なところなので手を抜かず頑張るのが大事。エンジニアは隔週の月曜はほぼコーディングはできないと割り切ります。

デイリースタンドアップ

毎朝(昼でもいいですが)はそれぞれのチームが個別で通常スクラムと同じようなデイリースタンドアップという朝会を行います。それぞれで日々の進捗や困りごと、相談事などを話し合う場です。ユーザーストーリーの実現を阻害するものやわからないことがあればここですぐにアラートを上げます。 Timersではこの時間に「その日までの成果物を見せたい人は見せて、フィードバックをもらったり褒めてもらう」という時間も設けてます。

スプリントレビュー

2週間の最終日、金曜日はいよいよスプリントレビューです。ここでは全チーム・PO・一部ステークホルダーが集い、それぞれのチームの作った成果を見せ合います。Timersではチームごとに代表者が1人、プロジェクターにつないでデモや動画で成果発表をしていく形式をとっています。

f:id:timers-tech:20200527175026p:plain:w400

最終的にはPOがそれら一つ一つの出荷判断にOK/NGを出していくのがゴールですが、参加者同士で質問やフィードバックも活発に行い合う場になってます。POとしてOKを出したものはめでたくリリースになります。実際Timersではここに至るまでに途中成果をSlackに共有したり、POに途中経過報告やフィードバックをもらっていたりするので、PO(自分)がスプリントレビューでNGを出すことはほぼゼロです。しかし「今回の成果を出荷するのはOKだけど、xxxの箇所は改善したい。新たにバックログアイテムとして積んでおきます」という事はよくあります。そのようにして継続的な改善のループが回っていく仕組みになっています。

※他の事例では、バザー形式といってテーブルごとにチームが発表を展示して、参加者は見て回る、というのもあるらしいです。

チーム振り返り

スプリントレビューが終わると、2週間の振り返りと次に向けた改善を話し合う「チーム振り返り（チーム・レトロスペクティブ）」の時間です。それぞれのチームで個別に、通常のスクラムで行うのと同じような振り返りを行います。振り返りの手段や内容はまたいくらでも話せてしまうので割愛します。 LeSSならではな点としては、チーム振り返りで「チームの枠を超えてLeSS全体で取り扱うべき議題」を抽出しておき、次の全体振り返りで話す用にとっておく、というところです。

全体振り返り

チーム振り返りの直後に全体振り返りがあります。参加者はそれぞれのチームの代表者とPOです。

ここではチーム個別ではなくLeSS全体を通した振り返りを行います。それぞれのチームで話し合いたい議題を持ち寄り、主にお互いのチームで良かったノウハウの共有やチームの枠を超えて話し合わなければいけない課題を取り扱います。この時間を有効に使うことでチーム同士の連携やチームとPOの連携、さらにチーム同士でのノウハウの伝搬が行われ、LeSS組織全体として強いものになっていきます。

Timersではここは比較的軽量で議題もあまり多くなかったり、事務的な議題（ゴールデンウィーク中のスプリントの動きはどうする？など）になる事が多いです。これは若干課題であり、この全体振り返りをより有効活用して強い組織にする機会を逃してしまっているかもしれないと思うのが正直なところです。

まとめ

以上がLeSSの紹介と、TimersにおけるLeSSでの大規模スクラム開発の概要です。当たり前ですがLeSSはスクラムの上に乗っているフレームワークなので、前提としてスクラム開発がちゃんと出来ないと論外です。Timersのスクラムチームでは全メンバーが非常に強い責任感を主体性を持っており自己組織化されたチームになっているおかげでLeSSもスムーズに回っていると感じています。

しかしLeSSで上手くプロダクト開発を行うにはここで書き切れない細かなノウハウや工夫がたくさんあります。もし興味があればぜひ @amado_tech にご連絡ください。