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