この記事は 株式会社カオナビ Advent Calendar 2023 7日目です。
はじめに
本記事では、1つのスクラムチームをスケールさせるのに LeSS を導入した取り組みの現在地点をお伝えできればと思います。
よりよい方法や間違った認識をしている箇所などございましたら、アドバイスいただけると光栄です。
また、本記事ではスクラムや LeSS の考え方やり方などについては詳しく触れません。
詳しい情報を知りたい方は、下記をご参照ください。
チームをスケールしたかった背景
私の所属するチームは「フィーチャーチーム」と呼ばれるような、ユーザーに価値を届け続けるために機能開発を行うチームです。
チームの人数構成としては、以下の8名で構成されていました。
- PO: 1名
- デザイナー: 1名
- バックエンドエンジニア: 3名
- フロントエンドエンジニア: 2名
- QC: 1名
安定した価値提供を行えるような良いチームでしたが、下記のような課題を抱えていました。
- 価値提供を行うのに、毎回同じ他チームとの連携が必要
- 連携先の機能について、関係性が深いのにあまりよく知らない
つまり、「ユーザーにとって一連した動作になりやすい2つの機能を、別々の2チームで運用していた」という状態でした。（※下記画像のようなイメージ）
この課題を解消するために、この2つのチームを合併して、1つの大きなチームにしようという事になったわけです。
LeSS(Large Scale Scrum)とは
そうして、チームをスケールさせるのに LeSS を導入するに至ったわけですが、前提として LeSS とは何か簡単にご紹介します。
LeSSは、1つのプロダクトを複数チームで協働するために考えられたスクラムです。
LeSSはスクラムの原理・原則、目的、要素、洗練された状態を大規模な状況にできるだけシンプルに適用したものです。
このように「スクラムをシンプルに適用し、拡張したもの」と表現されますが、スクラムと同様に1つのプロダクトバックログに全員で取り組み、各種イベントも実施します。
LeSS がスクラムと異なるのは、複数の開発チームが同期し仕事をするためのイベント（例： オーバーオールレトロスペクティブ）が増える点です。
LeSSをなぜ導入したのか
スクラムをスケーリングするためのフレームワークには、LeSS以外にもいくつか存在します。
代表的なものとして、下記のようなものが挙げられます。
こうした他のフレームワークではなく、LeSSを導入したのは、LeSSが「スクラムをそのまま拡張したシンプルなフレームワークである」ためです。
私たちのチームでは、スケール後に以下のような構成になることが想定されました。
- PO: 1名
- デザイナー: 1名
- バックエンドエンジニア: 4名
- フロントエンドエンジニア: 4名
- QC: 2名
このままでは、1つのスクラムチームとしては人数が多いため、チームを2つに分けようと考えました。
その際、チームの分け方としては、下記のようなイメージになります。
S@S や SAFe の場合、各チームに PO を置き、それを統括するような PO が横断してチームを見るなど、PO 自体もスケールさせていくような考え方を持っており、現在のチームにとっては少し過剰に見えます。
一方、LeSS の場合、1人の PO と 1つのプロダクトバックログを複数のチームで見るようなシンプルな構成になっていて、私たちのチームで取り入れるのにぴったりなのではないかと考え、導入することに決めました。
LeSS導入してからの変化と課題
現在は、LeSSを導入して3ヶ月が経過しました。
まだまだ導入して日は浅いですが、チームでは以下のようなことが課題として出てきています。
- POの手が回らなくなった
- チームで独自の進化を遂げるようになってきた
- プロダクトバックログが1つにならない
1. POの手が回らなくなった
今まで1つのスクラムチームで行っていた業務を、2つのチームにしても同様に1人で行うので、当然 PO にかかる負担が大きくなり、だんだんと手が回らなくなってしまいました。
そこで PO の業務のうち、いくつかの業務をチームメンバーで行うようにしました。
チームに PO の業務を権限委譲する中で、最も効果的だったのが「プロダクトバックログアイテムの受入条件を QC が中心となって記載する」ことです。
QC を中心に受入条件の記載を行うことで、以下のようなメリットがありました。
- PO の確認がなくてもチケットを完了出来るようになった
- QC が早い段階で仕様を把握出来るようになった
- 受入条件を書くことでテスト分析を先に行えるようになり、テスト設計の時間を短縮できた
- 受入条件がテスト観点に沿っていて見やすくなった
しかし、依然として PO にかかる負荷は大きい状態です。
現在は下記のブログ記事にあるような「チームPO制」の導入を検討するなど、引き続き模索しながら改善を続けていきます。
2. チームで独自の進化を遂げるようになってきた
具体的には、下記のようなことが起こっています。
- DoD がチームによって異なっている
- 個別の Working Agreement が作られている（もちろん共通なものもある）
- 片方のチームだけ、受入条件の記載をQCが行うようになった
これらは各チームが歩んできた歴史や、在籍するメンバーの特性によるところもありますが、チーム間でのコラポレーション不足 が原因であると考えています。
そこで、チームリードをしているメンバーで定期的に話す時間を設けることで、改善を図ろうとしています。
しかし、チーム間でのコラボレーションをする時の理想としては「ただ話す」という下記のような状態であると思っています。
(1) あなたは、チームBとの "調整が必要" なことに気づきます。
(2) 立ち上がって、
(3) チームBのところに歩いて行き、
(4) 「やぁ、話し合おうよ！」と言います。この一連を私たちは "ただ話す" とよんでいます。
とはいえ、現在は「チームBとの”調整が必要”なことに気づく」というところがハードルになっているので、まずは定期的に集まる場を設けて話すような実験をしてみようと思っています。
3. プロダクトバックログが1つにならない
LeSSでは、以下のようなルールが存在します。
出荷可能なプロダクト全体に対して、プロダクトバックログは1つ（そして1人のプロダクトオーナー）です。
私たちのチームでは、プロダクトバックログの管理をするのに Jira を使っていますが、未だに2つのプロジェクトに別れて運用してしまっています。
つまり、プロダクトバックログが2つある 状態になっています。
この原因は、先程挙げた 2. チームで独自の進化を遂げるようになってきた ことだと考えています。
チームで独自の進化を遂げている
→開発フローが一致しない
→Jira上で独自進化した自動化がコンフリクトしてしまっている
→１つのJira上でプロダクトバックログの管理ができない
という、悪循環に陥ってしまっているのです。
そのため、まずは 2. チームで独自の進化を遂げるようになってきた の改善に注力していこうと考えています。
まとめ
いかがでしたでしょうか？
チームをスケールさせるのに LeSS を導入した際、3ヶ月間でどんなことが起こったのかについてお話させていただきました。
今回は課題の側面ばかりを触れてきましたが、私たちのチームは非常に強い責任感と主体性を持っているメンバーが多く集まっており、いいところもたくさんあると思っています。
今後も様々な実験を通して着実に改善を積み重ねることで、理想とするチームに近づけるようにしていきたいと考えています。
We Are Hiring
株式会社カオナビでは一緒に働く仲間を募集しています。カジュアル面談も行っていますので、ご興味がある方は気軽にお声がけください。