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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

© DMM.com ② 複数スクラムチーム組成計画  Spotifyモデルを参考に複数チームの組成を計画  • Spotifyモデル  • 「ユニコーン企業のひみつ」で紹介されているコラボレーションパターン  • スクワッド  • プロダクトに責任を持つメンバーが揃ったチーム  • 作ったものを自分たちでメンテナンスする  • 自分たちで自分たちの仕事を生み出す  • トライブ  • 類似、関連したミッションを持つスクワッドのまとまり  • チャプター  • トライブ内の同じ線も線を持つメンバーのグループ  • ギルド  • 組織を横断して生成される、専門分野についてのグループ    12

Slide 13

Slide 13 text

Slide 14

Slide 14 text

© DMM.com ② 複数スクラムチーム組成計画  Spotify モデルを Rabbit に落とし込む  • スクワッド  • プロダクトに責任をもつスクラムチームを組成  • トライブ  • 分割なし（課金プラットフォームのリプレイスという共通の目的）  • チャプター  • チームリーダー、テックリードのチャプターを組成  • ギルド  • 既存プロダクトの運用保守チームとの協業グループを組成    14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

© DMM.com ③ パイロットチームの始動  • 1つのプロダクト（API）をリプレイスするチームを組成  • パイロットチームとして、今後のチーム組成のベースにする  • チーム組成に必要なドキュメンテーション  • インセプションデッキ  • 目的、背景、優先順位、方向性を端的に伝えるドキュメント  • Product Requirements Document（PRD）  • インセプションデッキより詳細化された要求仕様  • Rabbit では各プロダクトチームごとに作成  • Design Doc（DD）  • What, How, Why を記載するドキュメント  • 技術的な観点を含めた概要設計を記載  16

Slide 17

Slide 17 text

© DMM.com ③ パイロットチームの始動  • プロダクト内部の複雑性に対処するため、  段階的リプレイスを行うためのフェーズ分割を実施  （目安としては3ヶ月くらいで終わるイメージで分割）  • Ph.1: データベースのクラウド移設（負債脱却）  • Ph.2: アプリケーションのリライト（負債脱却）  • Ph.3: アプリケーションのリプレイス（良いプロダクトへの進化）  • Ph.4: データベースのマイグレーション（良いプロダクトへの進化）  • Ph.5: 継続的に進化、改善し続けるプロダクトへ...    17

Slide 18

Slide 18 text

© DMM.com ④ パイロットチームの拡大  • チーム組成時は4人チーム  • 業務委託契約で5名増員し、9人体制でスプリント開始  • 改善のサイクルを早めるため1週間スプリントを採用  • 慣れてきてから2週間スプリントへ移行  • ZenHub を使用したかんばんボード形式でバックログを管理  • ペアプログラミング/スウォーミングを推奨  • スプリントの繰り返しで自走できるプロダクトチームへ...  18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

© DMM.com 成功したこと  • 現状と理想のプロダクトのマップを可視化  • チーム分割した際の役割範囲の明確化ができた  • 自分のチームがプロジェクト全体のどこをやっているのか説明しやすい  • ドキュメンテーション  • インセプションデッキ、Product Requirements Document（PRD）、Design Doc（DD）を作成することで、オンボーディングが容易  • 4名→9名にスケールした際もスムーズにいけた  • チーム文化の形成  • ペアプロやスウォーミングをすることで、温度感や方向性のすり合わせ、スキルや知見の共有がいい感じになった  • 開発チームが自走できる状態になってきた  20