大きすぎるLeSSを2つに分割！LeSS Hugeを参考にLeSSを関心領域で分けた話

Slide 1

Slide 1 text

大きすぎるLeSSを2つに分割！ LeSS Hugeを参考にLeSSを関心領域で分けた話 2024.06.22 Scrum Fest Osaka 2024 荒川涼太(kouryou) SmartHR 技術統括本部/アジャイルコーチングユニット

Slide 2

Slide 2 text

自己紹介

Slide 3

Slide 3 text

自己紹介 ● 荒川涼太(kouryou) ● 2019/09 SmartHR 入社 ● エンジニア→プレイングマネージャーをしつつ、アジャイル推進活動に力を入れる ● 2023/09 からアジャイルコーチ専門で活動

Slide 4

Slide 4 text

LeSSについて

Slide 5

Slide 5 text

LeSSとは何か ● Large-Scale Scrumの略称 ● 1つのプロダクトを複数チームで協働するために考えられたスクラム ● LeSSはスクラムが重視していることをそのままに、大規模な状況向けにシンプルに拡張したもの

Slide 6

Slide 6 text

LeSSのプランニング ● プランニングが2つに分かれる ○ 全体向けのプランニング1 ○ チームごとに行うプランニング2

Slide 7

Slide 7 text

LeSSのレトロスペクティブ ● レトロスペクティブが2つに分かれる ○ 全体向けのオーバーオールレトロスペクティブ ○ チームごとに行うチームレトロスペクティブ

Slide 8

Slide 8 text

LeSSのプロダクトバックログリファインメント ● プロダクトバックログリファインメント(PBR)が3つに分かれる ○ 全体向けのオーバーオールPBR ○ 複数チームで行う複数チームPBR ○ チームごとに行う単一チームPBR

Slide 9

Slide 9 text

2種類のフレームワーク ● LeSS ○ 2〜8チーム ● LeSS Huge ○ 8チーム以上

Slide 10

Slide 10 text

SmartHRにおけるLeSS

Slide 11

Slide 11 text

すべての人が、信頼しあい、気持ちよく働くために。 Employee First.

Slide 12

Slide 12 text

© SmartHR, Inc. SmartHRが実現すること 12 業務効率化と同時に、必要なデータが自然と集まる仕組みにより、「人事データをいつでも活用できる」状態をつくりだせます活用できる手続きだけでなく、人事に関わるあらゆるシーンで活用できます従業員集まる従業員が労務・人事に関わる情報を直接入力。もうハンコも紙も不要です採用人員配置人材抜擢人材育成制度改定組織開発蓄まるタレントマネジメント等級職種評価結果エンゲージメントキャリア希望入退社情報部署氏名役職雇用形態性別勤怠給与労務管理人事データベーススキル

Slide 13

Slide 13 text

SmartHRの社内体制

Slide 14

Slide 14 text

SmartHRの社内体制 LeSS

Slide 15

Slide 15 text

基本機能におけるLeSS ● 一番最初のプロダクトである基本機能において 7チームでLeSSをしていた ○ 2020年からLeSSを3チームでスタートし、2023年末には7チームに

Slide 16

Slide 16 text

一般的なLeSSからLeSS Hugeへの転換点

Slide 17

Slide 17 text

一般的なLeSSからLeSS Hugeへの転換点 LeSSの本にはプロダクトオーナーがLeSSの限界点になると書かれている Craig Larman and Bas Vodde 『大規模スクラム Large-Scale Scrum(LeSS)』.丸善出版.2021 年,352p

Slide 18

Slide 18 text

LeSSのプロダクトオーナーの限界点 ● プロダクト全体の概要を把握できなくなる ● 内側と外側への集中のバランスが保てない ● プロダクトバックログが大きくなり、1人で作業するのが難しくなる

Slide 19

Slide 19 text

SmartHRにおける LeSS分割の機運

Slide 20

Slide 20 text

プロダクトオーナーの変更 ● 年々チーム数・機能が増え、プロダクトオーナーが全体を把握し続けるのが難しくなってきた ● そんな中、LeSSを始めてからずっとプロダクトオーナーをしていた方が異動することに

Slide 21

Slide 21 text

新しいプロダクトオーナーは2人立てることに ● 1人にすべてを託すのは大変すぎる ● ユーザーへの価値提供領域を2つにわけ、領域ごとにプロダクトオーナーを立てる ○ それぞれの領域で価値提供スピードを上げることが狙い

Slide 22

Slide 22 text

ついにLeSS Hugeへの転換点が来たか...

Slide 23

Slide 23 text

LeSS Hugeを参考に LeSSを分割してみる

Slide 24

Slide 24 text

LeSS Hugeとは何か ● LeSS Hugeでは、顧客の関心ごとに分けられた要求エリア（4チーム以上）という概念が追加 ● LeSS Hugeは通常のLeSSとそれほど変わらない ○ チーム視点では、要求エリア内で通常のLeSSをやっているように見える ● 各要求エリアに、プロダクトオーナーが1人存在

Slide 25

Slide 25 text

要求エリアの分割 ● 顧客の関心ごとに沿って要求エリアを２つに分割 ○ 要求エリアα（3チーム） ○ 要求エリアβ（4チーム）

Slide 26

Slide 26 text

本来のLeSS Hugeでは、要求エリアは4チーム以上が推奨されている

Slide 27

Slide 27 text

要求エリアが小さいことによるデメリット ● 部分最適の増加 ● 調整の複雑さの増大 ● ポジションの増加 ● 狭すぎる専門範囲と俊敏性の欠如により、新たに発生する企業視点で価値の高いアイテムに取り組むことが難しくなる

Slide 28

Slide 28 text

もし要求エリアを4チーム以上にするなら？

Slide 29

Slide 29 text

もし要求エリアを4チーム以上にするなら...？ ● 解決案1: 基本機能にもう1チーム増やす ○ しかし、事業計画的に基本機能よりリソースを投下したい領域は多く、もう1チーム増やすのは厳しい

Slide 30

Slide 30 text

もし要求エリアを4チーム以上にするなら...？ ● 解決案2: プロダクトの定義を拡張し、別アプリケーションを開発していたチームを要求エリアに加える ○ アプリケーションが綺麗に分離されているので、1 チームスクラム→LeSS Hugeに参加するオーバーヘッドの方が大きく思える

Slide 31

Slide 31 text

理論上の話は理解しつつも、やはり現実は難しい

Slide 32

Slide 32 text

厳密に教科書通りのLeSS Hugeではないが、 LeSS Hugeのエッセンスを元にLeSSを分割することに

Slide 33

Slide 33 text

LeSS分割後の姿

Slide 34

Slide 34 text

LeSS分割後の姿（概要） ● LeSS全体で集まるオーバーオール系のイベントは要求エリアごとに開催 ● 元々チーム単位で行っていたイベントは変更点なし

Slide 35

Slide 35 text

LeSS分割後の姿（詳細）イベント名変更点プランニング1 要求エリアごとに開催プランニング2 なしオーバーオールPBR 要求エリアごとに開催単一チームPBR なし複数チームPBR なし

Slide 36

Slide 36 text

LeSS分割後の姿（詳細）イベント名変更点スプリントレビュー要求エリアごとに開催チームレトロスペクティブなしオーバーオールレトロスペクティブ要求エリアごとに開催デイリースクラムなし

Slide 37

Slide 37 text

LeSS Hugeの話ではないけど工夫したこと

Slide 38

Slide 38 text

LeSS分割後の技術面での工夫 ● リポジトリが1つのアプリケーションなので、LeSSを跨いで基本機能を触る人向けの共有会を追加 ○ hotﬁx対応の知見共有 ○ 大型機能のリリース情報 ○ デプロイ方法の変更 etc

Slide 39

Slide 39 text

LeSS分割後の運用面での工夫 ● 基本機能の中で、31個ある機能がどっちの要求エリアの担当になるかを分類 ○ 機能ごとの運用や問い合わせ対応などは、要求エリアがオーナーシップを持つことに

Slide 40

Slide 40 text

LeSSを分割してみた結果

Slide 41

Slide 41 text

分割したメリット ● コミュニケーションが取りやすくなった ○ オーバーオールレトロスペクティブでこれまでより一歩踏み込んで議論できるように ○ 要求エリア全体で催し物をする際も動きやすくなった

Slide 42

Slide 42 text

分割したメリット ● コンテキストを把握しやすくなった ○ 把握すべき機能数が減ったため、それぞれの解像度が上がった ○ PBIや問い合わせの引き継ぎコストが減った ● チームが各要求エリアのドメインに対してオーナーシップを持てるようになった

Slide 43

Slide 43 text

分割したデメリット ● 稀にどっちの要求エリアが担当すべきか悩ましい問い合わせや要望が来る ● 要求エリアを跨いだ改善や動きをするときは大変 ● 学びの横展開は減った ○ 各要求エリアで同じ議題をオーバーオールレトロスペクティブで話していたことも

Slide 44

Slide 44 text

結局分割して正解だったの？

Slide 45

Slide 45 text

今のところはメリットが大きいやはり小さいは正義！

Slide 46

Slide 46 text

今後やっていきたいこと

Slide 47

Slide 47 text

今後やっていきたいこと ● もっとチーム間コミュニケーションをスムーズにしたい（”ただ話す”の布教） ● 要求エリアのプロダクトゴールをもっと浸透させたい ● 要求エリアをまたぐ課題をスムーズに解決できるようにしたい

Slide 48

Slide 48 text

ご清聴ありがとうございました！