LeanとDevOpsの科学の著者の一人であるNicole Forsgren氏が著者に入っているThe SPACE of Developer Productivity: There's more to it than you think - Microsoft Researchで提唱されているSPACEについて
以下記事も
要約
- SPACEは開発者の生産性を計測するためのフレームワーク
- 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字
- satisfaction and well being
- performance
- activity
- communication and collaboration
- Efficiency and flow
- 開発者の生産性は「重要な1つの指標」で把握する事は出来ない
- アクティビティデータであるコミット数だけを計測しては、適切に生産性を測れない
- 生産性を様々な側面から、バランスよく捉えるためのSPACE
- 推奨されている測定指標のカテゴリ(本文ではディメンションと定義)の頭文字
- 測定範囲として個人、チーム/グルーム、システムの3レベル
- 測定する指標は、複数のカテゴリにわたって少なくとも3つのメトリクスを推奨
- 少なくとも一つの評価指標に、アンケートデータなどの定性的な指標を含めるのを推奨
- 生産性を多面的に測定すると同時に、測定基準の選定でチームや組織で何が重要かを示し、行動を促す事も目指す
- ex) 従業員の健康、幸福、定着に配慮している企業は、生産性の測定に満足度と幸福の側面を含める
- ex) "生産性＝コード行数 "のみのチームと、"生産性＝コード行数 AND コードレビュー品質 AND 顧客満足度 "のチームの違い
- 具体的に測定すべき指標を明確に提示しているわけではないので、各自分達の組織やコンテキストに合わせて決定する
- あくまでフレームワーク
SPACEとは
- SPACEは開発者の生産性を計測するためのフレームワーク
- 5つのディメンション(カテゴリ)の頭文字
- satisfaction and well being
- performance
- activity
- communication and collaboration
- Efficiency and flow
- 生産性は単一の指標やアクティビティデータだけでは測れない
- また経営者、マネージャーだけが気にするものでもない
- 自分の仕事に対する洞察を得るためにも活用出来る
- 生産性の高さは、仕事に対する満足感や幸福感と高い相関
- SPACEに含まれる5つの要素と、個人、グループ、システムの3つのレベルの組み合わせで計測
- 5つのディメンション(カテゴリ)の頭文字
- Why SPACE
- チームやマネージャーが、開発者の生産性を「重要な1つの指標」で把握しようとすることがあまりにも多い
- しかし生産性を単一の次元・指標で計測することはできない
- 生産性のさまざまな側面を捉えるためのSPACE
- 生産性や測定基準をより広く、バランスよく捉える方法を提供
- 後述のアクティビティのみを計測した場合に生じる問題など回避
- 生産性や測定基準をより広く、バランスよく捉える方法を提供
開発者の生産性についてと既存の計測の問題
-
開発者の生産性を測定する理由
- 組織、マネージャー、開発者は、高品質なソフトウェアをより効率的に作成する能力を得ることができるため
- 開発者の幸福と満足を確保するため
- 生産性の高さは、仕事に対する満足感や幸福感と高い相関があることが、研究によって示されている
-
開発者の生産性についての神話
- Myth: Productivity is all about developer activity
- 最も一般的な俗説のひとつ。いわゆる開発者のアクティビティデータのみを計測するパターン
- アクティビティだけでは、効率的に仕事が出来るようになったのか、長時間労働した結果なのか判別できない
- プルリクエスト数、コミット数、コードレビュー数などのメトリクスだけ見ていては、ペアプロやブレインストーミングなどのコラボレーション活動を見逃すことになる
- ドキュメントなども
- そもそも開発者は納期に間に合うように調整することが多いため、生産性を評価する際に特定の活動指標に依存することは困難
- スケジュール遅らせる事ができないから土日出勤😇
- Myth: Productivity is only about individual performance
- チームスポーツと同じで、選手個人の成績とチームの成功の両方で判断される
- 個人的な生産性のみを考えてる開発者は、チームの生産性を低下させる
- コードレビュー、オンコールローテーションなど、チームにフォーカスした活動は、コードベースと製品・サービスの品質を維持するのに役立つ
- 個人、チーム、組織の生産性を最適化するためには、適切なバランスを見つけること、そしてトレードオフの可能性を理解することが重要
- チームスポーツと同じで、選手個人の成績とチームの成功の両方で判断される
- Myth: One productivity metric can tell us everything
- 「重要な1つの指標」を使って、チームの仕事全体を測定し、組織や業界全体でチームを比較することは出来ない
- 生産性はコンテキストに大きく影響される
- プロダクトエンジニアリングとプラットフォームエンジニアリングをしてるチーム間でデプロイ頻度の数値をそのまま比較はできない
- チームトポロジーで言うストリームアラインドチームチームとイネーブルメントチームでは生産性の定義も異なるはず
- Myth: Productivity Measures ARE useful only for managers
- 開発者自身も自分の仕事に対する洞察を得るために活用することができる
- 生産性の高さは、仕事に対する満足感や幸福感と高い相関
- Myth: Productivity is only about engineering systems and developer tools
- 開発者の生産性には、開発ツールやワークフローが大きな影響を与えるが、環境や職場文化などの人的要因も大きな影響を与える
- 環境や文化を健全に保つために必要な重要な作業は、組織の多くのメンバーや、従来から生産性の測定に使われている測定基準からは「見えない」ことがよくある
- モラルの向上、メンタリング、知識の共有などは、生産的な職場環境を維持するために不可欠な作業だが、測定されない事がある
- チーム全体の生産性に貢献する「目に見えない」仕事は、一般的に測定される他の側面と同様に重要
- Myth: Productivity is all about developer activity
-
生産性が捉えどころのないものなのは、ひとつのディメンション(カテゴリ)やメトリクスに集約できないものだから
- ex) 多くのチームが、開発者の生産性をSPACEの中のひとつのディメンション、例えばアクティビティのみ計測している
- アクティビティ
- コード行数やコミット数、プルリクエストの所要時間のような、作業過程で実行したアクションや完成したアウトプットの数
- いずれも単独で計測するには局所的で、他の重要な要素を見落とすことになる
- コード行数だけで生産性を図る事は出来ない
- アクティビティ
- ex) ストーリーポイントだけで生産性を計測
- ポイントを最適化することに集中し、他開発者の進歩や、他チームとのコラボレーションや新メンバーの受け入れなど、重要 && 見えない仕事が疎かになってしまう可能性
- ex) 多くのチームが、開発者の生産性をSPACEの中のひとつのディメンション、例えばアクティビティのみ計測している
-
開発者の生産性を「重要な1つの指標」で把握せず、複数の要素から多面的に扱う必要がある
SPACEに含まれるディメンション
- Satisfaction and well-being
- 開発者が自分の仕事、チーム、ツール、文化にどれだけ満足しているか、開発者がどれだけ健康で幸せか、仕事がそれにどのような影響を与えるか
- 生産性と満足度は相関関係にあり、満足度が生産性の先行指標となりうる
- 満足度とエンゲージメントの低下は、燃え尽き症候群や生産性の低下を示唆している可能性
- ex)
- パンデミック時にリモートワークが義務化された際、生産性の一部の指標（コードコミットやプルリクエストのマージ速度など）が上昇
- しかし、定性的データによると一部の人々は幸福感に悩まされていた
- アクティビティを評価する指標はポジティブだが、満足度を評価する指標を追加すると、より全体的な生産性が把握でき、一部の開発者は燃え尽き症候群になりかけていることが分かった
- 生産性のいくつかの側面をとらえたバランスの良い指標の重要性
- 満足度を測定するための項目
- Employee satisfaction
- 従業員の満足度、およびその従業員が自分のチームを他の人に薦めるかどうか
- Developer efficacy
- 開発者が仕事をするために必要なツールやリソースを持っているかどうか
- Burnout
- 過度かつ長期の職場ストレスによって疲労困憊になっていないか
- Employee satisfaction
- Performance
- ソフトウェア開発者個人の貢献度をプロダクトの成功に直接結びつけることが難しく、定量化が困難
- コード量が多い開発者が、高品質のコードを生成しているとは限らない
- 高品質なコードが顧客価値を提供するとも限らない
- 顧客を満足させる機能が、必ずしもビジネスに良い影響を与えるとも限らない
- ほとんど企業や組織では、ソフトウェアは個人ではなくチームによって開発されており、個々の開発者のパフォーマンスを評価するのは難しい
- ソフトウェア開発者のパフォーマンスを最も単純化すると、「開発者が書いたコードは、想定されたことを確実に実行したか？」
- パフォーマンスの次元を把握するための測定基準例
- Quality
- Reliability
- absence of bugs
- ongoing service health
- Impact
- Customer satisfaction
- customer adoption and retention
- feature usage
- cost reduction
- Quality
- パフォーマンスの次元を把握するための測定基準例
- ソフトウェア開発者個人の貢献度をプロダクトの成功に直接結びつけることが難しく、定量化が困難
- Activity
- アクティビティとは、業務を遂行する過程で完了した行動やアウトプットの数
- 比較的容易に測定・定量化できるアクティビティ指標
- Design and coding
- Volume or count of design documents and specs
- work items
- pull requests
- commits and code reviews
- Continuous integration and deployment.
- Count of build, test, deployment/release, and infrastructure utilization.
- Operational activity
- Count or volume of incidents/issues and distribution based on their severities
- on-call participation and incident mitigation
- Design and coding
- 比較的容易に測定・定量化できるアクティビティ指標
- 個人またはチームの生産性に関する意思決定を行うために単独で使用するべきではない
- 組織のニーズや開発環境に応じてカスタマイズ
- SPACEの他の要素と組み合わせて使う
- ソフトウェア開発に不可欠な活動の多くは、測定・定量化が難しい
- チームミーティングへの出席
- ブレーンストーミングへの参加
- チームメンバーの支援
- アーキテクチャガイダンスの提供
- アクティビティとは、業務を遂行する過程で完了した行動やアウトプットの数
- Communication and collaboration
- メンバーやチームがどのようにコミュニケーションをとり、協力し合うか
- ソフトウェア開発は、チーム内およびチーム間のコミュニケーション、調整、コラボレーションに依存する、共同的かつ創造的な作業
- チームの成果に貢献する仕事や、他のメンバーの生産性をサポートする仕事
- 個人の生産性やフロー状態に入る能力とはトレードオフで、モチベーションや満足度を低下させる可能性がある
- 見えない仕事や、調整・計画作業など、測定が困難な項目が多いが、コミュニケーション、コラボレーション、コーディネーションを測定するためのプロキシとして使用できる指標の例
- Discoverability of documentation and expertise
- How quickly work is integrated
- Quality of reviews of work contributed by team members
- Network metrics that show who is connected to whom and how
- Onboarding time for and experience of new members
- メンバーやチームがどのようにコミュニケーションをとり、協力し合うか
- Efficiency and flow
- 個人であれシステムであれ、中断や遅延を最小限に抑えて作業を進める、完了する能力
- いわゆる「フローに入る」
- チーム内およびチーム間の活動がどの程度うまく調整されているか、継続的に進展しているか
- 中断のない集中時間や、価値を創造するアプリ内の時間（ex: 開発者がIDEで過ごす時間は、「生産的」な時間とみなされる可能性が高い）で測定されることが多い
- チームやシステムレベルでは、バリューストリームマッピングでソフトウェアのアイデアや構築から顧客に届けるまでに必要なステップを把握することができる
- 遅延やハンドオフを最小限に抑えて、バリューストリーム内の流れを最適化する
- バリューストリームの中で非効率な部分を見つけ、取り除く
- 顧客やユーザーにとって価値を生まない活動は、ソフトウェア開発の無駄と呼ばれる
- 重複した作業、作業が正しく行われなかったことによる再作業、時間のかかる暗記作業など
- 顧客やユーザーにとって価値を生まない活動は、ソフトウェア開発の無駄と呼ばれる
- DORA (DevOps Research and Assessment) フレームワークは、チーム内のフローを監視するためのいくつかのメトリクスを導入
- four keys
- 個人、チーム、システムの各レベルでのEfficiency and flowは、満足度の向上と正の相関
- しかし，効率性が高まると他の要素に悪影響を及ぼす可能性
- フローとスピードを最大化すると，システムの品質が低下し，顧客から見えるバグの数が増える可能性(パフォーマンス)
- インタラプションを減らすことで個人の効率を最適化すると、コラボレーション活動が減少する可能性
- Efficiency and flowを把握するための指標例
- Number of handoffs in a process; number of handoffs across different teams in a process.
- Perceived ability to stay in flow and complete work.
- Interruptions: quantity, timing, how spaced, impact on development work and flow.
- Time measures through a system: total time, value-added time, wait time.
- 個人であれシステムであれ、中断や遅延を最小限に抑えて作業を進める、完了する能力
Example
- コードレビューに関する、個人レベル、チーム・グループレベル、システムレベルに該当する具体的な指標を示した例
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ではCode ReviewをSPACEで考える例も紹介されていた。
それ以外にも、SPACEのうち一部のみを参照する例。
SPACEの活用方法
- 複数のディメンション(カテゴリ)にわたって少なくとも3つのメトリクスを取得
- コミット数（アクティビティ）を測定している場合、プルリクエスト数とコーディング時間を測定基準ダッシュボードに追加してはいけない
- 2つの異なるディメンション(カテゴリ)から少なくとも1つの指標を追加すべき
- 少なくとも一つの評価指標に、アンケートデータなどの定性的な指標を含める
- システムの計測だけから観察できる情報よりも、生産性の全体像を把握する事ができる
- 測定基準はチームや組織で何が重要かを示し、行動を形成
- 従業員の健康、幸福、および定着に配慮している企業は、生産性の測定に満足度と幸福の側面を含める可能性がある
- 測定基準を追加,削除することで、何が重要であるかを伝え、行動を促すことができる
- "生産性＝コード行数 "のみのチームと、"生産性＝コード行数 AND コードレビュー品質 AND 顧客満足度 "のチーム
- 生産性とアウトプットに関する（問題はあるが含まれてはいる）指標に加えて、チームワーク（コードレビューを評価することにより）とエンドユーザー（顧客満足を評価することにより）の両方をも評価する方向へ生産性に関する認識を誘導
- 指標は行動を形成するものであり、2つの指標を追加することで、チームや組織の変化を形成することに貢献
- 複数の側面から複数の指標を測定することが重要である理由
- チームや組織の文化、あるべき姿を表現する
- コラボレーションと効率性のどちらに比重を置くかなど
- "生産性＝コード行数 "のみのチームと、"生産性＝コード行数 AND コードレビュー品質 AND 顧客満足度 "のチーム
- あくまでフレームワーク。測定すべき指標を明確に提示しているわけではないので、各々の組織やコンテキストに合わせて決定
- チームの性質によっても異なる可能性
- ストリームアラインドチームとイネーブリングチームの生産性の定義は同一？
- 両チームとも顧客満足度を追っていたとしても、顧客が異なる
- ストリームアラインドチームとイネーブリングチームの生産性の定義は同一？
- フェーズによっても異なる可能性
- Efficiency and flowを高める方が適切なフェーズとcommunication and collaborationを重視したい、など
- リプレイス系のPJをやっていると、仕様や設計を行う初期はcommunication and collaborationの比重が強いが、開発段階に入ればEfficiency and flowが高い方が生産性高いといえる?
- Efficiency and flowを高める方が適切なフェーズとcommunication and collaborationを重視したい、など
- カスタマイズする or しない
- 全チーム対象にして横で比較するか否か
- 全く比較せずに生産性の改善が必要なチームを特定できる？
- チームの性質が違う場合に適切な共通指標を作れるか
- 性質が似ているチーム間では比較するか否か
- イネブーリングチーム同士で比較する
- 特定の指標のみ全チームで共通
- 満足度の側面はmustとか
- 全チーム対象にして横で比較するか否か
- チームの性質によっても異なる可能性
計測時の注意
- 計測項目を絞る
- 計測項目が多すぎると、混乱やモチベーションの低下につながる可能性
- 膨大な数のメトリクスと改善目標を提示された場合、達成不可能な目標に感じられる
- すべてのディメンション(カテゴリ)が含まれている必要はない
- 計測項目が多すぎると、混乱やモチベーションの低下につながる可能性
- 指標選定
- 測定基準によっては適さないものもある
- リテンション
- 従業員の満足度を測るために使われることが多いが、満足度と比べ、報酬、昇進機会、チームとの問題、あるいはパートナーの異動などを反映することができる
- チームレベルでは、マネージャーがリテンション評価を守るために異動を阻止することがありうる
- 遅行指標であるため、気づいた時に既に問題が起きている
- ストーリーポイント
- コラボレーションを犠牲にして、自分たちの仕事に集中するインセンティブをチームに与える可能性
- リテンション
- 測定基準によっては適さないものもある
- プライバシー、測定結果の取り扱い
- 開発者のプライバシーに配慮し、匿名化された集計結果のみ扱う
- ただ個人レベルの生産性分析は、開発者にとって有益である可能性も
- Peer review and gender
- 女性はコードレビューで否定的なコメントを受け取る可能性が高く、肯定的なコメントを受け取る可能性は低い
- そのパターンが組織やチームになくてもこのような影響を考慮に入れる
- Normalizing measures across time
- 1年の単位で指標を見ると、育児休暇を取得した人などに偏り
- Perceptual measures
- 文化的な違いを考慮