レコチョクAdvent Calendar 2024

ネイティブアプリ開発チームの開発生産性の指標を定義してみた

Last updated at 2024-12-04Posted at 2024-12-04

この記事はレコチョク Advent Calendar 2024の5日目の記事となります。

会社の軽音同好会に参加したり、一人でスタジオに入ったりして、ギター熱がまだ続いている村田です。
株式会社レコチョクでiOSアプリエンジニアが集まるグループのエンジニアリングマネージャーと、株式会社エッグスでEggsアプリのプロダクトマネージャーをしています。

はじめに

エンジニアとして「開発生産性」を高めることが求められることも多いですが、なかなか定量的に評価することも難しいものかと思います。
それを組織や上司に求められ悩んでいる方も多いのではないでしょうか。
今回は自分なりに「開発生産性」を定義し、その可視化と向上に向けた取り組みについてご紹介できればと思います！

開発生産性の定義

早速ですが、今自分が見ているネイティブアプリ開発チームにおいて、開発生産性の評価指標になりうるものと定義した指標をご紹介します！
後ほど説明しますが、こちらはFour Keysという指標を元に作成しました。

デプロイの頻度
- 組織による正常な検証環境へのリリースの頻度
変更のリードタイム
- commitから検証環境稼働までの所要時間
変更障害率
- デプロイが原因で検証環境で障害が発生する割合（%）
サービス復元時間
- 組織が検証環境での障害から回復するのにかかる時間

Four Keysとは？

前の章でFour Keysを元にしていると書きましたが、ここでその詳細について説明します。

Four Keysとは、Google Cloudが運営するDevOps Research and Assessment（DORA）が確立したソフトウェア開発チームのパフォーマンスを示す4つの指標のことです。
速度と外部品質・安定性について、どちらも評価できる指標となっています。

デプロイの頻度
- 組織による正常な本番環境へのリリースの頻度
- どれくらいの頻度でリリースできているか
変更のリードタイム
- commitから本番環境稼働までの所要時間
- どれくらいの速度でリリースに向けて実装ができているか
変更障害率
- デプロイが原因で本番環境で障害が発生する割合（%）
- 外部品質を維持できているか
サービス復元時間
- 組織が本番環境での障害から回復するのにかかる時間
- 影響を以下に少なくできるか

余談ですが、DORAは研究結果について毎年レポートを出しており、そのレポートの内容に以下の記載がありました。

DORAの調査にて、開発チームをElite, High, Medium, Lowの4つにレベル分けし評価することが可能で、その中で一番良いとされるEliteチームはFour Keysすべての指標で優れたパフォーマンスを達成していることがわかっています。

品質を犠牲にスピードを上げるといった話が上がることも多いかと思いますが、その考え方はDORAの調査結果的に良い効果を上げるとは言えないのかも知れません。
継続的に品質を担保できる仕組みや工夫が行われている開発チームが結果として速いということなので、日常的な開発工程における課題の発見や改善などを当たり前にできる開発チームがパフォーマンスの良いチームの条件の1つなのでしょうね。

なぜその評価指標なのか

先ほどFour Keysについて簡単に説明しました。改めて我々の採用している基準を見ると、検証環境を計測範囲にする形で変更していることがわかるかと思います。
ここで、なぜ我々がそのままのFour Keysを採用していないのか説明します。

理由としては開発チーム（エンジニア）が自身でコントロールしやすいものを指標にしたかったからです。

開発生産性はレベル1〜3で分けることができ、レベルが上がるにつれて関係者も増え影響を与えることの難易度も高くなります。

FindyさんのFindy Team+活用セミナーの資料の内容をお借りしました。

(開発生産性のレベルについては開発生産性について議論する前に知っておきたいことの記事で非常に深く書かれているため、ぜひ読んでいただければと思います。私もかなり参考にさせていただきました。)

開発生産性レベルが高いほど組織・経営視点で直接的な生産性というものにつながると思いますが、そこをエンジニアの開発生産性としてコントロールするのは非常に難易度が高いです。
理想はレベル3の開発生産性を直接向上させることですが、変数の複雑性や対象範囲の広さから、時間がかかり心理的・物理的負担も大きくなります。

一方、レベル1の開発生産性はエンジニアが改善・コントロールしやすい範囲であり、より高いレベルでの開発生産性改善につながる基礎となります。
そのため、まずはレベル1の開発生産性改善に取り組もうと考え、これを定量化するための導入しやすい指標としてFour Keysを選択しました。

私が評価指標としたものは検証環境（主にdevelopブランチ）が計測範囲でしたが、Four Keysは本来は本番環境（主にmain, master）までが計測範囲です。
Four Keysをそのまま当てはめると本番環境までの反映を図ることになります。それは開発生産性レベルでいうと2が近いかと思います。
そうなってくると、エンジニアだけでなくプロダクトの機能企画などを中心に考えるビジネスメンバーも影響範囲に含まれてしまうため、エンジニアとしての開発生産性から少し広くなってしまうと考えました。
そのため、開発チーム内だけでコントロールすることができるよう検証環境までを対象としたFour Keysの値を開発生産性の評価指標としています。

開発生産性の可視化

そんな考えで定義した指標ですが、継続的に観察できなければ開発生産性が向上した！ということを多くの人が納得できる形で説明することは難しいです。
それを最速かつ効果的に可視化するためにFindy Team+というツールを導入しました。

このツールはGitHubのデータと連携してコミットやPRなどの時間をわかりやすく可視化するツールで、Four Keysの形式で可視化する機能もついておりまさにうってつけでした。

現状の改善に向けた取り組み

Findy Team+を導入し可視化したデータを見て振り返りを行うことで、どのような改善ができたのか紹介します。
ツールの導入自体は2024年9月からのため、記事の執筆時点ではまだまだ始めたばかりではありますが、それでも効果を実感できています。

先行指標の設定

開発生産性の評価指標をFour Keysと定義しましたが、それを向上させるためにより身近でコントロールしやすい先行指標として、開発におけるサイクルタイムやPRのサイズを見ていくようにしました。

サイクルタイム分析

レビュー分析

上記を先行指標とすることで、今どこに課題があるかを具体的に振り返りがしやすくなりました。
それにより直接的な課題の発見と、改善したことの効果を定量的に図れるようになったことは非常に良い点かなと思います。

PRのオープンからレビューまでの平均時間を改善した事例

開発チームAでは可視化した情報を見て振り返りを行い、オープンからレビューまでの平均時間が19.6hで、ここに課題があることが見えてきました。
ここの時間がかかることでコードレビューすべきPRがたまり、結果として時間が経ってからの思い出す認知的なラグや、修正や手戻りによる開発時間の増加、焦りによるレビュー項目の見落とし等のリスクが生じてしまいます。

チーム内でFindy Team+のKPTふりかえり機能を利用し、原因を深ぼってみると以下のような問題が見えてきました。

この問題の対応として、PRの運用方針についてチーム内ですり合わせ文章として明文化しました。具体的には以下のような観点をチームで話し、認識を合わせながら決定しています。

Pull Requestの目的
- 要件を満たしていること、バグが存在しないこと（潜在的なものも含む）を確認する
- コードの保守性・拡張性を向上させる
- 機能の仕様に関する知識の偏在化を防ぐ
Pull Requestの粒度
- 変更行数は250行以内
  - Findy Team+の市場上位10%は257行というデータを参考に設定
マージ基準
- レビュアー人数
- レビュアーの選定方法
レビュー・マージの所要時間目標
- オープンからレビューまで: 11h以内
  - Findy Team+のサイクルタイム分析のHighのラインを参考に設定
- オープンからマージまで: 24h以内
意識すべきこと
- 他社事例も参考にPRを作成・レビューする際の細かな心遣い等
  - 数値を改善するためだけのハックをしない
  - 確認・再現できる環境を明記する
  - 通知を受け取る
  - etc...