はじめに
今年度、社内のエンジニアが自分の成長を客観的な評価指標から実感できる仕組みを作ろうとしていたコンテキストで、エンジニアの評価指標について調べた内容をシェアします。
Four Keys
エリート DevOps チームであることを Four Keys プロジェクトで確認する
上記の記事で語られている様に、Google の DORA (DevOps Research and Assessment) チームがソフトウェア開発チームのパフォーマンスを評価する以下の4つの指標を提案しました。
- デプロイ頻度
- 変更のリードタイム
- 変更障害率
- サービス復元時間
この指標の登場により、従来ソフトウェア開発のパフォーマンスとして計測されていたコード行数やテストカバレッジよりも評価して意味のある開発生産性を計測できるようになりました。
スクラムチームで行うスプリントレトロスペクティブの様な振り返りとカイゼンアクションを決める場では、開発に関するカイゼンはすべてこの4つのどれに効きそうかという共通の尺度を以て進められるようになります。
計測方法
計測対象のレポジトリが GitHub もしくは GitLab に保存されていれば利用できます。
方法は大きく分けて2通りあります。
- 取得できる環境を構築する
- 取得できるサービスを活用する
取得できる環境を構築する方法
Four Keys を提唱している DORA が取得できるソフトウェアを OSS で公開しています。
セットアップの手順は、上記 OSS のページの How to use を読めば分かります。環境構築先は GCP を利用する前提で Terraform のコードも含まれているので、GCP アカウントを持っている方だとよりスムーズに始められそうです。
実際に取得したメトリクスの画面表示は、あんまり良いサンプルをキャプチャできなかったので、以下の記事の事例を共有させてください。
取得できるサービスを活用する
Four Keys を取得できるサービスが巷に出てきています。
興味がある方は、詳しくはサービスページからお問い合わせを。
Four Keys 取得の注意点
Four Keys の OSS の Github のページにリンクされた動画でアンチパターンが語られています。1点目は開発チームの外のメンバーに対してのアンチパターン、2点目は開発チームの中のメンバーに対してのアンチパターンと解釈しています。
- メトリクスの取得結果をチーム間で比較する
- メトリクスの数値目標を達成することをゴールとする
特に起きやすそうな1に関して補足をしておくと、この Four Keys という指標は様々なチーム固有の要因で変化します。例えば、開発するソフトウェアの規模、開発に使用するツール、プルリクエストのサイズ等の開発規約等です。開発チームの外のメンバーからすると、「こちらのチームはあちらのチームよりもメトリクスが悪いから、人員を増強したいと思う」などどテコ入れをしたくなってしまう場合もあるのでしょうが、提唱元の DORA が期待している使い方はそうではなく、開発チームが開発の健康状態を監視するために利用できる指標として扱って欲しい意図があるように動画からは伺えました。
SPACE
ここまでが Four Keys の紹介なのですが、調査を重ねていると興味深い論文を見つけました。
どうやらファーストオーサーは DORA にも所属している人物なようです。
この論文の冒頭で、こんな一文があります。
MYTH: One productivity metric can tell us everything
訳 -> 神話：一つの生産性メトリクスで全てを知ることができる
Four Keys も重要だけれど、それだけで開発者の生産性をすべて知ることのは不可能だとのこと。この論文は、ソフトウェア開発者の生産性を解像度高く評価するための多面的な観点を提供しています。論文の中では、重要な5つの観点の頭文字を取った「SPACE」という捉え方が提唱されています。
なお、利用する際には注意してほしい点として、各観点で測定できるメトリクスは、開発者の活動の一部を測定するための道しるべとして使用できますが先の Four Keys 同様に万能ではないことにご留意ください。個人やチームの生産性に関する決定を下すために単独で使用すべきではなく、組織のニーズや開発環境に基づいて複数のメトリクスを組み合わせるなど、カスタマイズして使用されるべきと記されています。
SPACE の主要な要素
- 満足度と幸福感(Satisfaction and well-being)
- パフォーマンス(Performance)
- 活動(Activity)
- コミュニケーションとコラボレーション(Communication and collaboration)
- 効率とフロー(Efficiency and flow)
SPACE の各要素について
各要素について簡単に解説します。
S: 満足度と幸福感
- 満足度: 開発者が自分の仕事、チーム、ツール、文化にどれだけ満足しているかを示します。
- 幸福感: 開発者がどれだけ健康で幸せであるか、およびその仕事がそれにどのように影響しているかを示します。
生産性と満足度は相関関係にあり、満足度の低下は生産性の低下の前兆となる可能性があるそうです。例えば、パンデミック時の在宅勤務において、一部の生産性指標が上昇したものの、実際には多くの人々が幸福感に苦労していることが質的データから示されています。
満足度と幸福感は一般にアンケート調査を通じて測定されます。測定する項目としては、従業員の満足度、開発者の自己効力感（仕事をするために必要なツールやリソースが十分にあるか）、仕事による疲労やストレスの度合い（バーンアウト）などがあります。
P: パフォーマンス
システムやプロセスの成果のことを指します。品質の高いコードを書いているかとか、顧客満足度の高いサービスの開発に貢献しているか、など。
パフォーマンスの測定は、開発者個々人の貢献とその成果の関連性を理解する上で重要です。しかし、ソフトウェア開発は多くの場合、チームによって行われるため、個々の開発者のパフォーマンスを正確に評価することは困難とも書かれています。チーム単位での測定なら効果があるので重要だ、とも解釈できます。
パフォーマンスを測定するための例としては、品質（信頼性、バグの不在、サービスの継続的な健全性）、影響（顧客満足度、顧客の採用と維持、機能の使用、コスト削減）などがあります。
A: 活動
作業の過程で完了したアクションや出力の数を数えることです。これには、開発者が行う多様で複雑な活動が含まれます。Four Keys の様なメトリクスもここに分類されそうに見えます。
活動の測定は、開発者の生産性やエンジニアリングシステムの効率に関する価値あるが限定された洞察を提供します。開発者の行う多様な活動を考慮することで、より正確な生産性評価が可能になります。
測定の観点と測定項目の例を記します。
- 設計とコーディング: 設計ドキュメントの量や数、作業項目、プルリクエスト、コミット、コードレビューなど。
- 連続的な統合とデプロイメント: ビルド、テスト、デプロイメント／リリースの回数、インフラストラクチャの利用など。
- 運用活動: インシデント／問題の数やボリューム、重大度に基づく分布、オンコール参加、インシデント対応など。
C: コミュニケーションとコラボレーション
人々やチームが効果的なコミュニケーションを取れているかをを捉えます。
効果的なチームは、高い透明性とチームメンバーの活動やタスクの優先順位に対する認識に依存しています。コミュニケーションとコラボレーションの測定は複雑であり、直接測定が困難な要素（例：目に見えない作業やチームタスクの調整や計画のためのアーティキュレーション作業）が含まれます。
以下のようなメトリクスを使用することはできると述べられています。
- チームメンバーのプルリクエストへのレビューの質
- 新しいメンバーのオンボーディングにかけた時間と経験
E: 効率とフロー
個人またはチームとして、中断や遅延を最小限にしながら作業を完了する能力です。
多くの開発者は、作業中に「フロー」状態に入ることを目指します。個人の効率は、生産的であり続けるために重要です。例えば、集中的な作業時間を確保するために、特定の時間をブロックオフすることが挙げられます。
測定方法としては個人/チームレベルでそれぞれ例が挙がっています。
- 個人レベル: 中断されない集中時間、エディタを使用している時間
- チームレベル: デプロイ頻度、変更のリードタイム
まとめ
以上、Four Keys と SPACE について紹介でした。
踏みこむ前は開発者を評価する指標なんてどう定義したらいいか分からないな。と感じていたので、この調査で開発者の生産性に対する解像度が高まったことは良かったです。
まずは足掛かり的にデータを起点に改善する文化を作ってみても良いかなとは感じるので、Four Keys は取ってみたいと感じた次第でした。