【メルカリ×DeNA】何を計測すべき？開発生産性可視化のWhy-What-How
2023年6月20日、ファインディ株式会社が主催するイベント「【メルカリ×DeNA】何を計測すべき？開発生産性可視化のWhy-What-How」がオンラインにて開催されました。
Findyでは、エンジニア組織支援クラウド「Findy Team+(チームプラス)」をリリースし、エンジニア組織づくりや生産性の可視化を通じたパフォーマンスの最大化支援に取り組んでいます。
昨今では、開発生産性を定量化する指標として、GoogleのDevOps Research and Assessment（DORA）プロジェクトによる研究で提唱された、Four Keys指標がトレンドになりつつあり、開発生産性の維持や向上をミッションに掲げて取り組む組織が増えてきています。
一方で、開発生産性に対する重要性を認識しつつも、可視化の方法がわからなかったり、取り組みのイメージが持てず、具体的な施策実行にまで至らないケースも多く聞かれています。
そこで本イベントでは、株式会社メルカリPlatform DXチームの星野さん、株式会社ディー・エヌ・エー（以下、DeNA）品質本部品質管理部SWET第二グループの片山さんと田熊さんをお招きし、開発生産性向上に向けた可視化の取り組み背景、計測指標や測定方法などについて、パネルディスカッション形式でお伺いしました。
■登壇者プロフィール
株式会社メルカリ Platform DXチーム 星野将さん
2017年にメルカリに入社。Individual Contributorからスタートし、Engineering ManagerとしてMicroservice migrationに携わる。またTechnical Product Managerとして安心・安全なFeature Releaseを遂行。今はまたSoftware EngineerとしてPlatform DX Teamに所属。昔から一貫して、開発の無駄をなくし，開発効率を上げられるエンジニアを目指している。
株式会社ディー・エヌ・エー 品質本部品質管理部SWET第二グループ 片山大樹さん
2020年DeNAに入社。SWETグループでiOSアプリを中心とした自動テストのサポートを行う。直近はAgile Testingのサポートやチームの健康状態可視化にも取り組んでいる。
株式会社ディー・エヌ・エー 品質本部品質管理部SWET第二グループ 田熊希羽さん
2018年にDeNAに入社。SWETグループで主にAndroidアプリへの自動テスト導入やサポートを行っている。 2020年よりPococha事業部を兼務し、PocochaのAndroidアプリの開発を担当。2021年よりSWET dev-vitalチームでプロジェクトの健康状態の可視化に取り組んでいる。 開発生産性の可視化における、取り組みの背景や課題
※本イベントのアーカイブ配信（無料）はこちら
目次
開発生産性の可視化における、取り組みの背景や課題
──まず最初に、登壇者の皆さまから自己紹介をお願いいたします。
星野：メルカリの星野と申します。2017年にメルカリに入り、ICからスタート後、EMをしたり、部署を変えてTechnical Product Managerをしたりしていました。今はソフトウェアエンジニアとしてPlatform DXチームで開発生産性に携わっています。本日はよろしくお願いします。
片山：DeNAのSWETグループに所属している片山です。2020年に入社し、SWET第二グループでiOSアプリを中心としたテスト自動化サポートを行っています。直近は、弊社のライブコミュニケーションアプリ「Pococha」というプロダクトで、アジャイルテスティングの導入サポートや、開発生産性の可視化などにも取り組んでいます。本日はよろしくお願いします。
田熊：同じくDeNAのSWET第二グループに所属している、田熊です。2018年に入社して、SWETグループで主にAndroidアプリへの自動テストの導入やサポートを行っています。2020年からは「Pococha」事業部を兼務し、Androidアプリの開発を担当。2021年よりSWET dev-vitalチームで、プロジェクトの健康状態の可視化に取り組んでいます。よろしくお願いします。
──本日は5つのテーマでお話を伺っていければと思います。それではさっそく、両社における開発生産性可視化の取り組み背景からお話いただけますでしょうか。
星野：背景としては2018年ごろに、それまでモノリスだったメルカリのアーキテクチャをマイクロサービスに分割、移行していくという大きな意思決定がありました。これは当時、界隈でもそこそこ話題にしていただいたので、もしかしたらご存知の方もいらっしゃるかもしれません。
当時は組織が急拡大するフェーズで、人がたくさん入ってくることが予想されていました。それに対してモノリスのアーキテクチャでは、例えばコードベースが複雑になる、障害時に影響範囲が局所化できない、どこかで障害が起きるとサービス全体が落ちてしまう、といった懸念があり、そういったものを解決したいという狙いがありました。
加えて、当時は現実的に1日これくらいというデプロイの上限値があり、人が増えることに対して、アーキテクチャがボトルネックになる懸念がありました。こうした背景から、マイクロサービスへの移行が決断され、新しいマイクロサービスアーキテクチャの基盤提供を担ったのが、当時私が所属していたMicroservice Platformチームです。
我々にはマイクロサービスによって、先ほど挙げた課題や懸念を解決できるという仮説がありました。その仮説を検証するには、スケーラブルなアーキテクチャによって生産性が向上していることを測定する仕組みが必要だったので、可視化の取り組みを始めました。ただ、早くからα版として取り組んではいたのですが、実際はさまざまな制約や事情があり、十分なアクションができるようになったのは最近のことです。
──DeNAさんからも取り組みの背景についてお願いいたします。
田熊：DeNAにはいろいろな事業部があるのですが、過去に開発生産性や品質が落ちてしまう課題があったとき、その教訓を生かせず、別のプロジェクトでも同じような問題が発生するということが起きていました。
SWETグループには、例えば「自動テストのサポートをしてください」といった依頼が来るのですが、そうしたタイミングだと、もう既に問題が大きくなっていて、解決が難しかったり、時間がかかったりすることが多くあります。そのため、問題が大きくなる前に予兆を発見できるように、開発プロセスの健康状態を可視化しようと、dev-vitalチームが誕生しました。
dev-vitalチームができて、しばらくはデータを収集できる基盤の整備などを行っていたのですが、進めていくなかで大きな課題がありました。それは、社内の各事業部での開発プロセスが統一されておらず、1つの計測手段で広くさまざまなプロジェクトに適用するのが難しいということです。
リリース頻度を例に挙げると、あるチームではマスターにマージすれば、自動で本番デプロイされるので、そこのCIやGitHubの情報を見ればいい。一方、他のチームでは「マスターマージ＝デプロイ」ではなくて、いくつかマスターに修正が溜まっていたものを、手動でデプロイしている等、リリース頻度だけを取っても、チームごとにどこを見れば良いのかが異なる状況でした。
一つの計測手段で適用するには、いろいろなチームのプロセスを変えなければならないし、それぞれのプロジェクトに合わせるには、一つひとつカスタマイズしなければならない。それをdev-vitalチーム主導でやっていくのは厳しいというのが、最初にぶつかった壁でした。
そのなかで、「Pococha」が開発プロセスをアジャイルに移行するという話があり、前職でアジャイル開発の経験がある片山が、開発プロセスの整備をサポートすることになりました。
その際、「Pococha」側でも一度定義したプロセスをどんどん良くしていきたいという思いがあったので、それならプロセスを変えたことによる効果測定をしたり、ボトルネックの箇所を特定したりするために、データの可視化をやっていきましょうと。そこで「Pococha」への適用を始めたという経緯があります。
可視化に取り組むチーム体制、スコープ対象やゴールは？
──続いては、開発生産性の可視化に取り組むチームの体制についてです。スコープ対象やゴール、KPIなども含め、ご紹介いただけますでしょうか。
星野：Platform DXチームでは、開発生産性に関わるタスクは、数あるミッションのうちの1つです。そのため、現在はチームの中から、私を含めた3人がそこにアサインされる形になっています。
スコープ対象は、メルカリグループ全体であり、USのメルカリプロダクトなども含まれています。ただし、株式会社ソウゾウは、独自で取り組んでいる部分があるので、そこだけ例外というイメージです。
ゴールに関しては、可視化することではなく、可視化したうえでの改善が目的なので、その状態をつくることをゴールとしています。KPIについては、現在仮置きしつつ、それも含めて検証を進めているところです。
──KPIについては検証中とのことですが、評価やOKRの指標にも置かれていないということでしょうか。また、仮説としてはどういったものを考えられていますか？
星野：そうですね、特に評価とは明確に切り離して考えています。今は、Four Keysの中からデプロイ頻度をピックアップしようとしています。これはFour Keys4つの指標の中でそれだけにフォーカスするというわけではなく、Four Keysをもとにした改善アクションを行った結果、その成果がデプロイ頻度に値が跳ね返ってくるのではないかという仮説ですね。
──DeNAさんのチーム体制はいかがでしょうか？
田熊：現在、dev-vitalチームのメンバーは4人です。そのうち、自分と片山が「Pococha」に対していろいろなアプローチをしている状態ですね。スコープの対象としては「Pococha」のみ。自分と片山以外のメンバーは、別チームに対してアプローチしているわけではなく、定例でのディスカッションなどに関わってもらっています。
dev-vitalチームのゴールは、開発プロセスの健康状態の可視化と悪化の早期発見。それができるダッシュボードを提供することで、早期にアクションが打てるようになることを目指しています。「Pococha」のチームでは、開発メンバー自身での自立的な開発プロセスの改善、定義した開発プロセスの維持をゴールとしています。
──参加者の方からいただいた質問にも触れたいと思います。「プロダクト開発側でも、生産性の課題は認識していることが多いと思います。そちらとのコミュニケーションや役割分担はどうされていますか？」とのことですが、いかがでしょうか？
星野：最終的に改善していくのはプロダクトの方々なので、理想はPlatform DXから計測できるデータを提供して、それをもとにした改善をプロダクト側で行ってもらうのが理想だと思います。
ただ、今はそこまで上手くまわせていないので、開発チームと一緒になって、どういう改善ができるかを探っている段階ですね。そのため、まだ明確な分担ができているとは言えません。
片山：自分は「Pococha」のQAエンジニアリード的な立場を兼務しているので、今は自身がプロダクト開発側でもあります。それにプラスして、いろいろな開発チームのリードの方々と週1で会話をして、可視化の取り組みを改善するための議論もしています。
そのため、自分自身がプロダクト開発側に行って、コミュニケーションで解決しているところがありますね。初期のころは、開発チームの一員として、実際に開発のサポートをしながら振り返りに参加して、一緒に数値を見ていくようなこともしていました。
【メルカリ】可視化において3つのデータソースから測定
──それでは、本日のメイントピックとなる、可視化における計測指標と測定方法について、ぜひ教えていただければと思います。
星野：Platform DXチームでは、DevStatsというプロダクトを提供しています。弊社のエンジニアブログでも触れていますが、データの収集・保存・可視化を行うプロダクトで、そのなかの大きなトピックの1つとして、開発生産性に関するものがあるという形ですね。
開発生産性に関する指標として、今はFour Keysを採用していて、そのコンセプトにのっとって収集から可視化までを行っています。下記は、Four Keysの各指標とデータの関連を示した図です。
※参考：「Mercari Engineering」ブログ：DevStats – メルカリ グループの各種指標計測について
大きなポイントが3つあって、1つはデータソースが3ヶ所のみということ。そのため、どのように測定しているのかという問いに対しては、GitHub、Deployment Tool、 Incident Management Toolの3ヶ所のデータソースに向き合えば、測れるはずだと考えています。
2つ目のポイントは、その3ヶ所のツールが全社的に統一されていること。ここが例えばDeNAさんと比較して、メルカリ独自のやりやすかった部分かなと思います。開発にはGitHub、デプロイにはSpinnakerを採用しています。Incident Management Toolは、かつてはJIRAでしたが、今はSaaSのツールを使っていて、これも全社的に採用されています。
3つ目のポイントは、MTTRやFailure Rateのところで、ここはインシデントの数をもとにした数値を可視化しています。このインシデントの数を使うことに関しては、議論の余地があるかなと思っています。
インシデント自体は担当者が手動で起票するものなので、GitHubやSpinnakerからWebhookのイベントを受け取って、それを集計することと比べると、ややマニュアル感が強いなと。インシデントの起票には全社的な基準がありますが、何らかの理由で起票されるべきものがされなかったときに、MTTRやFailure Rateの値が取れなくなってしまう脆弱さがあることを認識しています。
そのため、別の案として、例えば監視システムからのアラート、あるいは復旧の通知など、自動で通知される情報をもとに計算するという考え方もありますが、今は採用していません。いずれにしても、環境によって計測方法を自分たちで定義して、計測していく必要があるということが、大事なポイントかなと思います。
──ツールの統一について、DeNAさんでは大変だった部分としてお話がありましたが、メルカリさんではもともと統一されていたのでしょうか。それとも、マイクロサービス化を進めていくなかで、統一していったのでしょうか？
星野：まさにマイクロサービスに移行していくときに、当時のMicroservices Platform チーム側で一通りのツールセットを定めました。新しくマイクロサービスをつくる際に、それらをデフォルトで使えるような環境を整えて、デベロッパーが開発を始められる状態になっています。
これについては、弊社ではテクニカルな視点でのMicroservicesはたくさんあるのですが、事業としては1つなので、そういったことが比較的やりやすい環境にあります。そこは、事業が分かれているDeNAさんとは異なるところかなと思います。
【DeNA】データソースをJiraに絞り、内製ツールで測定
──では続いて、DeNAさんの計測指標と測定方法についても、教えていただけますでしょうか。
片山：「Pococha」ではデータソースをJiraに絞っています。Jiraから取れるデータをもとにカスタムしてしまったので、上手く取れていなかったベロシティなど、Jiraで表現しきれなかった部分も可視化しました。加えて、Four Keysをもとに自分たちなりに取るべきだと考えた、リリース頻度や本番障害数、チケットの各ステータスごとの遷移時間も計測しています。
また、「Pococha」の開発プロセスを改善するタイミングで、開発生産性とはそもそも何かというところに関して、「生産性が高い＝フロー効率が高い状態」と定義しています。そのため、フロー効率がより高い状態を目指せる、それがわかる指標の可視化を中心に進めていきました。
田熊：下記の図のように、Jiraのデータを取ってきて、BigQueryへアップロードしてくれる内製のJira分析ツールがあります。これは、過去にゲームタイトルでQAチケットを分析するためにSWETで開発したものを再利用していて、「Pococha」のカスタムフィールドに合わせるなどカスタマイズして使っています。
この内製ツールをCircle CIで定期実行させて、BigQueryにデータをアップロード。Looker StudioでBigQueryのデータをデータソースとして利用し、各チームのダッシュボードを用意するという構成になっています。
──Jiraで計測しているメトリクスのなかで、特に重視しているポイントはありますか？
片山：プロセスの改善という観点では、スプリント内で消化したポイントと、チケットのステータス遷移時間。この2つがチームで重視しているポイントになります。
ベロシティを見るだけでなく、差し込みで入ってきた案件や、集中したい機能開発と関係のないタスクがどれくらいあるかも可視化しています。そこに着手しているということは、本来進めたい開発が止まっているということなので、フロー効率に関する議論のもとにします。
チケットのステータス遷移時間ついては、例えば開発が終わったのに、それがすぐにテストされず待機時間があるとしたら、それはなぜかという議論のもとになります。そのため、今は、改善のためのベースになる数値として、ステータス遷移時間も重視して見始めています。
改善というより、予防的な側面が強いポイントの1つとしては、極端にリリース頻度が落ちていないかどうかを見ています。また、改善したものの、速さを重視して品質が落ちてしまっていないかを、変更障害率と復元時間から常にチェックしています。
可視化の取り組みを進めるなかでの、成果や学びは？
──実際に可視化の取り組みをされているなかで、現状どのような成果や学びがあったかについて、それぞれお伺いできればと思います。
星野：可視化されることで、数値をもとにした議論ができるようになり、経営層にも取り組みの結果を共有できるようになってきました。それによって、可視化への取り組みの重要性を、より高められているかなと思います。
ただ、それはあくまで副作用であって、最初に向けるべきベクトルは、現場のデベロッパー、エンジニアに対する改善の成果だと思っています。それで言うと、まだまだこれからで、実際にいくつかのチームと密に連携してアクションしている最中。イテレーションサイクルの真ん中にいるようなイメージです。
実際に数値を見て、現場でできるアクションを考え、実行するところから、プロダクト側への「こういう数値が見たい」といった改善のフィードバックを受け取ること。そして、開発チーム自身の開発生産性を高めていくという改善の両軸を狙っています。
これから望んでいる改善成果としては、例えばデプロイ数が100になりましたというような、数値できれいに表せる成果ではなく、「何々をしてデプロイ頻度が改善した」という状態をつくることにあります。そのため、なるべくそういうユースケースを増やして、汎用化していくことを目指しています。
──経営層への共有に関して、ご質問をいただいています。「経営層に対しては、売上への貢献とは完全に切り離して説明されているのでしょうか。もし説明しているとしたら、どのようにされていますか？」とのことです。
星野：これは2つの軸があると思っていて、現場のエンジニアと話すときには、最終的な目標は経営層が求めているようにビジネスをグロースすることである、と伝えていく必要があると考えています。そうしないと、目先の数値にフォーカスしてしまう。その数値はハック可能なものなので、本質的ではないアクションになってしまいます。
一方で経営層から見たときに、何かをしたら確実に売上が上がる、というものはないと思っていて。それは開発のアクションに限らず、例えばPMも「何個の企画をリリースしてください」ではなく、「価値を出して、売上を上げてください」と言われるはずですよね。
それと同じで、例えばFour Keysで計測している指標が、そのまま経営層に伝わるものでもないし、伝わっていいものでもないと思っています。生産性を高めることで、グロースに近づくという相関はあると思いますが、式で表せるようにダイレクトにつながるものではありません。そこの理解は、経営層側に伝えていく必要があると思います。
──DeNAさんは、現状の成果や学びについていかがでしょうか？
片山：SWET目線と「Pococha」目線、2つあります。まずSWET目線で言うと、データを提供することが1つの目的なので、可視化そのものは1つの成果だと思っています。ただ、それはあくまで提供する側の話で、「Pococha」側の目線としては、データを見ながら具体的な改善アクションを、チームで今検討しているところです。
具体例としては、先ほどお話したようにタスクの待ち時間を減らすとか、そういったものですね。並行して、追加で見たい指標の可視化にも取り組んでいます。
──そういった取り組みを進めるなかで、現場から挙がる懸念などはありますか？
片山：やはりデータ化するにあたって、特にステータスの遷移時間などは、外れ値が出てきてしまいます。数字が悪くなっているけど、よく見てみたら、ステータス遷移を手動でやっているので、それを忘れてしまっていたとか。そういった外れ値が混ざってしまって、改善アクションを起こしづらいということが、一部では起きていたりします。
対策としては、ステータス遷移にJiraのオートメーション機能を使って、ある程度自動で遷移できるようにする。フィールドの入れ忘れも、可能な限りJiraのオートメーションを使って自動的に埋めるなどして、対応するようにしています。
まだ計測できていない工程の可視化にもチャレンジしていく
──それでは最後のテーマとして、今後の方針についてもそれぞれお伺いできればと思います。
星野：可視化したデータから、まだ見えていない余白の部分がわかってくるので、そこに対するアプローチをしていきたいと思っています。例えば、開発プロセスで言うと、企画から開発が立ち上がるまでの工程は時間計測できていないので、そういったところも必要かなと。計測指標で言うと、Four Keys以外の指標の検討や検証も必要かなと考えています。
さらに、一番大事なところとして、可視化できる範囲を広げてビジネスアウトカム的なつながりを検証していくこと。先ほどもお話したように、根本的な目標はビジネスのグロースなので、そこに至る道筋や、何かしらの鳥瞰を明らかにしていきたいと考えています。
──DeNAさんは今後の方針について、いかがでしょうか？
片山：計測対象がプロダクトの中の開発チームで、その開発チームが複数あるのですが、そのダッシュボードを手動でつくっているため、運用が大変になってきています。なので、まず1つはその自動化を検討しています。2つ目は、ここまでにお話していたように、各チームから可視化のニーズを吸い上げ、常に改善し続けることですね。
3つ目としては、今開発プロセスをPFD（プロセスフローダイアグラム）で細かく書いているのですが、今計測できているのは開発全体の一部分だけ。Jiraで企画からリリースまで全部を管理しているわけではないので、先ほどメルカリさんからもあったように、企画段階など今まだ計測できていないプロセスの可視化にも、チャレンジしたいと思っています。
また、今は対象が「Pococha」だけとお話ししましたが、dev-vitalチームとしては、他の事業部でも可視化をしていく必要があると思っています。それを目的にdev-vitalチームができたので、「Pococha」で上手くいった成功事例をもとに、横展開もしていきたいというのが、今後の取り組みになります。
──ありがとうございます。最後に、今回ご参加いただいた感想をいただければと思います。
星野：非常にホットかつ難しいテーマで、わかりにくい部分もあったかもしれませんし、まだまだ自分がわかっていないところもあると思います。そういったところはぜひ感想をいただければと思います。また、アフターセッションなど別の機会でも、お話しできれば嬉しいです。本日はありがとうございました。
田熊：まだ取り組み途中で、今後もいろいろとやっていきたいところなので、ぜひまたアフターセッションの場でもお話できればいいなと思います。本日はありがとうございました。
片山：メルカリさんの取り組みで、やはり同じところで悩んでいるんだなという部分もありましたし、これからやっていくべきところもわかりました。自分たちの取り組みもまだ道半ばですが、アフターセッションの場で、同じ悩みを抱えている方々と直接お話できたらいいなと思います。本日はありがとうございました。
──ご参加いただいた皆さま、本日はありがとうございました！
※本イベントのアーカイブ配信（無料）はこちら
登壇企業様からのお知らせ
ファインディからのお知らせ
ファインディでは、Four Keysの可視化や、開発生産性向上をサポートするサービス「Findy Team+」を提供しております。現在、2週間無料トライアルも受け付けております。
