こんにちわ！
エンジニアリングマネージャーのkobaanです。
本日はアドベントカレンダー4日目です、皆さんはそろそろクリスマスケーキの予約終わりました？今年はケーキにチキンではなく、お寿司で和風に祝いたいなと思っています。
前回はScrumチームを分割したときの話をしましたが、LeSSを採用した経緯とLeSSってなんだと言うのをお話できればと思います。
複数のスクラムチームをうまく回す
これ、スクラムに限らず、複数チームを運営することは経験上めちゃくちゃ難易度高いと思っています。
理由としては一つでチーム間の調整です。
特にフィーチャーチームであり続けようとすると、調整ごとからは逃げることができません。
調整ポイント
- プロダクトバックログ
- 各ストーリーの仕様
- 実装中のコード
- 機能品質
- リリースの依存関係
個別のチームであればこれらを密に連携させ続ける必要があります。
特にワンプロダクトのテックタッチでは案件の独立性が高いように見えても、調整の必要性が高かったりします。
制約
当時大きな制約としてリソース制約がありました。
- POが１人しかいない
- SMが１人しかいない
今は採用を徐々に進められたことで、多少解消されていますが当時はすぐに解消できそうになかったので制約としておいていました。
大規模スクラムの検討
当時私はScrum of Scrumしか知らなかったのですが、よくよく調べてみると様々な種類のスケール方法があることがわかりました。
それを下記表にざっとまとめてみました。正直なところ、実際に経験のあるプロセスは少ないので、間違ってたらSNSなどで教えていただけると幸いです。
| 種類 | 正式名称 | 公式サイト | 役割追加 | 適正規模（私見） | PO/SMの兼任前提 | 書籍 |
|---|---|---|---|---|---|---|
| SAFe | Scaled Agile Framework | https://scaledagile.com/ | ありEO,EAなど９種 | 大規模・エンタープライズ | なし | ○ありAmazon |
| Scrum of Scrum | 同左 | 見つけられず | なし | 小〜中規模 | なし | △あり？専門書はなさそう。 |
| DAD | Disciplined Agile Delivery | https://www.pmi.org/disciplined-agile | ありDE,TEなど５〜６種 | 中規模 | なし | 見つけられず |
| LeSS | Large-Scale Scrum | https://less.works/ | なし（Huge-LeSSで１種追加） | 中規模 | あり | ○ありAmazon |
| Scrum @ Scale | 同左 | https://www.scrumatscale.com/ | ありSMMなど２種 | 中規模〜大規模 | なし | みつけられず |
LeSSが良かったポイント
- 役割追加がなくインストールコストが最小化できそうだった
- 規模感的にもちょうどよい
- PO/SMが複数チームで兼任前提になっている
- POはむしろ１人であることを前提にしている
- リソース制約に対してすごくちょうどよい
- 書籍もある
- さらに、他社でも近しい規模の企業でも利用されていて、参考にできる物が多く検討時点でもかなり助けられました。
LeSSで変わること・変わらないこと
参考：https://less.works/jp/less/framework
■変わること
- 下記のイベントが追加
- スプリントプランニング１
- オーバーオールレトロスペクティブ
- SM・POが兼任になったため一部のスクラムイベントでSM・POが不在
- 調整ごとがチーム内からチーム間に
■変わらなかったこと
- 分割前と同じく、プロダクトバックログは一つのまま
- ワンチームスクラム時代のイベントはほぼそのまま
今から思う、LeSSに求められる資質
①開発者のプロセス熟達
PO・SMが複数チーム兼任となるため、一つのチームにかけられる時間とリソースが必然的に減少することになります。つまり、開発者のみで運営したり、判断したりすることが増えるため、プロセスに対して熟達していくことが必要となります。
②スクラムマスターのアジャイルコーチ力
開発者の熟達のためにも、スクラムマスターはプロセスの守護者からコーチへ変容していく必要がありました。 そのためにも、自律的に運営するためのイベントの細かな運営方針のドキュメント整理や各チームにおけるミッションの明文化やデリゲーションを通じて、SMの関与度を下げていきました。 そのおかげか、半年たった今では道半ばではあるものの、少しづつ開発者でもしっかり進められる素地ができたかなと思っています。
③ボトルネックにならないPO戦略
POはLeSSにおいてもっともしんどいロールと言われていますが、今回のチーム分割においても変化がありました。 特にスプリントプランニング１とオーバーオールレトロスペクティブ以外の複数のスクラムイベントにPOは出席を原則しないため
- ユーザーストーリーやタスクを要点をシンプルにまとめる
- 詳細へあえて踏み込まず、開発者（エンジニアやデザイナー）に移譲できる部分は移譲する
- スクラムチームが優先度に迷いにくいようなスプリントバックログの優先度確認やスプリントゴール設計
上記のように役割分担をより意識することでボトルネックの回避ができたかなと考えています。
Ready to scale !
チーム分割を経て、LeSSというフレームワークを装着することができました。 理論上は８チームまでは行ける（目算では４チームくらいまではなんとか行けるのでは・・・）と思っているのでスケールできる準備はできたと思っています。 先述したとおり、POやSMの採用も進んできているため、APO（Area Product Owner）を導入したHuge-LeSSの採用や、各チームにSMを配置した上でプロセス改善のチャレンジを増やすなどを進めていきたいなと考えています。 もっといい感じのプロセスについて教えていただける方はもちろん、よりスケールするためにをディスカッションしたい方もぜひカジュアル面談にお越しください！ 色々とお話しましょう！
