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
690
大きすぎるLeSSを2つに分割!LeSS Hugeを参考にLeSSを関心領域で分けた話
Ryota Arakawa
June 22, 2024
Tweet
Share
More Decks by Ryota Arakawa
See All by Ryota Arakawa
アジャイルな組織を目指し現実的にスクラムマスターを増やしていく取り組み
kouryou
0
39
スクラムチーム立ち上げ期に意識したこと
kouryou
0
1.3k
Other Decks in Technology
See All in Technology
Microsoft 365 でデータセキュリティを強化しよう
sophiakunii
2
480
Amazon Managed Grafana で AWS IoT TwinMaker によるデジタルツインアプリケーションを動かしてみた
wakatsuki
0
120
Oracle Cloud Infrastructure:2024年10月度サービス・アップデート
oracle4engineer
PRO
0
190
Deep dive into Nuxt Server Components
wattanx
1
1.3k
Reality is not an End-to-End Prediction Problem: Applied NLP in the Age of Generative AI
inesmontani
PRO
0
190
不要なリソースを自動で定期的に整理する方法 ~Sandboxアカウントのコストを削減しよう!~
amixedcolor
4
240
Vue.js、Nuxtの機能を使い、 大量のコピペコードをリファクタリングする
igayamaguchi
3
1.4k
外部カンファレンスで登壇しよう! 〜「強い」エンジニアへの一歩を踏み出す〜
logica0419
4
140
プログラミング写経のすすめ
natsutan
0
170
Unlearn Modularity
lemiorhan
6
310
最新のWasm事情
askua
5
2.5k
寒冷地稲作の歴史にみるコミュニティ
miu_crescent
2
140
Featured
See All Featured
How GitHub (no longer) Works
holman
311
140k
Raft: Consensus for Rubyists
vanstee
136
6.6k
Statistics for Hackers
jakevdp
796
220k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
GraphQLとの向き合い方2022年版
quramy
43
13k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
126
18k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
22k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
What's new in Ruby 2.0
geeforr
342
31k
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や問い合わせの引き継ぎコストが減った • チームが各要求エリアのドメインに対してオーナー
シップを持てるようになった
分割したデメリット • 稀にどっちの要求エリアが担当すべきか悩ましい問 い合わせや要望が来る • 要求エリアを跨いだ改善や動きをするときは大変 • 学びの横展開は減った ◦ 各要求エリアで同じ議題をオーバーオールレトロ
スペクティブで話していたことも
結局分割して正解だったの?
今のところはメリットが大きい やはり小さいは正義!
今後やっていきたいこと
今後やっていきたいこと • もっとチーム間コミュニケーションをスムーズにしたい (”ただ話す”の布教) • 要求エリアのプロダクトゴールをもっと浸透させたい • 要求エリアをまたぐ課題をスムーズに解決できるよう にしたい
ご清聴 ありがとうございました!