Slide 1

Slide 1 text

© DMM.com CONFIDENTIAL DMM プラットフォームで プルリクエストのマージ時間を 250 時間から 50 時間に減らした話 juve534 2023/02/10 Developers Summit 2023

Slide 2

Slide 2 text

© DMM.com Twitter / GitHub juve534(ゆーべ) 所属 プラットフォーム事業本部 マイクロサービスアーキテクトグループ 認証認可チーム 自己紹介 2

Slide 3

Slide 3 text

© DMM.com 話すこと 3 自分が所属するチーム以外へ働きかけ、3 ヶ月に渡って開発効率改善活動 を行い、プルリクエストのマージ時間を短縮しました。 その試行錯誤を時系列で話していきます。

Slide 4

Slide 4 text

© DMM.com 所属組織の話 4

Slide 5

Slide 5 text

© DMM.com DMM プラットフォームとは 5 DMM は多くのWebサービスを運営しており、1 つの Web サービスにつき 1 部署があります。 次の図でいうと電子書籍であれば電子書籍配下に、動画であれば動画配下 に組織があります。 私が所属する DMM プラットフォームは会員や決済といった共通利用される 機能を提供する部署です。

Slide 6

Slide 6 text

© DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 6

Slide 7

Slide 7 text

© DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 7

Slide 8

Slide 8 text

© DMM.com マイクロサービスアーキテクトグループとは 8 DMM プラットフォームは長年の開発でマイクロサービス化が進んでいた反 面、サイロ化や技術的スプロールが起きていました。 ● 各チームで Datadog は導入しているが APM やサービスマップが繋 がっていない ● エコシステムがなかった

Slide 9

Slide 9 text

© DMM.com マイクロサービスアーキテクトグループとは 9 そういった課題を解決するために誕生しました。 DMM プラットフォームの開発効率やセキュリティレベルの向上のため、120 名超のエンジニアが共通利用するツールや仕組み(エコシステム)を開発・ 運用を行っています。 FYI Microservices Architect in DMM Platform

Slide 10

Slide 10 text

© DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 10

Slide 11

Slide 11 text

© DMM.com 改善活動のきっかけ 11

Slide 12

Slide 12 text

© DMM.com 他チームレビュー 12 マイクロサービスアーキテクトグループでは Go で書かれたバックエンドのコードレビューをしています。 • 第三者視点でコード品質向上に繋がる指摘 • 横断的に見ることで知見の横展開

Slide 13

Slide 13 text

© DMM.com 他チームレビューの担当 13 担当として CSS グループのコードレビューをしていました。 次のスライドで CSS グループの紹介をしていきます。

Slide 14

Slide 14 text

© DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 14

Slide 15

Slide 15 text

© DMM.com CSS グループとは 15 Customer Service Support の略です。 「カスタマサポート(CS)を行う人たちと連携し、DMMユーザーの顧客満足 度をあげること」をミッションに、ユーザと CS がやり取りするシステム開発を 行っています。 BE と FE でユニットが分かれており、 BE は開発者が 10 人、テックリードが1人の構成になっています。

Slide 16

Slide 16 text

© DMM.com コンフリクト多発を検知 16 CSS グループのコードレビューをしていたとき、 プルリクエスト(以下 PR)に「コンフリクト対応」のコミットログが 1 つの PR に 複数ありました。他の PR でも同じようなコメントがありました。

Slide 17

Slide 17 text

© DMM.com PR 生存期間も長い 17 PR の作成日を見ると 10 営業日以上前の日付でした。 週に 10 件近く PR が出ているくらい開発が活発なのに、10 営業日前の PR が残っており、何らかの問題を抱えていると感じました。

Slide 18

Slide 18 text

© DMM.com PR 生存期間とコンフリクトは関係している 18 PR の生存期間が長いと feature brunch と trunk brunch の乖離が大きく なり、コンフリクトしやすくなります。 PR マージに時間がかかっていることがコンフリクトの原因と考えました。

Slide 19

Slide 19 text

© DMM.com ヒアリングして改善に乗り出す 19 マージに時間がかかっていることやコンフリクトに課題感を持っているか、 CSS グループにヒアリングしました。 • マージに時間がかかっていることは認識している • 忙しくて改善まで手が回っていない状態 DMM プラットフォーム全体の開発効率向上がグループの責務なので、改善 に乗り出すことにしました。

Slide 20

Slide 20 text

© DMM.com DMM プラットフォームで プルリクエストのマージ時間を 250時間から50時間に減らした話 20

Slide 21

Slide 21 text

© DMM.com DMM プラットフォームで (CSSグループの) プルリクエストのマージ時間を250時 間から50時間に減らした話 21

Slide 22

Slide 22 text

© DMM.com 改善するために取り組んだこと 22 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 23

Slide 23 text

© DMM.com 改善するために取り組んだこと 23 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 24

Slide 24 text

© DMM.com 目標を決める 24 CSS グループのメンバーの目線を揃えるため、 開発着手してから PR マージまでの目標時間を決めました。 結論からいうと “開発着手してから PR マージまでを 72 時間以内” に収め ることにしました。

Slide 25

Slide 25 text

© DMM.com 目標を決めて期待したこと 25 目標を決め注力する範囲が決まったので、 「自発的に改善のアクションが生まれ、自然と数値が改善される」 ことを期待しました。

Slide 26

Slide 26 text

© DMM.com レビューフローの提案 26 目標を話す機会があったので、レビューフローも提案しました。 当時は「2 人のうちどちらか 1 人が見たらOK」というルールでした。 これだと「もう一人がみるだろう」と二人とも考え、レビューが遅れるリスクが あります。

Slide 27

Slide 27 text

© DMM.com 担当はコミュニケーションで決めることに 27 二人でコミュニケーションを取って担当を決め、 PR のレビュアー欄にどちらか一方をアサインすることで 担当者を明確化することにしました。

Slide 28

Slide 28 text

© DMM.com スプレッドシートで可視化 28 決めた目標が達成されているかみるため可視化も行いました。 スプレッドシートで PR 一覧を作りました。

Slide 29

Slide 29 text

© DMM.com スプレッドシートで可視化 29 マージにかかった日数は GitHub 上で見れましたが、 開発着手時間やレビュー着手までにかかった時間は 正確には取得できなかったので担当者の感覚値で入れていました。

Slide 30

Slide 30 text

© DMM.com スプレッドシートイメージ図 30

Slide 31

Slide 31 text

© DMM.com 改善するために取り組んだこと 31 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 32

Slide 32 text

© DMM.com 改善するために取り組んだこと 32 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 33

Slide 33 text

© DMM.com 定例ミーティングの開催 33 目標を決め可視化しただけでは不十分です。 週一で状況の確認と課題の掘り下げを行う定例ミーティングを開催しまし た。 週一という基準は改善サイクルを早くするために暫定で設けました。 3ヶ月やってみましたが、週一でうまく機能しました。

Slide 34

Slide 34 text

© DMM.com 課題をトラッキングした 34 見つかった課題には対策を書き出して毎週確認するようにしました。 対策がうまくいかなかったときは別案を検討しています。

Slide 35

Slide 35 text

© DMM.com 課題に対して仮説→実践→効果測定の サイクルが回せました 35

Slide 36

Slide 36 text

© DMM.com 改善するために取り組んだこと 36 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 37

Slide 37 text

© DMM.com 改善するために取り組んだこと 37 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 38

Slide 38 text

© DMM.com PR 作成までに時間がかかる 38 1ヶ月ほどメトリクスをみてハードルが高すぎたと感じました。 • 開発着手から PR 作成までに 2 日 • PR作成からマージまでは 10 日 2日(開発 & PR作成) 10日(PR作成 & PRマージ)

Slide 39

Slide 39 text

© DMM.com PR 作成までに時間がかかる 39 PR作成からマージまでを集中して改善することにしました。 1. 10日かかっているので改善できる点が多いはず 2. 2日かかっている開発 &PR の期間を短縮するには、開発者が小さいPR を作成する必要があるので、開発者がそれなりのスキルを持つ必要があ り、意識付けも必要になる 3. 開発着手からの時間を正確にトラッキングすることが難しい

Slide 40

Slide 40 text

© DMM.com 目標を変える 目標を変更して目線を PR マージの短縮に集中させることにしました。 開発着手してから PR マージ時間までの合計を 72 時間以内 ↓ PR がオープンになってから PR マージ時間を 72 時間以内 40

Slide 41

Slide 41 text

© DMM.com 根本原因は他にあった 41 しかし、結果が出ませんでした。 実は、開発効率を下げている根本的な原因が他にあったのです。

Slide 42

Slide 42 text

© DMM.com 改善するために取り組んだこと 42 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 43

Slide 43 text

© DMM.com 改善するために取り組んだこと 43 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 44

Slide 44 text

© DMM.com 原因を深堀りする 44 試行錯誤したけど改善されず頭を抱えました。 ふと PR がどれくらい溜まっているか気になり、GitHub 上で PR 数を確認し ました。 すると 30 件近くあり、中には 20 日前の PR も存在していました。

Slide 45

Slide 45 text

© DMM.com PR 生存期間が長くて数値が悪かった 45 仮に 1h でマージできた PR があっても 20 日前の PR がマージされれば平 均値が上がり、マージ時間は増えてしまいます。 まずは溜まっている PR を減らすことが必要でした。

Slide 46

Slide 46 text

© DMM.com 更に目標を変える 46 というわけで PR を減らすことに全力を注いでいきます。 PR がオープンになってから PR マージ時間を 72 時間以内 ↓ 溜まっている PR を 5 件に減らす

Slide 47

Slide 47 text

© DMM.com 目標の遷移をおさらい 47 下記の流れで目標を変え、取り組みを続けていきました。 開発着手してから PR マージ時間までの合計を 72 時間以内 ↓ PR がオープンになってから PR マージ時間を 72 時間以内 ↓ 溜まっている PR を 5 件に減らす

Slide 48

Slide 48 text

© DMM.com 改善するために取り組んだこと 48 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 49

Slide 49 text

© DMM.com 改善するために取り組んだこと 49 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する

Slide 50

Slide 50 text

© DMM.com 2 週間レビューでPR 数を全力で減らす 50 まずは時間を確保する方向で進めました。 CSS グループと相談し、レビュアー 2 人は 2 週間の間、レビューに集中さ せる体制にしました。 後続でもこの話は登場するので、「 2 週間レビュー」と発表では表現します。

Slide 51

Slide 51 text

© DMM.com レビュアーも増えた 51 同時期に別プロジェクトで離脱していたメンバーが戻ってきました。 これにより従来の 2 人に 1 人増え、レビュアー 3 人体制で進められるように なりました。

Slide 52

Slide 52 text

© DMM.com 2 週間レビュー & レビュアー 3 人体制の結果 52 2 週間レビュー & レビュアー 3 人体制の相乗効果で、 溜まっていた PR を 2 週間で 30 → 15 → 7 と減らせました! マージ時間もジリジリと減っていきました。

Slide 53

Slide 53 text

© DMM.com 233 時間から 128 時間に減った 53

Slide 54

Slide 54 text

© DMM.com 233 時間から 128 時間に減った 54

Slide 55

Slide 55 text

© DMM.com 再びマージ時間を目標に取り組む 55 PR 数が減ったので再び目標を戻し、改善活動を行っていきました。 溜まっている PR を 5 件に減らす ↓ PR がオープンになってから PR マージ時間を 72 時間以内

Slide 56

Slide 56 text

© DMM.com 再びマージ時間を目標に取り組む 56 マージに時間がかかった理由を掘り下げ、対策を伝えました。 ● 同期レビューを駆使してコミュニケーションコストを減らす ● 判断が難しい PR はテックリードと同期レビューを行う 地道な活動の結果、目標を大きく超えるマージ時間になりました。

Slide 57

Slide 57 text

© DMM.com 128 時間から 42 時間に減った 57

Slide 58

Slide 58 text

© DMM.com 128 時間から 42 時間に減った 58

Slide 59

Slide 59 text

© DMM.com その後の話 59 数値が下がった後も悪化しないように定例ミーティングを開催し、可視化→ 仮説→改善実行→効果測定のサイクルを回していきました。 これは文化として根付き自分の手を離れた後も、 CSS グループだけで改善サイクルを回していくようになりました。

Slide 60

Slide 60 text

© DMM.com 補足:開発効率改善による嬉しい副作用 60 コミュニケーションの場を設けることで知見共有ができました。 以下のような開発効率に直接関係ないメリットもありました。 • develop ブランチの運用に苦しんでいたので改善する • 成果物( API 仕様書、DB 設計書)のレビューフロー改善

Slide 61

Slide 61 text

© DMM.com 反省 61

Slide 62

Slide 62 text

© DMM.com オーナーシップの欠如による失敗 62 チームの開発プロセスに 他のチームの人間が割って入り改善させるのは、かなり困難です。 実は、定例ミーティングの取り組みは、最初からうまくいっていたわけではあ りませんでした。

Slide 63

Slide 63 text

© DMM.com オーナーシップの欠如による失敗 63 課題の共有こそしていたものの、具体的な解決策について、 自分も CSS グループも主体的に提案していなかったのです。 • 自分→CSS グループで課題意識を持っているから助言で良い • CSS グループ→忙しくて余裕がないので準備に手が回らない どちらもオーナーシップを持っておらず、主体的に引っ張る人がいない状態 でした。

Slide 64

Slide 64 text

© DMM.com どちらがオーナーシップを持つか? 64 CSS グループは普段の開発業務で忙しい、 一方マイクロサービスアーキテクトグループは DMM プラットフォームの開 発効率向上が責務です。 今回の取り組みを持ちかけた自分が、オーナーシップを持って進めることに した。

Slide 65

Slide 65 text

© DMM.com どちらがオーナーシップを持つか? 65 オーナーシップを持った自分が推進し、改善活動が動き出すようになりまし た。 やはりオーナーシップをもって進める人がいないと、動き出さないことを身を もって痛感しました。

Slide 66

Slide 66 text

© DMM.com 改善の助けになったもの 66

Slide 67

Slide 67 text

© DMM.com Findy Teams+ を活用してみる 67 今回の改善においては、Findy Teams+ が役に立ちました。 “プルリククローズまでの時間といった開発リードタイムを、指定した時系列 でひと目で確認できるので、開発効率の向上に活用できます。 https://findy-team.io/”

Slide 68

Slide 68 text

© DMM.com Findy Teams+ を活用してみる 68 Findy Teams+ を活用したところ、 下記の効果を得ることができました。 ● 数値を手軽に確認でき、定例ミーティングの時間を有効に使えた ● 様々な情報を可視化してくれるので、問題の深堀りができた

Slide 69

Slide 69 text

© DMM.com Findy Teams+ で可視化 69

Slide 70

Slide 70 text

© DMM.com Findy Teams+ で裏付けもできた 70

Slide 71

Slide 71 text

© DMM.com 今後の動き 71 CSS グループの改善に成功しましたが、他にも課題を抱えているチームが あるかもしれません。 そこで、DMM プラットフォーム全体に対して改善活動を行おうと進めていま す。

Slide 72

Slide 72 text

© DMM.com まとめ 72

Slide 73

Slide 73 text

© DMM.com まとめ 73 可視化→仮説→改善実行→効果測定の流れで失敗を繰り返しながら、開発 効率を改善することができました。

Slide 74

Slide 74 text

© DMM.com 参考資料集 74 • Microservices Architect in DMM Platform • Findy Teams+

Slide 75

Slide 75 text

© DMM.com マイクロサービスアーキテクト活動集 75 下記のようにアウトプットも行っていますので、興味がある方はみてみてくだ さい。 • DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴 • DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善 • DMMプラットフォームを支える負荷試験基盤 • DMMの取り組み最前線 ~フルマネージドNewSQLであるTiDB Cloudの 可能性~

Slide 76

Slide 76 text

© DMM.com 採用 76 今回の成功例を他グループにも展開していこうとしています。 一緒にやってくれる人、お待ちしていますー。 • Developer Productivity Team