大規模スクラム LeSS の各スクラムチームに「チームPO制」を導入してみた

こんにちは！株式会社スタメン/TUNAG事業部プロダクト開発部の手嶋/西川/若園です。弊社のプロダクト部では2022年から大規模スクラム LeSS(以下: LeSS)を導入しています。

その中で私たち3人は、チームプロダクトオーナー(以下：チームPOと呼ぶ)という通常ではLeSSに定義されていない役割を担って様々なことにチャレンジしてきました。

今回のブログでは、実際にチームPOとしてどのように活動をしてきたのかを紹介しながら、チームPOがスクラムにいるメリットや苦労した点を書いていきたいと思います。

LeSSとは

前提として、LeSSとは何かご紹介します。

(引用元：大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法)

LeSSは、１つのプロダクトを複数チームで協働するために考えられたスクラムです。

LeSSはスクラムの原理・原則、目的、要素、洗練された状態を大規模な状況にできるだけシンプルに適用したものです。

基本的にLeSSで定義されている役割は以下４つです。

プロダクトオーナー(1人)
スクラムマスター(複数人)
チーム(複数)
チーム代表者

上記の通り、LeSSにおけるPOは1人だけで、このPOが各チームに仕事を与えることができる唯一の役割だと定義されています。

(引用元：大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法)

プロダクトオーナーは１人で、顧客にとって素晴らしいプロダクトのビジョンに責任があって、その影響（ROIなど）を最適化します。プロダクトオーナーとして、あなたはプロダクトバックログを継続的に育て、学習および変化に対する適応にもとづいてアイテムを追加、削除、最優先順位付け（並び替え）します。また、上位マネジメント、チーム、顧客に対して、プロダクトバックログが見える状態にしておくことで、透明性を保ちます。あなたはアイテムが明確になるように、チームや顧客と協働します。新しいスプリントに提示するアイテムは、プロダクトオーナーが適応的に決めますが、どのくらい選択するかはチームが決めます。そして、プロダクトオーナーだけがチームに仕事を依頼することができます。

弊社でもスクラム導入直後は、上記4つのロールでスクラムを回していました。

スタメンでのLeSSの紹介

本来のLeSSの体制を踏まえた上で、弊社のLeSSの体制をご紹介します。

弊社のLeSSは、各チームがメンバーの技術領域ではなく職能で横断され、以下のように編成されています。また各チームには、プロダクトオーナーの役割が移譲された「チームPO」が1人配置されています。

冒頭で述べた通り、チームPOはLeSSでは定義されていないため、スクラム体制に移行した直後にはない役割でしたが、今では基本的に各チームに1人(開発者と兼任)配置することを前提として、以下のような組織体制を目指しています。

以降、「チームPO制」導入の背景やスクラムでの実体験をご紹介します。

プロダクト開発部の組織構成（※一部簡略化しています）

「チームPO制」導入の背景

「チームPO制」導入の目的は主に以下の2点でした。

① POのボトルネック化の防止 ②チームの「意思決定機能」を強め、自己組織化を一層深める

「チームPO制」導入前は、基本的には各チームのスクラム活動において、受入条件や詳細仕様を都度POに確認し、また同席の上でバックログアイテムを作成していましたが、その結果、チームの意思決定に関してPOへの依存度が高くなり「待ちのチーム」が発生し、POがボトルネックになることが増えてしまいました。

このボトルネックを解消するために、チームの意思決定を率先していく役割として「チームPO制」を導入することを決めました。元々は1開発者だった中でチームPOと兼任になったため、苦労した点も非常に多かったですが、スクラムにおける様々なイベントでチームが自立的に動ける場面が増えたと感じています。

スクラムの中での動き

弊社のスクラムでは、基本的に以下スケジュールで活動を行っています。その中で、実際にチームPOとしてどのような動きをしているのかご紹介します。

【1週間スプリントのスケジュール】

月曜
- スプリントレビュー(15:00 ~ 16:00)
- スプリントレトロスペクティブ(16:00 ~ 17:00)
- スプリントプランニング1(17:00 ~ 17:30)
- スプリントプランニング2(17:30 ~ 18:30)
火曜
- スクラムマスター会議(11:00~12:00)
- オーバーオールリファインメント(16:00 ~ 17:00)
水曜
- (チーム内)リファインメント
木曜
- PO会議(17:30 ~ 18:00)

スプリントプランニング

スプリントプランニングでは主に、自チームのスプリントゴールの決定とチーム間でのアイテムの調整を主導して行っています。

開発部全体のスプリントゴールに関してPOから共有があった後、各チームPOを中心にゴール達成に向けてどのように1週間活動していくのか議論と決定をします。

スプリントゴールに直接関与しないアイテム(弊社ではSRE関連、臨時の顧客対応、ルーティン業務など)もあり、また各チームのベロシティが違うので、自チームの状況と全体の優先順位の両方を考慮して意思決定を行っています。

以前のスプリントプラニングでは、各チーム毎に発言するメンバーや内容に偏りがあったため、タイムボックス内にスプリントゴールを決めることに非常に苦労していましたが、今では意思決定をリードするチームPOとPOを中心に優先順位にフォーカスした議論することでスムーズに決定できるようになってきました。

オーバーオールリファインメント

オーバーオールリファインメントでは、数ヶ月先を見据えた優先順位付けとリファインメントの担当チームの割り振りについて議論しています。

以下のようにリファイメントの担当や方法に関しては、チームが意思決定を行うことが推奨されています。

(引用元：大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法)

オーバーオールPBRでは、より詳細なリファインメントを「複数チームPBR」で行うか、「単一チームPBR」で行うかを決める。これはPOではなくチームに決めてもらうことで、自己組織化が促されPOの作業を減らします。

以前のオーバオールリファイメントは、基本的にPOからビジネス上の優先順位について共有を受けた上で、アサインチームがなんとなく決まっていきチームが意思決定を行うことが少ない状態でした。

「チームPO制」導入後チームの自己組織化が少しずつ進み、POからの共有内容以外にもチームから開発に関する要望(ex.技術的負債の解消など)がボトムアップで出ることが増えました。今ではそれらを含め全ての優先順位を検討した上で、各チームがリファイメント対象のアイテムに着手できそうなタイミングを共有し、担当する可能性が高いチームがリファインメントを行えるようにチーム間で調整しています。

同時に、POからは開発のWHY(なぜ今必要なのか、マネタイズ、期日)とWHAT(ユースケース、ストーリー、要件)について共有を受け、後のチーム内のリファイメントで活かしています。

リファインメント

リファインメントの前に、オーバーオールなどで共有を受けた内容をもとに、チームPOが受入条件を明記してバックログアイテムを作成しています。

見積もり時はチームPOがファシリテーションを行いながらポイントを算出しています。開発者の疑問点に対しては、オーバーオールリファインメント等で共有を受けた情報を元にチームPOが解消することで、チーム独力でアイテム作成できることが増えました。

まだまだ改善点はありますが、以前と比べるとPOを介した意思決定が少なくなり、チームが主体的に受入条件や詳細仕様に関して意思決定できるようになりました。

また、以前はHOW(どのように実装をするか)に意識が向きがちでしたが、意思決定の回数や責任が増したことで、チーム全体としてプロダクトのWHYやWHATにフォーカスした議論が活発になり、開発への向き合い方も変わり始めています。

チームPOが開発者と兼任なので、技術的に専門性が高いアイテムに関しても意思決定をスムーズに行える場面が増えたこともメリットの1つでした。

PO会議

PO会議は弊社が独自で行っているスクラムのイベントです。 POと各チームPOが参加者で、チームPOが動きやすくするために情報を同期する場として開催し始めました。具体的には、直近数スプリントの計画やスプリントレビューの設計について話しています。

直近数スプリントの計画に関しては各チームの情報を把握するために始めました。スプリントプランニングの場で1週間毎の動きはわかりますが、比較的長いプロジェクトにアサインされると、プロジェクトの終了時期が見えづらく、各チームが中期的にどのように連携していくべきなのか把握し辛かったためです。

スプリントレビューの設計に関しては、スプリントの状況を共有しつつ次のスプリントレビューでどのようなデモを行うのか事前にすり合わせを行っています。デモの時間が限られているので、各チームが使用する時間や優先順位について議論します。

また、社内のどのステークホルダー(営業部やカスタマーサクセス部のメンバー)をデモに招待するのかも決めています。結果として、スプリントレビューで有益なフィードバックを貰える場面が徐々に増えてきました。

最近では、PO主導でチームPOのレトロスペクティブも始めました。普段のレトロスペクティブは開発者として参加しているため、なかなか振り返りをする機会がありませんでしたが、この振り返りを通して開発部全体としてPOスキルの向上を図っています。

以上がスクラムでの活動の紹介になります。その他にも比較的大きめのプロジェクトにアサインされている時は、リリーススケジュールマネジメント/やQA項目の作成などを行っています。

チームPOを経験して感じたこと

良かったこととしては、チーム内で意思決定を完結できることが増えチームとして迅速に開発を行えるようになったことや、チームPOだけでなく開発メンバーも自分たちでプロダクトを作る意識が高まったことが挙げられます。

加えてプロダクトの開発方法よりも、その前段にあるWHYやWHATに意識が向くようになり、よりプロダクトの提供価値にこだわりを持つメンバーが増えたと感じています。

実際に直近では、プロダクトのKPIに開発部全体でフォーカスするために、チームPOが主体となり開発のKPIを可視化するダッシュボードを作成するプロジェクトも始めました。このような開発の成果を可視化する動きは、チームメンバーの関心も高いため、今後のスクラム活動においてより注力していきたいポイントの1つです。

一方で、開発者と兼任なので開発との時間配分を誤るとチームPOの業務に十分な時間が割けず、チームの動きを停滞させてしまうことがありました。特にバックログアイテムの受入条件やストーリーが明確になっていないと、リファイメントで時間が押してしまうので、バックログアイテム作成の時間を確保する必要がありますが、スプリント中に開発とのバランスを調整することに難しさを感じています。

また、プロジェクトマネジメントのスキルが不足しているという大きな課題があるので、今後はファシリテーションや仕様の意思決定に関してPOからスキルを学んだり、ステークホルダーとの連携を強めるために社内の連携フローを整えていきたいと思っています。