指標候補まとめ

複数記事を調査して候補について私見をまとめた

名前 評価 用途 メリット デメリット 計測上の注意点
ストーリーポイント ○ 中期の計画(この用途が基本)
生産量の参考 ・ざっくり精度だが、中期の計画には最適。
・現状把握のためのメトリクスとしても使える。 ・目標設定にはデメリットが大きいで
・数値にそこまでの精度がない
・意図的に大きくすることができてしまう
(分割すると増えるが、それは不確実性を下げる上では望ましい。見積もりがブレても完全に反映されるとは限らない) ・評価には使用しない
実装時間 ◎ ・直接的に価値を生む時間の可視化 ・会議が多いので、実際に使える時間がどれくらいか ・計測がめんどくさい
レビュー時間(実測) ◎ ・レビューにかかる時間の可視化 ・レビューに時間がかかりすぎていたら、レビュー方法の再検討が必要なため、 ・計測がめんどくさい
PR生存時間 ○〜◎ ・レビューにかかっている時間が長すぎることを検知
・放置されているPRがあることも検知 ・計測が簡単(スクリプトを組めばいけそう) ・放置されているのかレビューに時間がかかっているのかの区別ができない
PRコメント数 △〜○ コメントが多すぎる(コミュニケーションに課題がある)PRの検知 ・異常にコメントが多いPRがあったら何か改善余地があるとわかる ・コメント粒度はまちまちなので、良し悪しの判断には使えず、用途は異常検知ぐらい
・ペアプロ的に口頭で伝えることもある
・1つのコメントにまとめることも、バラバラで書くこともある
マージPR数 △〜○ ・分割した方が望ましく、分割すると上がるので単純に多ければ良い指標ではある ・不適切な分割(リリースできない状態でマージ等)されないことを守る
コミット数 × (コミットはいくらでも細かく刻めるので何の参考にもならない)
機能の開発リードタイム × ・測定対象の機能サイズがバラバラなので、単純比較できない
モチベーション指標 ○ チーム全般的な異常検知 ・モチベーション低下があれば、深堀ると総合的に組織的な課題が検知できそう ・オープンにこれを言えるようにするために結構な心理的安全性が必要 ・ざっくりと数値で定期的に取る？(1〜10ぐらい)
・結果はチーム内のみ共有にした方が良さそう
ビジネス指標 ○ 開発アウトカムの計測 ・本質的な成果を計測し、意識をそちらに向けられる ・開発以外の要素の影響が大きい
リリース数 △ リリースを継続できている体制かのチェック
→ここに課題感がなければ優先度低そう
達成ストーリーポイントの内訳 ○ バグやトイルが多すぎないかの検知 ・割と簡単に取れそうではある ・スクリプト化しないとちょっと面倒
カバレッジ ×〜△ テストが書かれていないコードの検知 ・高いことはテストが十分であることを一切保証しない

参考にしたページ(一部)

https://www.stepsize.com/blog/3-most-important-metrics-for-engineering-team-performance

リードタイム、PR数、SP、レビュー完了時間について言及

https://sourcelevel.io/measuring-engineering-teams-actionable-metrics-for-managers

以下のポイントはとても重要だと思った

Untitled

https://venturebeat.com/2021/07/18/use-these-metrics-to-get-the-most-out-of-your-engineering-team/

モチベーション指標、ビジネス指標、SPの内訳についてはこの記事からだったので結構良記事

Untitled

Untitled

この記事は何か

筆者執筆書籍