開発者の生産性計測のフレームワークであるSPACEでどのメトリクスを使うか考えてみる

SPACEフレームワークのディメンション・カテゴリでどのようなメトリクスをどう取得すればいいのかについて考えてみる SPACEについては以下記事を参照

TODO: まだ考えきれてない部分があるので、随時追記する。特にどう取得するかはほぼ未着手

Satisfaction and well-being

開発者の満足度・幸福度について。
この手の論文では頻繁に登場するが、生産性と満足度は相関関係にあり、満足度が生産性の先行指標となる可能性がある。
また満足度とエンゲージメントの低下は、燃え尽き症候群や生産性低下の兆候を示す可能性があるため可視化を推奨している

開発者体験も満足度に影響を与えるが、https://getdx.comが提唱してるDXフレームワークでも、開発者体験について「開発者が自分の仕事についてどう考え、どう感じ、どう評価しているか」と定義しており、開発者がどう感じているかは重要な要素

論文では、以下項目を測定することが可能と書いている

  • Employee satisfaction
    • 従業員の満足度、自分のチームを他の人に薦めるか
    • 測定するならeNPSやWevoxなどの社員サーベイツールを活用することになりそう
    • DXフレームワークが述べるように、必要に応じて開発体験やプラットフォームエンジニアリング文脈の項目も入れたい所
    • 1on1などのタイミングでふと出てくる可能性もあるが、何かしら明確な数値や量を定期的に見ることが大事
      • 1on1は浸透した感があるが、開発者へのサーベイを行なってる企業は少ない印象
  • Developer efficacy
    • 開発者が仕事をするために必要なツールやリソースを持っているかどうか
    • どう測るのが良いのか?
      • Employee satisfactionと合わせてサーベイ調査の項目に入れる?
      • サイクルタイムなどのボトルネックを深掘りして発見する?
        • 測定ではない
    • 測定方法ではないが、少額決済のチーム内承認や自己組織化チーム作るなどが実現のHowになるんだろうか
  • Burnout
    • 燃え尽き症候群。これもサーベイがメインになるのでは
    • 論文でも触れられているが、このカテゴリ・項目自体が定性的データの必要性から来ている
      • パンデミック時にアクティビティデータが(コミット数やPRマージ速度など)が上昇したが、定性的データによると満足度・幸福感に悩まされる人が出てきた
      • アクティビティ指標はポジティブだが、満足度を評価する指標を追加すると、より全体的に生産性が把握できる
      • 生産性を多角的にとらえた指標の重要性

論文内でもExampleが紹介されているが、個人・テーム/グループ・システムのレイヤーで振り分けるとこんな感じ

  • 個人
    • 開発者の満足度/開発者体験
    • コードレビューの満足度
    • リテンション
  • チーム/グループ
    • 開発者の満足度/開発者体験
    • リテンション
  • システム
    • エンジニアリングシステムへの満足度
      • CI/CD
      • デプロイ
      • etc…

個人レベルだと個人の主観での満足度になるが、システムレベルだとエンジニアリングシステムに対しての満足度を測ることになる
satisfaction and well beingなので、CI/CDにかかる時間ではなく、CI/CDそのものに対しての満足度を測定する

アクティビティデータだけでは一側面でしかなく、多角的に生産性を捉えられない事がSPACEが生まれた課題感でもあるので、このカテゴリの測定は重要度が高い。

フワッとした理解しかないが、実際に行うのであればeNPS取ることから始めるのかな?という気はする。
開発者体験的な所に手を出すなら、システムレベルでも測定出来ると捗りそうだなという印象

Performance

パフォーマンスで測定したいことは「開発者が書いたコードは、想定されたことを確実に実行したか?」で、QualityとImpactを測ろうという話

前提として、開発者個人の貢献度をプロダクトの成功に直接結びつけることが難しく、定量化が困難であり、アウトプットではなく、アウトカムとして評価するべきということが、論文で述べれている

  • コード量が多い開発者が、高品質のコードを生成しているとは限らない
  • 高品質なコードが顧客価値を提供するとも限らない
  • 顧客を満足させる機能が、必ずしもビジネスに良い影響を与えるとも限らない

論文では、測定基準の例としては以下が挙げられている

  • Quality
    • Reliability
      • いわゆる信頼性指標。エラーレートやレスポンスタイムなどなど
      • state of the devops reportでも信頼性についての話が出てる通り、生産性を測る上でもシステムのReliability指標は重要
      • Reliabilityから多少ずれる感はあるが、Core Web Vitalsも良さそう
    • Absence of bugs
      • そのまま捉えるとバグの数
      • 単純なバグ数ではなくても、インシデント数や変更失敗率で代替で良さそう
    • ongoing service health
      • エラーレートや稼働率
  • Impact
    • Customer satisfaction / Customer adoption and retention / Feature usage
      • どれだけ顧客にインパクトを与えたか?の測定
      • どれだけ開発者の満足度やReliability、開発組織内のサイクルタイムが速くても、顧客にインパクトを与えてなければ生産性高いとは言い難い
      • four keysなどの開発組織のプロセスの可視化・改善は一側面・レイヤーでしかなく、どれだけ効率良く、顧客に価値を提供しているかも含めて生産性だと思うので、この要素は重要だと思っている
      • 顧客へのNPS調査実施や機能利用率辺りを測定していくことになりそう
      • 最近だとCREが担いそうな部分
    • Cost reduction
      • 本当にどれだけコスト削減したかだけを測定すればいいのか?という疑問はある
      • いかに低コストがシステムを提供しているかという話だと理解している
      • ユーザー・データ量増加を加味したインフラコストを定期的に見て、ダウントレンドか見るとかになるんだろうか?
        • 1ユーザーあたりコスト的な

ただ論文内で紹介されている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は以下のような感じ。
測定自体は今だとFindyTeamsを入れれば終わりだが、 とはいえこれを測定してどう判断・活用していくか?と言われると難しい、特に個人レベル
明らかに過小・過剰なアクティビティデータが確認された場合をモニタリングするぐらいだろうか

  • 個人
    • コミット数・レビュー数・PR数
    • コーディング時間
      • first commitからreview開始 or マージまでの時間とかだった記憶…
  • チーム/グループ
    • ベロシティ
      • LeanとDevOpsの科学でもそれ以外もベロシティで生産性測るのは微妙という話があるので、これでいいのか。。?感はある
  • システム
    • デプロイ頻度
      • four keysの一部

書いてて思うが、Activityなのか他カテゴリではないのか判断に迷うものもあった。

論文内でOperational activityの一環としてon-call participation and incident mitigationが書かれていたが、on-call participationはcommunication and collaborationの方に入れたいと思ったりした
サイクルタイムもActivityなのか、outcome of a processなのでPerformanceに入るのか?とか

個人的に、特に個人レベルでのActivityは測定はしておくが、組織的に改善を回すイメージはあまり出来ていない。
1on1でたまーに使うかなぐらい

チーム/グループ・システムレベルだと、Performanceに入るかもしれないが、モニタリングはfour keysやサイクルタイム、機能リリース数などを見ておいて、より詳細なアクティビティデータは詳細に分析・改善案出しする際に使うので十分ではという感じがする。

Communication and collaboration

測定が困難な項目が多いが、論文内では以下指標が使えるかもと書いてる

  • Discoverability of documentation and expertise
    • ドキュメントの見つけやすさ
    • 色んな所に効いてくる重要な要素だけど、どうやって測定するんだ?という気持ち
    • 問い合わせに対してのドキュメント有無やヒット率を計測するとかはありそう
    • どうせ測定頑張るなら、有無やドキュメントのクオリティーも含めたい
    • TODO:
  • How quickly work is integrated
    • 言いたいことはわかるが、ドキュメントの見つけやすさと同じく測定方法がイメージつかない
    • 実質サイクルタイムで代用できるのは?という気がする
      • バリューストリームマッピングを定期的に行うでも良さそう
  • Quality of reviews of work contributed by team members
    • ソフトウェアエンジニアリングだと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.
    • サイクルタイムやプロセス内の待ち時間
      • レビュー開始までの時間なども関連

まとめ

一旦整理してみた。

基本的に測定が容易なアクティビティデータだけに頼るべきではないという主張のフレームワークなので、測定難しい印象のものも多い。
またあくまでもフレームワークであり、どのディメンション・カテゴリからどのメトリクスをどのレイヤーで測定するのかは組織での選定に任されているので当たり前だが、活用するにあたってここの選定が最も迷うなと改めて感じた

活用始める上では、どのようにディメンション・メトリクスを選んでいくが一番イメージついてないので、実際の活用例を収集するのが一番早そう
(そしてfour keysの明確に指標が提示されているありがたさ?楽さ?を実感した)