昨今、注目されるエンジニア組織の活動データの可視化と、生産性向上。

会社設立から約1年半のソウゾウでも”生産性可視化プロジェクト”が始動したと聞いて、このプロジェクトに関わるソフトウェアエンジニアの佐藤 直人（@naopr）と増田 謙一（@masudak）に話を聞いてみました！

今回のメルカンは、メルカリShopsを運営するソウゾウの人やカルチャーをゆるーーーくお伝えするPodcast「souzoh fm」との連動企画！お二人のゆるいトークと共にお楽しみください。

２人はどのようなエンジニア組織の姿を目指して、このプロジェクトに携わっているのでしょうか。

Small & Move Fastに始動した”生産性可視化プロジェクト”

ーまずはこのプロジェクトが始まるきっかけを教えてください

@masudak：僕は2022年1月にメルカリを退職して起業したのですが、その後、naoprさんと話す機会があって、そこで「エンジニア組織の生産性可視化に取り組んでいる会社も増えてきていて、僕らもできたらいいよね」という話したのがきっかけですね。

@naopr：最初は飲みの場で話しましたよね（笑）。組織が拡大していく中で、コミュニケーションパスが増えて生産性が落ちていくことはどこの会社でもよくある話だと思います。その時に、感覚的には生産性が落ちたと感じていても、本当に落ちているか、どのくらい落ちているかを客観的には見れていないことも多いです。ただ、「推測するな、計測せよ」の精神に則って数値として生産性を可視化することで、客観的に組織の変化に気づけるんじゃないかなとずっと思っていました。

@masudak：僕もnaoprさんの意見に賛成で、まず可視化して変化を見ていくことが大事だなと思います。あと、実はメルカリに在籍していた2017年頃にも同じようなプロジェクトにチャレンジしたことがあったので、その時の経験や反省を踏まえて改めてソウゾウでできることがあるんじゃないかなと感じました。

@naopr：それは初耳でした！こういうプロジェクトって、やったほうがいいとはみんな思ってはいるけど、社内のエンジニアのリソースを割いてやろうとすると開発業務もあるのでなかなか難しい。masudakさんに副業で入ってもらう形で小さく始める座組はこのプロジェクトにフィットしていたと思います。

数値で見えてきたソウゾウのエンジニア組織の今

ーなるほど。まさにMove Fastでまずやってみようと始動したプロジェクトだったんですね。どのように検討を進めたんですか？

@masudak：まず最初は、外部SaaSの導入を検討しました。ただ、僕らの求める要件を満たすことやセキュリティ・コンプライアンス観点の条件をクリアするのに苦労しましたね。

@naopr：社内のITやセキュリティチームにも相談していたのですが、結果としてはうまく条件が折り合わなかったので自分たちで開発をすることにしました。

@masudak：そうですね。厳密にいろいろやっていくとtoo muchになってしまうので、簡単に取れる数字でまずはやってみることにしました。Google Apps Scriptを使ってGitHubのAPIを叩いて、closeされたPull Requestのリストをスプレッドシートに出力しました。そして出力したデータをData Studioに連携させて可視化しました。これでチーム別・期間別のデプロイ頻度や、開発リードタイムを測定できるようになりました。

@naopr：SaaS導入で苦労した分、見える形でアウトプットが出たのはプロジェクトを進めていくモチベーション的にもよかったですね。しかも、その結果が示唆があるものだったので、非常に面白いなと思いました。

ーどんな結果が出たか教えてください！

@naopr：Googleが提唱しているFour Keysという開発チームのパフォーマンスを示す指標があり、そのうち「デプロイ頻度」と「変更のリードタイム」の定義に近い値を計測したのですが、この基準でいうと今のソウゾウはデプロイ頻度は最上位のEliteで、変更のリードタイムは上から2番目のHighでした。相対的に高いレベルで開発ができていることは喜ばしいことですが、この指標を継続して取りながら組織の変化に気づいたりPDCAを回すことが大事だと思っています。

Google Cloud で実行されている DevOps 組織の有効性を評価する より引用

もう少し詳細に見ていくと、デプロイ数はメルカリShopsリリース前の去年の4月をピークにゆるやかに右肩下がりになっているんですよね。開発チームの人数は増えているのでデプロイ数は増えるんじゃないかと思っていたんですけど、実際は減っていました。

チームごとの数値にも大きな傾向の差はなかったので、組織全体としてデプロイ数が落ちていることがわかります。メルカリshopsの最初のリリースが去年の7月なので、リリース前はコードレビューが今ほど厳格でなかったりQAせずにデプロイができていたりという要因からデプロイ数が増えるのは理解できるのですが、リリース後もゆるやかにデプロイ数が減っているのは分析する価値がありそうです。

デプロイ数：mainブランチにmergeされた週ごとのPull Requestの数

変更のリードタイムは4月が極端に短くて、7月くらいから増え始めて12月くらいをピークにそこから今まで同じような値で推移しています。デプロイ数のグラフと比較すると面白いんですが、デプロイ数が減っているときは開発リードタイムが増えているというような負の相関が見えています。

また、デプロイ数のほうはチーム毎に大きな差はなかったんですが変更のリードタイムはチームによる差が一定あるので、なぜチームによる差が出ているのか調べてみたいですね。

リードタイム：Pull Requestが作成されてからmainブランチにmergeされるまでの時間の週ごとの中央値

masudakさんはデータを見て、どんな感想がありましたか？

@masudak：naoprさんと同じく、デプロイ数は推移は興味深かったです。リードタイムに関しては作っている機能の大きさによっても変わってきそうですね。どちらもグラフと併せて個々のPull Requestを見ながらなぜこのような結果になったかの仮説を立てた上で、どうやってPDCAを回していくかを考えていきたいなと感じました。その時に、自分たちはこうありたいとか、ある程度理想の状態があるといいですよね。

@naopr：正直、今は組織として生産性が低いという課題感があるわけではないのですが、もう一段、二段上げられる余地があるということがわかったので、まだ始まったばかりではありますが、このデータを分析するのが楽しみです。

ソウゾウが目指す理想のエンジニア組織とは

ーmasudakさんから「自分たちのありたい理想の状態を持つ」という話がありましたが、ソウゾウでいうといかがですか？

@naopr：今回可視化した生産性の数値は、必ずしも上げ続けることが正解ではなくあくまで組織の健全さを測る指標の一つとして扱うべきだと思っています。この指標を継続してモニタリングしていく中で、急にデプロイ数が下がったりリードタイムが長くなったりしたときは、おそらくエンジニア組織になにか変化が起こっている兆候です。そういう変化に敏感に気づけるようにしたいと思っています。

あと、CTOのsuguruさんとの1on1で「僕らが大事にしたい生産性の本質は、エンジニアの開発体験なんじゃないか」と話をしています。エンジニアが快適に開発できているとか、モチベーションやオーナーシップを持って開発に取り組めているとか。そういったことを総合的に測るためにもこの指標を追っていきたいなと思いますね。

@masudak：この指標を継続的に追いながらPDCAを回すことで生産性が向上していって、エンジニアがチャレンジできる機会が増える。その結果として、今まで以上にお客さまにより早く価値を届けられるようになる。このプロジェクトでそんな好循環を生むことができたらいいですよね。

ー最後にこのプロジェクトへの意気込みを教えて下さい！

@naopr：今はGoogle Apps Scriptを使った暫定的な方法で数値を取っているので、より安定してモニタリングができるような体制を整えていきたいです。あとは、Four Keysのうち開発速度を測定する2つの指標しか取れていないので、安定性を測定する「変更障害率」や「サービス復元時間（MTTR）」も取れるようにしたいですね。

@masudak：生産性の指標を分析していくといろんな組織に適用できるような傾向が見えてくると思うので、そこも楽しみですね。ソウゾウでできたらメルカリグループ全体にも広げられるかもしれないし。

@naopr：今は僕ら2人でやってるプロジェクトなのに、将来的にメルカリグループ全体に横展開したいという野望はありますよね（笑）。まずはソウゾウの生産性向上の結果を出した上で各カンパニーのメンバーとも協力しながらグループ全体の生産性を上げていきたいと思ってます！

ーこれからが楽しみですね。ありがとうございました！