Retty × LeSSの取り組みと工夫 / Large-Scale Scrum in Retty

2022/10/26 【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれから

RettyにおけるLeSSの導入事例とプロダクト全体思考を継続するための取り組み・工夫

Transcript

1. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 Retty × LeSSの取り組みと工夫
 【Retty x アカツキゲームス x atama plus】LeSS導入の最前線、リアルとこれから 
 Retty株式会社
 池田 直弥

2. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 自己紹介
 池田 直弥
 Webチーム マネージャー
 2019年 Retty株式会社 中途入社
 
 ふりかえり大好きエンジニア
 技術的にはバックエンド系が好き
 スクラムマスターも楽しくやってました
 マネージャーにはなったばかりです🐥
 Nao_Mk2
3. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 サービス紹介
 3

4. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 目次
 • LeSS導入の背景、体制図
 • プロダクト全体思考を体現する
 取り組み・工夫
 4

5. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 LeSS導入の背景、体制図
 5

6. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 全体の優先順位ではなく調整の上手さに開発が左右される
 • 全体のKGIと各チーム同士のKPIの連動性がない 
 • チーム単位でリソースを確保し計画を作るため助け合いが困難 
 • お店情報、ネット予約のような関連性の高い機能のUIや体験乖離 
 なぜLeSSを導入したのか
 導入前の課題感
 ありたい姿
 一貫した体験設計でユーザーさんへ価値を届ける
 担当領域のベストではなく全体としてのベストへ
 参考: Rettyの開発組織をぶっ壊して、LeSSを導入した話をPO視点で書きました ( https://note.com/roki_n_/n/n9f1f84b4fa92 )

7. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 なぜLeSSを導入したのか
 LeSSのプロダクト全体思考がRettyのありたい姿にマッチした
 顧客は、プロダクトの一部分だけを買うということはなく、 プロダクト全体を購入 します。
 （中略）
 • プロダクト全体に統合されていない部分的なソフトウェアはまだ価値を有していない 
 • チームが自分たちの仕事を終えたとしても、統合されるまでは Done と言えない 
 • 単一チームのアウトプットへの部分最適と、プロダクト全体への全体最適、どちらを取るか選択を 迫られた時は、常にプロダクト全体を選択すべき である
 （中略）
 常に、プロダクト全体に意識を向けましょう。 
 常に、断片的な部品や仕掛かり中の部品に価値はない ことを全員に意識させましょう。 
 プロダクト全体思考 - Large Scale Scrum (LeSS) ( https://less.works/jp/less/principles/whole-product-focus.html )より抜粋 

8. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 LeSS体制図（全体像）
 PO
 toC Web Backlog
 PO
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 toC App Backlog
 toB Web Backlog
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer

9. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 LeSS体制図（プランナー陣の動き方イメージ）
 PO
 toC Web Backlog
 PO
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 toC App Backlog
 toB Web Backlog
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 • toCプランナーチームはアプリとWebのバックログにアイテムを追加
 ◦ toBに関わる部分の場合はtoBのバックログにも追加
 • 優先順位はPOが決定

10. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 LeSS体制図（エンジニア陣の動き方イメージ）
 PO
 toC Web Backlog
 PO
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 SM
 Engineer
 Engineer
 toC App Backlog
 toB Web Backlog
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 PdM
 Planner
 Designer
 • toC Webのバックログから2チームで分担してアイテムを取得
 • アイテムの優先順位調整をしたければPOと話し、POが最終決定

11. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 プロダクト全体思考を
 体現する取り組み・工夫
 11

12. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 プロダクト全体思考を体現する取り組み・工夫
 • 「チーム」で幅広く対応
 • トラベラーでチーム間コラボレーション

13. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 プロダクト全体思考を体現する取り組み・工夫
 • 「チーム」で幅広く対応
 • トラベラーでチーム間コラボレーション

14. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 チームの得意領域を尖らせすぎない
 フロントエンド得意 
 フロントエンド系 アイテム1 
 フロントエンド系 アイテム2 
 フロントエンド系 アイテム3 
 バックエンド系 アイテム1
 ・
 ・
 ・
 バックエンド得意 
 開発多すぎ
 開発少なすぎ
 チームの得意領域をならし特定チームに開発が偏りすぎないように
 フロントエンド系 アイテム1 
 フロントエンド系 アイテム2 
 フロントエンド系 アイテム3 
 バックエンド系 アイテム1
 ・
 ・
 ・

15. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 フロントエンド中心 / バックエンド中心で貢献しますで良い
 ただ「バックエンド（フロントエンド）なのでやりません」はしない
 全員がフルスタックエンジニアになれ、ではない
 得意領域の部分最適ではなくプロダクトの全体最適へ貢献
 苦手領域への対処方法
 • 得意な人とペア（モブ）プログラミング
 • チーム横断の特定テーマの相談チャンネルを活用
 ◦ #frontend_ask のようにその領域が得意な人に相談できる場
 参考: モブとソロを織り交ぜてハイアウトプットなチーム開発 ( https://speakerdeck.com/nao_mk2/high-output-with-swarming-and-solo-work )

16. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 プロダクト全体思考を体現する取り組み・工夫
 • 「チーム」で幅広く対応
 • トラベラーでチーム間コラボレーション

17. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 例：お店の予約情報を取得するAPIの刷新 
 • お店の予約は複雑
 ◦ 期間限定コース、席と席をくっつけて予約可能人数を増やす、など 
 • システムパフォーマンスを考慮しGo言語で開発する方針（RettyはPHPがメイン） 
 1チームでうまく開発しきれないときもある
 技術
 （コード設計、Go言語、
 パフォーマンスチューニング） 
 予約の業務知識が乏しい 
 （業務経験が短い）
 技術
 （コード設計、Go言語（初めて）） 
 予約の業務知識が豊富
 （業務経験が長い）
 チームA
 チームB
 両チームの強みが同時に必要になったがチームが別……😢

18. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 トラベラーで知識を他のチームへ広げる
 特定領域のエキスパートが別チームに混ざることで知識を広げる
 プロダクトグループは 数名の経験豊富な技術的なエキスパート達を頼みにしている ことがよくあります。 このように全てのチームから必要とされているが、十分な人数がいない時に、全てのチームが彼らの知 識を使える状態にするにはどうしたら、良いのでしょうか？ 
 彼らにはトラベラーになってもらいます。 毎スプリント彼らには別のチームのメンバーになってもらい 、ペ アを組んでコーチしてもらったり、ワークショップを開催してもらったり、技術的な教育をしてもらいます。 
 調整と統合 - Large Scale Scrum (LeSS) ( https://less.works/jp/less/framework/coordination-and-integration )より抜粋 
 参考: チーム間の情報共有を促進させて より良い協働をするための工夫 ( https://speakerdeck.com/nob210209/scrum-fest-mikawa-2022 )

19. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 トラベラーで知識を他のチームへ広げる
 得意な人を集めた専用チームを作り直すことはしなかった
 • 専用チームにしたとて、そこでずっと開発・運用するわけではない
 ◦ いずれフィーチャーチームの持ち物になる
 • 予約は飲食業において重要かつ幅広くあちこちに影響する
 ◦ 触れるチームが少ないとすぐにボトルネックになる
 特定の人、チームをボトルネックにしない
 専門領域ではなくプロダクト全体の優先順位に合わせられる体制を

20. Copyright ©2022 Retty, Inc.
 Copyright ©2022 Retty, Inc.
 一番大事なのは「何を達成したいか」
 組織やチームが「何を達成したいのか」の価値観をまず話す
 プラクティスはそれを体現できるものを選択・実行
 （LeSSというフレームワークやプラクティスに囚われすぎない）
 組織やチームのありたい姿の実現にLeSSが適している限り
 LeSSを継続してうまく活かせる！