こんにちは、プロダクトエンジニアの宮園です。
労務コア開発1部に所属しています。
本記事では、労務コア開発1部でLeSS（Large-Scale Scrum）をやめた話についてシェアします。
LeSSをやめるに至った背景と移行手順について説明します。
LeSS（Large-Scale Scrum）とは
LeSSとは、1つのプロダクトを複数チームで協働するために考えられたスクラムです。
スクラムが重視していることをそのままに、大規模な状況向けにシンプルに拡張したものです。
通常のスクラムの各種イベントに加え、複数チーム合同で実施するイベントがあります。
- 全体スプリントプランニング
- オーバーオールPBR（プロダクトバックログリファインメント）
- オーバーオールレトロスペクティブ
LeSSをやっていた背景
労務コア開発1部では「基本機能」というプロダクトを開発しています。
「基本機能」はSmartHR最古にして最大のプロダクトで、開発には人数が必要でした。
ただ、1チームの人数には上限があり、スクラムガイドには最大10人と書かれています。
10人以上が必要だったため、複数のチームを作ることになりました。
そして「1つのプロダクトを複数チームで触る」選択をしました。
そんな状況でも崩壊しないための知見を求めた結果、LeSSを採用することになりました。
直近の労務コア開発1部では、3チームでLeSSをやっていました。
労務コア開発1部のLeSS運用
労務コア開発1部の開発アイテムには、大きく2種類があります。
- フィーチャー（大型の機能開発）
- フィーチャー以外（比較的、小型の機能開発）
スプリントでは、フィーチャーを中心に開発しています。
大体の比率は、フィーチャーが8割・フィーチャー以外が2割となっています。
フィーチャーの運用
フィーチャーは、各チームへ事前にアサインしています。
本来LeSSにおいては、開発アイテムをチームへ事前に割り当てることを（できるだけ）避けます。
事前に割り当てると、アジリティと学習を減らし、特定のチームへの依存が増すためです。
ただし、プロダクトの成長に伴って関心領域が広がっていく中で、引き継ぎやリファインメントのコストが高くなりすぎました。
そこで、費用対効果を踏まえて、各チームへ事前にアサインするようになりました。
フィーチャー以外の運用
フィーチャー以外は、オーバーオールPBRでチーム間での調整を行っています。
労務コア開発1部のLeSS運用の課題
前述したLeSSを運用する中で、以下の課題に直面しました。
- オーバーオール系イベントの効果が限定的
- LeSSは現状のチーム体制には過剰である可能性
- 確保できる作業時間が不十分
オーバーオール系イベントの効果が限定的
フィーチャーについては、それぞれ各チームが独立して開発を担当しています。
そのため、各チームが担当するフィーチャー開発については、チーム間の連携は限定的でした。
オーバーオール系イベントでは、フィーチャー開発に関するチーム間の調整はほとんど発生していませんでした。
LeSSは現状のチーム体制には過剰である可能性
フィーチャーについては、チーム間での協業や調整が必要になることは多くありません。
フィーチャー以外など、チーム間の協業や調整が必要な場合には、個別のミーティングやSlackによるコミュニケーションで適切に対応できていました。
したがって、比較的規模の大きなフレームワークであるLeSSは、現状のチーム体制には過剰である可能性がありました。
確保できる作業時間が不十分
SmartHR では、様々な会議が開催されています。
その結果、十分な作業時間を確保することが難しい状況でした。
そんなとき、VP of Engineeringから技術統括本部2025年スローガンの中で、注力ポイントの1つとして「作業時間の確保」が掲げられました。
これにより、会議のある日をまとめたり時間の削減が求められました。
そこでオーバーオール系イベントも見直しの対象になりました。
実験「思い切ってLeSSをやめてみる」
前述の課題を解決するために、思い切ってLeSSをやめることにしました。
各チームの担当する開発は独立性が高く、チーム間の連携や調整を必要とする場面は限定的になっていたためです。
そのため、LeSSが本来持つチーム間の協調や調整を促進する仕組みを十分に活かすことが難しい状況となっていました。
LeSSをやめることに対して事前の大きな懸念はなく、むしろ作業時間の確保や開発効率の向上への期待が高まっていました。
そのため、「実験」と位置づけ、一定期間試行した後にその結果をふりかえることにしました。
「実験」では具体的に、以下の3点を変更しました。
- 各チームの代表者による移行推進
- オーバーオール系イベントの廃止
- フィーチャー以外の開発アイテム調整の非同期化
各チームの代表者による移行推進
移行を円滑に進めるため、各チームから1名の代表者を選出しました。
選出された代表者たちで定例会議を実施し、各チームの総意を集約しました。
定例会議では、LeSSをやめる手順や準備について話し合いました。
オーバーオール系イベントの廃止
オーバーオール系イベントを廃止しました。
- 全体スプリントプランニング
- オーバーオールPBR（プロダクトバックログリファインメント）
- オーバーオールレトロスペクティブ
この変更により、木曜日に実施していたチームスプリントプランニングを、水曜日に前倒して実施できるようになりました。
フィーチャー以外の開発アイテム調整の非同期化
オーバーオールPBRの廃止に伴い、Slackによる非同期コミュニケーションでの調整に変更しました。
調整のキッカケを作るため、毎週Slackのリマインダー機能により自動でスレッドを立てています。
実験のふりかえり
およそ2ヶ月間の実験期間を経て、ふりかえりを行いました。
LeSSをやめることに対して大きな懸念はなく、むしろ好影響の方が大きい結果となりました。
よって、継続してLeSSをやめる結論に至りました。
ふりかえり手順
以下の手順で実施しました。
- 全員を対象に、実験に関するふりかえりアンケート
- 各チームごとに、アンケート結果を見ながら実験のふりかえり
- 各チームの代表者で、各チームのふりかえり結果を集計
ふりかえり結果と今後の展望
LeSSをやめたことで、以前よりも自然な開発サイクルになりました。
各チームの独立性が高い状況で、オーバーオール系イベントに費やしていた時間が削減されました。
その結果、開発チーム全体として実装に集中できる時間が増加しました。
一方で、チーム間の偶発的な情報交換や連携の機会は減少しました。
各チームが一同に会する機会が減少したため、必然とも言えます。
ただ現時点では、必要に応じて各チームが主体的にコミュニケーションを取れており、特に問題は発生していません。
しかし今後はより意識的に、チーム間の情報交換や連携を促進するための仕組みを検討していきたいと考えています。
また、スプリントレビューは全チーム合同での実施を継続しています。
各チーム別々に実施すると、ステークホルダーの参加コストが高まるなどの理由によるものです。
最適な状態とは言えないため、こちらも改善を検討していきたいと考えています。
まとめ
組織やプロダクトの状況によっては、LeSSのメリットが薄れてくることもあるかと思います。
もし、現在の開発体制が合わないと感じているのであれば、思い切って変更を検討しても良いかもしれません。
今回、LeSSから各チームでのスクラムへの移行は、まさに経験主義に基づいた「実験」として実施しました。
合わなければ元の体制に戻せるようにしておくと、安心して試すことができると思います。
We Are Hiring!
SmartHR では一緒に働く仲間を募集中です！
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
