Large-Scale Scrum（LeSS）体験記 - BASEプロダクトチームブログ

この記事は、BASE Advent Calendar 2022 18日目の記事です。今日担当するのはバックエンドエンジニアの cureseven です。

2022、チャレンジし続けたスクラム

phpcon沖縄2022のスポンサーセッションで、「Gather × Code With Me × ペアプロのお誘いで最高です」という発表をさせていただきました。本記事は後日談のような内容です。どのように開発を進めているのかの補足として発表資料を見ていただけると良いと思います。また、アドベントカレンダー9日目では私たちのチームがどんな雰囲気のチームかを覗くことができます。合わせてご覧ください。 https://devblog.thebase.in/entry/2022/12/09/110000

さて、私のチームは、phpcon沖縄2022発表当時のプロジェクトを終え、新しい機能開発に着手し始めました。今回のプロジェクトは開発規模も大きいため、以前とは違い2チーム合同でのプロジェクトになっています。登壇時うまくいっていたことも2チーム合同となるとうまくいかないことも多く、その中でチャレンジしていることについて触れたいと思います。

2チーム合同になり問題になったこと

コミュニケーションコストが増えた

1チームは5-6人で構成されているのですが、2チーム合同となるとAmazonでいうところのピザ2枚ルールには当てはまらなくなってきたと感じました。人数としてはピザ2枚の範囲内かもしれませんが、開発してきた背景の違う2チームが合流したので人数関係なくコミュニケーションコストが発生するようになりました。 2チーム全体で合意・意思決定を行うことは、小さいチームより時間がかかります。さまざまな意見が出て良いこともある反面、スクラムのスピード感にはマッチしないと感じました。

作業内容が被り、コンフリクトが発生した

仕様が定まっていないところから始まったプロジェクトでした。その段階でリファインメントし、開発にちょっとずつ着手していこうという状態で、作業できる箇所が小さかったのでコードもストーリーも近しいものに着手することになってしまいました。作業を並列化するのも難しく、コードのコンフリクトも起こりました。

コーディングルールが2チーム間で異なり、レビューが前に進まなくなった

これまで積んできた経験が異なる2チームが同時にレビューすることで、設計思想のすり合わせのコストがかかるようになりました。

工夫していること

私たちのスクラムは、1チームでのスクラムを無理やり拡張させたものではなく、2チーム合同でLarge-Scale Scrum(LeSS)だと改めて認識できました。大規模スクラムのエッセンスを取り入れながら、経験を元に作業効率を上げるための取り組み（プラクティス）を行っています。

チームごとに、全く違うテーマに取り組む

現状はプロジェクトのプロダクトバックログにラベリングし、各ラベリングされたセクションごとに作業チームが別れている状態です。プロジェクトとして一番優先して作りたい機能はあるものの、複数チーム合同で着手すると時間がかかったという経験から、次の優先度のラベルの機能開発に着手することで全体としての作業効率が上がってきています。お互いのチームを信頼して任せられるようになりました。ラベリングの1つとして、フロントエンドが先行してUI実装していくものがあります。このおかげで、課題の発見を早めることができています。また、バックエンドが着手するタイミングで機能要件が明瞭な状態にしておくこともできます。

トラベラーやってみた

LeSSのエッセンスとして、トラベラーというものがあります。 https://less.works/jp/less/framework/coordination-and-integration 開発経験・知識がある人がチームを跨いでアイテムに取り組んだり意見を言う役割を負う人のことです。私は１スプリントだけトラベラーに挑戦してみたのですが、タスクの引き継ぎに有効でした。また、作業メンバーが両チーム奇数人だった場合、トラベラーを一人派遣することで偶数人ずつになりペアプロのレーンが増えると言う副作用も享受できました。デイリースクラムでは、トラベラーを行っている期間自分のチームへのコミットが薄くなった場合、議論に参加しにくくなってしまいました。その時はトラベル先のチームのデイリーにのみ参加するのが良いかなと思いました。今は、アプリケーションにおけるクラス設計の意思決定をする有志チームがあり、継続してトラベラーのような役割を果たしてくれています。

作業に集中できる時間を少しでも多くする

2チーム合同でプロジェクトを進めていくために、チーム合同での振り返りとトライを決める「オーバーオールレトロスペクティブ」、プロジェクトとして何を達成したいかをすり合わせる「オーバーオールプロダクトバックログリファインメント」が各スプリントにセットされていますが、エンジニアの参加者は各チームランダムな代表者数名としています。決まったことはデイリースクラムやslackで非同期に共有、気になったら閲覧できるようなミーティングの録画を共有しておくことで対応しています。 2チーム合同になったことで増えがちなミーティング時間も、慣れてきた段階で代表者制にすることで節約できるようになっていきました。

最後に

2022では、BASE全体としてスクラムの導入が積極的に行われていくようになってきました。スクラムは、経験を大事にします。ナレッジを共有しながら、チームに合わせたスクラムの在り方を模索していきたいです。まだまだ生産性を上げていきたいので、デイリースクラムやレトロスペクティブで議論していきたいです。