1 ©MIXI スクラムマスターなしでも いい感じにスクラム開発している話 アジャイル開発エンジニア勉強会〜各社の取り組みや課題から学ぶ会〜 株式会社MIXI ﾗｲﾌﾞｴｸｽﾍﾟﾘｴﾝｽ事業本部 ﾌｧﾝｺﾐｭﾆｹｰｼｮﾝ部 Fansta開発ｸﾞﾙｰﾌﾟFansta第1開発ﾁｰﾑ ⽇下亜紀⼦

©MIXI 2 Fanstaとは ● サッカー/野球/ラグビーのライブビューイングができる店舗の検索‧予約サービス ● Web版とApp版（iOSとAndroid）がある

©MIXI 3 開発の歴史 2020年秋 2021年4⽉ 4⽉ 2021年8⽉ 開発開始 Web版リリース 私含めエンジニア3⼈採⽤して10⼈規模 のチームに スクラムではなく、タスクボードでタ スクのステータス管理をしていた程度 WebとAppチームを統合 MGRがスクラム勉強会を⾏い、 POとなりスクラム開発開始 ちょっとずつ改善を 繰り返して約3年経過... App版リリース 2022年3⽉

©MIXI 4 スクラムの特徴 ● スクラムマスターは不在 ○ リソース不⾜のため ○ 全員で主体的に進められそうな期待があったため ● 開発チームはエンジニア 4名とQA 3名の計7名 ○ デザイナーは含まない ● 2週間スプリント ● スクラムの会議体は全て実施している ○ スプリントレビュー、スプリントレトロスペクティブ、スプリン トプランニングで丸⼀⽇ ○ デイリースクラム（リファインメント含む）を毎⽇15分~1時間 ○ スクラムマスターがいないので、ファシリは全員でローテーショ ンしている

©MIXI 5 どうしていい感じに回っているって思えるんだろう？ ①開発チームが⾃分たちだけでスプリントゴールを達成する⼒があると感 じられている （情報の透明性、POへの信頼、⼼理的安全性の⾼さ、技術⼒の網羅性） ②スプリントレトロスペクティブが活発で、スプリントごとに継続的にプ ロセスを改善している実感がある

©MIXI 6 今までの改善例 ● カンバンツールをTrelloからGitHub Projectsに移⾏してissueやPRと の紐付けを楽にした ● ベロシティとは別に⼯数ベースのキャパシティを導⼊してベロシティ 予測の精度を上げた ● PBIごとの不具合数も算出してふりかえりの指標にした ● レビュー待ちのPRをスプリントバックログボードで⾒える化してデイ リーで確認することで開発フローが滞らないようにした ● ペアプロ‧ペアワークを積極的にするようになった etc…

©MIXI 7 どうしていい感じなんだろう？ ● T型スキルの⼈材を採⽤している ○ エンジニアはWeb/App、フロントエンド/バックエンド、どのタ スクでもこなせる ○ スクラムの考え⽅にも共感している ● チームメンバーの変動が少ない ● スクラムマスターは不在でも、スクラムが好きで率先してインプット ＆アウトプットする有志がいる ● 開発チームとは別に遊撃部隊というインフラ系の担当者が1⼈いて、 プロセスの⾃動化周りを⽀援してくれる ○ CI/CD、バーンダウンチャートなどのスクラム便利ツールの⾃動 化など

©MIXI 8 それでももちろん課題はある ● スクラムマスターはいるに越したことはない ● 開発メンバーだけだと実現に時間のかかる改善がしづらい ○ 開発を⽌めるような⼤きめの改善は進めにくい ○ 時間をかけて試⾏錯誤しながら効果を試す改善もしづらい

©MIXI 9 もしもスクラムマスターがいたら ● 新しいメンバーへのスクラム開発のインプットをしたい ○ 現状やりながら慣れてもらっているが、慣れるのに時間がかかる ので⼀気にインプットした⽅が早く受け⼊れてもらえそう ● もっとエンジニアとQAの壁をなくしていきたい ○ E2Eテストの⾃動化の推進をしたり ○ エンジニアでもE2Eテストを実装‧保守できるようになったり ○ QAでも不具合の原因調査ができるようになったり ● スプリントレトロスペクティブでKPT以外を試したい ○ そのときどきの課題に合ったふりかえり⼿法の選定‧実験 etc…

10 ©MIXI