登壇者はこの方
日下 亜紀子 氏
株式会社MIXI
ライブエクスペリエンス事業本部 ファンコミュニケーション部
Fansta開発グループ Fansta第1開発チーム
2015年にFA機器メーカーに新卒入社し、ウォーターフォール開発を経験。 その後、技術系雑誌の編集職を経て、2019年に技術系スタートアップ企業に入社。そこで初めてスクラム開発に触れる。2021年からは株式会社ミクシィ（現 MIXI）でFanstaというスポーツ観戦に特化した店舗の検索・予約サービスの開発を担当し、スクラムマスターではないものの積極的に開発プロセスの改善に取り組んでいる。
日下：本日は「スクラムマスターなしでもいい感じにスクラム開発している話」と題して、私たちのチームでの取り組みをご紹介します。
開発の歴史
開発は2020年秋にスタートし、翌年春にWeb版をリリース。その後、事業の拡大に伴い、2021年8月に私を含むエンジニア3名が新たに加わり、10名規模のチームとなりました。
当初は「スクラム開発」として明確に運用していたわけではなく、タスクボードによるステータス管理が中心でした。その後アプリ版の開発が始まり、チームは「Web側」と「アプリ側」に分割。一連のリリースが落ち着いたタイミングでチームを再統合し、本格的にスクラム開発を導入することとなりました。
導入時には全員で『スクラムブートキャンプ』を読み、スクラム経験のあるマネージャーと勉強会を実施。そのマネージャーがプロダクトオーナー（PO）として就任し、現在のスクラム運用が始まりました。
私たちのスクラムの特徴
最大の特徴は、「スクラムマスター不在」でスクラムを運用していることです。
リソースに限りがあるなか、新機能を次々にリリースしたいフェーズだったため、スクラムマスターを明示的に配置することは見送りました。その代わり、開発メンバー全員が主体的にスクラムマスターの役割を分担・実践することで、うまく機能しています。
また、デザイナーがチームにいないため、開発の着手はデザインが確定してからというルールを設けています。なお、スプリント期間は開始当初から変わらず「2週間」を継続。スクラムガイドに記載されている全てのイベントも実施しており、各イベントのファシリテーションはメンバーがローテーションで担っています。
「いい感じ」の定義とは？
私たちが「いい感じ」と感じている状態を、以下のように定義しています。
スプリントゴールの理解と主体的なタスク設計
POが提示するスプリントゴールに対し、開発チームが自らタスクを分解し、ポイント見積もりを行ったうえで、実現可能性を自信を持って説明できる状態です。仕様や判断材料は常に共有されており、POとも気軽に確認・提案ができる心理的安全性が保たれています。
継続的な改善の実践
スプリントごとに実施している振り返りで活発な意見交換が行われ、実際の改善施策につながっています。定期的な見直しができており、組織としてのアップデートが継続的に行われている点が評価ポイントです。
今までの改善例
以下のような改善を実施してきました。
カンバンツールを GitHub Projects に移行
タスクのIssueやPull Requestとの紐付けが簡易化し、タスク管理の一元化が実現。
工数ベースのキャパシティ導入
ベロシティの予測精度が向上し、より現実的なスプリント計画が立てられるように。
レビュー待ちPRの可視化
ボード上でレビュー待ちが確認できるようになり、放置されることが減少。リリース遅延の防止にもつながっています。
なぜ「いい感じ」に運用できているのか？
ポイントは以下の4点です。
T型人材の採用
専門性を持ちつつも幅広い領域に関心を持つメンバーで構成されており、スクラムの運用も自律的に行えています。
チーム構成の安定
メンバーの入れ替わりが少なく、経験の蓄積と継承がスムーズに行えています
スクラムが好きで率先してインプット＆アウトプットする有志
スクラムマスターは不在でも、スクラムが好きで率先してインプット＆アウトプットする有志がいる
遊撃部隊というインフラ系の担当者
開発チームとは別に遊撃部隊というインフラ系の担当者が1人いて、CI/CDやテスト自動化の支援など、プロセスの自動化周りを支援してくれる
現状の課題と「もしもスクラムマスターがいたら」
もちろん、すべてが順風満帆というわけではありません。
スクラムマスターがいないことによって、時間のかかる実験的な改善や、大規模な変革の推進は難しいと感じています。特にQAメンバーの入れ替わりが多く、スクラムへのキャッチアップに負荷がかかっている現状は課題です。
もしスクラムマスターがいれば…
- QAメンバーへのオンボーディングをより丁寧に支援できる
- エンジニアとQAの職域を越えた連携（T型スキルの促進）に向けた活動がしやすくなる
- 振り返り（レトロスペクティブ）でKPT以外のフレームワークにも挑戦できる
など、チームのさらなる成長が期待できると考えています。
おわりに
スクラムマスター不在でも「いい感じ」にスクラムを運用できているチームの一例として私たちのチームの現状を紹介しました。
その要因としては、「T型スキルのある人材」「主体性の高いチーム」「支援体制の工夫」など、複数の好条件が揃っていることが挙げられます。
本日の発表が、スクラムの運用に悩む皆さまの一助となれば幸いです。
以上で、発表は終わりです。
▼▼ぜひ他登壇者の発表レポートもご覧ください
アジャイル開発エンジニア勉強会
イベント中にあがったQ＆Aはこちらをチェック！
こうして私はスクラムマスターをやめた。
小林壮太さんの発表内容については、以下の記事リンクからご覧ください。
こうして私はスクラムマスターをやめた。【アジャイル開発エンジニア勉強会／イベントレポート】 - TECH Street (テックストリート)
スクラムマスターなしでもいい感じにスクラム開発している
日下 亜紀子さんの発表内容については、以下の記事リンクからご覧ください。
スクラムマスターなしでもいい感じにスクラム開発している話【アジャイル開発エンジニア勉強会／イベントレポート】 - TECH Street (テックストリート)
スクラムとウォーターフォールの間で開発スタイルを模索している話
ウチノさんの発表内容については、以下の記事リンクからご覧ください。
スクラムとウォーターフォールの間で開発スタイルを模索している話【アジャイル開発エンジニア勉強会／イベントレポート】 - TECH Street (テックストリート)
