Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Shunsuke Nakao
December 15, 2021
290

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

Shunsuke Nakao

December 15, 2021
Tweet

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施策1担当制なため、施策メンバー間での連携やコミュニケーションが少なく、 施策メンバー同士での知見共有の機会が少ない 現状の課題と改善点
  26. 課題と改善点に対するTry デザイナーの負荷が高い Try. 鋭意採用中 不具合対応や開発環境の改善に関する Issueが溜まっている 施策メンバーとその他開発メンバーの役割が曖昧 Try. 現状は施策の優先順位が高いため、施策メンバー以外も施策に取り組んでい る。緊急度が高いIssueのみ施策メンバー以外が巻き取っているが、役割の境目

    が曖昧なので、この辺りの議論は必要 施策メンバー同士の知見共有の機会が少ない Try. 振り返りの他に、メンバー入れ替え時のオンボーディング、ランチ会を追加
  27. まとめ

  28. • 仮説検証サイクルの高速化を目指す「施策チーム」を結成し、 1ヶ月の施策進 行量を3個→11個へ上昇 • BMLループのBuild→Measureを専門的に回し、メンバーの定期的な入れ替 えでノウハウを全体に共有 • 仮説立て〜効果測定のサマリーをデータ分科会で全体で学習 •

    選択と集中により、現時点では施策進行量を増やしノウハウの蓄積を優先し ている まとめ
  29. Thank you.