DMMプラットフォームでプルリクエストのマージ時間を250時間から50時間に減らした話 / Developers Summit 2023
by
juve534
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
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