推測するな、計測せよ〜小さく始める生産性可視化と分析〜
登壇資料はこちらから
アーカイブ動画はこちらから私は株式会社メルカリの「メルカリShops」の開発チームでEMをしている佐藤と申します。※
本日は「推測するな、計測せよ〜小さく始める生産性可視化と分析〜」についてお話しします。
普段は@naoprというハンドルを使用し、社内やインターネットでは「なおぱー」と呼ばれております。
※本記事は、2023年5月30日時点の情報です。
お話しする内容は、弊社の開発生産性に関する取り組みについて大きく4つの構成でご紹介していきます。
メルカリShopsと開発組織
「メルカリShops」は、「かんたんで、売れる」をコンセプトにしたeコマースプラットフォームで、スマホだけでネットショップが開設できるサービスです。2021年10月に開始し、技術的にはメルカリとは別のシステムでフルスクラッチでの開発です。
開発組織の話に移りますが、元々はメルカリのグループ会社、株式会社ソウゾウが開発を担当していました。しかし、現在はメルカリ本体での開発となっています。
組織としては、プロダクトチームとイネイブリングチームの2種類で構成されています。
プロダクトチームはお客様の課題解決にフォーカスしており、エンジニアだけでなくプロダクトマネージャーやデザイナーも所属しているクロスファンクショナルなチームです。スクラム単位で4つのチームがあり、1チームは約10人です。イネーブリングチームは技術強化やインフラ整備を行うエンジニアのみのチームです。
「チームトポロジー」の本の概念で言うと、プロダクトチームはストリームアラインドチーム、イネーブリングチームはイネーブリングチームとプラットフォームチームの組み合わせです。
メルカリShopsの本格提供から2ヶ月後、メルカリのOBの方との会話がきっかけで、株式会社ソウゾウで「生産性可視化プロジェクト」、通称「PJ-Productivity」が立ち上がりました。
Mさんと私は、「開発組織の生産性をどう測定し、どう活用するか」に大きな興味を持っていました。小さな組織でも生産性の可視化を始め、それを定期的に観測することで、組織が大きくなった際に生産性が低下してもすぐに対処できると考えました。
現状に課題を感じていない段階でのこの取り組みは、珍しいのかもしれません。この会話から1ヶ月後に、このプロジェクトを開始することとなりました。
生産性可視化プロジェクト（PJ-Productivity）の立ち上げ
生産性を可視化するために外部SaaSの導入を考えましたが、GitHubのアクセス権やセキュリティ・コンプライアンスの問題で導入は見送りました。その後、自社開発を検討し、githubAPIのPull-req関連の情報や「Four Keys」という指標に関する調査を進めました。
自前での開発を検討する際に、プロジェクトメンバーとして十分な時間が限られていたため、最小工数で意味のある指標を特定する必要がありました。結果、2つの指標の可視化を決定しました。
生産性可視化までの挑戦と苦労
最初に取り上げるのは「デプロイ数」です。これは、masterブランチにmergeされたPull-reqの数を指しています。以下の図では、このデプロイ数を週別に示しています。この図は後ほど再度触れます。
次に、「開発リードタイム」という指標です。これはPull-reqが作成されてからマスターブランチにマージされるまでの時間を示しています。週別に、このリードタイムの中央値を示す図もご紹介します。
この図からは、デプロイ数と比較して、チームや時期によるばらつきの大きさが読み取れると思います。
これらのグラフの作成方法や背後のアーキテクチャについても説明します。
サーバーの設置やメンテナンスは煩雑なので、私たちはGoogleSheetsとGoogleAppsScriptを活用しています。具体的には、Google Sheetsに設定されたGoogleAppsScript（GAS）が毎日1回実行され、このスクリプトがGitHub APIを呼び出して、シートにPull-reqの情報を追記します。
取得する情報としては、Pull-reqのタイトル、作成時間、クローズされた時間、そしてgitlabのURLです。チームの関連付け情報は独自のロジックで生成しています。
そして、このシートのデータをLooker StudioというGoogle Cloudのサービスに接続して、グラフ化しています。
結果はどうだったのでしょうか。
私たちが初めに行ったのは、自社の相対的な立ち位置を確認することでした。
指標の分析と改善の取り組み
Googleクラウドの記事には、「Four Keys」という指標に対して、エリートからローまでの4段階のレベルが示されています。ソウゾウのデプロイ頻度は、この中で最上位のエリートに該当し、リードタイムは上から2番目のレベルでした。
もとより私たちは生産性に特別な課題を感じていなかったので、これが客観的にも証明されたことは良い結果と受け取っています。
次に、デプロイ数とリードタイムを俯瞰し、その大まかな傾向を掴みました。メルカリShoptsの初リリースは7月末で、その基準で前後の数値を比較すると、初リリース後のデプロイ数は減少し、リードタイムは増加していました。
興味深いことに、ファーストリリース後も開発チームの人数は増加しているにも関わらず、デプロイ数は減少しています。また、チーム間でのリードタイムの差が大きいことが分かり、これらのデータを基に更なる調査を進めました。
デプロイ数の変遷を詳しく見ると、大きな変化が2回ありました。一つはファーストリリースの際、もう一つはファーストリリース後の年末から1月頃でした。私たちは、これらのタイミングでデプロイ数がなぜ減少したのかを考察しました。
まず、デプロイの回数がリリース前に多かった理由は明確です。スピードを重視して進めていたため、現在のような厳格なコードレビューやQAが行われていなかったこと、そしてエンジニアの稼働が高かったことが主な要因でした。
次に、ファーストリリース後の1月にデプロイ数が減少したことは意外でした。そこで、デプロイ数が多い月と少ない月を2ヶ月ずつピックアップし、Pull-reqの内容を詳細に確認しました。この確認で、11月までと1月以降のPull-reqの傾向が大きく変わっていることが明らかになりました。
ファーストリリースから12月までのPull-reqには、機能リリース以外にも、多くのバグ対応やインフラ設定の追加が含まれていました。特にチームEは、インフラ設定の追加によるPull-reqが目立ち、1月以降はその数が明確に減少していました。
これを踏まえると、リリース直後の一時的なデプロイ数の増加は、1月以降の減少とは別の要因によるものでした。結局、ファーストリリースから12月までのデプロイ数は参考値として捉えるべきで、1月以降の微増は予測通りだったと考えられます。対処すべき問題は確認されませんでした。
デプロイ数に続いてリードタイムの変遷を分析しました。ファーストリリース後、リードタイムが急増し、チーム間でその差が大きいことが特徴です。
チームB(赤色)は縦軸を突き抜ける傾向にあり、対照的にチームE(青色)はリードタイムが短いです。
主な理由として、QAの取り組みを強化したことが挙げられます。
この差は主に開発する機能の違いから来ています。大きな機能開発を行うチームは長いリードタイムとなり、インフラの小変更やバグ修正を行うチームは短いリードタイムとなります。
ただし、このグラフだけでの改善点は明確でなかったため、異なる角度からの分析も実施しました。
リードタイムを1時間未満、24時間以内、300時間以内、600時間以内、それ以上という区分でグラフ化した結果、大半は1時間以上24時間以下のリードタイムでした。1時間未満や300時間以下のリードタイムはほぼ同じで、300時間以上のリードタイムを持つものは一定数確認されました。この長いリードタイムのPull-reqを中心に改善策を考えることとしました。
リードタイムが長いPull-reqは、高いQAコストやコンクリフトの発生、障害のリスク増大などの問題があり、開発者の体験が悪化していました。
リードタイムが長いPull-reqの多くは、新規マイクロサービスや新規APIの作成に関連していました。これらのPull-reqは、バックエンドとフロントエンドの変更を1つのフィーチャーブランチにまとめていることが特徴です。そこで、既存機能に影響を与えないバックエンドの変更を先行リリースすることで、リードタイムを短縮する試みを開始しました。
この方法には、開発体験の向上などの利点があったものの、全てのケースで適用可能なわけではなく、リードタイムの劇的な短縮は確認できませんでした。また、デプロイの回数増加による作業負荷の増加を、ChatOpsなどを用いて軽減する取り組みも進めています。
ただ、定量的アプローチだけでは生産性改善の限界を感じたため、定性的アプローチも導入しています。
開発チームへのアンケートを基に、効果的かつ実施しやすい改善点を特定し、活動を始めました。当プロジェクトは2人のメンバーで構成されており、すべてのタスクを実施するのは難しいことから、サブプロジェクトを設定し、外部メンバーに一部の活動をリードしてもらっています。
アプローチの詳細は時間の都合上割愛しますが、最後に詳しい内容をまとめたブログ記事のリンクをご紹介いたしますので、そちらをご参照ください。
まとめです。
ソウゾウでは、業務委託メンバーと2人というスモールチームで、生産性可視化プロジェクトを立ち上げました。
最小工数で必要最低限の数値が見れるようなダッシュボードを実装しました。ダッシュボードで可視化したデプロイ数とリードタイムを元に、現状分析と改善活動を少しずつ開始しています。
定量アプローチだけでなくて、定性面からも改善を行っています。
今日お話した内容は、ブログやPodcastでも公開しているので、よろしければぜひご覧ください。
- 「推測するな、計測せよ」ソウゾウで始動したエンジニア組織の生産性可視化
- 生産性可視化PJを通して実現したい理想的な開発組織とは
- 【続編】「推測するな、計測せよ」エンジニア組織の生産性可視化 〜定量分析で得られた知見、定性分析の開始、そしてチーム拡大へ〜
