会員数3,914万人を超える総合エンタメサイト「DMM.com」を運営し、60以上のサービスを展開する、合同会社DMM.com（以下DMM）。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、DMMの認証認可チームでエンジニアを務める木村さんにインタビュー。開発チームにおける課題と取り組みについて、「Findy Team+」のデータを踏まえながらお話を伺っていきます。

DMMプラットフォームの開発効率とセキュリティ向上を担う

――最初に、木村さんの簡単なご経歴と現在の業務内容を教えてください。

木村：2013年に新卒でDMMに入社して、今年3月までは映像配信サービスのバックエンドエンジニアとしてサービス開発を行っていました。現在は、認証認可チームに所属していて、認証認可のシステム構築や他チームの開発サポートなどを行っています。

――所属されている開発チームのミッションについて、教えていただけますか？

木村：まず組織構成からご説明すると、DMM.comの共通機能をつくるプラットフォーム事業本部という部署があります。DMMは、60以上のサービスを展開しているので、それらのサービスにおいて共通で利用される部分、例えばDMM.comのマイページやアカウントの管理、決済やカスタマーサポート、不正対策などといったものを、プラットフォーム事業本部が担っています。

この部署は、エンジニア数が120名を超える規模なので、組織としての技術戦略、どの技術に投資し、どう活用していくのかなどの方向性を整理する必要があります。そこで、組織的な技術戦略を考えて実行する、マイクロサービスアーキテクトグループというグループが3年前に立ち上がりました。

そのグループのなかに、SREチーム、デベロッパープロダクティビティチーム、そして私が所属する認証認可チームの3つが含まれています。マイクロサービスアーキテクトグループでは、DMM.comのプラットフォーム全体の開発効率とセキュリティレベルを向上させる、というミッションを持っています。

当初は、手動のスプレッドシート管理で取り組みを開始

――マイクロサービスアーキテクトグループでは、「Findy Team+」をご活用いただく前に、どのような課題があったのでしょうか？

木村：もともとグループの活動の一環として、チーム横断でコードのプラクティスを共有したり、アーキテクチャの支援をしたりしています。それで、プラットフォーム事業本部の他の開発チームのコードレビューを行っていたんですね。

ある時、カスタマーサポート領域を担当するCustomer Service Supportグループ（以下CSSグループ）のコードレビューをしていたところ、「コンフリクトを解決しました」というメッセージが、1つのプルリクで複数回発生しているのを見つけました。それも1つだけではなく、いくつかのプルリクで発生していたんです。

この原因を深掘りしたところ、プルリクのオープンからマージまでの時間が、10営業日以上かかっていることがわかりました。なので、プルリクをマージするまでの時間がかかりすぎているところを課題として、改善活動を始めることにしました。

――その課題を解決するために、どういったことに取り組まれましたか？

木村：まずは、タスクに着手してからプルリクを出すまでの時間と、プルリクをマージするまでの時間を、CSSグループの方に決めてもらいました。そして、決めただけでは改善しているかどうかの判断ができないので、それを毎週確認していくという作業をしました。

最初はスプレッドシートで一つ一つ、プルリクのマージまでの時間を全部トラッキングしたんです。プルリクを見れば、メインのレビュアーやプルリクの作成者は載っていますが、レビュアーや実装者が誰のときにボトルネックになっていて、どのくらいの時間がかかっているのかというのは、スプレッドシートでないと一覧で見ることができなかったからです。

ただ、このやり方はつらかったですね。プルリクを出す人にスプレッドシートへ転記してもらって、手動で管理していたんです。当初は、統一がとれていない部分もあり、「そのプルリクは記載しなくて大丈夫です」とか「このプルリクが記載されていません」とか、そういうものが出てきてバタバタしていました。

普通は開発スピードが落ちているとき、プルリクの数が少ない傾向にあると思いますが、このCSSグループはプルリクの数がすごく多かったんですね。それもあって、スプレッドシートでの管理がより大変だったのですが、その時点で一般的な開発スピードが遅い状態とは、ちょっと何か違いそうだなと感じていました。

――そのスプレッドシートの運用によって、どのような結果が見えてきたのでしょうか。

木村：タスクに着手してからプルリクを出すまではスムーズな一方で、プルリクが出てからレビューしてマージされるまでの時間が長いことが、このスプレッドシートから判明しました。スプレッドシートに設けていた欄にも「レビュー待ち」というコメントが大量にあり、開発スピードは速いのに、レビューが遅いという現象が発生していたんです。

このレビューが追いついていないという問題に対しては、3つの軸から解決しようと考えました。1つ目は、レビューの時間を確保すること。2つ目は効率化すること。これは例えば、CSSグループは品質を担保するために、テックリードの承認をもって完了としているのですが、そのチェック項目を減らすことができないか、などです。そして、3つ目はレビューする人を増やすことでした。

ちなみに、この課題に気づいたのは今年の7月頃だったのですが、後から「Findy Team+」で直近1年のCSSグループのメトリクスを見てみたところ、1月の時点からそもそも開発効率が悪かったんです。なので、取り組みを始めるよりも前から、慢性的に存在していた問題だったことがわかりました。 CSSグループの直近1年（2021年12月～2022年12月）のリードタイムサマリ

「Findy Team+」で開発効率のメトリクスをチェック

――御社では、今年8月から「Findy Team+」を導入いただいています。導入のきっかけを教えていただけますか？

木村：DMM.comとしてはすでに「Findy Team+」を導入していて、利用できる状況になっていました。チーム内で使い始めたのは、とにかくスプレッドシートでメトリクスを見るのが大変だったので、「Findy Team+」で見れるかどうかを確認してみよう、というのがきっかけでした。

そして、スプレッドシートで管理しているものが「Findy Team+」で見れそうだったので、本格的に使っていこうと。ただ、使い始めた時点では、あまり機能を把握しきれていなかったので、手探りで使いながら、9月くらいまではスプレッドシートでの管理と並行していました。

――「Findy Team+」のなかで、どの画面のどういった指標をご覧になっていましたか？

木村：先ほど挙げた、タスクに着手してからプルリクを出すまでの時間と、プルリクが出てからマージされるまでの時間、この2つの指標を「Findy Team+」でも見ていました。

ただ、スプレッドシートでの管理によって、すでにレビューに時間がかかっていることがわかっていました。なので、プルリクが出てからレビューされるまでの時間と、あとはレビューに入ってから終わるまでの時間、つまりやり取りが多くて時間がかかっているのかという、この2つも見て状況を確認していました。

「Findy Team+」のメニューにある、「詳細比較」の画面もよく利用していました。これは主に、CSSグループと自分たちのチームの開発効率を比較してみたり、先月分と今月分を比較してみたり、といった使い方ですね。

そして、この画面の主要スタッツに、1プルリクあたりの平均マージ・クローズ時間や、コミットからプルリク作成までの平均時間、レビューからアプルーブまでの平均時間などがあって、ここはやはりコアなメトリクスなので基本的にチェックしていました。 「詳細比較」の画面で見るCSSグループのスタッツの推移

――これらの指標で、設定されていた目標があれば教えてください。

木村：実は最初に、ファーストコミットからプルリクをマージするまでの全部を含めて、3営業日（72時間）以内を目標としていたのですが、ハードルが高すぎて全然達成できなかったんです。なので、ひとまずはプルリク作成からマージまでを、3営業日以内に収めていこうとしていました。"3営業日以内"という基準はトランクベース開発の short lived feature branch の生存期間を基準に決めました。 https://trunkbaseddevelopment.com/short-lived-feature-branches/

原本には "the branch should only last a couple of days." とあるので、自分たちは3営業日を採用しました。

ところが、とにかくプルリクが溜まりすぎてしまっていて、マージに平均200時間かかっていました。なかにはマージに14日かかって残っているものがあったりしたんです。その状況で3営業日以内のマージを目標にしても達成できないので、溜まっているプルリクの数を減らすという方向に目標を転換しました。

平均プルリククローズ時間を5分の1に短縮し、目標を達成

――レビューが追いついていない状況を、どのように改善していったのでしょうか？

木村：レビューの効率化はあまり効果が出ず、レビューの時間を確保することにしました。レビュアーが2人だったので、例えば2人が1日1時間必ずレビューする時間をつくるなど、その体制でどうやってレビューをさばいていくか試行錯誤しました。ただ、レビューの時間が取れるなら、そもそもこの問題は発生していないはずで、レビューの時間を捻出できない環境にあったんですよね。

レビューする人も増やせればいいのですが、レビューをするに値するスキルを持っていなければならないので、そう簡単には増やせません。なので、技術力云々の話ではなく、レビューの時間を取る、つまりそこに時間を投資するという組織としての判断が必要で、現場のエンジニアだけで解決できる問題ではありませんでした。

そこで、CSSグループのテックリードにCSSグループのマネージャーとスケジュールについて交渉するように提案したんです。1日1時間でもレビューの時間が足りなかったので、「このスプリントとこのスプリントは、1日中ずっとレビューしかしない時間を取りたい」といった話をする提案をしました。CSSグループのマネージャーも状況は把握していたので、そうした交渉はすんなり通ったと伺いました。相談前の改善ミーティングにCSSグループのマネージャーに参加してもらって、現場で対応できる範囲では限界まで努力していると理解してもらえたのも大きかったと思っています。

――そうした取り組みの結果、9月頃は平均プルリククローズ時間が300時間弱だったところから、今では55時間ほどと5分の1に短縮され、目標の3日以内を達成されています。この取り組みの経過は、どういった形で確認されていましたか？ CSSグループの直近半年（2022年6月～2022年12月）のリードタイムサマリ

木村：週に1回のミーティングで確認することを続けていました。最初はスプレッドシートを見ながらでしたが、「Findy Team+」を使うようになってからは、先ほど挙げた指標をチェックして、それだけだと足りない部分は、オープンなプルリクの数も見たりしていました。

取り組みでは、オーナーシップと地道な積み重ねが重要

――「Findy Team+」を導入いただいて、感じたメリットがあれば教えてください。

木村：「Findy Team+」の導入前は、マージ時間を数値で可視化できていなかったので、3日以内にマージするという目標が達成できているか正確に把握できていない状態でした。そこから、「Findy Team+」でマージ時間を把握していくことで、意識の改善に繋がっていきましたし、手動の集計では気づけなかったメトリクス（ex. PR 作成からレビューまでのリードタイム）も見ることができましたので、皆すごく積極的にレビューする動きになっていきました。

それから、この取り組みでは毎週ミーティングに1時間取っているのですが、「Findy Team+」を使うようになってから、メトリクスの確認がすごく速くなりました。全員でパッと数字を見て状況確認を終わらせられ、課題にどうアプローチするかという話し合いに時間を割くことができるので、そこもすごく良いなと思います。

――定量面での改善結果だけでなく、開発者体験という面でも何か変化はありましたか？

木村：CSSグループからは、非常にレビューが楽になったという声を聞けています。レビューが滞りながらも目の前のタスクに忙殺されていた時期は、非常に辛く感じていたそうですが、こうやって可視化することで確実に一歩一歩対策を打てるようになり、一気に改善結果に繋げることができたことが大きかったようです。今ではメンバー間で楽しく競ってレビューできるような、チーム環境に変化しているそうです。

――今回の取り組みを経て、同じような課題に取り組む他社の方に伝えたいことがあればお願いします。

木村：実は、最初にこの課題についてミーティングを開いたとき、課題を持っているCSSグループがオーナーシップを持って進めてくれると思っていたんですね。だから、僕はアドバイザーのような形で、助言していけばいいだろうと考えていました。でも、当初どちらもオーナーシップを持っていなかったために、全然うまくいかなかったんです。

そこで、自分がオーナーシップを持って、積極的に介入していったことで、こうした結果につながりました。なので、やはり誰かがオーナーシップを持つ必要があるということを、今回すごく学びましたね。

あとは、地道さです。今回、レビューの時間が全然取れていないことがわかって、「じゃあレビューを1日1時間取りましょう」と決めたわけですが、これはアプローチとしては正しくても、「そんなことでいいの？」と感じてしまう人もいると思うんです。

でも、実際に1日1時間をとるようにして翌週に「Findy Team+」を確認してみると、前の週よりマージ時間が短縮されていました。そうやって効果測定をすることで方向性の正しさを確認し、懸念を払拭していきました。すぐに効果が出るものばかりではないので、アプローチによっては翌々週に確認することもしていました。小さなことでもアプローチして効果測定を打つ積み重ねが、すごく大事だったなと思います。

なので、オーナーシップを持って進めることと、小さなことをコツコツ積み重ねていくこと。この2つが重要だったかなと感じますね。

求めているのは「Scientific」なマインドを持つエンジニア

――今後、さらに取り組んでいきたいと考えていることはありますか？

木村：「Findy Team+」でこのように可視化できることがわかったので、プラットフォーム事業本部の他チームにも、同じような課題を抱えているところがないかを確認して、あればサポートしていくという取り組みを今始めています。

――それでは最後に、一緒に働きたいと思うエンジニア像について教えてください。

木村：DMM.comでは、開発チームの在り方を表す「Tech Vision」が掲げられていて、そのなかの1つに「Scientific」があります。感覚ではなく数値で物事を判断し、データをもとに議論していくという考え方で、今回の事例もそれをとてもよく表していると思います。そうしたScientificなマインドを持つ人と働きたいですね。

我々はテック領域を相手にした開発をしていて、技術的な問題を技術で解決していくのが仕事です。なので、Scientificな考え方が好きで、技術領域で勝負したいと考えるようなエンジニアの人には、とても魅力的な環境だと思います。

それから、今回の取り組みは、もともとカジュアルに上司との1on1で「こういう課題があって気になっているんです」と話したところから、こうしてしっかりと結果が出るところまで発展しました。このフットワークの軽さも魅力の1つだと思いますので、そういった環境を求めているエンジニアの方にもぜひ来ていただきたいです。

――木村さん、ありがとうございました！

※DMMの採用ページでは組織の開発効率を改善したいエンジニアを募集しています。 https://dmm-corp.com/recruit/engineer/1594/

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction