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
営業疑似体験ゲーム「ヒアリングチャレンジオンライン版」
chibanba1982
PRO
0
100
ロジカルシンキング研修用スライド
chibanba1982
PRO
0
240
家族アルバム みてね 事業紹介 / Our Business
familyalbum
4
28k
P2B Haus法人サポータープランのご提案
sotarok
2
1.1k
SpiderPlus & Co. 会社紹介資料
spiderplus_cb
0
500
心理的安全性をテーマにしたチームビルディングゲーム「ベストチーム」
chibanba1982
PRO
0
370
ABCash会社紹介資料「Culture Deck2025」
abcash_recruit
0
9.8k
ログラス会社紹介資料 新卒採用 ビジネス職[経営幹部候補]/ Loglass Company Deck
loglass2019
1
2k
comorebi_cultuerdeck_2025
comorebi_tokyo
0
290
危機管理コンセンサスゲーム「船長の決断 カード版」
chibanba1982
PRO
0
270
【エンジニア採用】BuySell Technologies会社説明資料
buyselltechnologies
3
56k
良い仮説を評価する技術
tumada
PRO
21
6.9k
Featured
See All Featured
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
For a Future-Friendly Web
brad_frost
176
9.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
348
20k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.9k
GraphQLの誤解/rethinking-graphql
sonatard
68
10k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
GraphQLとの向き合い方2022年版
quramy
44
13k
Being A Developer After 40
akosma
89
590k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
59k
Building Applications with DynamoDB
mza
92
6.1k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.5k
Side Projects
sachag
452
42k
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 ご清聴ありがとうございました