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

by Naoya.i

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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 )より抜粋  

Slide 8

Slide 8 text

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 

Slide 9

Slide 9 text

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が決定 

Slide 10

Slide 10 text

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が最終決定 

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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 ) 

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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