SPACEフレームワークのディメンション・カテゴリでどのようなメトリクスをどう取得すればいいのかについて考えてみる SPACEについては以下記事を参照
メトリクス例はこの辺りを参照。
from The SPACE of Developer Productivity: There's more to it than you think - Microsoft Research
Introducing Developer Velocity Lab to improve developers’ work and well-being | OD532で紹介されていた例。
Satisfaction and well-being
開発者の満足度・幸福度について。
この手の論文では頻繁に登場するが、生産性と満足度は相関関係にあり、満足度が生産性の先行指標となる可能性がある。
また満足度とエンゲージメントの低下は、燃え尽き症候群や生産性低下の兆候を示す可能性があるため可視化を推奨している
開発者体験も満足度に影響を与えるが、https://getdx.comが提唱してるDXフレームワークでも、開発者体験について「開発者が自分の仕事についてどう考え、どう感じ、どう評価しているか」と定義しており、開発者がどう感じているかは重要な要素
論文では、以下項目を測定することが可能と書いている
- Employee satisfaction
- 従業員の満足度、自分のチームを他の人に薦めるか
- 測定するならeNPSやWevoxなどの社員サーベイツールを活用するとか
- DXフレームワークが述べるように、必要に応じて開発体験やプラットフォームエンジニアリング文脈の項目も入れたい所
- 1on1などのタイミングでふと出てくる可能性もあるが、何かしら明確な数値や量を定期的に見ることが大事
- 1on1は浸透した感があるが、開発者へのサーベイを行なってる企業は1on1と比べると少ない印象
- Developer efficacy
- 開発者が仕事をするために必要なツールやリソースを持っているかどうか
- どう測るのが良いのか？
- Employee satisfactionと合わせてサーベイ調査の項目に入れる？
- サイクルタイムなどのボトルネックを深掘りして発見する？
- 測定ではない
- 測定方法ではないが、少額決済のチーム内承認や自己組織化チーム作るなどがHowになるか
- Burnout
- 燃え尽き症候群。これもサーベイがメイン
- 論文でも触れられているが、このカテゴリ・項目自体が定性的データの必要性から来ている
- パンデミック時にアクティビティデータが(コミット数やPRマージ速度など)が上昇したが、定性的データによると満足度・幸福感に悩まされる人が出てきた
- アクティビティ指標はポジティブだが、満足度を評価する指標を追加すると、より全体的に生産性が把握できる
- 生産性を多角的にとらえた指標の重要性
以下は、論文内でも紹介されている、個人・テーム/グループ・システムのレイヤーで振り分けた例
- 個人
- 開発者の満足度/開発者体験
- コードレビューの満足度
- リテンション
- チーム/グループ
- 開発者の満足度/開発者体験
- リテンション
- システム
- エンジニアリングシステムへの満足度
- CI/CD
- デプロイ
- etc…
- エンジニアリングシステムへの満足度
個人レベルだと各々の主観での満足度になり、システムレベルだとエンジニアリングシステムに対しての満足度を測ることになる
そしてsatisfaction and well beingなので、CI/CDにかかる時間ではなく、CI/CDそのものに対しての満足度を測定する
アクティビティデータだけでは一側面でしかなく、多角的に生産性を捉えられない事がSPACEが生まれた課題感でもあるので、このカテゴリの測定はSPACEの中では重要度が高いと理解している。
フワッとしたイメージしかないが、実際に行うのであればeNPSから始め、開発者体験的な所に手を出すなら、システムレベルでも測定出来ると捗るなという印象
Performance
パフォーマンスで測定したいのは「開発者が書いたコードは、想定されたことを確実に実行したか？」で、QualityとImpactを測ろうという話
前提として、開発者個人の貢献度をプロダクトの成功に直接結びつけることが難しく、定量化が困難であり、アウトプットではなく、アウトカムとして評価するべきということが、論文で述べれている
- コード量が多い開発者が、高品質のコードを生成しているとは限らない
- 高品質なコードが顧客価値を提供するとも限らない
- 顧客を満足させる機能が、必ずしもビジネスに良い影響を与えるとも限らない
論文では、測定基準の例としては以下が挙げられている
- Quality
- Reliability
- いわゆる信頼性指標。エラーレートやレスポンスタイムなどなど
- state of the devops reportでも信頼性についての話が出てる通り、パフォーマンスを測る上でもシステムのReliability指標は重要
- Reliabilityから多少ずれる感はあるが、Core Web Vitalsも良さそう
- Absence of bugs
- そのまま捉えるとバグの数
- 単純なバグ数ではなくても、インシデント数や変更失敗率で代替で良さそう
- ongoing service health
- エラーレートや稼働率
- Reliability
- Impact
- Customer satisfaction / Customer adoption and retention / Feature usage
- どれだけ顧客にインパクトを与えたか？の測定
- どれだけ開発者の満足度やReliability、開発組織内のサイクルタイムが速くても、顧客にインパクトを与えてなければ生産性高いとは言い難い
- 例えばfour keysなどの開発組織のプロセスの可視化・改善は一側面・レイヤーでしかなく、上位に生産性・パフォーマンスにどれだけ効率良く、顧客に価値を提供しているかが存在している
- 顧客へのNPS調査実施や機能利用率・プロダクトKPI辺りの話の認識
- Cost reduction
- いかに低コストがシステムを提供しているかという話だと理解
- ユーザー・データ量増加を加味したインフラコストを定期的に見て、ダウントレンドか見るとかになるんだろうか？
- 1ユーザーあたりコスト的な
- Customer satisfaction / Customer adoption and retention / Feature usage
論文内で紹介されているExampleだと、outcome of a processとして以下のような例が挙げられており、個人・チーム/グループレベルだとQualityとImpactはどこに行った？となっている
- 個人
- code review velocity
- チーム/グループ
- code review velocity
- ベロシティ
- システム
- code review velocity
- code review acceptance rate
- Customer satisfaction
- Reliability
コンテクストも違う中で、ReliabilityやCustomer satisfactionの測定をして、比較されることを避けているのか？と思いつつ、 とはいえ普通にチーム毎で見たい数値だとは思っている。
Activity
アクティビティは業務を遂行する過程で完了した行動やアウトプットの数を表し、比較的容易に測定・定量化できるため、歴史的によく使われていた指標
いわゆるコミット数とかレビュー数とかその辺
SPACEはアクティビティだけ見ても生産性を特定出来ない！が基本スタンスなので、利用する場合も色々注意点が記載されている
- 単独では使用しない
- ソフトウェア開発に不可欠な活動の多くは、測定・定量化が難しい
- アクティビティだけでは、効率的に仕事が出来るようになったのか、長時間労働した結果なのか判別できない
論文内で紹介されているExampleは以下のような感じ。
測定自体は、それこそFindyTeamを入れれば終わりだが、 とはいえこれを測定してどう判断・活用していくか？と言われると悩ましい点もある、特に個人レベル
明らかに過小・過剰なアクティビティデータが確認された場合をモニタリングするぐらいだろうか
- 個人
- コミット数
- レビュー数
- PR数
- コーディング時間(first commitからreview開始 or マージまでの時間とか)
- チーム/グループ
- ベロシティ
- システム
- デプロイ頻度
個人レベルでのActivityは測定はしておくが、組織的に改善を回すイメージはあまり出来ていない。
1on1でたまーに使うかなぐらい
チーム/グループ・システムレベルだと、別ディメンションに入るかもしれないが、four keysやサイクルタイム、機能リリース数などをモニタリングしつつ、アクティビティデータは詳細に分析・改善時に活用で十分ではという感じが。
Communication and collaboration
測定が困難な項目が多いが、論文内では以下指標が使えるかもと書いてる
- Discoverability of documentation and expertise
- ドキュメントの見つけやすさ
- 色んな所に効いてくる重要な要素だけど、どうやって測定するのだ？という気持ち
- 問い合わせに対してのドキュメント有無やヒット率を計測するとかはありそう
- どうせやるなら有無やドキュメントのクオリティーも含めたい
- How quickly work is integrated
- 言いたいことはわかるが、ドキュメントの見つけやすさと同じく測定方法がイメージつかない
- 実質サイクルタイムで代用できるのは？という気がする
- バリューストリームマッピングを定期的に行うでも良さそう
- Quality of reviews of work contributed by team members
- ソフトウェアエンジニアリングだとPRレビュー関一番大きく、測定も一定可能
- レビュー品質とかコメント返信率とかレビュースピードとかマージまでの時間とか
- ソフトウェアエンジニアリングだとPRレビュー関一番大きく、測定も一定可能
- Network metrics that show who is connected to whom and how
- 直訳すると、「誰が誰にどのようにつながっているかを示すネットワークメトリクス」
- コミニュケーションフローとか相関図的な話？
- 特定の情報を知りたい時に誰が詳しいか？誰に聞けばいいのか？がすぐにわかるかとかも含まれそう
- ただ測定どうするのかはイメージつかない
- 直訳すると、「誰が誰にどのようにつながっているかを示すネットワークメトリクス」
- Onboarding time for and experience of new members
- オンボーディング体験と完了までの時間
- オンボーディング体験はアンケートで、完了までの時間はオンボ完了の定義さえあれば、そこに至る時間を測定する
測定も難しいものが多く、そして次に触れるEfficiency and flowとトレードオフになる可能性もあるので、取り扱い難しいディメンション
ドキュメント周りは測定・改善がやりきれると、インパクト大きそう
Efficiency and flow
要するにフローに入れてるか？作業に集中する時間を確保できているか？バリューストリームの中で非効率な部分はないか？などについて
作業に使えるどれだけまとまった時間が確保できているか？価値を創造するアプリ内の時間（ex: IDEで過ごす時間）で測定されることが多いらしい
各レベルでのEfficiency and flowは、満足度の向上と正の相関があるらしいが、同時に個人の効率を最適化すると、コラボレーション活動が減少する可能性についても示されている
指標例としては
- Number of handoffs in a process
- プロセス(開発~リリースまでとか)内で、どれだけ仕事の受け渡しが発生してるか？
- 受け渡しすればするほど無駄が生じる可能性
- Howとしては自己組織化チーム作るとかになるんだと思う
- 測定はバリューストリームマッピングで見る？
- 開発周りはサイクルタイムで代替出来そう
- Perceived ability to stay in flow and complete work
- いまいち英文で意味を捉えられていない
- Number of handoffs in a processと似た話で、どれだけチーム内でタスクを完了出来ているか？の話だと理解
- これも測定はサーベイやバリューストリームマッピングぐらいしか思いついていない
- Interruptions: quantity, timing, how spaced, impact on development work and flow
- 差し込み。マルチタスク度合いも関連しそう
- コンテクストスイッチがどれだけ発生するか？という話だと理解
- 関連指標としてはReview Pickup Timeとか
- Time measures through a system: total time, value-added time, wait time.
- サイクルタイムやプロセス内の待ち時間
- レビュー開始までの時間なども関連
- サイクルタイムやプロセス内の待ち時間
まとめ
一旦整理してみた。
基本的に測定が容易なアクティビティデータだけに頼るべきではないという主張のフレームワークなので、測定難しい印象のものも多い。
- あくまでもフレームワークであり、どのディメンション・カテゴリからどのメトリクスをどのレイヤーで測定するのかは組織での選定に任されているので当たり前だが、活用するにあたってここの選定が最も迷う
- Code Review関連でのメトリクス活用をSPACEの枠組みで捉えると良い
というのを改めて感じて終わった