ソウゾウで、生産性可視化プロジェクト“PJ-Productivity”の推進をしている@masudakです。「メルカリShops [フライング] アドベントカレンダー2022」の8日目を担当します。

今年5月末にメルカンにて、Google Four Keysを参考に生産性計測を始められたこと、分析はこれからということを記事（以後前回記事）にしました。

「推測するな、計測せよ」ソウゾウで始動したエンジニア組織の生産性可視化 | mercan (メルカン)

それから5ヶ月経て、本プロジェクトにどんな変化があったか、知見や課題を共有します。

前回記事の振り返り

前回記事に載せた調査結果は、以下のようなものでした。

• ソウゾウは生産性が高い
  • Google Four Keysを参考にするとデプロイ数は最上位のEliteで、リードタイムは上から2番目のHigh ※1
• サービスリリース時（2021年7月）と比べると、デプロイ数は減少傾向にある。リードタイムは上昇傾向にある
• その要因については調査が必要

前回記事以降のデータ詳細を調査し、多くの学びがありました。本記事はそういった取り組み・学びについて共有していきます。

※1 Google Four Keysではデプロイ数を「コードを push する頻度」、変更リードタイムを「コードの commit から本番稼働まで」としている。ソウゾウでは簡単に計測しやすいよう、デプロイ数を「mainブランチにmergeされたPull Requestの数」、リードタイムを「Pull Requestが作成されてからmainブランチにmergeされるまでの時間」とした

本プロジェクトに起きた3つの変化

ソウゾウのバリュー”Move Fast”に基づき、この期間も多くのチャレンジを行いました。その結果、3つの変化がありました。

• ① 定量結果をもとに、分析・改善施策が進行
• ② 定量アプローチに限界を感じ始め、定性アプローチを開始
• ③ サブプロジェクト発足による、チーム力強化

前回記事について振り返ったのち、それぞれについて述べていきます。上記の取り組みについて知りたい方は、振り返りをスキップし、①からお読みください！

① 定量結果をもとに、分析・改善施策が進行

詳細な分析を開始

数字は単なる数字であって、詳細を調査しなければ、いいのか悪いのか判断できません。ということで、なぜその数字になっているのかを調べました。

といっても、やっていることはシンプルです。

• ① 数値が高い月と低い月の2ヶ月分を選ぶ
• ② その期間のPRの変更差分をソースコードレベルで確認する

①については、デプロイ数が多い（またはリードタイムが短い）月と、デプロイ数が少ない（またはリードタイムが長い）月を比較対象として選びました。そうすることで、デプロイ数が多い月にはどういった傾向があるか判断できると考えたからです。

②については、PRを一つ一つ確認することで、どういった種類の開発なのかを調べることができます。

結果分かったのは以下でした。

• リリース後も半年（2021年7月〜12月）は機能リリース、バグ対応、インフラの設定追加が増えていた
• その以降（2022年1月〜）数字が安定し始め、デプロイ数は増加、リードタイムは減少傾向になってきた

前者については、サービスの機能開発のみならず、Cloud Runの設定変更や脆弱性対応などインフラの設定追加もよく見られました。
特にインフラの環境は開発環境・本番環境など、環境が複数にまたがるため、見かけ上デプロイ数が上昇する傾向にありました。

つまり、リリース後半年ほどは細かな不具合修正やインフラの設定値変更等が多く、通常の運用フェーズとは異なった数値的特徴が見られると言えます。そのため、この期間の生産性指標はあくまで参考値として扱うほうがよいと言えそうです。

その点を踏まえると、2022年1月以降が正常値として扱うことが妥当であること、また1月以降デプロイ数やリードタイムがより向上していることも分かってきました。

以下の図では、デプロイ数が2022年1月以降右肩上がり、ということが分かります。

定量データに基づく改善策の実施

デプロイ数やリードタイムが安定しており、数字も良くなっているので何も改善しなかったか、と言うとそういうわけではありません。

開発リードタイムをさらに詳細に分析していくなかで、改善できそうなポイントが見つかってきました。

上記の図では、リードタイム600時間を超えるPRが、毎月2,3個程度あることを示しています。時期の変動はなく、常にそういった開発が動いていました。

長時間mainブランチにマージできないとなると、マージする際のQAコストが非常に大きく、かなり慎重にQAしなければなりません。また、mainブランチにすでにマージされた機能を取り込み続けると、コンフリクトが発生しやすく、本来必要のない作業まで発生してしまい、開発体験が悪化したり障害の発生リスクが上がります。

そういったビックバンリリースを避けるため、新規マイクロサービスや新規APIといった既存機能に影響のないバックエンド差分を先にリリースし、その後クライアントをリリースすることで、リードタイムを短くする取り組みを一部のチームで試験的に始めました。

② 定量アプローチの限界を感じ始め、定性アプローチ開始

ここまでデプロイ数、リードタイムの可視化を進めていましたが、非常に苦労したのがそれらの数値から具体的な課題を見つけることでした。
たとえば、一週間に一回もデプロイできない、リードタイムも一週間以上という状態であれば、改善していこうという機運も作りやすいでしょう。しかし、全くそういう状況ではありませんでした。

そのため、今までの定量アプローチに加えて定性アプローチも取り入れることにしました。

アンケート実施

実際開発・企画している人に聞くのがよいだろうということで、アンケートを作成し、ソウゾウのエンジニア・PMの方々に回答をお願いしました。

質問は以下のようにしました。

• ソウゾウでの開発に対する満足度をお答えください（5段階評価）
• なぜそのように感じましたか？
• 開発をする上で、一番課題に感じてる点は何ですか？
• ソウゾウでは、一秒でも早くお客さまに新しい機能を提供するため、より生産性の高い組織を目指し- ています。その実現のために、ソウゾウに足りないものはどういった点でしょうか？

忙しいなか、本当に多くの方が回答してくださりました。そのおかげで定性的なデータが集まりました。
（余談ですが、メルカリグループでは、こういったアンケートを取る際に、積極的に回答してくださる方が本当に多いです。こういう点も素敵な会社だと思う理由だったりします）

アンケート分析

定量的アプローチで課題感が見えにくく悩んでいたのですが、定性的アプローチだと想像以上に課題があげられていました。

ここに上げたのは一部ですが、このような回答が挙げられていました。

• Pull Request 毎のデプロイ環境の上限数
• ドメイン知識の偏り
• 設計レビューの属人化
• テストコード修正コストの高さ
• 複数サービスを跨いだときの動作確認
• カンパニー間のコミュニケーション

こういったなかで、取り組みやすく、効果が高いものをEMの会議で選定しました。

• Pull Request 毎のデプロイ環境の上限数
• ドメイン知識の偏り
• 設計レビューの属人化

ソウゾウでは、Pull Request 毎のデプロイ環境が自動で作成され、QAしやすい環境をつくっています。一方で、Cloud Runは同時に稼働できるリビジョンに上限があるため同時に稼働できるQA環境数に上限がありました。そのため、並行して多くの開発を行っているとQA環境数が上限に達してしまい、開発が終わっている案件のQAができない状況が発生していました。Googleの担当の方にご相談したところ、幸運にもCloud Runのリビジョン数が直近で1000から2000に倍増した旨を教えていただきQA環境が枯渇してしまうことがなくなりました。

また、ソウゾウでは、現在60以上ありどんどん増えていくMicroservicesの開発を特定のチームに委ねるのでなく全てのチームで開発・運用しているのですが、自分が開発したことのあるMicroserviceのことは分かるが、触ったことのないMicroserviceについてはあまり分からず学習コストが高いという声もありました。この課題については後述するサブプロジェクトを立ち上げて改善方法を検討しているところです。

設計レビューについては、Lead Architectを含む数人に依頼が集中してしまい負荷が高まってしまったり、負荷が高い状況からカジュアルに依頼がしにくいという問題が起きていました。その問題を軽減するため、設計レビューを依頼するためのSlack usergroupを作り各チームのシニアなエンジニアや設計レビューに興味のあるメンバーが自由にgroupに入れるようにしました。
取り組みはまだ始まったばかりですが、ソウゾウでは設計レビューを特定の誰かの承認フローにせずに、より良い設計を目指して広く議論する場にしたいという思いがあります。

③ サブプロジェクト発足による、チーム力強化

元々PJ-Productivityは、業務委託である私@masudakと、ソウゾウEMのnaoprさん二人で始めたプロジェクトです。限られた時間で行っていることに加え、定量的には課題が少ないことで、なかなか他メンバーの巻き込みに苦労しておりました。

一方、定性的アプローチにより、課題感が見えてきたことで、サブプロジェクトも作れるようになってきました。

たとえば、ドメイン知識の偏りについては、オーナーシップを持つエンジニアが現れ、どのようにドメイン知識を共有していくか、サブプロジェクト化が進みました。

2人の思いで始まったプロジェクトが少しずつ拡大し、エンジニアの開発体験をより良くするため、より推進するようになりました。

終わりに

前回記事を公開した6月からの変化をまとめました。少しでも参考になる情報はありましたでしょうか。

開発組織の生産性についてはまだまだ情報が外に出ていないと感じています。そのため、可能な限りオープンに発信しました。ぜひ少しでもご活用頂けると嬉しいです。
（積極的に他社さんとも交流したいため、お気軽にご連絡ください）

また、アンケート回答やサブプロジェクトの推進等、本プロジェクトにご協力頂いたみなさま、本当にありがとうございました。

本業のプロダクト開発があるなか、多くの方が時間を割いて、このプロジェクトに協力頂いています。この場を借りて、改めて感謝を伝えさせてください。

本プロジェクトはまだ始まったばかりです。アンケートの結果を見ても、エンジニアの開発体験をより向上したり、より早くお客さまに価値提供するという意味では、まだまだできることがたくさんあります。

引き続き、エンジニアのさらなる開発体験の追求、よりお客さまに早く価値提供できる組織のため、チャレンジを続けられればと思います。

---

Souzohではメンバーを大募集中です。メルカリShopsの開発やSouzohに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。

• Software Engineer
• Software Engineer, Site Reliability
• Software Engineer (Internship) – Mercari Group （※新卒採用に応募するにはまずインターンへの参加をお願いしています。）

またカジュアルに話だけ聞いてみたい、といった方も大歓迎です。こちらの申し込みフォームよりぜひご連絡ください！