開発チームをLessを導入してスケールさせた事例の紹介になります。
©2021 RAKUS Co., Ltd.#RAKUSMeetup2021.08.04 / RAKUS MeetupEiichi Mitaスクラム開発チームをLessでスケールさせた話
View Slide
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■自己紹介Eiichi Mita @eichisanden2014年にラクスに中途入社以来、楽楽明細の開発に従事フロントエンドもバックエンドもどっちもやるエンジニア認定スクラムマスター趣味はSplatoon2(永遠のA帯)2
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■今回お話するプロダクト「楽楽明細」3• 請求書などの帳票を発行するSaaS• ローンチから6年ほど経過しているが成長しているサービス• アプリケーションはモノリシック
©2021 RAKUS Co., Ltd.#RAKUSMeetup1. 分割前の話2. 大規模スクラム手法 Less3. 分割してみる4. 分割後の話5. まとめ4Contents
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■はじめに• 大規模スクラムLess(Large-Scale Scrum)の導入事例を紹介します• 1チームスクラムと共通する話やチームビルディングの話もします• 発表者はスクラムマスターの役割を担っています5
©2021 RAKUS Co., Ltd.#RAKUSMeetup1. 分割前の話2. 大規模スクラム手法 Less3. 分割してみる4. 分割後の話5. まとめ6
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■チームを分割することになった背景1スクラムチームを鍛え続けるのが理想ではあるが…• 肥大化していくプロダクトバックログ• この機能がないと契約できない…(顧客)• この機能がないと競合他社と勝負できない…(営業)• 問い合わせを減らしたいので機能を直して欲しい…(CS)• 潜在顧客にリーチするためこの機能を早く提供したい…(PO)7
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■チームを分割することになった背景ニーズに応えるために…• 数年スパンでメンバーを増やしていく人員計画• 9人/1チームで収まりきらなくなった8
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ人数が増えてきたらどうすれば良い?9Eak K.によるPixabay からの画像
©2021 RAKUS Co., Ltd.#RAKUSMeetup1. 分割前の話2. 大規模スクラム手法 Less3. 分割してみる4. 分割後の話5. まとめ10
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■大規模スクラムの手法• 「スクラムガイド」は1チームでの状況が中心に扱われてる• SAFe/DAD/Nexus/Scrum ofScrumsなど、スクラムをスケールさせる手法がある• その中でLessを採用した115th State of Agile Reportより引用https://stateofagile.com/
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■Lessを採用した理由• 我々のチーム規模に丁度よかった• 1チームスクラムとの差分が少ない• 役割、成果物、プロセスの追加が殆どない• 元々スクラムをやっているのでメンバーの負担が少ないと考えた• 単純明快さに惚れた• 公式サイトの「調整と統合」が秀逸12上司に紹介されてこの本を読んでいて、実はかなり前から導入を密かに狙っていました。ちなみにScrumの本としても良書ですただ話す--------------------チーム間の調整にもっとも良い方法は単純に、ただチーム間の調整をすることです。課題があれば自己管理されたチームの誰もが他チームの所に行って議論することが期待されています。もし、「ただ話す」ことが出来ない状況なのであれば、電話したり、最悪の場合にはメールを送れば良いわけです。調整の為に形式張った場は不要で、調整が遅れるだけです。立ち上がって話に行ってください。https://less.works/jp/less/framework/coordination-and-integration
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■Lessとは• 「Less is Scrum」なので、スクラムの原理・原則はそのまま適用される。• 経験主義、透明性、自己管理チームなど…• 10の原理原則、フレームワーク、ガイド、実験で構成されている• More with Less• 役割やプロセスは少なくしてもっと多くのものを得る• 2~8チームでの開発に対応している。• それ以上の規模は「Less Huge」が対応している。13
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■Lessのルール(構造)• 1~3チームに1人のSM• SMは専任でフルタイム• チームは自律的、多能工、同一ロケーション、長期存続である• 殆どのチームは顧客中心のフィーチャーチームであること14
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■Lessのルール(プロダクト)• 1人のプロダクトオーナー• 1つのプロダクトバックログ• 全てのチームで共通のDoneの定義• 各チームで個別の拡張版Doneの定義を持つこともできる15
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■Lessのルール(スプリント)• 各チームのスプリントのサイクルは揃える• 各スプリントの終りにはコードを統合する• スプリントプランニングの1部は複数チームで行う• スプリントプランニングの2部は基本、チーム別で• 関連のあるものは集まって行う• デイリースクラムはチーム単位で行う• スプリントレビューは全体で1つ• ふりかえりはチーム単位で行った後に全体でも実施16
©2021 RAKUS Co., Ltd.#RAKUSMeetup1. 分割前の話2. 大規模スクラム手法 Less3. 分割してみる4. 分割後の話5. まとめ17
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■分割の方針• 1チーム5名~6名の2チームに分割• 戦力が偏って不公平感が出ないように配慮• チームごとの作業や知識の偏りは防ぎたい• 運用については同列。当番制で両チームが担当する• 各チームは「得意分野・デフォルト担当機能」を持つが、その他の機能開発も実施する18ベテランベテラン中堅若手若手新卒若手新卒ベテランベテラン中堅SM
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■分割の方針• チーム名は自分たちで決めて貰った• 自分達で名前を決めることでオーナー意識を持ってもらいたい• 〇〇さんチームや〇〇機能チーム名は避ける19
©2021 RAKUS Co., Ltd.#RAKUSMeetup1. 分割前の話2. 大規模スクラム手法 Less3. 分割してみる4. 分割後の話5. まとめ20
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■分割後のチームの変化• デイリースクラム(朝会)• スプリントレトロスペクティブ(ふりかえり)• スプリントデモ• スプリントプランニング21
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■スプリントのタイムスケジュール22AM PM月火水木金朝会プラニング1プラニング2ふりかえり デモ夕会AM PM月火水木金朝会プラニング1プラニング2ふりかえり デモ夕会ふりかえり共有分割前分割後→かなり変更は少ない全員チーム別代表者凡例:
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■デイリースクラム(朝会)• チーム別に実施している• 内容は1チームスクラムと同じ• 15分間のタイムボックス• 昨日何をしたか/今日何をするか/困っていることは?23
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■デイリースクラム(朝会)• 他チームの様子を知るために「偵察」を送り込むプラクティスを紹介したが…• メンバーの意見を聞いた結果、全員参加することに• 全体共有→Aチーム朝会→Bチーム朝会の流れ• 最近はZOOMで実施していて物理的な制約がなく、短時間で済んでいるので2チームの間はこのスタイルで良いと思っている• 他のチームの話に割って入ってもOK• 「気になったことはどんどん質問しよう」と明確に言っている• チーム間の認識齟齬などは早い段階で発見したい狙い24
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■スプリントレトロスペクティブ(ふりかえり)• チームごとに実施する• 翌日、話したサマリーを他チームに共有する• 横断的な課題が出たときはオーバーオールレトロスペクティブを実施する• 大きな機能開発単位でのふりかえりなども必要に応じて開催25
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■スプリントレトロスペクティブ(ふりかえり)• 現在はMiroで実施している• 1チームスクラム時代にある程度慣れているのでやり方は任せている• ファシリテーターは持ち回り• KPTなど、手法はファシリテータが決めている• 大抵は下記の流れでやっている261. チェックイン(ルールの確認など)2. スプリント期間内の事実確認1. 運用や障害対応はどれぐらいあった?2. 割り込みはどれぐらいあった?3. (片方のチームは)感謝を伝える3. 付箋に記入4. 話し合うものを投票で決める5. 話し合い6. ふりかえりのふりかえり
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■スプリントデモ• ZOOMで週1時間で行っている• 参加者は事業部長、サポート、PO 、SM 、UIデザイナー、開発チーム全員• デモする人は当番制• 2チームになったが大きな変化はない27
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■スプリントプランニング• スプリントプランニング1• POと各チームの代表者が集まって、どのPBIを担当するかを決める• スプリントプランニング2• 各チームで個別にプランニングする(複数チームで協力する必要があれば複数チームでプランニングする)28
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■運用どちらかのチームに作業が依存しないように当番制で行う• 運用当番• 他部署からの依頼や質問の対応• リリース当番• リリース準備と立ち合い、リリース後作業を担当• アラート監視当番• 週ごとに当番制→ 担当する人が偏らないようにチーム内でもローテーション29
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■悩ましいところ• リーダを置くことのジレンマ• スクラム的にはリーダーという役割はない• スクラムチームが9人までというのはリーダーなしの限界が9人だから(らしい)• 元々ある問題だったが、2チームになり調整ごとが増え、より顕著に• 経験年数、性格によってはリーダに頼りたい様子• 今の自分達には、「リード役」がいないと難しいという事実を受け止め一旦はリーダーありの状態を許容している• 壁打ち相手になって「いいじゃない」という感じにしたい• 「決めて下さい」のような会話が多くないかは注視する30
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■悩ましいところ• PO が実質Proxy 問題• 現状はビジネス側のステークホルダーの意向をPOが確認していて一人のPOという原則を守れていないのが課題• プロダクトオーナーなのかプロジェクトマネージャなのか• POがプロジェクトマネージャ的な役割も一部担っている現状はこれで前に進むしかないが、POの仕事に集中することでスピード感アップしたい31事業部長製品企画 PO開発組織ビジネス側優先順位や要件を確認
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■悩ましいところ• いつの間にか「作ること」目的になってしまっていないか?• ちゃんと使ってもらいたい人に、使いやすいものを作れているのか?• 大きな機能開発ではユーザインタビューをするようにした• ユーザから直接意見を聞くことでの学びが多い32
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■悩ましいところ• インフラがチームに入っていない• 情報格差や受け渡しのコストが掛かりやすい• 現状は同じチームに入れることは難しいので情報共有を小まめにやり、お互いの領域をカバーし合うしかない• デザイナーもチームに入っていない• プレゼンテーションナルなコンポーネントをStorybookに切り出して作業分担しやすいようにトライ33
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■リモートワークでどうなったか• チーム開発の進め方としては大きな影響はなかった。• そのためには気軽に会話が始められる仕掛けが必要• 固定のZOOMのURLを用意しておく• BチームはNeWorkを使用中34
©2021 RAKUS Co., Ltd.#RAKUSMeetup1. 分割前の話2. 大規模スクラム手法 Less3. 分割してみる4. 分割後の話5. まとめ35
©2021 RAKUS Co., Ltd.#RAKUSMeetup あ■まとめ• 大きなギャップもなく2チーム制に移行できている• 2チームになったことで情報の受け渡しなどのオーバーヘッドが増えたことは間違いないが、必要なコストの範囲• 3~4チームになると別の課題が出るとは思うが今の延長で行けそうな感触• スクラムが出来ていればLessはやりやすい• 他の大規模スクラムのフレームワークと比べてLessは導入しやすい(と思う)36
©2021 RAKUS Co., Ltd.#RAKUSMeetupご清聴ありがとうございました37