Upgrade to Pro — share decks privately, control downloads, hide ads and more …

スクラム開発チームをLessでスケールさせた話/Scaling Scrum team with Less

A1
August 04, 2021

スクラム開発チームをLessでスケールさせた話/Scaling Scrum team with Less

開発チームをLessを導入してスケールさせた事例の紹介になります。

A1

August 04, 2021
Tweet

More Decks by A1

Other Decks in Programming

Transcript

  1. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    2021.08.04 / RAKUS Meetup
    Eiichi Mita
    スクラム開発チームを
    Lessでスケールさせた話

    View Slide

  2. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■自己紹介
    Eiichi Mita @eichisanden
    2014年にラクスに中途入社
    以来、楽楽明細の開発に従事
    フロントエンドもバックエンドもどっちもやるエンジニア
    認定スクラムマスター
    趣味はSplatoon2(永遠のA帯)
    2

    View Slide

  3. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■今回お話するプロダクト「楽楽明細」
    3
    • 請求書などの帳票を発行するSaaS
    • ローンチから6年ほど経過しているが成長しているサービス
    • アプリケーションはモノリシック

    View Slide

  4. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    1. 分割前の話
    2. 大規模スクラム手法 Less
    3. 分割してみる
    4. 分割後の話
    5. まとめ
    4
    Contents

    View Slide

  5. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■はじめに
    • 大規模スクラムLess(Large-Scale Scrum)の導入事例を紹介します
    • 1チームスクラムと共通する話やチームビルディングの話もしま

    • 発表者はスクラムマスターの役割を担っています
    5

    View Slide

  6. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    1. 分割前の話
    2. 大規模スクラム手法 Less
    3. 分割してみる
    4. 分割後の話
    5. まとめ
    6

    View Slide

  7. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■チームを分割することになった背景
    1スクラムチームを鍛え続けるのが理想ではあるが…
    • 肥大化していくプロダクトバックログ
    • この機能がないと契約できない…(顧客)
    • この機能がないと競合他社と勝負できない…(営業)
    • 問い合わせを減らしたいので機能を直して欲しい…(CS)
    • 潜在顧客にリーチするためこの機能を早く提供したい…(PO)
    7

    View Slide

  8. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■チームを分割することになった背景
    ニーズに応えるために…
    • 数年スパンでメンバーを増やしていく人員計画
    • 9人/1チームで収まりきらなくなった
    8

    View Slide

  9. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    人数が増えてきたらどうすれば良い?
    9
    Eak K.による
    Pixabay からの画像

    View Slide

  10. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    1. 分割前の話
    2. 大規模スクラム手法 Less
    3. 分割してみる
    4. 分割後の話
    5. まとめ
    10

    View Slide

  11. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■大規模スクラムの手法
    • 「スクラムガイド」は1チーム
    での状況が中心に扱われてる
    • SAFe/DAD/Nexus/Scrum of
    Scrumsなど、スクラムをスケー
    ルさせる手法がある
    • その中でLessを採用した
    11
    5th State of Agile Reportより引用
    https://stateofagile.com/

    View Slide

  12. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■Lessを採用した理由
    • 我々のチーム規模に丁度よかった
    • 1チームスクラムとの差分が少ない
    • 役割、成果物、プロセスの追加が殆どない
    • 元々スクラムをやっているのでメンバーの
    負担が少ないと考えた
    • 単純明快さに惚れた
    • 公式サイトの「調整と統合」が秀逸
    12
    上司に紹介されてこの本を読んでいて、実はかなり前から導
    入を密かに狙っていました。
    ちなみにScrumの本としても良書です
    ただ話す
    --------------------
    チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題
    があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されて
    います。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合
    にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけ
    です。立ち上がって話に行ってください。
    https://less.works/jp/less/framework/coordination-and-integration

    View Slide

  13. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■Lessとは
    • 「Less is Scrum」なので、スクラムの原理・原則はそのまま適用される。
    • 経験主義、透明性、自己管理チームなど…
    • 10の原理原則、フレームワーク、
    ガイド、実験で構成されている
    • More with Less
    • 役割やプロセスは少なくして
    もっと多くのものを得る
    • 2~8チームでの開発に対応している。
    • それ以上の規模は「Less Huge」が対応している。
    13

    View Slide

  14. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■Lessのルール(構造)
    • 1~3チームに1人のSM
    • SMは専任でフルタイム
    • チームは自律的、多能工、同一ロケーション、長期存続である
    • 殆どのチームは顧客中心のフィーチャーチームであること
    14

    View Slide

  15. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■Lessのルール(プロダクト)
    • 1人のプロダクトオーナー
    • 1つのプロダクトバックログ
    • 全てのチームで共通のDoneの定義
    • 各チームで個別の拡張版Doneの定義を持つこともできる
    15

    View Slide

  16. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■Lessのルール(スプリント)
    • 各チームのスプリントのサイクルは揃える
    • 各スプリントの終りにはコードを統合する
    • スプリントプランニングの1部は複数チームで行う
    • スプリントプランニングの2部は基本、チーム別で
    • 関連のあるものは集まって行う
    • デイリースクラムはチーム単位で行う
    • スプリントレビューは全体で1つ
    • ふりかえりはチーム単位で行った後に全体でも実施
    16

    View Slide

  17. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    1. 分割前の話
    2. 大規模スクラム手法 Less
    3. 分割してみる
    4. 分割後の話
    5. まとめ
    17

    View Slide

  18. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■分割の方針
    • 1チーム5名~6名の2チームに分割
    • 戦力が偏って不公平感が出ないように配慮
    • チームごとの作業や知識の偏りは防ぎたい
    • 運用については同列。当番制で両チームが担当する
    • 各チームは「得意分野・デフォルト担当機能」を持つが、その
    他の機能開発も実施する
    18
    ベテラン
    ベテラン
    中堅
    若手
    若手
    新卒
    若手
    新卒
    ベテラン
    ベテラン
    中堅
    SM

    View Slide

  19. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■分割の方針
    • チーム名は自分たちで決めて貰った
    • 自分達で名前を決めることでオーナー意識を持ってもらいたい
    • 〇〇さんチームや〇〇機能チーム名は避ける
    19

    View Slide

  20. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    1. 分割前の話
    2. 大規模スクラム手法 Less
    3. 分割してみる
    4. 分割後の話
    5. まとめ
    20

    View Slide

  21. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■分割後のチームの変化
    • デイリースクラム(朝会)
    • スプリントレトロスペクティブ(ふりかえり)
    • スプリントデモ
    • スプリントプランニング
    21

    View Slide

  22. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■スプリントのタイムスケジュール
    22
    AM PM







    プラニング1
    プラニング2
    ふりかえり デモ


    AM PM







    プラニング1
    プラニング2
    ふりかえり デモ


    ふりかえり共有
    分割前
    分割後
    →かなり変更は少ない
    全員
    チーム別
    代表者
    凡例:

    View Slide

  23. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■デイリースクラム(朝会)
    • チーム別に実施している
    • 内容は1チームスクラムと同じ
    • 15分間のタイムボックス
    • 昨日何をしたか/今日何をするか/困っていることは?
    23

    View Slide

  24. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■デイリースクラム(朝会)
    • 他チームの様子を知るために「偵察」を送り込むプラクティスを
    紹介したが…
    • メンバーの意見を聞いた結果、全員参加することに
    • 全体共有→Aチーム朝会→Bチーム朝会の流れ
    • 最近はZOOMで実施していて物理的な制約がなく、短時間で済
    んでいるので2チームの間はこのスタイルで良いと思っている
    • 他のチームの話に割って入ってもOK
    • 「気になったことはどんどん質問しよう」と明確に言っている
    • チーム間の認識齟齬などは早い段階で発見したい狙い
    24

    View Slide

  25. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■スプリントレトロスペクティブ(ふりかえり)
    • チームごとに実施する
    • 翌日、話したサマリーを他チームに共有する
    • 横断的な課題が出たときはオーバーオールレトロスペクティブを実施する
    • 大きな機能開発単位でのふりかえりなども必要に応じて開催
    25

    View Slide

  26. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■スプリントレトロスペクティブ(ふりかえり)
    • 現在はMiroで実施している
    • 1チームスクラム時代にある程度慣れているのでやり方は任せている
    • ファシリテーターは持ち回り
    • KPTなど、手法はファシリテータが決めている
    • 大抵は下記の流れでやっている
    26
    1. チェックイン(ルールの確認など)
    2. スプリント期間内の事実確認
    1. 運用や障害対応はどれぐらいあった?
    2. 割り込みはどれぐらいあった?
    3. (片方のチームは)感謝を伝える
    3. 付箋に記入
    4. 話し合うものを投票で決める
    5. 話し合い
    6. ふりかえりのふりかえり

    View Slide

  27. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■スプリントデモ
    • ZOOMで週1時間で行っている
    • 参加者は事業部長、サポート、PO 、SM 、UIデザイナー、開
    発チーム全員
    • デモする人は当番制
    • 2チームになったが大きな変化はない
    27

    View Slide

  28. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■スプリントプランニング
    • スプリントプランニング1
    • POと各チームの代表者が集
    まって、どのPBIを担当するか
    を決める
    • スプリントプランニング2
    • 各チームで個別にプランニン
    グする(複数チームで協力す
    る必要があれば複数チームで
    プランニングする)
    28

    View Slide

  29. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■運用
    どちらかのチームに作業が依存しないように当番制で行う
    • 運用当番
    • 他部署からの依頼や質問の対応
    • リリース当番
    • リリース準備と立ち合い、リリース後作業を担当
    • アラート監視当番
    • 週ごとに当番制
    → 担当する人が偏らないようにチーム内でもローテーション
    29

    View Slide

  30. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■悩ましいところ
    • リーダを置くことのジレンマ
    • スクラム的にはリーダーという役割はない
    • スクラムチームが9人までというのはリーダーなしの限界が
    9人だから(らしい)
    • 元々ある問題だったが、2チームになり調整ごとが増え、より
    顕著に
    • 経験年数、性格によってはリーダに頼りたい様子
    • 今の自分達には、「リード役」がいないと難しいという事実を
    受け止め一旦はリーダーありの状態を許容している
    • 壁打ち相手になって「いいじゃない」という感じにしたい
    • 「決めて下さい」のような会話が多くないかは注視する
    30

    View Slide

  31. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■悩ましいところ
    • PO が実質Proxy 問題
    • 現状はビジネス側のステークホルダーの意向をPOが確認していて一人の
    POという原則を守れていないのが課題
    • プロダクトオーナーなのかプロジェクトマネージャなのか
    • POがプロジェクトマネージャ的な役割も一部担っている
    現状はこれで前に進むしかないが、POの仕事に集中することでスピード感
    アップしたい
    31
    事業
    部長
    製品
    企画 PO
    開発組織
    ビジネス側
    優先順位や要件を
    確認

    View Slide

  32. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■悩ましいところ
    • いつの間にか「作ること」目的になってしまっていないか?
    • ちゃんと使ってもらいたい人に、使いやすいものを作れているの
    か?
    • 大きな機能開発ではユーザインタビューをするようにした
    • ユーザから直接意見を聞くことでの学びが多い
    32

    View Slide

  33. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■悩ましいところ
    • インフラがチームに入っていない
    • 情報格差や受け渡しのコストが掛かりやすい
    • 現状は同じチームに入れることは難しいので情報共有を小まめ
    にやり、お互いの領域をカバーし合うしかない
    • デザイナーもチームに入っていない
    • プレゼンテーションナルなコンポーネントをStorybookに切り出
    して作業分担しやすいようにトライ
    33

    View Slide

  34. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■リモートワークでどうなったか
    • チーム開発の進め方としては大きな影響はなかった。
    • そのためには気軽に会話が始められる仕掛けが必要
    • 固定のZOOMのURLを用意しておく
    • BチームはNeWorkを使用中
    34

    View Slide

  35. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    1. 分割前の話
    2. 大規模スクラム手法 Less
    3. 分割してみる
    4. 分割後の話
    5. まとめ
    35

    View Slide

  36. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
     あ
    ■まとめ
    • 大きなギャップもなく2チーム制に移行できている
    • 2チームになったことで情報の受け渡しなどのオーバーヘッドが
    増えたことは間違いないが、必要なコストの範囲
    • 3~4チームになると別の課題が出るとは思うが今の延長で行けそ
    うな感触
    • スクラムが出来ていればLessはやりやすい
    • 他の大規模スクラムのフレームワークと比べてLessは導入しやす
    い(と思う)
    36

    View Slide

  37. ©2021 RAKUS Co., Ltd.
    #RAKUSMeetup
    ご清聴ありがとうございました
    37

    View Slide