仮説検証サイクルを高速で回す為に、DMMポイントクラブ アプリチームが行っている取り組み | DMM iOS Meetup #2

Transcript

1. 仮説検証サイクルを 高速で回す為に、 DMMポイントクラブ アプリチームが 行っている取り組み @noa4021J DMM iOS Meetup #2 2021.12.15
2. 自己紹介 中尾 俊介 Nakao Shunsuke 合同会社DMM.com プラットフォーム事業本部 メンバーシップサービス部 DMM ポイントクラブグループ iOS Engineer @noa4021J github.com/noa4021J 2021年4月新卒入社。DMMポイントクラブ iOSアプリの開発に従事。
3. DMMポイントを貯めて、使って、管 理できる、DMMの新しいポイント サービス。
4. • 2021年4月にiOS/Androidで先行リリース • 2021年9月にWeb版をリリース • くじ引き機能やポイントチャージ機能、 レポーティング機能など順次機能追加中 https://lp.pointclub.dmm.com/
5. 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新卒以降）
6. • 仮説検証サイクルに「 BMLループ」を 型として採用 • 職能に関係なく全員が仮説を立て、データ を取って分析し学習する。プロダクトへの 反映は各職能で行う DMMポイントクラブの開発手法 Build Measure Learn Product Data Idea 1. Build … 仮説からプロダクトを作る 2. Measure … プロダクトをリリースし、顧客の反応を 計測、”データ”を得る 3. Learn … データをもとに学習し、新たな仮説に反 映する cf: リーン・スタートアップ - エリック・リース著
7. 仮説検証サイクルを運用する上で モバイルアプリチームが抱えていた課題
8. Backlogに積んだ施策の消化量が少なく、 着手までに長い時間が掛かっていた • 各メンバーが提案した施策をチケット化し、施策用の Backlogに 積み上げていく（ボトムアップ） • iOS/Android版の本格リリースの 1ヶ月後には上記運用を開始、 当時既に37個の施策が積み上がっており、現時点では 70個以上 の施策が控えている • 運用開始直後は1ヶ月で3個程度しか完了できなかった DMMポイントクラブ アプリチームが抱えていた課題
9. 仮説検証サイクルの高速化を目指す専門チーム （通称: カセツバクシンオー） Designer 1人 Web team Backend Engineer 1人 Mobile App team iOS Engineer 1人 Android Engineer 1人 1ヶ月ペースで1~2名程度入れ替え 開発リソースを全て施策進行に振った、施策の進行に専念するチーム
10. DMM PointClub 開発メンバー 施策BANK 施策をチケット化 IDEA 施策チーム プロダクトへ反映 PRODUCT 施策チームの責務 検証結果共有 LEARN データ分科会 DATA データ計測、分析 MEASURE 検証方法の要件定義、実 装 BUILD #施策案壁打ち
11. DMM PointClub 開発メンバー 施策BANK 施策をチケット化 IDEA 施策チーム プロダクトへ反映 PRODUCT 施策チームの責務 検証結果共有 LEARN データ分科会 データ計測、分析 MEASURE 検証方法の要件定義、実 装 BUILD #施策案壁打ち BUILD → MEASUREを専門に回し 続けることで試行回数を増やし、仮説 検証サイクルを高速に回す為のノウ ハウを蓄積。 定期的にメンバーを入れ替え知見共 有しながら、開発チーム全体へ還元す る
12. 施策チームの活動サイクル
13. 施策チームの活動サイクル 1. 施策案の要件定義、検証方法の策定 2. （デザイン作成） 3. 実装 4. QA / リリース 5. 分析用ダッシュボード、クエリの作成 6. 定例での検証結果共有
14. 1. 施策案の要件定義、検証方法の策定 2. （デザイン作成） 3. 実装 4. QA / リリース 5. 分析用ダッシュボード、クエリの作成 6. 定例での検証結果共有 施策チームの活動サイクル 基本、1施策1担当 適宜必要なメンバーの取り付け、外 部との調整など、横断的な施策の進 行をリードする。
15. PRD Product Requirements Document Step1. 施策案の要件定義、検証方法の策定 施策BANK Design Doc • 何を（What） • 何のために（Why） • どのように作るのか（How）を定義する （ What / Why ） • 問題、仮説などのWhyに対するソ リューションの定義 • 実現可能性の調査 • ステークホルダーとの合意形成 （ What / Why ） • PRDで決めたソリューションの具 体的な実現方法の定義（デザイン, システム設計） • テスト項目の作成、周知やリリー ス時の計画など （ How ） 優 先 度 （粗削り）
16. Step1のPRD~DD定義の段階で、同時並行で作成。 • PRD段階：PRDの内容（ユーザーストーリーマッピング etc）を元にプロトタイプを作成 • DDの段階：要件や各ガイドライン（ HIG/MateriaI Design）に則ってプロトタイプを洗練 →デザイ ンFix Step2. デザイン作成 DesignDoc PRD Designer UI Design Prototype
17. 普通に実装します。 施策チームとは別で、 ”開発サイクルの高速化 ”を目指す プロジェクトがありますが、今回は時間の都合上割愛。 Step3. 実装 DesignDoc Backend Engineer Android Engineer iOS Engineer iOS/Android API UI Design
18. 実装が完了後、機能単位でテストを実施。 実装後にテストを実施することで、リリース時に行うテストの負担を減らす。 既存の機能への影響が考えられる場合はそこもテストする。 Step4. QA, リリース テスト項目書 検証用アプリ 開発メンバー 非実装者 修正作業 🥳 リリース可 😭 バグ報告 リリース作業 基本1~2週間毎にリリース
19. Step5. 分析用ダッシュボードの作成 リリース後、データが溜まってきた段階で分析用のクエリを作成。 PRD/DDの作成時に効果測定に必要な情報の定義も行なっているので、それを参考にダッシュボードを作る。 • エンジニアは全員クエリを書ける 前提なので、分析も自前で行う • 効果測定に必要な情報の定義と 書いたクエリで出てきた数値に 誤りがないかをレビュー
20. Step6. 定例での検証結果共有 データ分科会にてダッシュボード、検証結果を共有。 • 仮説は何だったか • 検証方法は何か • 検証結果はどうだったか 学習結果を元に、開発メンバーがそ れぞれ新たな施策を作成 データと試行回数を積み重ね、仮説 検証の質を上げていく 施策メンバーは次に待つ新たな施策へ...
21. KPTを用いて、メンバーの入れ替え時に振り返りを実施 メンバー入れ替え（因子継承） • KPTにあがってきたものから次 期メンバーに引き継ぐノウハウ やプロブレムに対する Tryを集約 し共有（通称：因子）
22. 施策チームを導入してみた結果
23. 導入前 施策チームの導入後の結果 導入後 • 開発系（機能拡充etc） : 2個 • 開発以外（マーケetc）：1個 3個 11個 • 開発系（機能拡充etc） : 7個 • 開発以外（マーケetc）：4個 施策実施量/月
24. • 開発リソースを施策の実施に移動させたのが高速化の大きな要因なため、ト レードオフ →試行回数が増えていくにつれ、作業効率は上がっていくと想定 施策チーム導入で得た知見 Pros Cons • 施策の進行のみに集中することが決まっている為、施策の進行が止まること がない → 1つの施策で待機が発生しても、別の施策を並行して進行可能 • 施策進行の形式化により施策の進行速度が上昇 → 施策進行がある程度形式化され、合意形成のタイミングが最適化された
25. • 施策が進む代わりに開発環境の改善や不具合に関する Issueが進められず、 溜まっている • デザイナーがグループで１人しかいないため、デザイナーの負荷が高くボトル ネックになっている • 施策メンバーとその他開発メンバーの役割が明確になっていない • 1施策1担当制なため、施策メンバー間での連携やコミュニケーションが少なく、 施策メンバー同士での知見共有の機会が少ない 現状の課題と改善点
26. 課題と改善点に対するTry デザイナーの負荷が高い Try. 鋭意採用中 不具合対応や開発環境の改善に関する Issueが溜まっている 施策メンバーとその他開発メンバーの役割が曖昧 Try. 現状は施策の優先順位が高いため、施策メンバー以外も施策に取り組んでい る。緊急度が高いIssueのみ施策メンバー以外が巻き取っているが、役割の境目 が曖昧なので、この辺りの議論は必要 施策メンバー同士の知見共有の機会が少ない Try. 振り返りの他に、メンバー入れ替え時のオンボーディング、ランチ会を追加
27. まとめ
28. • 仮説検証サイクルの高速化を目指す「施策チーム」を結成し、 1ヶ月の施策進 行量を３個→１１個へ上昇 • BMLループのBuild→Measureを専門的に回し、メンバーの定期的な入れ替 えでノウハウを全体に共有 • 仮説立て〜効果測定のサマリーをデータ分科会で全体で学習 • 選択と集中により、現時点では施策進行量を増やしノウハウの蓄積を優先し ている まとめ
29. Thank you.