Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大きすぎるLeSSを2つに分割!LeSS Hugeを参考にLeSSを関心領域で分けた話
Search
Ryota Arakawa
June 22, 2024
Technology
0
1.1k
大きすぎるLeSSを2つに分割!LeSS Hugeを参考にLeSSを関心領域で分けた話
Ryota Arakawa
June 22, 2024
Tweet
Share
More Decks by Ryota Arakawa
See All by Ryota Arakawa
AI活用の壁を超える! 開発組織への普及の秘訣
kouryou
1
920
アジャイルな組織を目指し現実的にスクラムマスターを増やしていく取り組み
kouryou
0
730
スクラムチーム立ち上げ期に意識したこと
kouryou
0
1.5k
Other Decks in Technology
See All in Technology
5min GuardDuty Extended Threat Detection EKS
takakuni
0
150
Observability infrastructure behind the trillion-messages scale Kafka platform
lycorptech_jp
PRO
0
140
Prox Industries株式会社 会社紹介資料
proxindustries
0
320
rubygem開発で鍛える設計力
joker1007
2
220
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
470
Understanding_Thread_Tuning_for_Inference_Servers_of_Deep_Models.pdf
lycorptech_jp
PRO
0
130
Amazon ECS & AWS Fargate 運用アーキテクチャ2025 / Amazon ECS and AWS Fargate Ops Architecture 2025
iselegant
17
5.7k
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
570
Observability в PHP без боли. Олег Мифле, тимлид Altenar
lamodatech
0
360
Welcome to the LLM Club
koic
0
190
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
320
25分で解説する「最小権限の原則」を実現するための AWS「ポリシー」大全 / 20250625-aws-summit-aws-policy
opelab
9
1.2k
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
42
7.5k
Why Our Code Smells
bkeepers
PRO
337
57k
Designing for humans not robots
tammielis
253
25k
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.3k
Optimizing for Happiness
mojombo
379
70k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Become a Pro
speakerdeck
PRO
28
5.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
124
52k
Agile that works and the tools we love
rasmusluckow
329
21k
Documentation Writing (for coders)
carmenintech
72
4.9k
Into the Great Unknown - MozCon
thekraken
39
1.9k
Transcript
大きすぎるLeSSを2つに分割! LeSS Hugeを参考にLeSSを 関心領域で分けた話 2024.06.22 Scrum Fest Osaka 2024 荒川
涼太(kouryou) SmartHR 技術統括本部/アジャイルコーチングユニット
自己紹介
自己紹介 • 荒川 涼太(kouryou) • 2019/09 SmartHR 入社 • エンジニア→プレイングマネージャーをしつつ、アジャ
イル推進活動に力を入れる • 2023/09 からアジャイルコーチ専門で活動
LeSSについて
LeSSとは何か • Large-Scale Scrumの略称 • 1つのプロダクトを複数チームで協働するために考え られたスクラム • LeSSはスクラムが重視していることをそのままに、大 規模な状況向けにシンプルに拡張したもの
LeSSのプランニング • プランニングが2つに分かれる ◦ 全体向けのプランニング1 ◦ チームごとに行うプランニング2
LeSSのレトロスペクティブ • レトロスペクティブが2つに分かれる ◦ 全体向けのオーバーオールレトロスペクティブ ◦ チームごとに行うチームレトロスペクティブ
LeSSのプロダクトバックログリファインメント • プロダクトバックログリファインメント(PBR)が3つに分 かれる ◦ 全体向けのオーバーオールPBR ◦ 複数チームで行う複数チームPBR ◦ チームごとに行う単一チームPBR
2種類のフレームワーク • LeSS ◦ 2〜8チーム • LeSS Huge ◦ 8チーム以上
SmartHRにおけるLeSS
すべての人が、 信頼しあい、 気持ちよく働くために。 Employee First.
© SmartHR, Inc. SmartHRが実現すること 12 業務効率化と同時に、必要なデータが自然と集まる仕組みにより、 「人事データをいつでも活用できる」状態をつくりだせます 活用できる 手続きだけでなく、人事に関 わるあらゆるシーンで活用
できます 従業員 集まる 従業員が労務・人事に関わる 情報を直接入力。 もうハンコも紙も不要です 採用 人員配置 人材抜擢 人材育成 制度改定 組織開発 蓄まる タレントマネジメント 等級 職種 評価結果 エンゲージメント キャリア希望 入退社情報 部署 氏名 役職 雇用形態 性別 勤怠 給与 労務管理 人事 データベース スキル
SmartHRの社内体制
SmartHRの社内体制 LeSS
基本機能におけるLeSS • 一番最初のプロダクトである基本機能において 7チームでLeSSをしていた ◦ 2020年からLeSSを3チームでスタートし、2023年 末には7チームに
一般的なLeSSからLeSS Hugeへ の転換点
一般的なLeSSからLeSS Hugeへの転換点 LeSSの本には プロダクトオーナーがLeSSの限 界点になると書かれている Craig Larman and Bas Vodde
『大規模スクラム Large-Scale Scrum(LeSS)』.丸善出版.2021 年,352p
LeSSのプロダクトオーナーの限界点 • プロダクト全体の概要を把握できなくなる • 内側と外側への集中のバランスが保てない • プロダクトバックログが大きくなり、1人で作業するの が難しくなる
SmartHRにおける LeSS分割の機運
プロダクトオーナーの変更 • 年々チーム数・機能が増え、プロダクトオーナーが全 体を把握し続けるのが難しくなってきた • そんな中、LeSSを始めてからずっとプロダクトオー ナーをしていた方が異動することに
新しいプロダクトオーナーは2人立てることに • 1人にすべてを託すのは大変すぎる • ユーザーへの価値提供領域を2つにわけ、領域ごと にプロダクトオーナーを立てる ◦ それぞれの領域で価値提供スピードを上げること が狙い
ついにLeSS Hugeへの転換点が来たか...
LeSS Hugeを参考に LeSSを分割してみる
LeSS Hugeとは何か • LeSS Hugeでは、顧客の関心ごとに分けられた要求 エリア(4チーム以上)という概念が追加 • LeSS Hugeは通常のLeSSとそれほど変わらない ◦
チーム視点では、要求エリア内で通常のLeSSを やっているように見える • 各要求エリアに、プロダクトオーナーが1人存在
要求エリアの分割 • 顧客の関心ごとに沿って 要求エリアを2つに分割 ◦ 要求エリアα(3チーム) ◦ 要求エリアβ(4チーム)
本来のLeSS Hugeでは、要求エリアは4チーム以上 が推奨されている
要求エリアが小さいことによるデメリット • 部分最適の増加 • 調整の複雑さの増大 • ポジションの増加 • 狭すぎる専門範囲と俊敏性の欠如により、新たに発 生する企業視点で価値の高いアイテムに取り組むこ
とが難しくなる
もし要求エリアを4チーム以上にするなら?
もし要求エリアを4チーム以上にするなら...? • 解決案1: 基本機能にもう1チーム増やす ◦ しかし、事業計画的に基本機能よりリソースを投 下したい領域は多く、もう1チーム増やすのは厳し い
もし要求エリアを4チーム以上にするなら...? • 解決案2: プロダクトの定義を拡張し、 別アプリケーションを開発していたチームを 要求エリアに加える ◦ アプリケーションが綺麗に分離されているので、1 チームスクラム→LeSS Hugeに参加するオー
バーヘッドの方が大きく思える
理論上の話は理解しつつも、やはり現実は難しい
厳密に教科書通りのLeSS Hugeではないが、 LeSS Hugeのエッセンスを元にLeSSを分割することに
LeSS分割後の姿
LeSS分割後の姿(概要) • LeSS全体で集まるオーバーオール系のイベントは要 求エリアごとに開催 • 元々チーム単位で行っていたイベントは変更点 なし
LeSS分割後の姿(詳細) イベント名 変更点 プランニング1 要求エリアごとに開催 プランニング2 なし オーバーオールPBR 要求エリアごとに開催 単一チームPBR
なし 複数チームPBR なし
LeSS分割後の姿(詳細) イベント名 変更点 スプリントレビュー 要求エリアごとに開催 チーム レトロスペクティブ なし オーバーオール レトロスペクティブ
要求エリアごとに開催 デイリースクラム なし
LeSS Hugeの話ではないけど工 夫したこと
LeSS分割後の技術面での工夫 • リポジトリが1つのアプリケーションなので、LeSSを跨 いで基本機能を触る人向けの共有会を追加 ◦ hotfix対応の知見共有 ◦ 大型機能のリリース情報 ◦ デプロイ方法の変更
etc
LeSS分割後の運用面での工夫 • 基本機能の中で、31個ある機能がどっちの要求エリ アの担当になるかを分類 ◦ 機能ごとの運用や問い合わせ対応などは、 要求エリアがオーナーシップを持つことに
LeSSを分割してみた結果
分割したメリット • コミュニケーションが取りやすくなった ◦ オーバーオールレトロスペクティブでこれまでより 一歩踏み込んで議論できるように ◦ 要求エリア全体で催し物をする際も動きやすく なった
分割したメリット • コンテキストを把握しやすくなった ◦ 把握すべき機能数が減ったため、それぞれの解 像度が上がった ◦ PBIや問い合わせの引き継ぎコストが減った • チームが各要求エリアのドメインに対してオーナー
シップを持てるようになった
分割したデメリット • 稀にどっちの要求エリアが担当すべきか悩ましい問 い合わせや要望が来る • 要求エリアを跨いだ改善や動きをするときは大変 • 学びの横展開は減った ◦ 各要求エリアで同じ議題をオーバーオールレトロ
スペクティブで話していたことも
結局分割して正解だったの?
今のところはメリットが大きい やはり小さいは正義!
今後やっていきたいこと
今後やっていきたいこと • もっとチーム間コミュニケーションをスムーズにしたい (”ただ話す”の布教) • 要求エリアのプロダクトゴールをもっと浸透させたい • 要求エリアをまたぐ課題をスムーズに解決できるよう にしたい
ご清聴 ありがとうございました!