開発者、開発組織の生産性を改善するためのステップとして、まず可視化することの重要性は言うまでもないが、実際に生産性指標として使われているメトリクスは開発者のアクティビティによるものからシステムレベルも含め多々存在している。
今回は具体的にイメージをつけるためにどのようなメトリクスが用いられているのかについて調べてみた
直接生産性には関連しないが、生産性低下に繋がりうる品質、体験関連のメトリクスについては別でまとめることにするため、今回は除外した
個人or組織など、グルーピングの単位はある気がしているのでどこかで整理し直す
他にも追記したいので随時更新予定
Four Keys
言わずと知れた、LeanとDevOpsの科学で紹介されたState of DevOps ReportやDevOps Research and Assessment(DORA)チームの研究・調査から導き出されたソフトウェア開発チームのパフォーマンスを示す4つの指標
four keysの何が良いのか?
Git/GitHubベースのアクティビティメトリクス
最近見聞きするケースが増えたFindy Teamsでの可視化などでも用いられているコード、Gitベースのメトリクス
実際にはFour Keysを計測するために使われる例が多いが、Four Keysの文脈に関係なく、コミット数やスプリント毎のストーリポイント数で生産性を測っている例はいくつか見受けられたので、一旦独立したカテゴリにしておいた
いわゆるアクティビティにあたり、単体では生産性を適切に表す指標とは言いづらいものが多いが、測定が比較的容易でもあるため利用実績は多く、Four Keysを追っている場合でもコミット数なども別途追加で可視化している例は多かった
比較的測定が容易、また特にボトルネックなどの改善につながる示唆を得ることも可能なため、あくまでコミット数やコード行数だけで開発者、開発組織の生産性を測ることが難しいというだけで、可視化して追跡すること自体の意味は大きいと考えている
単純にこの辺の数値を見てあーだこーだ分析してみるだけでも楽しいというのもある
指標(WIP: まだ追加出来ていない指標が沢山ある)
- コミット数
- 平均コミットサイズ
- PR作成数、マージ数
- JIRAチケットのクローズ数
- コード行数
- 平均PRクローズ時間
- PR作成~closeまでの時間
- 多くの場合、Four Keysの変更のリードタイムにはfirst commit~masterマージまでの時間を含むため、変更のリードタイムの一部を表す指標になる
- コードレビューにかかる時間
- 基本は平均PRクローズ時間に含まれ、Four Keysとしては変更のリードタイムに関連する
- 実際にボトルネックを特定して改善進めていくとなれば、細かく可視化されている必要が出てくる
- CIに関する数値(成功,Flaky率、時間、etc)
- CIにかかる時間などは平均PRクローズ時間、そして変更のリードタイムに繋がる。また後述のフィードバックループにも関連する
- PR Closeまでのボトルネックになっているのは、コードレビューとCIが体感多いので、コードレビューにかかる時間と合わせて可視化しておくと改善時には便利
参考
- Findy Teamsの指標を使ってチームの生産性を改善しよう - ANDPAD Tech Blog
- 開発者生産性指標の可視化 / pepabo-four-keys
- データで振り返るエンジニア組織の生産性向上 〜NewsPicks & PR TIMESの事例、DevOpsの取り組みからデプロイ頻度の計測まで〜
- How to Measure and Improve Developer Productivity
- Measuring software development productivity
- Measuring & Maximizing Developer Productivity
マイクロフィードバックループ
日々開発者が実行/直面する作業の一つ一つは小さくとも、それらも塵も積もれば山となる、という話
つまり自動テストの実行など開発者が日々行なっている基本的な事に要する時間が長ければ、一つ一つは数十秒であっても、その分が積み重なると開発スピード、体験の低下、またFour Keysのスコア低下にも繋がってしまう
CI回すのに数十分かかる時の影響を考えるとイメージしやすいが、CBTD(code-build-test-debug) loopに限らず、ドキュメント探しにかかる時間やローカル環境や開発環境に反映されるまでの時間なども含まれる
バリューストリームマップで洗い出した課題を解決していくのとほぼ同じという印象
どちらにしてもマイクロフィードバックループ悪化の検知、またFour Keysなどのより上位のメトリクス改善に繋げるために、マイクロフィードバックループやバリューストリームの可視化は重要
指標
- Validate a local code change works
- Find root cause for defect
- Validate component integrates with other components
- Validate a change meets non-functional requirements
- Become productive on new team
- Get answers to an internal technical query
- Launch a new service in production
- Validate a change was useful to the customer
参考
SPACE
SPACEで使われるメトリクス。SPACEについてはhttps://r-kaga.com/blog/about-space-of-developer-productivityでまとめている
指標(WIP)
- Satisfaction and well-being
- 生産性は仕事、チーム、文化への満足度や幸福度、健康状態にも影響される
- 生産性と満足度は関連しているため、満足度が生産性の先行指標として機能する可能性、また満足度とエンゲージメントの低下は、燃え尽き症候群や生産高の低下を予兆する可能性がある
- ex)
- Employee Satisfaction
- 開発者の満足度は?
- 自分の会社を他の人に勧めたいと思うか?
- Developer Efficacy
- 仕事を行うために必要なツールやリソースへのアクセスを持っているか
- Burnout
- 仕事に対する疲労感
- Employee Satisfaction
- Performance
- ビジネスのパフォーマンスと開発者のパフォーマンスは直接結びつかないことが多い
- ビジネスの成果には、セールス、マーケティング、顧客満足度など、さまざまな要素が絡んでくる
- 大量のコードを書いている開発者が、高品質のコードを書いているとは限らない
- 顧客価値は高品質なコードによって提供されるとは限らない
- アウトプットではなくアウトカム
- 長期的な健全性を図る上では、リリースが時間通りに行われたかどうかよりも、リリースの目標が達成されたかどうかが適切
- ImpactとQuality
- Impact
- 顧客満足度、オンボーディングにかかる時間、機能利用率、コスト削減、提供機能数
- Quality
- 品質、信頼性、バグのなさ、サービス全体の健全性、SLA
- Impact
- ビジネスのパフォーマンスと開発者のパフォーマンスは直接結びつかないことが多い
- Activity
- 開発者の何らかの活動から生まれる数値を計測する
- アクティビティだけでは生産性を適切に測定するのは難しい
- 大量のコード ≠ 高品質のコード
- SPACEでは、単独で使用することはせず、またあくまでも最初のきっかけとして利用すべきとなっている
- ex)
- 何らかの活動の数や時間を計測する
- Design and coding
- 設計書や仕様書の数
- プルリクエスト数
- コミット数
- コードレビュー数、かかる時間
- Operational activity
- オンコールへの関与
- インシデント数、削減数
- Continuous integration and deployment
- ビルド数、時間
- テストにかかる時間
- デプロイ頻度
- Communication and collaboration
- コミュニケーションとコラボレーションはソフトウェア開発には必要
- 開発者全体の満足度にも大きく関わってくる
- ex)
- The speed with which work is assimilated.
- Network measurements that reveal who and how people are connected.
- Discoverability of documentation and expertise.
- Quality of reviews of work contributed by team members.
- Time spent onboarding new members and their prior experience.
- コミュニケーションとコラボレーションはソフトウェア開発には必要
- Efficiency and flow
- 開発者がフロー状態に入れるか
- チーム内やチーム間の連携が取れているか、進捗が安定しているか
- 情報やナレッジの流れ
- 関係するチームの数を減らし、オーバーヘッドによる時間のロスを考慮するなど、プロセス全体のレイテンシーを削減する
- ex)
- Number of handoffs required in a process.
- Ability to quickly and efficiently complete work.
- Time required throughout a system, time between processes
- The total number of handoffs in a process; the total number of handoffs between teams in a procedure.
- Interruptions: the number, time, and spacing of interruptions, as well as their impact on development work and flow.
- The perceived capacity to stay in the zone and finish tasks.
- Time is measured using a system that includes total time, value-added time, and wait time.
参考
- 開発者の生産性を測るためのフレームワーク
SPACE
について - Measuring & Maximizing Developer Productivity | Harness
- What is developer productivity and how to measure it?