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
仮説検証サイクルを高速で回す為に、DMMポイントクラブ アプリチームが行っている取り組み | ...
Search
Shunsuke Nakao
December 15, 2021
3
640
仮説検証サイクルを高速で回す為に、DMMポイントクラブ アプリチームが行っている取り組み | DMM iOS Meetup #2
Shunsuke Nakao
December 15, 2021
Tweet
Share
More Decks by Shunsuke Nakao
See All by Shunsuke Nakao
モバイルアプリのSLI/SLOについて考える | DMM.swift #2
noa4021j
2
640
開発生産性とどう向き合うか | DMM Meetup #39
noa4021j
21
7.6k
Teslaに学ぶ開発高速化とDMMポイントクラブの挑戦 | DMM Meetup #38
noa4021j
2
550
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
519
39k
Faster Mobile Websites
deanohume
304
30k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
167
49k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
32
1.8k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
800
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
The Cost Of JavaScript in 2023
addyosmani
45
6.6k
Designing the Hi-DPI Web
ddemaree
280
34k
A Philosophy of Restraint
colly
203
16k
Transcript
仮説検証サイクルを 高速で回す為に、 DMMポイントクラブ アプリチームが 行っている取り組み @noa4021J DMM iOS Meetup #2
2021.12.15
自己紹介 中尾 俊介 Nakao Shunsuke 合同会社DMM.com プラットフォーム事業本部 メンバーシップサービス部 DMM ポイントクラブグループ
iOS Engineer @noa4021J github.com/noa4021J 2021年4月新卒入社。DMMポイントクラブ iOSアプリの開発に従事。
DMMポイントを貯めて、使って、管 理できる、DMMの新しいポイント サービス。
• 2021年4月にiOS/Androidで先行リリース • 2021年9月にWeb版をリリース • くじ引き機能やポイントチャージ機能、 レポーティング機能など順次機能追加中 https://lp.pointclub.dmm.com/
iOS Engineer 4人 Android Engineer 4人 DMMポイントクラブの開発体制 Designer 1人 Product
Owner 1人 Growth/Marketer 1人 Mobile App team Web team Frontend Engineer Backend Engineer 6人 全体で20名弱が在籍。内、新卒8名 (19新卒以降)
• 仮説検証サイクルに「 BMLループ」を 型として採用 • 職能に関係なく全員が仮説を立て、データ を取って分析し学習する。プロダクトへの 反映は各職能で行う DMMポイントクラブの開発手法 Build
Measure Learn Product Data Idea 1. Build … 仮説からプロダクトを作る 2. Measure … プロダクトをリリースし、顧客の反応を 計測、”データ”を得る 3. Learn … データをもとに学習し、新たな仮説に反 映する cf: リーン・スタートアップ - エリック・リース著
仮説検証サイクルを運用する上で モバイルアプリチームが抱えていた課題
Backlogに積んだ施策の消化量が少なく、 着手までに長い時間が掛かっていた • 各メンバーが提案した施策をチケット化し、施策用の Backlogに 積み上げていく(ボトムアップ) • iOS/Android版の本格リリースの 1ヶ月後には上記運用を開始、 当時既に37個の施策が積み上がっており、現時点では
70個以上 の施策が控えている • 運用開始直後は1ヶ月で3個程度しか完了できなかった DMMポイントクラブ アプリチームが抱えていた課題
仮説検証サイクルの高速化を目指す専門チーム (通称: カセツバクシンオー) Designer 1人 Web team Backend Engineer 1人
Mobile App team iOS Engineer 1人 Android Engineer 1人 1ヶ月ペースで1~2名程度入れ替え 開発リソースを全て施策進行に振った、施策の進行に専念するチーム
DMM PointClub 開発メンバー 施策BANK 施策をチケット化 IDEA 施策チーム プロダクトへ反映 PRODUCT 施策チームの責務
検証結果共有 LEARN データ分科会 DATA データ計測、分析 MEASURE 検証方法の要件定義、実 装 BUILD #施策案壁打ち
DMM PointClub 開発メンバー 施策BANK 施策をチケット化 IDEA 施策チーム プロダクトへ反映 PRODUCT 施策チームの責務
検証結果共有 LEARN データ分科会 データ計測、分析 MEASURE 検証方法の要件定義、実 装 BUILD #施策案壁打ち BUILD → MEASUREを専門に回し 続けることで試行回数を増やし、仮説 検証サイクルを高速に回す為のノウ ハウを蓄積。 定期的にメンバーを入れ替え知見共 有しながら、開発チーム全体へ還元す る
施策チームの活動サイクル
施策チームの活動サイクル 1. 施策案の要件定義、検証方法の策定 2. (デザイン作成) 3. 実装 4. QA /
リリース 5. 分析用ダッシュボード、クエリの作成 6. 定例での検証結果共有
1. 施策案の要件定義、検証方法の策定 2. (デザイン作成) 3. 実装 4. QA / リリース
5. 分析用ダッシュボード、クエリの作成 6. 定例での検証結果共有 施策チームの活動サイクル 基本、1施策1担当 適宜必要なメンバーの取り付け、外 部との調整など、横断的な施策の進 行をリードする。
PRD Product Requirements Document Step1. 施策案の要件定義、検証方法の策定 施策BANK Design Doc •
何を(What) • 何のために(Why) • どのように作るのか(How)を定義する ( What / Why ) • 問題、仮説などのWhyに対するソ リューションの定義 • 実現可能性の調査 • ステークホルダーとの合意形成 ( What / Why ) • PRDで決めたソリューションの具 体的な実現方法の定義(デザイン, システム設計) • テスト項目の作成、周知やリリー ス時の計画など ( How ) 優 先 度 (粗削り)
Step1のPRD~DD定義の段階で、同時並行で作成。 • PRD段階:PRDの内容(ユーザーストーリーマッピング etc)を元にプロトタイプを作成 • DDの段階:要件や各ガイドライン( HIG/MateriaI Design)に則ってプロトタイプを洗練 →デザイ ンFix
Step2. デザイン作成 DesignDoc PRD Designer UI Design Prototype
普通に実装します。 施策チームとは別で、 ”開発サイクルの高速化 ”を目指す プロジェクトがありますが、今回は時間の都合上割愛。 Step3. 実装 DesignDoc Backend Engineer
Android Engineer iOS Engineer iOS/Android API UI Design
実装が完了後、機能単位でテストを実施。 実装後にテストを実施することで、リリース時に行うテストの負担を減らす。 既存の機能への影響が考えられる場合はそこもテストする。 Step4. QA, リリース テスト項目書 検証用アプリ 開発メンバー 非実装者
修正作業 🥳 リリース可 😭 バグ報告 リリース作業 基本1~2週間毎にリリース
Step5. 分析用ダッシュボードの作成 リリース後、データが溜まってきた段階で分析用のクエリを作成。 PRD/DDの作成時に効果測定に必要な情報の定義も行なっているので、それを参考にダッシュボードを作る。 • エンジニアは全員クエリを書ける 前提なので、分析も自前で行う • 効果測定に必要な情報の定義と 書いたクエリで出てきた数値に
誤りがないかをレビュー
Step6. 定例での検証結果共有 データ分科会にてダッシュボード、検証結果を共有。 • 仮説は何だったか • 検証方法は何か • 検証結果はどうだったか 学習結果を元に、開発メンバーがそ
れぞれ新たな施策を作成 データと試行回数を積み重ね、仮説 検証の質を上げていく 施策メンバーは次に待つ新たな施策へ...
KPTを用いて、メンバーの入れ替え時に振り返りを実施 メンバー入れ替え(因子継承) • KPTにあがってきたものから次 期メンバーに引き継ぐノウハウ やプロブレムに対する Tryを集約 し共有(通称:因子)
施策チームを導入してみた結果
導入前 施策チームの導入後の結果 導入後 • 開発系(機能拡充etc) : 2個 • 開発以外(マーケetc):1個 3個
11個 • 開発系(機能拡充etc) : 7個 • 開発以外(マーケetc):4個 施策実施量/月
• 開発リソースを施策の実施に移動させたのが高速化の大きな要因なため、ト レードオフ →試行回数が増えていくにつれ、作業効率は上がっていくと想定 施策チーム導入で得た知見 Pros Cons • 施策の進行のみに集中することが決まっている為、施策の進行が止まること がない
→ 1つの施策で待機が発生しても、別の施策を並行して進行可能 • 施策進行の形式化により施策の進行速度が上昇 → 施策進行がある程度形式化され、合意形成のタイミングが最適化された
• 施策が進む代わりに開発環境の改善や不具合に関する Issueが進められず、 溜まっている • デザイナーがグループで1人しかいないため、デザイナーの負荷が高くボトル ネックになっている • 施策メンバーとその他開発メンバーの役割が明確になっていない •
1施策1担当制なため、施策メンバー間での連携やコミュニケーションが少なく、 施策メンバー同士での知見共有の機会が少ない 現状の課題と改善点
課題と改善点に対するTry デザイナーの負荷が高い Try. 鋭意採用中 不具合対応や開発環境の改善に関する Issueが溜まっている 施策メンバーとその他開発メンバーの役割が曖昧 Try. 現状は施策の優先順位が高いため、施策メンバー以外も施策に取り組んでい る。緊急度が高いIssueのみ施策メンバー以外が巻き取っているが、役割の境目
が曖昧なので、この辺りの議論は必要 施策メンバー同士の知見共有の機会が少ない Try. 振り返りの他に、メンバー入れ替え時のオンボーディング、ランチ会を追加
まとめ
• 仮説検証サイクルの高速化を目指す「施策チーム」を結成し、 1ヶ月の施策進 行量を3個→11個へ上昇 • BMLループのBuild→Measureを専門的に回し、メンバーの定期的な入れ替 えでノウハウを全体に共有 • 仮説立て〜効果測定のサマリーをデータ分科会で全体で学習 •
選択と集中により、現時点では施策進行量を増やしノウハウの蓄積を優先し ている まとめ
Thank you.