Findy Team+ Lab

イベントレポート

【DMM×バイセル】結局何を追うべき?開発生産性向上に向けたベストプラクティス

【DMM×バイセル】結局何を追うべき?開発生産性向上に向けたベストプラクティス

2023年1月18日、ファインディ株式会社が主催するイベント「【DMM×バイセル】結局何を追うべき?開発生産性向上に向けたベストプラクティス」がオンラインにて開催されました。

2022年は、DPE(Developer Productivity Engineering)の専門部署を立ち上げたり、Four Keysをモニタリングしたりするなど、開発生産性の可視化や向上に、組織として取り組みを進める企業が大きく増えました。一方で、開発生産性を計測する多様なメトリクスのなかで注力すべき指標や、取り組みの推進方法などが模索されている側面もあります。

そこで、今回のイベントでは、開発生産性向上に組織として取り組まれている、合同会社DMM.comの高橋史行(pospome)さんと木村剛士(takeshi)さん、株式会社BuySell Technologiesの赤川龍之介さんと渡邊直人さんをお招きしました。エンジニア組織の状況や開発生産性向上への取り組み、直面した課題とその乗り越え方などについて、パネルディスカッション形式でお話していただきました。

■登壇者プロフィール pospomeさん / 合同会社DMM.comプラットフォーム事業本部 マイクロサービスアーキテクトグループ マネージャー @pospome DMMのプラットフォーム事業本部でアーキテクトに従事。得意分野はアプリケーションアーキテクチャ。

木村 剛士(takeshi)さん / 合同会社DMM.comプラットフォーム事業本部 マイクロサービスアーキテクトグループ 認証認可チーム @juve534 2013年に新卒でDMM.comに入社し、映像配信サービスのバックエンドエンジニアとしてサービス開発に従事。 2022年3月から現在の部署で認証認可システムの構築や他チームの開発サポートを行っている。 合同会社DMM.comの企業概要はこちら

赤川 龍之介さん / 株式会社BuySell Technologies 開発2部Promasチーム エンジニアリングマネージャー @r_akgw ソシャゲ→SIer→医療系にてエンジニアとしてのキャリアを経て、2021/07からEMとしてバイセルに入社。主にリユースプラットフォームのPjMとメンバーのピープルマネジメントに従事している。

渡邊 直人さん / 株式会社BuySell Technologies CTO室 エンジニアリングマネージャー  @naoto_pq グリー、マネーフォワードを経て、バイセルにCTO室のEMとして入社。組織横断での生産性向上や組織の制度設計などに従事。 株式会社BuySell Technologiesの企業概要はこちら

■モデレーター 内田博咲也/ファインディ株式会社 新卒でデロイトトーマツコンサルティング合同会社に入社し、全社・事業戦略策定、新規事業の立ち上げ・推進等を経験し、2021年10月よりFindyに参画。Findy Team+事業部にて、マーケティング・セールス・カスタマーサクセスを担当。

※本イベントのアーカイブ配信(無料)はこちら

目次

登壇者4名の自己紹介からイベントスタート

――本日はよろしくお願いいたします。まずは、登壇者の皆さまの自己紹介をお願いします。

pospome:こんにちは、pospomeです。DMMプラットフォームでアーキテクトをやっています。よろしくお願いします。

takeshi:木村剛士といいます。DMMプラットフォームでバックエンドエンジニアをしています。認証認可システムの開発と、他グループの開発サポートを行っています。本名は、剛士で“つよし”と読むのですが、takeshiという愛称で呼ばれています。

赤川:バイセルでエンジニアリングマネージャーをしている、赤川です。Promasチームというところに所属していて、ピープルマネジメントをしたり、メンバーと一緒に設計したりコードを書いたりするプレイングマネージャーをやっています。

渡邊:渡邊直人と申します。バイセルのCTO室でエンジニアリングマネージャーをしています。エンジニア組織の評価制度など、横断的なところに携わっているのですが、今回「Findy Team+」を導入して、別チームでスクラムマスターとして生産性向上をサポートしたので、その事例を本日お話できればと思っております。

――本日のパネルディスカッションは、4つのテーマを用意しております。なかでも、「開発生産性向上に取り組む過程で直面した課題と乗り越え方」をメイントピックとして、「Findy Team+」のデータも参照しながら、ディスカッションしていければと思います。

dmm_buysell_01

それぞれの会社における開発チーム体制とミッション

――それでは、まず1つ目のテーマ「開発チームの体制やミッションは?」について、DMMさんからお願いします。

pospome:DMMはいろいろなサービスを展開していて、サービスごとに部署があり、それぞれに開発組織や技術戦略を持っています。そのため、今回はDMM全体での話ではなく、あくまで我々が所属しているDMMプラットフォーム事業本部という部署での話になります。

我々はプラットフォーム事業本部内にあるマイクロサービスアーキテクトグループ(下記図で赤色に示された部分)に属していて、僕はこのグループのマネージャーをしています。そして、その下にある認証認可チームにtakeshiさんが属しています。

マイクロサービスアーキテクトグループは、プラットフォーム事業本部全体の開発効率やセキュリティレベルを向上させるエコシステムをつくることや、組織戦略の策定や推進をミッションとしています。その施策の一環として、takeshiさんがCSSグループ(下記図で緑色に示された部分)の開発効率を改善したというのが、本日お話する内容になります。

dmm_buysell_02

――続いて、バイセルさんからも開発チーム体制とミッションについてお願いします。

赤川:バイセルはリユース事業を行っている会社で、会社全体の業務としては、下記の図のように買取から在庫管理や販売といった流れがあります。

今、注力しているのがバイセルリースプラットフォーム「Cosmos」で、そのなかにある商品マスタサービス(下記図の赤い枠で示された部分)が、私の所属するPromasチームで動いています。この商品マスタサービスは、買取から在庫管理、販売という業務の流れの中で、商品の情報や価格などを一元管理するものです。

チームのミッションは、この商品マスタサービスを立ち上げて基幹システムに導入し、業務を効率化していくことでした。開発メンバーのチーム構成は、私がエンジニアマネージャーで、サーバーサイドが2人、フロントエンドが3人。そして、新卒などジュニアのメンバーが多いという特徴のチームになります。

dmm_buysell_03

さまざまな試行錯誤があった「Findy Team+」導入前

――続いては、「開発生産性をどのように計測し、改善活動を行っているか?」というテーマになります。まずは、「Findy Team+」導入前の取り組み状況から、お伺いできればと思います。

赤川:なぜ開発生産性に着目したのかという、背景からお話したいと思います。先ほどお話したとおり、Promasチームはジュニアのメンバーが多いチームで、私がメンバーと1on1をするなかで、「エンジニアとして何を目指したいのか」といった話をしていたんですね。

そこで、「テックリードを目指したい」というメンバーもいたのですが、そのためには具体的に何をすべきなのか、社内のテックリードの方と比べて今どれくらいのスキルなのか、といったところが不明確な状況でした。

そこで、普段の生産性を見てみることにしたんです。我々はスクラムで開発していて、ストーリーポイントを1つ1つ課題につけているので、まずはベロシティを計測して見るようにしました。

ただ、ベロシティはあくまでチームの生産性に着目するものなので、個人の生産性を測るにはアンチパターンだったはずだなと。加えて、スプリントを終了したときに、各々がつけたストーリーポイントを人単位で見てみると、前回との比較はできるものの、なぜ生産性が下がったのか深掘りしづらく、ネクストアクションにつながりにくい状態でした。

そういった経緯から開発生産性について調べ始めて、Four Keysという指標があるけれども、それをどうやって上げていけばいいのかと調べていたら、「Findy Team+」と出会ったという流れでしたね。

――ベロシティ以外にも、GitHub上から見れるプルリクエストやコミットなど、ご覧になっていたものはありましたか?

赤川:スポットで見ることもありましたが、内容を深ぼって、ネクストアクションに起こすといったことはしてなかったです。

――DMMさんからも、「Findy Team+」導入前の取り組み状況についてお願いします。

pospome:我々マイクロサービスアーキテクトグループは、プラットフォーム事業本部全体の開発効率を向上させる活動の一環として、各チームのコードレビューも行っています。そのため、takeshiさんがCSSチームのコードレビューをしていたのですが、そこでGitHubのプルリクのコンフリクトが多いことに気づいたんですね。

そして、そのコンフリクトの多さについて、CSSチームにヒアリングをしたことが最初のきっかけでした。そのとき、たまたまFour Keysが話題になり始めていた時期で、僕がそういった知識を持っていたこともあり、生産性を可視化してみようという話になったんです。

最初は、GitHubのプルリクを見ながら、ファーストコミットとマージの日時をスプレッドシートに入力して、マージまでにかかっている時間を見ていました。それ以外にも、あらゆるメトリクスを手動でスプレッドシートに入力して可視化していた、というのが「Findy Team+」導入前の取り組みです。導入前は、かなり泥臭い作業をしていましたね(笑)。

――手動での管理は、なかなか大変なことだったと思うのですが、それについてCSSグループからの反応はありましたか?

takeshi:いえ、特にありませんでした。でも、支援されている立場のCSSチームにとっては、作業の大変さなどについて、言い出しづらい部分もあったかもしれません。実際は、自分に届いていなかっただけで、チームのテックリードの方が上手く進めてくださっていた可能性はあると思います。

生産性向上に取り組むなかで直面した課題と乗り越え方

――続いて、「Findy Team+」をご導入いただいた後の、「開発生産性向上に取り組む過程で直面した課題と乗り越え方とは?」についてお伺いできればと思います。

pospome:課題はいろいろありましたが、最初に直面した課題は、どちらのチームがオーナーシップを持って改善作業を進めるかというところでした。CSSチーム側は「支援してもらえるんだ」と考え、マイクロサービスアーキテクトチーム側は「外から見てテコ入れする程度だろう」と考えていたので、お互いに責任感を持たない状態になってしまっていたんです。

そのせいで、当初は進め方がグダグダで、何も考えずに週1で集まることになってしまって(笑)。やはりAPIを開発しながら開発生産性の向上まで取り組むのは、なかなか難しいことですし、第三者だからこそチームを改善する推進力が生まれると考えて、まずは我々がオーナーシップを持つことから始めました。

――コメントで「取り組みにおいて、どれくらいの頻度でデータを振り返っていましたか?」という質問をいただいていますが、いかがでしょうか。

pospome:「Findy Team+」のデータは、毎週確認していました。月1とかだと、改善までのリードタイムが長くなってしまうので。毎週見て、改善していなければ、なぜ改善していないのかメトリクスを深掘りするという感じでした。ある程度、開発効率が改善した段階であれば、毎週見る必要はないと思っています。

――続いて、バイセルさんからも直面した課題とその乗り越え方についてお願いします。

赤川:Four Keysなどの知識があまり深くないメンバーで「Findy Team+」を見ていくことになったので、コンソールを見てもメトリクスが多く、最初はどの指標に注力すればいいかわからない状態で1~2週間くらい経っていました。

まずは、サイクルタイム分析を見て、なんとなく「この数字を良くしていくんだろうな」というところから、スクラムのタスクの粒度を見直してみたんです。大きすぎるタスクの粒度を小さくするように、メンバーにも周知しながら進めていたんですが、なかなかそれがサイクルタイムの数字に響かない日々が続きました。

そんななか、ファインディのカスタマーサポートの方に、そのあたりの相談をさせていただいたところ、プルリク作成数を指標にするといいかもしれないと伺ったんですね。それで、テックリードの方とPromasチームのメンバーのプルリク作成数を見てみたら、確かに差があるなと。そこから、プルリク作成数を指標にしてみることにしました。

実際に進めていくと、プルリク作成数を増やすためには、単位を縮小しなければいけない。そのためにはタスクの粒度を小さくしなければならないし、仕様が十分に理解できている必要がある、と逆算して考えるようになりました。最初にやったタスクの粒度の見直しとやっていることは同じなのですが、プルリク作成数を増やすというイメージを持ったことで、よりその精度が上がったのかなと思います。

もう1つの課題は、「Findy Team+」を見ることも含め、開発生産性への意識をメンバーに浸透させていく必要があったことです。これについては、1on1のなかで時間をつくって、「Findy Team+」を見ながら、先週と今週の生産性を振り返るようにしたり、レトロスペクティブでも「Findy Team+」を使って、みんなでチームの生産性を見ることを心がけるようにしていました。

それから、「Findy Team+」の数値は、メンバーの評価に組み込むことはせず、ゲーミフィケーションのような形を意識していました。「他チームの生産性と比べてうちはこれくらいだから、もっと乗り越えていこうぜ」と盛り上げていく感じですね。

――コメントからのご質問で、「個人にフォーカスを当てて振り返りをすることに対して、ハレーションは起きませんでしたか?」といただいています。

赤川:特にハレーションは起きませんでした。あくまで数字は、自分のスキルを測る1つの指標という位置づけなので、「数字がいくつになったからテックリード」とは誰も思っていないというのがあります。自分がどの位置にいるのかを測る物差しでしかないので、「昨日の自分より今日の自分が伸びていることを楽しみましょう」といった広め方をしています。

――続いて、渡邊さんがサポートされたチームでの事例についてもお願いします。

渡邊:僕は赤川さんとは別のチームに対して、「Findy Team+」を導入してサポートしていました。僕はマネージャーではなくスクラムマスターという立場で、開発チームからスクラムというフレームワークを用いて自分たちの生産性を高めたい、不確実性をうまくコントロールできる状態にしたいというオーダーがあり、サポートしていたという前提があります。

赤川さんと同じだったのは、まずプルリク作成数にフォーカスしたところです。ファインディの方から事例を聞いたり、各種イベントで話を聞いたりしていると、プルリク作成数にフォーカスすることで生産性が上がるという仮説の確度が高そうだったので、取り組みを始めました。

今回、僕がスクラムマスターとしてチャレンジしたのは、レトロスペクティブでKPTをやめたことです。KPTでは皆さんに課題を挙げてもらうことになりますが、その課題がチームの状態や環境によって結構ブレてしまうなと。上手く機能するときもあると思うのですが、僕がサポートしているタイミングでは、もうちょっと上手くやりたいなと思っていました。

なので、KPTをやめてプルリク作成数だけを確認し、そこに対する課題分析と、インパクトが出せそうなトライを1つだけ決めることにしました。具体的な取り組み例としては、プルリクのボリュームが大きいと数が増えないので、1プルリクあたりの変更行数を100行以下にすること。それから、プルリク作成数が増えるとレビューが大変になるので、プルリクが出てから2時間以内にレビューすることなどですね。

そういった挑戦的なトライについて、レトロスペクティブでの喧喧諤諤の議論を踏まえながらも、生産性が上がるかもしれないからやってみましょうと。そして、次の週に確認して、確かにプルリク作成数が増えたとか、やってみたら意外と開発者体験として良かったと振り返りつつ、自分たちでいろいろと挑戦しながら課題を解決していきました。

詳細については、noteやテックブログにまとめたものがありますので、ぜひご覧ください(※記事最後にURL記載)。結論としては、プルリク作成数が最初のKPI、ボーリングで言うセンターピンのような、それを倒せば他の生産性に当たっていくものとイメージして、フォーカスしてきたという形になります。

現状はディスカバリーというより、デリバリーのところですね。まずはエンジニアが継続的にものづくりができている状態に持っていって、今後より事業貢献につながるディスカバリーを、POや事業部側の方と目指していくフェーズになるかなと思っています。

【DMM】リードタイムが約3分の1にまで大きく減少

――ここからは取り組みの効果について、「Findy Team+」のデータを見ていきたいと思います。こちらはDMMさんのサイクルタイム分析で、アクションごとのリードタイムが積み上げ棒グラフで示されています。9月ごろからリードタイムが約3分の1と大きく減っていることがわかりますが、これについていかがでしょうか?

dmm_buysell_04

pospome:改善を始めたのは7月ごろなのですが、9月頭まで苦戦していて、グラフを見るとまったく開発効率が上がっていないんですよね。その間は試行錯誤をしていて、その後に一気に下がったという形になっています。

最初に気づいた問題は、コンフリクトが多いというものだったのですが、なぜコンフリクトが多かったかというと、プルリクがマージされずに滞留していたからだったんです。常に25~30個のプルリクがあって、それぞれが少しずつマージされていくと、その他のマージされないプルリクにコンフリクトが発生するという状況ですね。

それで、マージまでに時間がかかっている原因を確認していったところ、プルリクのレビューに割く時間が極端に少ないことがわかりました。なので、それをCSSチームのマネージャーに直接話して、レビューする時間を1日1時間などと決めて確保してもらったんです。それが功を奏して、リードタイムが一気に減ったという流れですね。

――参考までに、DMMさんの同じ期間の稼働人数当たりのプルリク作成数を見ると、約2倍に増えており、取り組みによってアウトプット量も大きく増えていることが読み取れます。

dmm_buysell_05

【バイセル】プルリク作成数やデプロイ頻度が大幅に向上

――続いて、バイセルさんのデータです。棒グラフがプルリク作成数、3本ある折れ線グラフの一番上が平均プルリククローズ時間で、下2本はその内訳になっています。9月半ばからプルリク作成数が大幅に上昇し、リードタイムはその前から徐々に減っていることがわかりますが、実感としてはいかがでしょうか?

dmm_buysell_06

赤川:「Findy Team+」を導入したのが8月で、指標をプルリク作成数に決め打ちしてからは、数字が右肩上がりになってきているのをデイリーで見ていました。サイクルタイム分析でも、ランクがMediumやLowだったのが、ピークのときはEliteやHighになっていましたし、リードタイム全般が下がっていることは、すごく実感していましたね。

――コメントで「モブプロやペアプロなどを取り入れている際に、データを見るうえで気をつけていることはありますか?」とご質問いただいていますが、いかがでしょうか。

赤川:モブプロなどは、なるべく頻繁に行うべきだと思っていて、2人でつくっているものが1人のプルリクになっていたとしても、チームのアウトプットとして見れば特に問題ないかなと思っています。

――こちらのデータでは、棒グラフがデプロイ頻度、折れ線グラフが変更のリードタイムというコミットからマージまでの時間を示しています。デプロイ頻度が大幅に上がり、リードタイムも減少していることがグラフから見てとれます。

dmm_buysell_07

赤川:こんなに顕著に出るんだという驚きがありますね(笑)。実は、この時期にフィーチャーフラグを導入していて、それによってデプロイすることへの抵抗感がなくなったというのもあります。

――12月くらいから少しリードタイムが増えている傾向について、コメントで質問をいただいています。要因として思い当たるものはありますか?

赤川:年末年始というのもありますが、メンバーの1人がPdMとしての役割を持つようになった影響が大きいと思います。完全にPdMになったわけではなく、開発もしているのですが、そこがボトルネックになってリードタイムが落ちているという形ですね。

――もう1つコメントからの質問で、「プルリク作成数が改善することによる他の生産性への影響を、業務のなかで実感することはありますか?」といただいています。

渡邊:まず1つは、プルリクをたくさん出していると、エンジニア目線で進捗の実感がより得られやすくなります。プルリクを出して、レビューをもらってマージするという、そのサイクルが上手くまわっているという感覚ですね。

あとは、僕が見ていたチームでも、スプリントレビューに向けて、提供しようと思っていた機能をきちんとやりきるんだという意識ができつつあり、結果としてベロシティもFour Keysも安定しています。なにより実感として、メンバーみんなが「スコアも高いし、自分たち生産性高まってるかも」と感じる状態になったと、僕自身見ていて感じますね。

――今後は、デプロイ頻度を維持していくのか、引き続きプルリク作成数を追っていくのかなど、どのように考えられていますか?

赤川:先ほどの話でもあったように、我々としては一旦プルリク作成数をセンターピンとして見ています。ただ、最終的には見なければならないのは、ユーザーへの価値提供のタイミングだと思っていて。なので、デプロイ頻度だけではないような気もしているという感じですね。

――イベントの事前にいただいていた質問に、「本質的に追うべき数値は何か、どういう追い方をすべきか?」といったものがありました。これについて、DMMさんとしてはいかがでしょうか?

pospome:本質的に何を追うべきかは、正直わかっていません。なぜかというと、例えばプルリク作成数が多いといっても、たくさん障害が起きていて修正のプルリクを上げている可能性もありますし、マージの時間が短ければ本当に生産性が高いのかと言われると、そうではないと思っているからです。 ただ、相関関係はあって、プルリクの数が多いということは、サイズが小さくてレビューしやすくなっていたり、マージしやすくてコンフリクトが発生しにくくなっていたりと、正しい値に収束させることで妥当な生産性が出ている指標になります。 なので、その傾向を知って「この値を目指しましょう」というのが限界かなと。より本質的にやっていく場合は、自作でメトリクスを収集する必要が出てくると思っています。

――それではお時間となりましたので、イベントは以上となります。登壇者の皆さま、本日はありがとうございました!

※本イベントのアーカイブ配信(無料)はこちら

■DMM.com事例記事DMMプラットフォームでプルリクエストのマージ時間を250時間から50時間に減らした話 / Developers Summit 2023プルリクのリードタイムを5分の1に劇的改善。科学的思考とオーナーシップで変革するDMM.comのエンジニア組織

■BuySell Technologies事例記事PR数は開発生産性のセンターピンかもしれない生産性指標を可視化してチームのワークフローを改善したら生産性が爆上がりした話リファイメントとプランニングを改善することで、チームの属人化が解消された話「プルリク作成数がセンターピン」BuySell Technologiesの仮説思考が生んだ圧倒的生産性向上と課題解決

関連記事

エンジニアのキャリアプランニングについて【株式会社hokan】# 開発生産性LT Week

エンジニアのキャリアプランニングについて【株式会社hokan】# 開発生産性LT Week

イベントレポート
目標設定を組織に浸透させるには どうしたらいいのか? 〜導入初期フェーズの取り組み〜【株式会社Macbee Planet】# 開発生産性LT Week

目標設定を組織に浸透させるには どうしたらいいのか? 〜導入初期フェーズの取り組み〜【株式会社Macbee Planet】# 開発生産性LT Week

イベントレポート
ビジネスアウトカムを中心とするためのフルサイクルエンジニアという選択【アセンド株式会社】# 開発生産性LT Week

ビジネスアウトカムを中心とするためのフルサイクルエンジニアという選択【アセンド株式会社】# 開発生産性LT Week

イベントレポート
事業目標と個人目標設定について【GO株式会社】# 開発生産性LT Week

事業目標と個人目標設定について【GO株式会社】# 開発生産性LT Week

イベントレポート

エンジニアリング組織の
パフォーマンスを最大化

Findy Team+はGitHubやJiraなど
エンジニア向けツールを解析することで、
エンジニアリング組織の生産性を可視化するサービスです。