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
3k
大規模で複雑!巨大レガシーシステムをリプレイスするためにスクラムチームを立ち上げた話
大規模な課金系プラットフォームのリプレイスするためのスクラムチームを立ち上げる際にぶつかった課題と、それを解決するためにとった行動について紹介します。
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
セーフィー株式会社(Safie Inc.) 会社紹介資料
safie_recruit
6
310k
【株式会灯白社】会社紹介資料_カンパニーデック
tohakusha202006
0
550
フレームワークを生み出すメタフレームワークという考え方 -適応型から生成型へ- #RSGT2025 / From adaptive to generative
kyonmm
PRO
2
2.8k
Srush Company Deck
tomomifuruya
0
3.7k
2025年版 新入社員研修で使えるビジネスゲーム7選
chibanba1982
PRO
0
440
会社案内資料
mkengineering
1
340
サスメド株式会社 Culture Deck
susmed
0
38k
キャッチアップ会社紹介
catchup
2
52k
ABCash会社紹介資料「Culture Deck2025」
abcash_recruit
0
11k
NewsPicks Expert説明資料 / NewsPicks Expert Introduction
mimir
0
11k
一年間の試行錯誤で改善! WordPressサイト制作フローと受注スタイル
koots2021
1
260
クロスマート株式会社_会社紹介資料
xmart_recruit
2
380
Featured
See All Featured
Building an army of robots
kneath
302
45k
Learning to Love Humans: Emotional Interface Design
aarron
274
40k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
45
2.3k
Measuring & Analyzing Core Web Vitals
bluesmoon
6
220
It's Worth the Effort
3n
184
28k
Become a Pro
speakerdeck
PRO
26
5.1k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
RailsConf 2023
tenderlove
29
980
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
39
1.9k
Facilitating Awesome Meetings
lara
51
6.2k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.2k
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 ご清聴ありがとうございました