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
Top 07 Ways to connect QuickBooks Payroll Support Number
qbpayroll1
0
190
[ 24/7~ HELP™] QuickBooks® ^^Enterprise Online Help for USA user
hisepiyi
0
120
大AI時代を長く活躍するための 「コンフォート・ゾーン」の新解釈
mkitahara01985
0
1.1k
7 Best Ways to Reach HP Printer Support Number (USA 2025) 📞 +1-888-503-6380
charlesmick
0
280
ties|クラウド顧客・案件管理システム - サービスのご紹介
so_kotani
2
470
How can i speak to someone at Expedi𝓪® USA : A Complete Guide Steps
travelhupsupport
0
120
コミュニティでUGCを増やす技術
chlorine0528
1
280
Talk to Someone At Expedi𝓪™️ USA Contact Numbers
travelcare
0
120
Management Workflow
dskst
2
390
{{ Fix~it~Fast }} How to ReSolve QuickBooks Enterprise Errors via Phone?
likoxe
0
120
【DearOne】Dear Newest Member
hrm
2
10k
アウトカムファーストな専門技術組織の構築と運用のための取り組み / Efforts to Build and Operate an Outcome-First Technical Expertise Organization
lycorptech_jp
PRO
5
470
Featured
See All Featured
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Thoughts on Productivity
jonyablonski
69
4.7k
Optimizing for Happiness
mojombo
379
70k
Code Review Best Practice
trishagee
69
19k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
Agile that works and the tools we love
rasmusluckow
329
21k
Writing Fast Ruby
sferik
628
62k
How to Think Like a Performance Engineer
csswizardry
25
1.7k
How STYLIGHT went responsive
nonsquared
100
5.6k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
RailsConf 2023
tenderlove
30
1.1k
Building an army of robots
kneath
306
45k
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 ご清聴ありがとうございました