Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
大規模で複雑!巨大レガシーシステムをリプレイスするためにスクラムチームを立ち上げた話
Search
KitazawaYoshitaka
June 14, 2022
Business
1
3.1k
大規模で複雑!巨大レガシーシステムをリプレイスするためにスクラムチームを立ち上げた話
大規模な課金系プラットフォームのリプレイスするためのスクラムチームを立ち上げる際にぶつかった課題と、それを解決するためにとった行動について紹介します。
KitazawaYoshitaka
June 14, 2022
Tweet
Share
More Decks by KitazawaYoshitaka
See All by KitazawaYoshitaka
DMM.comの課金プラットフォームにおけるサーバーサイドKotlin事情
ktzwystk
0
820
Other Decks in Business
See All in Business
ソーシング・ブラザーズ株式会社|会社説明資料
sbro
0
800
Introduction of Elastic Infra Inc.
elasticinfra
0
710
VISASQ: ABOUT US
eikohashiba
15
500k
M3 Career Culture Deck(セールス&コンサルティング職)
m3c
1
280k
国内ランサムウェア3事例から学ぶ中小病院におけるサイバーセキュリティ対策 / Cybersecurity Learned from Cases
henryofficial
0
260
FERMENSTATION Recruitment
fermenstation
0
400
アッテル会社紹介資料/culture deck
attelu
10
15k
DMM.com アルファ室採用案内資料
dmmcom2025
0
420
【Progmat】受益証券発行信託に係る税制改正の背景と今後のST市場
progmat
0
220
略歴 (2025年6月27日)
tsogo817421
2
240
株式会社BALLAS 会社案内
ballas_inc
0
20k
【全ポジション共通】㈱エグゼクション/会社紹介資料
exe_recruit
1
1.3k
Featured
See All Featured
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
233
17k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Gamification - CAS2011
davidbonilla
81
5.4k
GitHub's CSS Performance
jonrohan
1031
460k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
A Tale of Four Properties
chriscoyier
160
23k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
It's Worth the Effort
3n
185
28k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Navigating Team Friction
lara
187
15k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
50k
Faster Mobile Websites
deanohume
307
31k
Transcript
© DMM.com 大規模で複雑! 巨大レガシーシステムを リプレイスするために スクラムチームを立ち上げた話 新任スクラムマスターが向き合った課題とその対策 DMM.com 北澤由貴(Kitazawa
Yoshitaka) 2022年6月14日
© DMM.com 北澤 由貴 / Kitazawa Yoshitaka 2 自己紹介
DMM.com プラットフォーム事業本部 第2開発部 ポイントグループ Team Leader 2016年中途入社。 DMMポイント関連システムの保守/運用/開発に従事。 ポイントシステムのリプレイス、課金系マスタ管理サービスを構築する。 その他、開発チームの立ち上げを複数行い、現在はスクラムマスター 兼テックリードとして新しい課金系サービスの開発に従事している。 Twitter: @ystk_ktzw GitHub: kitazawa-yoshitaka
© DMM.com • 事業紹介 • 課題に向き合いチームを組成する • 成功と失敗 • まとめ
3 アジェンダ
© DMM.com 事業紹介 4
© DMM.com 事業紹介 DMMを支えるプラットフォーム 5 第1開発部 第3開発部 プラットフォーム戦略企画部 カスタマーサポート部 第2開発部
課金系プラットフォームを提供 今日話すのはここです!
© DMM.com DMMを支える課金プラットフォーム • 月間決済額 約150億円 • DMMポイントだけで約100億円規模 • 50を超えるサービスに課金機能を提供
• 主にAPIを各サービスに提供 • 1,000 request / second 以上 • エンドユーザー向けのフロントエンドも提供 6
© DMM.com プロジェクト紹介 Project-Rabbit • DMMのプラットフォームの大部分をリプレイスする • コードネーム:Rabbit • なぜリプレイスするのか
• プラットフォームの開発速度がDMMの事業展開についていけない • 複数システムの複雑な絡み合い • 継ぎ足し使ってきた秘伝のタレ 7 業務とシステムを整理し、DMMのスケールアップに対応させる
© DMM.com 本日の主題 Rabbit の中で、課金系のプラットフォームをリプレイスするため、スクラム チームを立ち上げました。 その際にぶつかった課題と、それを解決するために取った行動について紹 介します。 8
© DMM.com 課題に向き合い チームを組成する 9
© DMM.com 課題に向き合う Project-Rabbit の課題 • 大規模である • 複数のプロダクトが複雑に絡み合っている •
一つひとつのプロダクトの複雑性が高い • 全てを知るドメインエキスパートがいない 以上の課題を踏まえて、スクラムチームを立ち上げるまでに実施してきたこ とを紹介します。 10
© DMM.com ① 現状の整理と理想の定義 • リプレイス対象のプロダクトと、その関係性を図式化 • リプレイス後の理想形を図式化 • ギャップの把握
• 理想形にするためのやることを整理 11 現状の図式
© DMM.com ② 複数スクラムチーム組成計画 Spotifyモデルを参考に複数チームの組成を計画 • Spotifyモデル • 「ユニコーン企業のひみつ」で紹介されているコラボレーションパターン •
スクワッド • プロダクトに責任を持つメンバーが揃ったチーム • 作ったものを自分たちでメンテナンスする • 自分たちで自分たちの仕事を生み出す • トライブ • 類似、関連したミッションを持つスクワッドのまとまり • チャプター • トライブ内の同じ線も線を持つメンバーのグループ • ギルド • 組織を横断して生成される、専門分野についてのグループ 12
© DMM.com ② 複数スクラムチーム組成計画 Spotifyモデル 13
© DMM.com ② 複数スクラムチーム組成計画 Spotify モデルを Rabbit に落とし込む • スクワッド
• プロダクトに責任をもつスクラムチームを組成 • トライブ • 分割なし(課金プラットフォームのリプレイスという共通の目的) • チャプター • チームリーダー、テックリードのチャプターを組成 • ギルド • 既存プロダクトの運用保守チームとの協業グループを組成 14
© DMM.com ② 複数スクラムチーム組成計画 Spotify モデルを Rabbit に落とし込む 15
© DMM.com ③ パイロットチームの始動 • 1つのプロダクト(API)をリプレイスするチームを組成 • パイロットチームとして、今後のチーム組成のベースにする • チーム組成に必要なドキュメンテーション
• インセプションデッキ • 目的、背景、優先順位、方向性を端的に伝えるドキュメント • Product Requirements Document(PRD) • インセプションデッキより詳細化された要求仕様 • Rabbit では各プロダクトチームごとに作成 • Design Doc(DD) • What, How, Why を記載するドキュメント • 技術的な観点を含めた概要設計を記載 16
© DMM.com ③ パイロットチームの始動 • プロダクト内部の複雑性に対処するため、 段階的リプレイスを行うためのフェーズ分割を実施 (目安としては3ヶ月くらいで終わるイメージで分割) • Ph.1:
データベースのクラウド移設(負債脱却) • Ph.2: アプリケーションのリライト(負債脱却) • Ph.3: アプリケーションのリプレイス(良いプロダクトへの進化) • Ph.4: データベースのマイグレーション(良いプロダクトへの進化) • Ph.5: 継続的に進化、改善し続けるプロダクトへ... 17
© DMM.com ④ パイロットチームの拡大 • チーム組成時は4人チーム • 業務委託契約で5名増員し、9人体制でスプリント開始 • 改善のサイクルを早めるため1週間スプリントを採用
• 慣れてきてから2週間スプリントへ移行 • ZenHub を使用したかんばんボード形式でバックログを管理 • ペアプログラミング/スウォーミングを推奨 • スプリントの繰り返しで自走できるプロダクトチームへ... 18
© DMM.com 成功と失敗 19
© DMM.com 成功したこと • 現状と理想のプロダクトのマップを可視化 • チーム分割した際の役割範囲の明確化ができた • 自分のチームがプロジェクト全体のどこをやっているのか説明しやすい •
ドキュメンテーション • インセプションデッキ、Product Requirements Document(PRD)、Design Doc(DD) を作成することで、オンボーディングが容易 • 4名→9名にスケールした際もスムーズにいけた • チーム文化の形成 • ペアプロやスウォーミングをすることで、温度感や方向性のすり合わせ、スキルや 知見の共有がいい感じになった • 開発チームが自走できる状態になってきた 20
© DMM.com 失敗したこと • Spotifyモデルのようには いかない • スクラムチーム間の コミュニケーションは リーダーチャプターに
寄ってしまった 21
© DMM.com 失敗したこと • スクラムマスター不在の状況 • 私がプロダクトオーナーを引き受けたタイミングでスクラムマスター不在に • 当時は開発チームを減らしたくないという思いが強かった •
役割を明確にしないことで、 スクラムを機能させることの責任の所在が不明確に… • 経験のあるメンバーのフォローに感謝…! 22
© DMM.com まとめ 23
© DMM.com まとめ 大規模開発におけるスクラムチームを組成するために 実践してきたことと、成功と失敗についてお話しました。 私の経験で参考になったところがありましたら、 是非皆様のチームの糧にしていただければと思います! 24
© DMM.com ご清聴ありがとうございました