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

Transcript

1. 大きすぎるLeSSを2つに分割！ LeSS Hugeを参考にLeSSを 関心領域で分けた話 2024.06.22 Scrum Fest Osaka 2024 荒川 涼太(kouryou) SmartHR 技術統括本部/アジャイルコーチングユニット
2. 自己紹介
3. 自己紹介 • 荒川 涼太(kouryou) • 2019/09 SmartHR 入社 • エンジニア→プレイングマネージャーをしつつ、アジャ イル推進活動に力を入れる • 2023/09 からアジャイルコーチ専門で活動
4. LeSSについて
5. LeSSとは何か • Large-Scale Scrumの略称 • 1つのプロダクトを複数チームで協働するために考え られたスクラム • LeSSはスクラムが重視していることをそのままに、大 規模な状況向けにシンプルに拡張したもの
6. LeSSのプランニング • プランニングが2つに分かれる ◦ 全体向けのプランニング1 ◦ チームごとに行うプランニング2
7. LeSSのレトロスペクティブ • レトロスペクティブが2つに分かれる ◦ 全体向けのオーバーオールレトロスペクティブ ◦ チームごとに行うチームレトロスペクティブ
8. LeSSのプロダクトバックログリファインメント • プロダクトバックログリファインメント(PBR)が3つに分 かれる ◦ 全体向けのオーバーオールPBR ◦ 複数チームで行う複数チームPBR ◦ チームごとに行う単一チームPBR
9. 2種類のフレームワーク • LeSS ◦ 2〜8チーム • LeSS Huge ◦ 8チーム以上
10. SmartHRにおけるLeSS
11. すべての人が、 信頼しあい、 気持ちよく働くために。 Employee First.
12. © SmartHR, Inc. SmartHRが実現すること 12 業務効率化と同時に、必要なデータが自然と集まる仕組みにより、 「人事データをいつでも活用できる」状態をつくりだせます 活用できる 手続きだけでなく、人事に関 わるあらゆるシーンで活用 できます 従業員 集まる 従業員が労務・人事に関わる 情報を直接入力。 もうハンコも紙も不要です 採用 人員配置 人材抜擢 人材育成 制度改定 組織開発 蓄まる タレントマネジメント 等級 職種 評価結果 エンゲージメント キャリア希望 入退社情報 部署 氏名 役職 雇用形態 性別 勤怠 給与 労務管理 人事 データベース スキル
13. SmartHRの社内体制
14. SmartHRの社内体制 LeSS
15. 基本機能におけるLeSS • 一番最初のプロダクトである基本機能において 7チームでLeSSをしていた ◦ 2020年からLeSSを3チームでスタートし、2023年 末には7チームに
16. 一般的なLeSSからLeSS Hugeへ の転換点
17. 一般的なLeSSからLeSS Hugeへの転換点 LeSSの本には プロダクトオーナーがLeSSの限 界点になると書かれている Craig Larman and Bas Vodde 『大規模スクラム Large-Scale Scrum(LeSS)』.丸善出版.2021 年,352p
18. LeSSのプロダクトオーナーの限界点 • プロダクト全体の概要を把握できなくなる • 内側と外側への集中のバランスが保てない • プロダクトバックログが大きくなり、1人で作業するの が難しくなる
19. SmartHRにおける LeSS分割の機運
20. プロダクトオーナーの変更 • 年々チーム数・機能が増え、プロダクトオーナーが全 体を把握し続けるのが難しくなってきた • そんな中、LeSSを始めてからずっとプロダクトオー ナーをしていた方が異動することに
21. 新しいプロダクトオーナーは2人立てることに • 1人にすべてを託すのは大変すぎる • ユーザーへの価値提供領域を2つにわけ、領域ごと にプロダクトオーナーを立てる ◦ それぞれの領域で価値提供スピードを上げること が狙い
22. ついにLeSS Hugeへの転換点が来たか...
23. LeSS Hugeを参考に LeSSを分割してみる
24. LeSS Hugeとは何か • LeSS Hugeでは、顧客の関心ごとに分けられた要求 エリア（4チーム以上）という概念が追加 • LeSS Hugeは通常のLeSSとそれほど変わらない ◦ チーム視点では、要求エリア内で通常のLeSSを やっているように見える • 各要求エリアに、プロダクトオーナーが1人存在
25. 要求エリアの分割 • 顧客の関心ごとに沿って 要求エリアを２つに分割 ◦ 要求エリアα（3チーム） ◦ 要求エリアβ（4チーム）
26. 本来のLeSS Hugeでは、要求エリアは4チーム以上 が推奨されている
27. 要求エリアが小さいことによるデメリット • 部分最適の増加 • 調整の複雑さの増大 • ポジションの増加 • 狭すぎる専門範囲と俊敏性の欠如により、新たに発 生する企業視点で価値の高いアイテムに取り組むこ とが難しくなる
28. もし要求エリアを4チーム以上にするなら？
29. もし要求エリアを4チーム以上にするなら...？ • 解決案1: 基本機能にもう1チーム増やす ◦ しかし、事業計画的に基本機能よりリソースを投 下したい領域は多く、もう1チーム増やすのは厳し い
30. もし要求エリアを4チーム以上にするなら...？ • 解決案2: プロダクトの定義を拡張し、 別アプリケーションを開発していたチームを 要求エリアに加える ◦ アプリケーションが綺麗に分離されているので、1 チームスクラム→LeSS Hugeに参加するオー バーヘッドの方が大きく思える
31. 理論上の話は理解しつつも、やはり現実は難しい
32. 厳密に教科書通りのLeSS Hugeではないが、 LeSS Hugeのエッセンスを元にLeSSを分割することに
33. LeSS分割後の姿
34. LeSS分割後の姿（概要） • LeSS全体で集まるオーバーオール系のイベントは要 求エリアごとに開催 • 元々チーム単位で行っていたイベントは変更点 なし
35. LeSS分割後の姿（詳細） イベント名 変更点 プランニング1 要求エリアごとに開催 プランニング2 なし オーバーオールPBR 要求エリアごとに開催 単一チームPBR なし 複数チームPBR なし
36. LeSS分割後の姿（詳細） イベント名 変更点 スプリントレビュー 要求エリアごとに開催 チーム レトロスペクティブ なし オーバーオール レトロスペクティブ 要求エリアごとに開催 デイリースクラム なし
37. LeSS Hugeの話ではないけど工 夫したこと
38. LeSS分割後の技術面での工夫 • リポジトリが1つのアプリケーションなので、LeSSを跨 いで基本機能を触る人向けの共有会を追加 ◦ hotfix対応の知見共有 ◦ 大型機能のリリース情報 ◦ デプロイ方法の変更 etc
39. LeSS分割後の運用面での工夫 • 基本機能の中で、31個ある機能がどっちの要求エリ アの担当になるかを分類 ◦ 機能ごとの運用や問い合わせ対応などは、 要求エリアがオーナーシップを持つことに
40. LeSSを分割してみた結果
41. 分割したメリット • コミュニケーションが取りやすくなった ◦ オーバーオールレトロスペクティブでこれまでより 一歩踏み込んで議論できるように ◦ 要求エリア全体で催し物をする際も動きやすく なった
42. 分割したメリット • コンテキストを把握しやすくなった ◦ 把握すべき機能数が減ったため、それぞれの解 像度が上がった ◦ PBIや問い合わせの引き継ぎコストが減った • チームが各要求エリアのドメインに対してオーナー シップを持てるようになった
43. 分割したデメリット • 稀にどっちの要求エリアが担当すべきか悩ましい問 い合わせや要望が来る • 要求エリアを跨いだ改善や動きをするときは大変 • 学びの横展開は減った ◦ 各要求エリアで同じ議題をオーバーオールレトロ スペクティブで話していたことも
44. 結局分割して正解だったの？
45. 今のところはメリットが大きい やはり小さいは正義！
46. 今後やっていきたいこと
47. 今後やっていきたいこと • もっとチーム間コミュニケーションをスムーズにしたい （”ただ話す”の布教） • 要求エリアのプロダクトゴールをもっと浸透させたい • 要求エリアをまたぐ課題をスムーズに解決できるよう にしたい
48. ご清聴 ありがとうございました！