大規模で複雑！巨大レガシーシステムをリプレイスするためにスクラムチームを立ち上げた話

大規模な課金系プラットフォームのリプレイスするためのスクラムチームを立ち上げる際にぶつかった課題と、それを解決するためにとった行動について紹介します。

Transcript

1. © DMM.com 大規模で複雑！
 巨大レガシーシステムを
 リプレイスするために
 スクラムチームを立ち上げた話 
 新任スクラムマスターが向き合った課題とその対策
 DMM.com 北澤由貴（Kitazawa Yoshitaka）
 2022年6月14日

2. © DMM.com 北澤 由貴 / Kitazawa Yoshitaka
 
 2 自己紹介
 DMM.com プラットフォーム事業本部
 第2開発部 ポイントグループ Team Leader
 
 2016年中途入社。
 DMMポイント関連システムの保守/運用/開発に従事。
 ポイントシステムのリプレイス、課金系マスタ管理サービスを構築する。 その他、開発チームの立ち上げを複数行い、現在はスクラムマスター 兼テックリードとして新しい課金系サービスの開発に従事している。
 Twitter: @ystk_ktzw GitHub: kitazawa-yoshitaka 
 

3. © DMM.com • 事業紹介
 • 課題に向き合いチームを組成する
 • 成功と失敗
 • まとめ
 3 アジェンダ

4. © DMM.com 事業紹介
 4
5. © DMM.com 事業紹介
 DMMを支えるプラットフォーム
 5 第1開発部
 第3開発部
 プラットフォーム戦略企画部
 カスタマーサポート部
 第2開発部
 
 課金系プラットフォームを提供
 今日話すのはここです！

6. © DMM.com DMMを支える課金プラットフォーム
 • 月間決済額 約150億円
 • DMMポイントだけで約100億円規模
 • 50を超えるサービスに課金機能を提供
 • 主にAPIを各サービスに提供
 • 1,000 request / second 以上
 • エンドユーザー向けのフロントエンドも提供
 6
7. © DMM.com プロジェクト紹介
 Project-Rabbit　
 • DMMのプラットフォームの大部分をリプレイスする
 • コードネーム：Rabbit
 • なぜリプレイスするのか
 • プラットフォームの開発速度がDMMの事業展開についていけない
 • 複数システムの複雑な絡み合い
 • 継ぎ足し使ってきた秘伝のタレ
 7 業務とシステムを整理し、DMMのスケールアップに対応させる

8. © DMM.com 本日の主題
 Rabbit の中で、課金系のプラットフォームをリプレイスするため、スクラム チームを立ち上げました。
 その際にぶつかった課題と、それを解決するために取った行動について紹 介します。
 8
9. © DMM.com 課題に向き合い
 チームを組成する
 9
10. © DMM.com 課題に向き合う
 Project-Rabbit の課題
 • 大規模である
 • 複数のプロダクトが複雑に絡み合っている
 • 一つひとつのプロダクトの複雑性が高い
 • 全てを知るドメインエキスパートがいない
 以上の課題を踏まえて、スクラムチームを立ち上げるまでに実施してきたこ とを紹介します。
 10
11. © DMM.com ① 現状の整理と理想の定義
 • リプレイス対象のプロダクトと、その関係性を図式化
 • リプレイス後の理想形を図式化
 • ギャップの把握
 • 理想形にするためのやることを整理
 11 現状の図式

12. © DMM.com ② 複数スクラムチーム組成計画
 Spotifyモデルを参考に複数チームの組成を計画
 • Spotifyモデル
 • 「ユニコーン企業のひみつ」で紹介されているコラボレーションパターン
 • スクワッド
 • プロダクトに責任を持つメンバーが揃ったチーム
 • 作ったものを自分たちでメンテナンスする
 • 自分たちで自分たちの仕事を生み出す
 • トライブ
 • 類似、関連したミッションを持つスクワッドのまとまり
 • チャプター
 • トライブ内の同じ線も線を持つメンバーのグループ
 • ギルド
 • 組織を横断して生成される、専門分野についてのグループ
 
 12
13. © DMM.com ② 複数スクラムチーム組成計画
 Spotifyモデル
 13
14. © DMM.com ② 複数スクラムチーム組成計画
 Spotify モデルを Rabbit に落とし込む
 • スクワッド
 • プロダクトに責任をもつスクラムチームを組成
 • トライブ
 • 分割なし（課金プラットフォームのリプレイスという共通の目的）
 • チャプター
 • チームリーダー、テックリードのチャプターを組成
 • ギルド
 • 既存プロダクトの運用保守チームとの協業グループを組成
 
 14
15. © DMM.com ② 複数スクラムチーム組成計画
 Spotify モデルを
 Rabbit に落とし込む
 
 15
16. © DMM.com ③ パイロットチームの始動
 • 1つのプロダクト（API）をリプレイスするチームを組成
 • パイロットチームとして、今後のチーム組成のベースにする
 • チーム組成に必要なドキュメンテーション
 • インセプションデッキ
 • 目的、背景、優先順位、方向性を端的に伝えるドキュメント
 • Product Requirements Document（PRD）
 • インセプションデッキより詳細化された要求仕様
 • Rabbit では各プロダクトチームごとに作成
 • Design Doc（DD）
 • What, How, Why を記載するドキュメント
 • 技術的な観点を含めた概要設計を記載
 16
17. © DMM.com ③ パイロットチームの始動
 • プロダクト内部の複雑性に対処するため、
 段階的リプレイスを行うためのフェーズ分割を実施
 （目安としては3ヶ月くらいで終わるイメージで分割）
 • Ph.1: データベースのクラウド移設（負債脱却）
 • Ph.2: アプリケーションのリライト（負債脱却）
 • Ph.3: アプリケーションのリプレイス（良いプロダクトへの進化）
 • Ph.4: データベースのマイグレーション（良いプロダクトへの進化）
 • Ph.5: 継続的に進化、改善し続けるプロダクトへ...
 
 17
18. © DMM.com ④ パイロットチームの拡大
 • チーム組成時は4人チーム
 • 業務委託契約で5名増員し、9人体制でスプリント開始
 • 改善のサイクルを早めるため1週間スプリントを採用
 • 慣れてきてから2週間スプリントへ移行
 • ZenHub を使用したかんばんボード形式でバックログを管理
 • ペアプログラミング/スウォーミングを推奨
 • スプリントの繰り返しで自走できるプロダクトチームへ...
 18
19. © DMM.com 成功と失敗
 19
20. © DMM.com 成功したこと
 • 現状と理想のプロダクトのマップを可視化
 • チーム分割した際の役割範囲の明確化ができた
 • 自分のチームがプロジェクト全体のどこをやっているのか説明しやすい
 • ドキュメンテーション
 • インセプションデッキ、Product Requirements Document（PRD）、Design Doc（DD） を作成することで、オンボーディングが容易
 • 4名→9名にスケールした際もスムーズにいけた
 • チーム文化の形成
 • ペアプロやスウォーミングをすることで、温度感や方向性のすり合わせ、スキルや 知見の共有がいい感じになった
 • 開発チームが自走できる状態になってきた
 20
21. © DMM.com 失敗したこと
 • Spotifyモデルのようには
 いかない
 • スクラムチーム間の
 コミュニケーションは
 リーダーチャプターに
 寄ってしまった
 21
22. © DMM.com 失敗したこと
 • スクラムマスター不在の状況
 • 私がプロダクトオーナーを引き受けたタイミングでスクラムマスター不在に
 • 当時は開発チームを減らしたくないという思いが強かった
 • 役割を明確にしないことで、
 スクラムを機能させることの責任の所在が不明確に…
 • 経験のあるメンバーのフォローに感謝…！
 22
23. © DMM.com まとめ
 23
24. © DMM.com まとめ
 大規模開発におけるスクラムチームを組成するために
 実践してきたことと、成功と失敗についてお話しました。
 私の経験で参考になったところがありましたら、
 是非皆様のチームの糧にしていただければと思います！
 24
25. © DMM.com ご清聴ありがとうございました