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

Developers Summit 2023
https://event.shoeisha.jp/devsumi/20230209/session/4187/

Transcript

1. © DMM.com CONFIDENTIAL DMM プラットフォームで プルリクエストのマージ時間を 250 時間から 50 時間に減らした話 juve534 2023/02/10 Developers Summit 2023
2. © DMM.com Twitter / GitHub juve534（ゆーべ） 所属 プラットフォーム事業本部 マイクロサービスアーキテクトグループ 認証認可チーム 自己紹介 2
3. © DMM.com 話すこと 3 自分が所属するチーム以外へ働きかけ、3 ヶ月に渡って開発効率改善活動 を行い、プルリクエストのマージ時間を短縮しました。 その試行錯誤を時系列で話していきます。
4. © DMM.com 所属組織の話 4
5. © DMM.com DMM プラットフォームとは 5 DMM は多くのWebサービスを運営しており、1 つの Web サービスにつき 1 部署があります。 次の図でいうと電子書籍であれば電子書籍配下に、動画であれば動画配下 に組織があります。 私が所属する DMM プラットフォームは会員や決済といった共通利用される 機能を提供する部署です。
6. © DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 6
7. © DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 7
8. © DMM.com マイクロサービスアーキテクトグループとは 8 DMM プラットフォームは長年の開発でマイクロサービス化が進んでいた反 面、サイロ化や技術的スプロールが起きていました。 • 各チームで Datadog は導入しているが APM やサービスマップが繋 がっていない • エコシステムがなかった
9. © DMM.com マイクロサービスアーキテクトグループとは 9 そういった課題を解決するために誕生しました。 DMM プラットフォームの開発効率やセキュリティレベルの向上のため、120 名超のエンジニアが共通利用するツールや仕組み（エコシステム）を開発・ 運用を行っています。 FYI Microservices Architect in DMM Platform
10. © DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 10
11. © DMM.com 改善活動のきっかけ 11
12. © DMM.com 他チームレビュー 12 マイクロサービスアーキテクトグループでは Go で書かれたバックエンドのコードレビューをしています。 • 第三者視点でコード品質向上に繋がる指摘 • 横断的に見ることで知見の横展開
13. © DMM.com 他チームレビューの担当 13 担当として CSS グループのコードレビューをしていました。 次のスライドで CSS グループの紹介をしていきます。
14. © DMM.com 組織構造イメージ図 電子書籍 xxxx xxxx マイクロサービス アーキテクト CSS プラットフォーム DMM.com xxxx xxxx 動画 14
15. © DMM.com CSS グループとは 15 Customer Service Support の略です。 「カスタマサポート（CS）を行う人たちと連携し、DMMユーザーの顧客満足 度をあげること」をミッションに、ユーザと CS がやり取りするシステム開発を 行っています。 BE と FE でユニットが分かれており、 BE は開発者が 10 人、テックリードが1人の構成になっています。
16. © DMM.com コンフリクト多発を検知 16 CSS グループのコードレビューをしていたとき、 プルリクエスト（以下 PR）に「コンフリクト対応」のコミットログが 1 つの PR に 複数ありました。他の PR でも同じようなコメントがありました。
17. © DMM.com PR 生存期間も長い 17 PR の作成日を見ると 10 営業日以上前の日付でした。 週に 10 件近く PR が出ているくらい開発が活発なのに、10 営業日前の PR が残っており、何らかの問題を抱えていると感じました。
18. © DMM.com PR 生存期間とコンフリクトは関係している 18 PR の生存期間が長いと feature brunch と trunk brunch の乖離が大きく なり、コンフリクトしやすくなります。 PR マージに時間がかかっていることがコンフリクトの原因と考えました。
19. © DMM.com ヒアリングして改善に乗り出す 19 マージに時間がかかっていることやコンフリクトに課題感を持っているか、 CSS グループにヒアリングしました。 • マージに時間がかかっていることは認識している • 忙しくて改善まで手が回っていない状態 DMM プラットフォーム全体の開発効率向上がグループの責務なので、改善 に乗り出すことにしました。
20. © DMM.com DMM プラットフォームで プルリクエストのマージ時間を 250時間から50時間に減らした話 20
21. © DMM.com DMM プラットフォームで （CSSグループの） プルリクエストのマージ時間を250時 間から50時間に減らした話 21
22. © DMM.com 改善するために取り組んだこと 22 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
23. © DMM.com 改善するために取り組んだこと 23 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
24. © DMM.com 目標を決める 24 CSS グループのメンバーの目線を揃えるため、 開発着手してから PR マージまでの目標時間を決めました。 結論からいうと “開発着手してから PR マージまでを 72 時間以内” に収め ることにしました。
25. © DMM.com 目標を決めて期待したこと 25 目標を決め注力する範囲が決まったので、 「自発的に改善のアクションが生まれ、自然と数値が改善される」 ことを期待しました。
26. © DMM.com レビューフローの提案 26 目標を話す機会があったので、レビューフローも提案しました。 当時は「2 人のうちどちらか 1 人が見たらOK」というルールでした。 これだと「もう一人がみるだろう」と二人とも考え、レビューが遅れるリスクが あります。
27. © DMM.com 担当はコミュニケーションで決めることに 27 二人でコミュニケーションを取って担当を決め、 PR のレビュアー欄にどちらか一方をアサインすることで 担当者を明確化することにしました。
28. © DMM.com スプレッドシートで可視化 28 決めた目標が達成されているかみるため可視化も行いました。 スプレッドシートで PR 一覧を作りました。
29. © DMM.com スプレッドシートで可視化 29 マージにかかった日数は GitHub 上で見れましたが、 開発着手時間やレビュー着手までにかかった時間は 正確には取得できなかったので担当者の感覚値で入れていました。
30. © DMM.com スプレッドシートイメージ図 30
31. © DMM.com 改善するために取り組んだこと 31 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
32. © DMM.com 改善するために取り組んだこと 32 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
33. © DMM.com 定例ミーティングの開催 33 目標を決め可視化しただけでは不十分です。 週一で状況の確認と課題の掘り下げを行う定例ミーティングを開催しまし た。 週一という基準は改善サイクルを早くするために暫定で設けました。 3ヶ月やってみましたが、週一でうまく機能しました。
34. © DMM.com 課題をトラッキングした 34 見つかった課題には対策を書き出して毎週確認するようにしました。 対策がうまくいかなかったときは別案を検討しています。
35. © DMM.com 課題に対して仮説→実践→効果測定の サイクルが回せました 35
36. © DMM.com 改善するために取り組んだこと 36 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
37. © DMM.com 改善するために取り組んだこと 37 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
38. © DMM.com PR 作成までに時間がかかる 38 1ヶ月ほどメトリクスをみてハードルが高すぎたと感じました。 • 開発着手から PR 作成までに 2 日 • PR作成からマージまでは 10 日 2日（開発 & PR作成） 10日（PR作成 & PRマージ）
39. © DMM.com PR 作成までに時間がかかる 39 PR作成からマージまでを集中して改善することにしました。 1. 10日かかっているので改善できる点が多いはず 2. 2日かかっている開発 &PR の期間を短縮するには、開発者が小さいPR を作成する必要があるので、開発者がそれなりのスキルを持つ必要があ り、意識付けも必要になる 3. 開発着手からの時間を正確にトラッキングすることが難しい
40. © DMM.com 目標を変える 目標を変更して目線を PR マージの短縮に集中させることにしました。 開発着手してから PR マージ時間までの合計を 72 時間以内 ↓ PR がオープンになってから PR マージ時間を 72 時間以内 40
41. © DMM.com 根本原因は他にあった 41 しかし、結果が出ませんでした。 実は、開発効率を下げている根本的な原因が他にあったのです。
42. © DMM.com 改善するために取り組んだこと 42 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
43. © DMM.com 改善するために取り組んだこと 43 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
44. © DMM.com 原因を深堀りする 44 試行錯誤したけど改善されず頭を抱えました。 ふと PR がどれくらい溜まっているか気になり、GitHub 上で PR 数を確認し ました。 すると 30 件近くあり、中には 20 日前の PR も存在していました。
45. © DMM.com PR 生存期間が長くて数値が悪かった 45 仮に 1h でマージできた PR があっても 20 日前の PR がマージされれば平 均値が上がり、マージ時間は増えてしまいます。 まずは溜まっている PR を減らすことが必要でした。
46. © DMM.com 更に目標を変える 46 というわけで PR を減らすことに全力を注いでいきます。 PR がオープンになってから PR マージ時間を 72 時間以内 ↓ 溜まっている PR を 5 件に減らす
47. © DMM.com 目標の遷移をおさらい 47 下記の流れで目標を変え、取り組みを続けていきました。 開発着手してから PR マージ時間までの合計を 72 時間以内 ↓ PR がオープンになってから PR マージ時間を 72 時間以内 ↓ 溜まっている PR を 5 件に減らす
48. © DMM.com 改善するために取り組んだこと 48 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
49. © DMM.com 改善するために取り組んだこと 49 1. 目標を決めて可視化する 2. 定例ミーティングの開催 3. 目標を変える 4. 更に目標を変える 5. レビュー時間を確保する
50. © DMM.com 2 週間レビューでPR 数を全力で減らす 50 まずは時間を確保する方向で進めました。 CSS グループと相談し、レビュアー 2 人は 2 週間の間、レビューに集中さ せる体制にしました。 後続でもこの話は登場するので、「 2 週間レビュー」と発表では表現します。
51. © DMM.com レビュアーも増えた 51 同時期に別プロジェクトで離脱していたメンバーが戻ってきました。 これにより従来の 2 人に 1 人増え、レビュアー 3 人体制で進められるように なりました。
52. © DMM.com 2 週間レビュー & レビュアー 3 人体制の結果 52 2 週間レビュー & レビュアー 3 人体制の相乗効果で、 溜まっていた PR を 2 週間で 30 → 15 → 7 と減らせました！ マージ時間もジリジリと減っていきました。
53. © DMM.com 233 時間から 128 時間に減った 53
54. © DMM.com 233 時間から 128 時間に減った 54
55. © DMM.com 再びマージ時間を目標に取り組む 55 PR 数が減ったので再び目標を戻し、改善活動を行っていきました。 溜まっている PR を 5 件に減らす ↓ PR がオープンになってから PR マージ時間を 72 時間以内
56. © DMM.com 再びマージ時間を目標に取り組む 56 マージに時間がかかった理由を掘り下げ、対策を伝えました。 • 同期レビューを駆使してコミュニケーションコストを減らす • 判断が難しい PR はテックリードと同期レビューを行う 地道な活動の結果、目標を大きく超えるマージ時間になりました。
57. © DMM.com 128 時間から 42 時間に減った 57
58. © DMM.com 128 時間から 42 時間に減った 58
59. © DMM.com その後の話 59 数値が下がった後も悪化しないように定例ミーティングを開催し、可視化→ 仮説→改善実行→効果測定のサイクルを回していきました。 これは文化として根付き自分の手を離れた後も、 CSS グループだけで改善サイクルを回していくようになりました。
60. © DMM.com 補足：開発効率改善による嬉しい副作用 60 コミュニケーションの場を設けることで知見共有ができました。 以下のような開発効率に直接関係ないメリットもありました。 • develop ブランチの運用に苦しんでいたので改善する • 成果物（ API 仕様書、DB 設計書）のレビューフロー改善
61. © DMM.com 反省 61
62. © DMM.com オーナーシップの欠如による失敗 62 チームの開発プロセスに 他のチームの人間が割って入り改善させるのは、かなり困難です。 実は、定例ミーティングの取り組みは、最初からうまくいっていたわけではあ りませんでした。
63. © DMM.com オーナーシップの欠如による失敗 63 課題の共有こそしていたものの、具体的な解決策について、 自分も CSS グループも主体的に提案していなかったのです。 • 自分→CSS グループで課題意識を持っているから助言で良い • CSS グループ→忙しくて余裕がないので準備に手が回らない どちらもオーナーシップを持っておらず、主体的に引っ張る人がいない状態 でした。
64. © DMM.com どちらがオーナーシップを持つか? 64 CSS グループは普段の開発業務で忙しい、 一方マイクロサービスアーキテクトグループは DMM プラットフォームの開 発効率向上が責務です。 今回の取り組みを持ちかけた自分が、オーナーシップを持って進めることに した。
65. © DMM.com どちらがオーナーシップを持つか? 65 オーナーシップを持った自分が推進し、改善活動が動き出すようになりまし た。 やはりオーナーシップをもって進める人がいないと、動き出さないことを身を もって痛感しました。
66. © DMM.com 改善の助けになったもの 66
67. © DMM.com Findy Teams+ を活用してみる 67 今回の改善においては、Findy Teams+ が役に立ちました。 “プルリククローズまでの時間といった開発リードタイムを、指定した時系列 でひと目で確認できるので、開発効率の向上に活用できます。 https://findy-team.io/”
68. © DMM.com Findy Teams+ を活用してみる 68 Findy Teams+ を活用したところ、 下記の効果を得ることができました。 • 数値を手軽に確認でき、定例ミーティングの時間を有効に使えた • 様々な情報を可視化してくれるので、問題の深堀りができた
69. © DMM.com Findy Teams+ で可視化 69
70. © DMM.com Findy Teams+ で裏付けもできた 70
71. © DMM.com 今後の動き 71 CSS グループの改善に成功しましたが、他にも課題を抱えているチームが あるかもしれません。 そこで、DMM プラットフォーム全体に対して改善活動を行おうと進めていま す。
72. © DMM.com まとめ 72
73. © DMM.com まとめ 73 可視化→仮説→改善実行→効果測定の流れで失敗を繰り返しながら、開発 効率を改善することができました。
74. © DMM.com 参考資料集 74 • Microservices Architect in DMM Platform • Findy Teams+
75. © DMM.com マイクロサービスアーキテクト活動集 75 下記のようにアウトプットも行っていますので、興味がある方はみてみてくだ さい。 • DMMプラットフォームのマイクロサービス戦略 オーナーシップの落とし穴 • DMMプラットフォーム ゼロから始めるKubernetes運用 課題と改善 • DMMプラットフォームを支える負荷試験基盤 • DMMの取り組み最前線 ~フルマネージドNewSQLであるTiDB Cloudの 可能性~
76. © DMM.com 採用 76 今回の成功例を他グループにも展開していこうとしています。 一緒にやってくれる人、お待ちしていますー。 • Developer Productivity Team