スクラムチームをLeSSっぽく2分割したらリリース頻度が2倍になった話

時系列データ分析ツール「Node-AI」を開発するスクラムチームは、LeSS（Large-Scale Scrum）を参考にした開発プロセスを採用しました。

本記事では、その背景や数か月試した結果について紹介します！

はじめに

はじめまして、イノベーションセンター Node-AIチームの中野、半澤です。

（中野）Node-AIチームでは2024年4月からスクラムマスターとして活動しております。過去には研究者やデータサイエンティスト、ソフトウェアエンジニアなど幅広くジョブチェンジして今に至ります。

中野将尚 | LinkedIn

（半澤）Node-AIチームでは開発者としてインフラからフロントまで幅広く関わっております。また、チームビルディングの話題も興味があるので、そういった話にちょいちょい首を突っ込んでいます。

我々は「フロントエンドを Vue.js から React にリプレイスしたお話 (前編)」で紹介した開発体制から次のステップに進んで、 LeSSを参考にした開発プロセスを採用し、運用してきました。

結果としてリリース頻度を約2倍にできましたが、そこに至るまでの裏話や新たに出てきた課題などについてシェアしたいと思います。

Node-AIについて

話の本題へ入る前に、Node-AIについて簡単に紹介します。

Node-AIはノーコードで時系列データのAIモデルを作成できるWEBアプリケーションです。

詳しい説明は以前の記事でも説明しているのでそちらをご参照ください。

現在（2024年6月時点）はβ版として公開しており、無料で利用可能です！（一部機能は有料）

フロントエンドのリプレイスを終えて

Node-AIの開発チームは「フロントエンドのリプレイス」という大規模なプロジェクトを完遂するため、約10名のソフトウェアエンジニアを以下2チームに分割しておよそ1年半進めてきました。

プロダクト全体を改善するチーム
リプレイスに集中して取り組むチーム

そして、2023年12月の年末リリースというトラブル発生フラグが立ちまくりのリプレイス作業は何事もなかったようにシームレスに完了し、これまでの技術では実現できなかった洗練されたUXを提供できたことでお客さまからも喜びの声を多数いただきました。

Node-AIチームは一新されたフロントエンドを武器に、さらにプロダクトを成長させていくため、新年一発目のお題として、今後のチーム体制について話し合うことになりました。

チーム分割に対する勘所

Node-AIのスクラムチームは基本的に1チーム体制を採用してきましたが、いくつかの場面で一時的にチームを分割した体制を取っていました。フロントエンドのリプレイスプロジェクトがその一例ですが、他には「SRE的に動くチームとNode-AIの機能開発チーム」で分割したこともあります。

その経験の中で、開発者からは1チーム体制へのネガティブな感情と複数チーム体制に対するポジティブな感情が、振り返りでよく出ていました。 1チーム体制だと人数が多いため、認知負荷やコミュニケーションコストが高く調整ごとやファシリテーションにストレスを感じたり、スプリントプランニングで分割された各タスクの負荷分散がうまくいかず、動きが遅くなるといったことです。

一方、複数チーム体制においては認知負荷やコミュニケーションコストが下がるためタスクに集中できたり、より自分事として捉えられチャレンジもしやすくなることで創造的な取り組みも増えたということが、 Fun Done Learn等の振り返りでも可視化されチームの共通認識となっていました。

この話は以下のようにスクラムガイドにも記載されていることですし、他社さんの事例もたくさんあるので目新しい発見ではありません。

スクラムガイド（2020）

スクラムチームは、敏捷性を維持するための⼗分な⼩ささと、スプリント内で重要な作業を完了するための⼗分な⼤きさがあり、通常は 10 ⼈以下である。⼀般的に⼩さなチームのほうがコミュニケーションがうまく、⽣産性が⾼いことがわかっている

ただ、実際に1チーム体制とチーム分割の体制を両方とも長期間実践することで、 1チーム体制の課題（認知負荷・コミュニケーションコスト・タスクの負荷分散等）をチームが深く認識できていました。

そこで、それら課題の解消を狙いとしてチーム分割を前提に大規模スクラムの各種フレームワーク（LeSS、Scrum@Scale、Nexus等）の理解と議論を進めました。

コンポーネントチームとフィーチャーチーム

Node-AIは多数の技術で構成されており、開発者内でも技術ごとに得手不得手や知識差はあります。

以下に主要な技術要素を挙げます。これに加えて複雑なシステムの品質を担保するためのテスト技術群などQA的なスキルや、時にはカスタマーサクセスチームを支援するコンサルタント的な素養も求められます。

時系列データの機械学習
フロントエンド（React）
バックエンド（Python/C#）
インフラ（パブリッククラウド、Kubernetes）

機械学習については教科書的なことだけでなく、研究開発チームの成果・ノウハウも取り込みます。そのため研究レベルの技術を解釈して実装に落とし込むことも必要になります。

エンジニア約10人を複数のフィーチャーチームに分割した場合、それらのスキルが各チーム内で横断的にカバーできるか、という問いがチームでありました。

結論としてはLeSSの考え方を参考にチームを2つのフィーチャーチームに分割しましたが、公平に分割すると開発速度に大きく影響しそうなものについて、片方のチームに得意なメンバーを固める体制としました。（一部コンポーネントチーム化）

※ LeSSやフィーチャーチーム・コンポーネントチームについて基本的なことは解説しませんので、 Introduction to LeSS - Large Scale Scrum (LeSS) などをご参照ください。

具体的には、新フロントエンド導入で手薄になっていたE2E試験とフロントエンドの結合試験はある程度形になるまで専門性を持ったメンバーを1チームに寄せました。まずは1チーム内でスプリントを進めながらノウハウを共有し、その後もう一方のチームに展開する作戦です。

その他の技術も偏りはありますが、チーム内で完結できる能力をもったメンバー構成となっています。ただ大きめな新機能の設計レベルになると特定の開発者に依存する場合はあるため、完全に分離できているわけではありませんし、お互いのチームメンバー間で密に連携せざるを得ないことはよくあります。

今のところチーム間で積極的に連携することが何か課題になっている感覚はあまりなく、むしろコミュニケーションが活性化し、心理的安全性につながっている気がします。

実際の運用

2チーム体制はLeSSを参考に構成することとしましたが、LeSSの形式やプラクティスを積極的に採用するのではなく必要な部分を少しずつ取り入れる形としました。理由として、1チーム体制時にも継続的に改善に取り組んできた良い面は残したいですし、各種プラクティスを強制しなければならないほどの課題感はなかったためです。

以下はLeSSを参考にした部分です。

プロダクトバックログは1つ
スプリントプランニングは第一部を全体で行い、第二部をチームごとに行う

一方、以下の部分は独自に決めたプロセスです。

デイリースクラムは第一部を全体で行い、第二部をチームごとに行う
振り返り（レトロスペクティブ）は全体で行うことを基本とし、チーム単位で行うかどうかは内容によって決める

LeSSではチームごとのデイリースクラムのみが基本ですが、 Node-AIでは全体のデイリースクラム（内部ではOverall朝会と呼んでいる）を開催することにしました。

LeSSといっても2チームで約10人という世の中の大規模スクラムと比較すればまだ少人数です。全体で予定を合わせることはそこまで大変なことではありません。

Overall朝会では以下のことを実施しています。

今日のイベント、不在者の確認
全体向けに話したいことがあれば共有

両チームは開発問わずさまざまな場面で連携するため、だいたい1日に1議題くらいは話し合っています。事務処理や全体イベント（リファインメント等）の調整ごと、他チームにも共有したいトピックや相談頭出し等さまざまです。

このOverall朝会は15分をタイムボックスとしていますが1分で終わることもあり、たいていは5分以内で終わります。

レトロスペクティブについては全体で話すだけでも十分に効果的な内容もあるため、チーム単位でのレトロスペクティブは任意としました。ただ実際は2回に1回程度の割合でチームごとのレトロスペクティブを実施しています。

スプリントレビューについては臨機応変に調整しています。多くの場合2名以上のステークホルダーにきていただくため、以下の流れになることが多いです。

最初に参加者全員に対してプロダクトオーナー（PO）からプロダクトゴールに向けた状況やレビューの全体像を説明
招待したステークホルダーの数だけ場所を分かれてレビューを実施
- 各ステークホルダー向けにインクリメントのレビューを実施（ファシリテーションは開発者）
- POや開発者はそれぞれのレビュー場所に自由にばらけて議論に参加
最後に全体に対してPOから今後のロードマップ等を共有

※ スプリントレビュー含めて全てのイベントは基本的にリモートで開催しており、NTT ComのコミュニケーションツールNeWorkを使用しています。 NeWorkでは複数の場所に分かれてコミュニケーションしつつ、他の会話にも気軽に参加できるようになっています。

レビュー対象のインクリメントは各チームで内容が異なることもありますが、 1つのスプリントゴールに向けたプロダクトバックログアイテム（PBI）を分担していることもあります。いずれにせよ、事前にレビューのシナリオを2チームで話し合って準備しています。

また、チームごとに分かれてスプリントレビューを実施するということは基本的にありません。他チームのインクリメントに関連する次のPBIは次スプリント以降に自分のチームで対応する可能性があり、そのためにステークホルダーのフィードバックを直接聞く機会は貴重なためです。

また、他の場所で行われたレビューの状況やフィードバックのメモはスプリントレビュー後に全員で眺めながら議論したり、 PBIの種となるペインを抽出する作業も共同で実施しています。

そのようにすることで他チームの開発内容を深く理解することにつながり、「どちらかのチームしか対応できないPBI」が発生しないようにする効果があると考えています。

チームへの愛着

このようにNode-AIの開発は2チーム体制で進めていくことを合意して運用してきました。そこで「せっかくチームを分けたのだからチーム名くらい付けよう」という話があがりました。

実は今まで2チーム体制に分けたときは特にこだわったチーム名を付けておらず、フロントエンドのリプレイス時には「本流チーム」と「リビルドチーム」という何とも味気ない呼び方でした。

新しいチーム名は何か共通の概念で統一したほうがよいとの声が多数だったため、まずはアイデア出しから始め、「お酒の名前」「何らかの記号」などが挙げられ、多数決で「花の名前」で名づけることになりました。

「花言葉」を使って何らかの意味をチーム名に持たせられるということで各チームが議論し、結果として「アザレア」「モモ」という花が選ばれました。

アザレアの花（２） | フリー写真素材 Photo-pot

モモ（桃）の花無料フリー写真素材 (freephoto.sakura.ne.jp)

ちなみにアザレアの花言葉は「節制」「禁酒」「恋の喜び」、モモの花言葉は「私はあなたのとりこ」「天下無敵」「気立ての良さ」「長命」などのようです。

最初は小恥ずかしさもあった名前ですが、今ではお互いのチームを自然に「アザレア」「モモ」と呼ぶようになり、事情を知らない人の前でも普通に言ってしまい微妙な空気になることもあります。

またそれぞれaz（azalea）、mm（momo）という略語も浸透したことでSlack等のチャットコミュニケーションでいちいち「リビルドチームは～」とか書かず「mmは～」と書けるためタイピング時間の節約にも役立っています。

またざっくりアザレアは紫色、モモはピンク色だと思うことにして、タスク管理ツールでもPBI等に色付けをすることで、どちらのチームのタスクなのかが一目でわかるようにもなりました。

チーム名というのはチームへの愛着のわずかな要素ではありますが、最初にやってよかったことの1つだと感じています。

2チーム体制を続けてきて

さて、上記の通り2024年1月から2チーム体制を続けてきました。ここで現状を振り返ると、以下のことがわかりました。

各チームで独立してほとんどのPBIを実施できている
技術的な偏りについてはチーム内/チーム間で少しずつスキトラ（スキルトランスファー）が進んでいるが、まだまだ完全ではない
チームを分割したことによる認知負荷やコミュニケーションコストは軽減されているとともに、チーム間連携に大きな問題は発生していない

1.と2.について、現状でも「この人じゃないと難しい」という技術領域はどうしても存在するため、一部のPBIがチームに依存した形となることはあります。しかし、ほとんどのPBIはどちらのチームでもこなせる状態になっています。

そのためスプリントプランニング時に、どちらのチームでPBIをとるか？でお見合い状態になることもしばしばあります（笑）。たいていそういった場合はチームメンバーのWillでPBIの担当チームが決まります。

また、チームによって扱う技術領域に偏りが出ないように、前スプリントで扱ったPBIと似たPBIが次のスプリントにある場合は、もう一方のチームが担当するといった工夫もしています。その場合は必要に応じて他チームの有識者に教えてもらいながらPBIを進めていくこともあります。（状況によってはもちろん短期的な効率を重視して似たPBIを同じチームで担当することもあります。）

一方で上記に記載している、「この人じゃないと難しい」という技術領域はハイレベルなものや込み入ったものであり、スキトラはなかなか進んでいない状況です。一朝一夕でスキトラできるものではありませんし、各チームメンバーの興味関心のある技術の違い、キャリアプランも影響してくるため難しい問題です。

3.については本記事を執筆している我々も感じていることですし、レトロスペクティブでもチームメンバーの多くから同様の声が挙がりました。チームを分割した狙いの1つである「認知負荷/コミュニケーションコストについての負担の軽減」については効果を得ることができたと感じています。

また、レトロスペクティブにて出た内容を一部紹介します。このレトロスペクティブは2チーム体制になってから3カ月過ぎた4月頭に実施したものです。

◆良かった点（Keep）

リリース頻度が上がった

◆気になる点（Problem）

細かい挙動を把握していない機能が増えた

良かった点として「リリース頻度が上がった」ということが挙がりました。以前は1スプリント（1週間）で原則1回でしたが、最近では1スプリントで2回、3回と複数リリースできることが増えてきました。これはより素早い価値検証を可能にするものとなるため、チーム分割により非常に良い効果が出ていると考えています。

具体的に何が理由で「リリース頻度が上がった」のか、大きく2つあると考えています。

1つめはチーム体制以外の効果によるもので、「リプレイスによってコードを修正しやすくなった」からです。リプレイスによって技術負債が解消して機能追加が容易になり、結果としてリリース頻度の向上に寄与したということになります。

2つめはチームが小さくなったことによる「認知負荷/コミュニケーションコストについての負担の軽減」になります。認知負荷やコミュニケーションコストが軽減することで、実装に集中できる時間が増えたということになります。実際に開発者からのコメントでも「タスクを取る迷いは減った（誰かが取るかも…？という迷いが減った）」という意見が出ています。

それに付随して、ある程度チームごとの判断でリリースができるため、各チームが1～2回リリースできている状態です。

一方、気になる点として「細かい挙動を把握していない機能が増えた」が挙がりました。

具体的には、スプリントレビュー時に初めて他チームのインクリメントを見ることが多く、内容を知らないままスプリントレビューに出てしまうといった問題が出てきました。

これだと他チームのインクリメントに対するフィードバックへの理解が深まらず、関連するPBIが生まれても同じチームが担当する、といったようにタスクがチームに固定された状態が深刻化すると予想されます。

この改善策として、スプリントレビュー前日にお互いのチームでインクリメントのデモをする取り組みを考えました。これにより少なくとも他チームのインクリメントがどういったものか理解して翌日のレビューに臨むことができるようになりました。

まだ取り組みを始めたばかりですが、この取り組みによってよりよいレビューを実施できていると感じています。

以下はレトロスペクティブ時の議論の一部のキャプチャになります。