CastingONEのLeSS(Large Scale Scrum)運用について
これは CastingONE Advent Calendar 2023 15日目の記事です。
はじめに
CastingONEでは、2023年の11月よりプロダクト開発チームを2チームに分割しLeSS(Large Scale Scrum)のフレームワークを使って開発してきましたが、この度12月よりめでたく3チーム体制にスケールさせました。
LeSS運用からちょうどほぼ大体1年という時期でもあるので今回は弊社のLeSS運用方法や運用してみての所感について紹介したいと思います。
LeSS(Large Scale Scrum)概要
LeSSはその名の通り、基本的には通常のスクラムです。
スクラムを何か根本的に改良したみたいなものではなく、スクラムを大きな組織でも適用できるように必要最低限の要素を付け加えた拡張フレームワークです。
簡単なイメージとしては、
-
複数のスクラムチームが存在し、各チームのメンバはチーム内で通常のスクラムを行う
-
各スクラムチームにはチーム代表がそれぞれ存在し、チーム代表、スクラムマスター、プロダクトオーナーのみが参加するチーム横断イベントが以下2つ存在する
スプリントプランニング1: プロダクトバックログアイテムの各チームへの割当を決める
オーバーオールレトロスペクティブ: チーム横断での振り返りを行う
といったイメージです。
通常のスクラムとの差分でいうとスプリントプランニングとレトロスペクティブがそれぞれチーム内とチーム横断の2つに分かれる感じです(各チーム内で行うスプリントプランニングとレトロスペクティブはそれぞれスプリントプランニング2, チームレトロスペクティブという名前で呼ばれます)
全チームのメンバがスクラムイベントとして一堂に会するのはスプリントレビューのみになります。
LeSSの詳細はこちらを御覧ください。https://less.works/less/framework
CastingONE開発チームのLeSS
チーム構成
CastingONEでは所謂プロダクト軸と職種軸でのマトリクス型の組織体制を運用しており、図中の赤枠部分が各スクラムチームに該当します。
各スクラムチームに専属のPdM, Designerが1名とSWEとQAがそれぞれ複数名ずついる構成です。と言いたいんですが、現状Designerが2名なので実態としてはDesignerはチーム横断で動いてもらってたりします。
プロダクトオーナー(PO)は、プロダクト企画部長が担当しており、オーバーオールレトロスペクティブ、リファインメント、スプリントプランニング1に出席しています。
プロダクトバックログ
CastingONEでは開発タスクをEpic,Story,Taskの3つの粒度で管理しています。Epicは1つ以上のStoryを含み、Storyは1つ以上のTaskを含む構造です。
Epic
Epicには複数のユーザストーリをまとめた、機能としてリリースできる単位の1つのまとまりになります。要素としてはその機能全体としての概要や目的と背景、ユースケースなどが含まれます。
リファインメントを行うプロダクトバックログのアイテムは全てEpicの粒度で管理しており、PdM中心に、開発ロードマップから落とした新しい機能や修正を行いたい機能などを、詳細が詰まっていないアイデアの段階でまずは起票します。
起票したEpicは毎週のリファインメントで優先度を入れ替えつつ、PdMのタスクとして優先度の高いものから順に、要求や実現したい価値・機能などをスプリントプランニング2で議論できる粒度まで固めます。
例:
「他システムでexportされたCSVをそのままimportできるようにする」
Story
Storyは基本的には「xxxはyyyできる」の形で記載する、ユーザ目線で可能になる1つのアクションを記載します。
StoryはPdMがEpicの概要を固める段階で切り出す場合もあれば、スプリントプランニング2で詳細要件を詰めながらエンジニアが追加や削除を行うこともあります。
例:
「ユーザは他システムでexportされたCSVの構造を登録することができる」
「ユーザは他システムでexportされたCSVをアップロードすることによりデータを登録できる」
Task
TaskはStoryを実現するために必要な開発タスクを記載します。スプリントプランニング2で詳細要件を詰めながらエンジニアが追加を行い、一旦Taskが出揃った段階でスプリントプランニング2が完了となります。
GithubのPRを出すときには該当するTaskを紐づけます。
例:
「他システムのCSV構造を登録するAPIの実装」
「他システムのCSV構造を登録する画面の実装」
スクラムイベント
CastingONEでは現状1週間スプリントでスクラムを行っています。
図において、青塗りのイベントがチーム単位のイベント、緑塗りのイベントがチーム横断の代表者のみが出席するイベントです。
ご覧のように、デイリースクラム以外のスクラムイベントを全て金曜日に詰め込んで運用しています。
以前はスプリントプランニング2を月曜日に行っていましたが、一応2時間確保しているスプリントプランニング2が、スプリントによっては結構長引くこともあり、1週間のうちがっつり開発に集中できる日が3日しかないのは如何なものかという声がチラホラとレトロなどで上がった結果として今のやり方に変えました。
金曜日はかなりスクラムイベントモリモリで特にチーム代表はほぼ作業できる時間がない日にはなっていますが、スプリントレビューで出たフィードバックや意見について記憶が新鮮なままスプリントプランニング内で会話できたりと付随的なポジティブ面も多く今のところ悪くない感触です。
先述のプロダクトバックログの作り方で触れたリファインメント、スプリントプランニング1,2以外の各イベントで何をやっているか、簡単に書いておきます。
デイリースクラム
デイリースクラムでは各メンバが簡単に昨日やったことと今日やることの共有、困りごとの相談などを行います。
スプリントレビュー
スプリントレビューではスプリントで開発した機能のデモを行い、フィードバックを受けます。
スプリントレビューにはプロダクト開発チーム全員とPO、カスタマーサクセス(CS)部メンバの一部が参加し、機能によっては時間を区切って参加者に該当機能を自由に操作してもらう時間を作ったりもしています。
スプリントレビュー
スプリントレビューではスプリントで開発した機能のデモを行い、フィードバックを受けます。
スプリントレビューにはプロダクト開発チーム全員とPO、カスタマーサクセス部メンバの一部が参加します。
チームレトロスペクティブ
スプリントに関する振り返りを、各メンバが今回のスプリントに関するお気持ちを自由形式で述べる前半30分とKPTを行う後半30分で行っています。
KPTのボードはチームごとに分けて管理しており、チームレトロスペクティブで話す中で開発チーム全体で議論すべきと判断されたトピックに関してはその後のオーバーオールレトロスペクティブに持ち込まれます。
オーバーオールレトロスペクティブ
チーム横断での振り返りを行います。各チームのレトロスペクティブのサマリをチーム代表が共有したり、チームレトロから上がってきた議題について話し合い意思決定を行います。
また、リリーススケジュールの調整などもこのイベント内にて行っています。
ここで話した内容は議事録とは別に終了後すぐにslackの開発用のチャネルで全体共有を行います。
1年運用してみての所感と今後
LeSS導入から1年で、細かい運用をアップデートしてきましたが、LeSSとしてのアップデートというより「振り返りのやり方変えてみよう」とか「バックログの管理方法変えよう」みたいな、どちらかというとLeSSじゃない単体のスクラムでも多分同じようなアップデート入れてただろうなという感じの、そもそもスクラムの時代からモヤモヤしていたものや新しいメンバが来てくれて今までチーム内になかったアイデアを出してくれたという類のアップデートが多く行われてきたかなぁという印象です。
逆にいうとLeSS自体はスクラムで開発していたチームならあまり困ることなくすんなり導入できる良いフレームワークだったかな思っています。
今回12月より3チーム体制に移行しましたが、実は5月くらいの時点ですでに1チーム10名を超えてしまっており3チーム体制に移行したいよねという話はずっとしていました。PdMが足りないなどの問題により延期されていたものが漸く実現したという形です。各チーム、以前にも増して自分たちのチームを強くしようという動きだったりプロダクトに対する議論が活発化しているので、改めてチームをコンパクトに保つのは大事だなという所感です。
LeSSには8チームを超えると適しているとされる更に拡張フレームワークであるLeSS Hugeというものが存在します。これは全チームを事業ドメインに応じたエリアという概念にグループ化し、エリアプロダクトオーナー(APO)とエリアプロダクトバックログ(APB)を追加してスケールさせる手法です。
CastingONEのLeSSまだ3チーム体制ですが、プロダクトのロードマップを鑑みると直近でLeSS Hugeに移行したほうが効率が良さそうと考え始めています。また移行したら何か書こうと思います。
最後に
CastingONEではスクラムなどの開発手法も自らアップデートしつつ最高のプロダクトを作っていく仲間を多職種募集中です!興味がある方は気軽にご連絡ください!
Discussion