組織全体の改善サイクルが回っておらず、スピード感もない　LeSSにおける“複数チームが関わる部分がうまくいかない”問題への対応

迫氏の自己紹介

迫康晃氏：それでは「大規模スクラムにおけるコミュニケーション課題への対応」というタイトルで発表します。まず今日の話のまとめですが、「やりたいこととイベントの目的を整理しよう」ということと「意思決定と共有フローを決めよう」というのがテーマです。

ということで自己紹介です。SmartHRで基本機能のシニアマネージャーをしている迫と申します。3年ほど前にバックエンドのエンジニアとして入社をして、プレイングマネージャー、マネージャーを経て、2023年10月から現職で働いています。最近ハマっているのは『葬送のフリーレン』とダンベルプレスです。よろしくお願いします。

まずは会社の紹介です。SmartHRという会社は、「SmartHR」というプロダクトを作っていて、大きく3つの領域の機能を備えています。

1つ目は労務管理で、これまで紙で行ってきた労務のやり取りをオンライン化するという機能です。2つ目は人事データベースの機能で、入社手続きなどで溜まった従業員の情報を一元管理できます。あとはタレントマネジメントの機能で、溜まった従業員情報を基に情報を可視化したり、人員配置を考えたりといった機能も提供しています。

（スライドを示して）細かい機能はこういったものを備えています。

「SmartHR」の基本構成

システム構成としては、図のようになっています。左のSmartHRの基本機能に従業員データや企業のデータが入っていて、APIを使って右のオプション機能が必要な情報を取ってきて、それぞれの環境で扱っているという構成です。今日は基本機能の話をします。

基本機能の役割ですが、電子申請とか従業員のデータ管理、部署とかマスターデータの管理です。申請・承認の機能とか入社手続きとか、いろいろな機能がいっぱいあります。

基本機能はリリース時からずっと積み上げてきた多くの機能がある、モノリシックなRailsアプリケーションになっています。これらを今7チームで開発しています。

スクラムの拡張フレームワークを使った開発

「7チームでどうやってやっているんですか？」という話ですが、Large-Scale Scrum（LeSS）というスクラムの拡張フレームワークを使って開発しています。

（スライドを示して）簡単にスクラムとLeSSの違いを紹介しておくと、スクラムでは以下の5つのスクラムイベントを行っています。

LeSSはその5つに加えて、複数チームで進めるためのスクラムイベントがいくつか存在します。

スプリントプランニング1で全体のプランニングを行って、プランニング2で各チームでプランニングを行います。PBR（Product Backlog Refinement）は3つに分かれていて、オーバーオールPBRと複数チームPBRが複数チームで行うイベントになります。レトロスペクティブも、チームで行うものと全体で行うものがそれぞれあるかたちです。

先に言っておくと、今回イベントとして見直しを行ったのは、この2つ（オレンジ色のもの）についてです。

LeSSをやってみてうまくいっていること・うまくいっていないこと

LeSSをしばらくやってみて、うまくいっていることと、いないことを振り返ると、うまくいっていることとしては、各チームでのスクラム開発というところで、スクラムイベントを実施してデリバリーをするというところは問題なくできています。

また、プロダクトに対するロードマップの決定であったり、開発アイテムに対する優先順位の決定なども問題なくできています。あとは、7チームで開発していてもハチャメチャになっていないという点もあります。

1つのリポジトリを複数のチームで開発するのはけっこう大変なんですが、なんとかこれまでやってこられているという点では、うまくいっているのかなと思っています。

逆にうまくいっていないこととして、以下の2点を感じていました。1つが、組織全体に対しての改善サイクルが回っていないというところと、全体にスピード感がない、もっと早くしたいなというのがありました。

あらためて見てみると、個別のチームで見るとうまくいっているんですが、複数チームが関わる部分がうまくいってなさそうに感じました。

全体に対する現状理解から見えている課題感

全体に対する現状理解しようということで、まずは、複数チームでやっているオーバーオールPBRから見ていくと、今7チーム全員で行っていて、やっていることとしては、PBI（Product Backlog Item）の振り分けとかロードマップの共有、あとは各チームの開発状況や個別で行っているプロジェクトの共有、人事情報とか異動の情報、対応依頼といった全体向けのお知らせやお願いの共有もやっています。

オーバーオールレトロスペクティブも7チーム全員で行っていて、やっていることとしては、各チームのレトロスペクティブで行ったふりかえり内容の共有と、各チームで行っている取り組みの中で、ほかのチームでも参考にできる良い取り組みの共有とか。あとはグループ全体のProblemを話してTryを決めることもやっています。

スプリントプランニング1は7チーム全員で行っていて、各チームのPBIをスプリングバックログに入れることと修正箇所の共有ということで、1つのリポジトリを複数のチームで触るので、「次のスプリントではこのあたりのコードを触るので、同じ箇所を触る人は教えてください」といったようなコミュニケーションを事前に取ることで、無駄なコンフリクトを回避するようなことをしています。

見えている課題感として、LeSSのイベントとしてやることと、組織としてやることが混ざっているという点。あと、扱う課題の内容とか優先順位が定まっておらず、大小なんでも話してしまっている。あとは、人数の増加に対してアップデートがされておらず、議論と共有のコストが高いといった課題感がありました。

なぜこういうふうになってしまったのか？

「なぜこういうふうになってしまったのか？」というところですが、これまでLeSSのチームの変遷を見てくると、2020年1月から2チームでスタートしていて、2021年で4チーム、2022年で6チーム、2023年で7チームとチームが増えてきました。

スクラムイベントに対してマイナーチェンジは行ってきたものの、やり方は大きく変わっていないです。必要なことを足していった結果、今に至ります。

また、過去にオーバーオールレトロスペクティブを代表者制にしたこともあるんですが、そうすると代表者がチームのリーダーのような期待値になってしまって良くないというようなことがあったり。

あとは、扱うトピックに対してステークホルダーが参加していなくて議論ができないとか、決まったことがチームに共有がうまくされていなくて問題が起きたこともあって、過去に1度元に戻した経緯もあります。

行ってきた対応

とはいえ、なんとかしようということで……。ここからが行ってきた対応ということで、諸々を整理していきます。

まずは各スクラムイベントでやりたいことを見ていくと、PBRでは、開発するものに対して扱いたいです。とはいえ、全体でアナウンスをしないといけないというものもあるので、そういったものは周知したいです。

レトロスペクティブでは、プロセスの議論について注力したいですが、とはいえ、大きな課題も優先順位をつけて解決していきたいです。プランニングでは、次のスプリントの計画をやりたいということで、これは達成できていそうかなと思います。

次に、各イベントの目的を整理していきます。オーバーオールPBRでは、ロードマップの共有、検討中／今後予定している開発に対する共有、あとはPBIの振り分けを目的にしました。

オーバーオールレトロでは、全体や複数チームのプロセスに関わる方針の議論、決定というのを目的にしています。

扱っている課題と意思決定も整理していきます。スプリント内の複数チームに関わる課題については、オーバーオールレトロスペクティブで話すものなので、LeSSのメンバーで扱います。

ただ、やはり大人数で議論はできないので、議論しやすいように参加者を絞ります。チームから1、2名の代表者を当番制で参加するように変更しつつ、気になるトピックがある人は参加OKとしています。イベントの前に事前にトピックを挙げてもらって、興味のある方、もしくはステークホルダーとして参加してほしい方には声掛けをすることも行っています。

扱っている課題と意思決定の整理というところで、組織全体の大きな課題もありますが、こちらについては中長期的な課題が多いため、少人数で扱うようにしました。これはPOとマネージャーと、扱うトピックによってはステークホルダーも入れて話していきます。レトロスペクティブでは扱わないテーマのため、別途、戦略検討会というかたちで別の機会を設けました。

最後に、話したこと・決まったことの共有方法ですが、オーバーオールレトロスペクティブで話した結果については、参加者がそれぞれチームに持ち帰って、各チームの中で共有してもらっています。多くのチームでは、次のデイリースクラムで共有してもらっています。

中長期の課題への方針や人事情報などのアナウンス系については、もともとオーバーオールPBRで行っていたんですが、これをオーバーオールPBRと共有会というかたちで分離をして、分離するだけではなく、共有内容にメリハリをつけるために、冒頭5分を読み込みタイムとして、質問を募ってまとめて回答するというようなスタイル。プラスで、特に重要なものについては口頭で共有を行い補足をするようなスタイルでやっています。

この方法は社内の別のミーティングでも行っていて、内容のインプットに集中できたり、話されているものに対して突発的に質問を考えなくて良いというのがメリットです。

改善されたポイントと、残っている課題

（スライドを示して）最終的に行ったアクションをまとめると、このようなかたちになりました。

改善されたポイントとしては、大小それぞれの課題について議論がしやすくなったというところと、共有内容にメリハリがついて、会議体がスリム化されました。あとは、重要な共有内容が周知されやすくなったというところと、諸々整理されたことによって、開発時間が捻出されたというところにもつながっています。

ただ、残っている課題として、今回行った改善は言わば対症療法的なものになるので、改善はしたものの、依然コミュニケーションコストは大きいという課題があります。

可能な限りチーム間のコミュニケーションコストが少ないことが理想ではありますが、これまで創業してから積み上げてきた機能の拡大に伴って組織を肥大化させてきたというところもあるので、これが根本の原因なのかなと考えています。なので現在は組織構造と併せて、アーキテクチャ全体の見直しも進めています。

ということで、発表は以上になります。大規模な開発に興味のある方、アーキテクチャの見直しに興味のある方、大募集中です。ご清聴ありがとうございました。