組織規模が拡⼤する中で⼤規模スクラムを導⼊した判断と⼯夫

■イベント
ローンチ4年でARR70億を達成するためのエンジニアリング組織の取り組み
https://sansan.connpass.com/event/292027/

■登壇概要
タイトル：組織規模が拡⼤する中で⼤規模スクラムを導⼊した判断と⼯夫
登壇者：技術本部 Bill One Engineering Unit　⼭⼝ 裕明

■Bill One エンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

Transcript

1. Sansan株式会社 部署 名前 組織規模が拡⼤する中で ⼤規模スクラムを導⼊した 判断と⼯夫 ローンチ4年でARR70億を達成するためのエンジニアリング組織の取り組み Bill One Engineering Unit ⼭⼝ 裕明
2. - スクラム, LeSS, LeSS Huge の詳しい説明は割愛します。 ガイドやサイトを御覧ください。 前提 LeSS Huge LeSS Framework スクラムガイド
3. - 組織拡⼤による組織構造の複雑化と More な部分 - LeSS Huge のエッセンスの導⼊と⼯夫した点 - LeSS Huge のエッセンスの導⼊前と導⼊後の変化 - 今後取り組みたいこと アジェンダ
4. 組織拡⼤による組織構造の複雑化と More な部分
5. 組織拡⼤による組織構造の複雑化 フェーズに合わせた開発フレームワークを導⼊ スクラム開発 LeSS Framework をベースに導⼊ LeSS Huge をベースに導⼊ ⼈、チームが 急激に増える 初のチーム分割 PdM が 複数⼈に 単独のチーム
6. 組織拡⼤による組織構造の複雑化 フェーズに合わせた開発フレームワークを導⼊ スクラム開発 LeSS Framework をベースに導⼊ LeSS Huge をベースに導⼊ ⼈、チームが 急激に増える 初のチーム分割 PdM が 複数⼈に 単独のチーム 組織拡⼤する中でも 順調に開発は進んでいたが More な部分も発⽣
7. - 四半期ごとに PdM が⽬標とする PBI を決定 - 開発サイドの裁量が薄い - PdM と各開発チームで調整し取り組む PBI を決定 - 個別調整で決まることが多く不透明感も強い - PdM が 1 ⼈から複数⼈に増員 - コミュニケーションが複雑化、コストも増加 - 各チームに専⾨領域ができた - 効率重視に開発を進めた結果で良い⾯もあるがリソースが固定化 - 結果としてチーム間の協⼒が⽣まれにくい - プランニングの形骸化 - 他チームの状況が⾒えづらいことで単純な報告が増加 組織が拡⼤する中で発⽣した More な部分
8. LeSS Huge のエッセンスの導⼊と ⼯夫した点
9. - このアイデアをベースに現⾏組織に適応 LeSS Huge のエッセンス PB (プロダクト・バックログ) を要求エリアごとに分割する APdM APdM PdM 全体 PB ITEM 1 … … … … … A エリア PB ITEM 1 ITEM 2 … B エリア PB ITEM 4 ITEM 5 … グループA グループB FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM FEATURE TEAM
10. ⼯夫 1 スクラムの 3 本柱を 意識したイベント設計
11. - スクラムの 3 本柱 - 透明性 - 検査 - 適応 - なぜ意識するのか？ - 透明性がなければ検査ができない - 検査ができなければ適応ができない スクラムの 3 本柱とは？
12. スクラムの 3 本柱を意識したイベント設計 スクラムの 3 本柱を意識しつつ LeSS Huge のイベントをカスタマイズ イベント PdM エリアPdM 開発 デザイナー 概要 エリアリファインメント ◯ ◯ (ATL, PdL) ◯ ・エリア PB の PBI を明確化、概算の⾒積り、優先順位付け (= 未来の PBI の話し) プレプランニング ◯ ◯ ・PdM はリファインメント前の PBI を⼀時的な優先度で並べる ・全体 PB からエリア PB に割り振る エリアプランニング (= プランニング 1) ◯ ◯ (ATL) ・着⼿中のエリア PB のステータスをアップデートする ・未着⼿のエリア PB から開発チームがどの PBI に取り組むか選ぶ 開発プランニング (= プランニング 2) ◯ ・PBI の詳細を検討、詳細の⾒積り PdL/PdM連携 ◯ ◯ (PdL) ・着⼿中の PBI の明確化、利⽤状況の確認 (= 現在の PBI の話し)
13. - エリア(の範囲で⾏う)プランニング - 透明性: エリア PB で⼀元管理 - 検査: 着⼿中のエリア PB のステータスをアップデート - 適応: 未着⼿のエリア PB から開発チームがどの PBI に取り組むか選ぶ - エリア(の範囲で⾏う)リファインメント - 透明性: エリア PB で⼀元管理 - 検査: エリア PB の PBI を明確化、概算の⾒積り - 適応: 優先順位付け スクラムの 3 本柱を意識したイベント設計の具体例
14. ⼯夫 2 ガイドを作成し浸透を図る
15. ガイドを作成し浸透を図る 独⾃の⼤規模スクラムガイドを作成し、MTG で何度も伝え浸透を図った
16. LeSS Huge のエッセンスの 導⼊前と導⼊後の変化
17. 導⼊前と導⼊後の変化 導⼊前 導⼊後 ⽬標とする PBI の決定 四半期ごと 継続的 取り組む PBI の決定 クローズド (PdM と開発チームの個別調 整) オープン (エリアプランニング) チームのオーナーシップ範囲 チーム (専⾨領域) エリア チーム間の協⼒ 難しい ⽐較的容易
18. 今後取り組みたいこと
19. - LeSS Huge ベースの⼤規模スクラムを 4 ヶ⽉運⽤してみて - 肌感としては 100 名程度まではスケール可能 - 今後取り組みたいこと - より開発にフォーカスできる環境づくり - 計測ベースのパフォーマンスの向上 - PBI の細分化と⾒積もり精度の向上 - 各種イベントのブラッシュアップ - チームを越えたの学びの強化 - LeSS Huge の他のエッセンスの取り込み (全体振り返りなど) - 100 名を越えてもアジリティが⾼く開発できる組織づくり 今後取り組みたいこと
20. Sansan 技術本部 Bill One 開発エンジニア 採用情報 https://media.sansan-engineering.com/billone-engineer