Zenn
株式会社ログラス テックブログPublicationへの投稿
🔖

Four Keysだけじゃない開発者生産性フレームワーク

r.kagaya
2022/12/20に公開
生産性
開発者体験
開発生産性
idea

本記事は株式会社ログラス Productチーム Advent Calendar 2022の20日目の記事になります。
昨日はtkamaiさんのto B SaaS企業を2社経験して感じた、プロダクトマネージャーに大切なことでした。

はじめに

昨今、開発生産性や開発者体験、Four Keys(DORA Metrics)にDeveloper Productivity Engineering(DPE)などの言葉を耳にする機会が少しづつ増えてきたように思います。

生産性可視化・改善の動きは弊社でも強まってきており、先月11月からログラス開発組織初のnot フィーチャーチーム、チームトポロジーで言う所のイネーブルメントチームが誕生しました。
私は上述のイネーブルメントチームの中で、特に開発生産性・体験の向上を役割として持つことになったため、開発生産性は個人的にもホットトピックです。
様々な企業の取り組みを調べてもFour Keysを参照してる例が多い印象ですが、そのほかにも面白い論文・フレームワークは存在しています。
そこで今回はFour Keys以外で、直近参考にしている開発生産性可視化・改善に関連する論文・フレームワークを紹介します。
(開発生産性フレームワークと呼称して良いかわからないですが、便宜上...)

SPACE

SPACEは、開発者の生産性をどう捉えるかについてのヒントを与えてくれるフレームワークです。
著者の一人であるNicole Forsgren氏は、LeanとDevOpsの科学の著者の一人でもあります。
そんなNicole Forsgren氏が、2021年にGitHub、ビクトリア大学、Microsoft Researchのメンバーと共に発表した論文、The SPACE of Developer ProductivityでSPACEフレームワークは提唱されています。

この論文では、生産性が捉えどころのないものである理由として、単一の指標やディメンションで表すことが出来ないからだと述べています。
開発者の生産性を重要なひとつの指標で測ることは出来ず、またひとつの指標のみに注目してしまうと、意図していない結果を引き起こすことがリスクとして挙げられています。
そのようなリスクを避け、バランスよく生産性指標を選定するための方法として、SPACEフレームワークは定義されています。
またフレームワークと称してる通り、各々の組織やコンテキストに合わせて測定指標は選定すべきとされており、特定の測定指標が明確に提示されているわけではありません。

特徴

大きく分けて、SPACEの骨子は以下二つです。

カテゴリ/ディメンションの定義

SPACEという名前は、開発者生産性の測定指標として推奨・重要だと定義されているカテゴリ(論文内ではディメンションと記述)の頭文字から来ています。

  • Satisfaction and well being
    開発者が自分の仕事、チーム、ツール、文化にどれだけ満足しているか
  • Performance
    • 開発者が書いたコードは、想定されたことを確実に実行したか？
  • Activity
    • 業務を遂行する過程で完了した行動やアウトプットの数
  • Communication and collaboration
    • メンバーやチームがどのようにコミュニケーションをとり、協力し合うか
  • Efficiency and flow
    • 個人であれシステムであれ、中断や遅延を最小限に抑えて作業を進める、完了する能力

5つのカテゴリ・ディメンションが存在し、これらにまたがるが故に単一指標では扱えなく、それが捉えどころがないと言われる所以だと述べています。

個人・チーム/グループ・システム、それぞれのレベルでの計測

SPACEの5つのカテゴリ・ディメンションに加え、個人、グループ、システムの3つのレベルの組み合わせで計測することが論文で述べられています。

チームスポーツのように選手個人の成績とチームの成績の両方で判断されるべきという話と同時に、個人・チーム/グループ・システムと切り分けて検討することも、SPACEの根本の思想である多面的に生産性を捉えることを表しています。

活用方法

実際の測定指標の選定に関しては、複数のカテゴリ/ディメンションにわたって少なくとも3つの指標を取得することを推奨しています。
同一カテゴリ/ディメンションだけで取るのではなく、例えばコミット数を測定している場合、PR数などのアクティビティデータに分類されるメトリクスではなく、それ以外のカテゴリ/ディメンションから選定すべきとしています。
また全体像をより把握するために、少なくとも一つはアンケートデータなどの定性的な指標を含めることも推奨しています。

さらには、測定基準はチームや組織で何が重要かを示し、行動を形成するものであると述べられています。
例えば、生産性＝コード行数、コードレビュー品質、顧客満足度で測ることで、チームワーク（コードレビューを評価）とエンドユーザー（顧客満足を評価）の両方を含めて生産性指標を定義することで、チームや組織の文化、あるべき姿を表現することが可能だという例が紹介されています。

SPACEの5つのカテゴリ/ディメンションを見るとわかるように、Communication and collaborationとEfficiency and flowのように一定トレードオフが発生しかねないものが存在しており、コラボレーションと効率性のどちらに比重を置くかは組織・チームにおけるスタンスそのものです。
生産性はコンテキストに大きく影響されるものであるため、SPACEはあくまでフレームワークであり、最終的な測定指標は自分達の組織やコンテキストに合わせて決めるものであると言えます。

具体例

論文内で紹介されているExampleです。
そのまま採用することは推奨してないと理解していますが、イメージを掴むには参考になります。

https://dl.acm.org/cms/attachment/9f3f11c8-8c6e-48e9-a1a2-7772a8cfa441/forsgren1.png
参照：The SPACE of Developer Productivity｜https://queue.acm.org/detail.cfm?id=3454124

Introducing Developer Velocity Lab to improve developers’ work and well-being | OD532ではCode ReviewをSPACEで考える例も紹介されており、個人的にはこのように特定の何かに対してメトクスでの計測や改善を検討する際に、SPACEで捉えてみるのもしっくりくる使い方だと感じています。

https://user-images.githubusercontent.com/20347995/206892698-40bd9379-da54-448c-9222-60ccb75ce981.png

参照：Introducing Developer Velocity Lab to improve developers’ work and well-being | OD532｜https://www.youtube.com/watch?v=RhX9-xcrH0w&list=WL&index=6

利用例

具体的な活用例は多くありませんが、以下記事でGithub, Netflixの開発チームで導入しているとの記述はありました。
Continuous improvement metrics: Lessons from 6 software teams | TechBeacon

Netflixに関しては、Netflixの生産性チームの人間がSPACEについてbig fanだと言及していますが、具体的な活用については特に話されてはいません。
Creating a Culture of Engineering Productivity at Netflix - DevInterrupted

GitHub Copilotの調査レポートでは、SPACEを用いてどのような側面から調査を行うかを決めたと書かれています。
Research: quantifying GitHub Copilot's impact on developer productivity and happiness | The GitHub Blog

DXフレームワーク

続いて、An Actionable Framework for Understanding and Improving Developer Experienceで紹介されているDXフレームワークについてです。
開発者体験の可視化と改善アクションに関するフレームワークで、どのような要因が開発者体験・生産について影響を与えるか、どのように改善を行うべきかについての戦略などが含まれています。

詳しくはわかっていませんが、論文自体は以下会社・サービスから出されたもののようです。
開発者の満足度と生産性に関する研究を行ってる研究者によって設計と書かれており、前述のSPACEの考案者であるNicole Forsgren氏の名前も登場しているほか、顧客例の中には、TwilioやVercelの名前があります。
DX: The Developer Experience Platform

DXフレームワークの構成要素

DXフレームワークは、ざっくり以下要素で構成されています。

  • Developer Experienceの定義
    • 「開発者が自分の仕事についてどう考え、どう感じ、どう評価しているか」
      • レガシーコードに慣れた開発者は、技術的負債について不満に感じない可能性もある
    • 人間の体験における三つの主要な次元に由来
      • cognition(認知)
      • affect(感情)
      • conation(行動する意志)
  • DX Factors
    • 開発者体験に影響を与える要因
    • Development and release
      • コーディングとリリースに関連する要因
        • 開発環境
        • 十分な自動化テスト
        • テストの信頼性
        • フィードバックループの速度
        • etc…
    • Product management
      • プロダクトマネジメントに関連する要因
        • 目標、スコープ、要件の明確化
        • 無茶な納期
        • ビジネスへの価値提供の実感
        • etc…
    • Collaboration and culture
      • 人と人の関係がどのように仕事を行う上での妨げになったり、助けになったりするかに関連する要因
    • Developer flow and fulfillment
      • 開発者フローと充実感
      • 開発者フローに影響を与える要因
        • 自律性
        • チャレンジとスキルの間のバランス
        • フロー
          • 障害なく進歩すること
          • 中断されない十分な時間があること
        • etc…
  • Contextual Characteristics
    • DX Factorsのうちより重要なものを判断する要因・背景
  • Barriers to Improvement
    • 開発者体験の向上を阻む障壁
    • 主に技術よりも、組織的なもの
  • Strategies
    • 開発者体験を向上させるために採用している戦略について
    • 個人的な戦略とチームとしての戦略
  • Coping Mechanisms
    • 改善されない開発者体験にどのように対処しているか

全体像は以下の図の通りです。

参照：An Actionable Framework for Understanding and Improving Developer Experience｜http://paper.getdx.com/

開発者へのインタビューを通じて導き出された、どのような要素が開発者体験に影響をもたらすのかの整理も参考になりますが、個人的には開発者体験が主観的なものであり、今までの経験によって差分があるという点を、論文を通じて改めて実感しました。

Key Takeaways for Industry Practitionersで、Developer experience is highly personalという内容が取り上げられていますが、同じチームに所属する開発者でも、感じる体験は大きく異なる可能性があり、またある種のトレードオフや妥協が必要になることがあるというのは、まさしくその通りだと実感してます。
レガシーコードの例もわかりやすいですが、それ以外にもコードレビューを行うことはチームにとって有益である一方で、レビュワーにとっては機能開発に割く時間が減少してしまい満足度が低下する可能性もあり得ます。
この話はSPACEでも話されている、特定の指標や一要素だけで生産性や体験を図ることの悪影響や難しさを表してる良い例だなと感じています。

DXというサービス自体の話は触れることが出来ませんでしたが、関心があるのでデモを受けてみたいと思います。
DX: The Developer Experience Platform

EBM(エビデンスベースドマネジメント)

もはや開発者生産性フレームワークとは呼ばない気はしますが、最近(アドベントカレンダー投稿数日前)になって知ったので取り上げます。

EBMは、Scrum.org が開発した、ゴールと実験、プロダクト価値・ビジネス価値へのフォーカスに重点を置いたプラクティスです。
日本語翻訳版に加えて、非常にわかりやすい解説記事もあるので、EBMの詳細については以下記事を参照して頂くと良さそうです。

エビデンスベースドマネジメントガイド
エビデンスベースドマネジメントガイド by Scrum.org
EBM(Evidence-Based Management)におけるTime toMarket(T2M)の重要性
EBM入門 - W-G-X edition

EBMの構成要素としては、組織ゴール、重要価値領域、実験ループがありますが、個人的に重要価値領域が今の自分には刺さっています。
重要価値領域(KVA)について参考資料から抜粋しましたが、ざっくり以下が重要価値領域の概要とその指標例です。

  • CV(Current Value)
    • 現在プロダクトが提供している価値
    • 指標例
      • 従業員1⼈あたりの収益
      • プロダクトコスト⽐率
      • 顧客満⾜度
      • 顧客使⽤指標
  • T2M(Time-to-Market)
    • プロダクトをリリースするまでのリードタイムやリリース回数
    • より高速にリリースサイクルを回して学習・フィードバックサイクルが回せることの証明
    • Four Keys(DORA Metrics)のうち速度に関するものが含まれる
    • 指標例
      • デプロイ頻度
      • 変更のリードタイム
      • 学習時間
      • ピボットまでの時間
  • A2I(Ability to Innovate)
    • ユーザーにエンゲージメントされてるプロダクトを作れる環境か？
    • Four Keys(DORA Metrics)のうち安定性に関するものが含まれる
    • 指標例
      • 本番環境のインシデントの数
      • 技術負債
      • コンテキストスイッチにかかる時間
      • 変更失敗率
  • UV(Unrealized Value)
    • 未実現の価値
    • CV と UV の両⽅を考慮することで、現在と未来のメリットのバランスをとることがで
      きる
    • 指標例
      • 市場占有率
      • 顧客（ユーザー）満⾜度ギャップ
      • 望ましい顧客体験または満⾜度

EBMに良さを感じたのは、単純なベロシティ追跡に対するモヤモヤやプロダクト価値の観点は(直接的には)含まれていないFour Keysに感じるある種の片手落ち感から来ています。
生産性可視化の文脈でも、Four Keysやサイクルタイムなどの開発プロセス改善は土台的なものであり、その上にはプロダクト価値や顧客満足度、BtoB SaaSを提供している弊社で言えばARRなどのビジネス指標が存在しているはずです。
ちょうど開発生産性可視化やメトリクスベースでの改善活動について、EBMで言う所のT2M(Time-to-Market)とA2I(Ability to Innovate)に含まれる指標をまずは追いかけ始めつつ、その後プロダクト価値、最終的にはビジネス価値まで。。と整理していたため、開発プロセスだけに閉じず、プロダクト価値・ビジネス価値にもフォーカスした可視化・改善の道筋を立ててくれているEBMに対しては欲しかった物では？と感じました。
ビジネス寄りの指標を可視化・改善する事の難易度は変わりませんが、既に一定道筋をつけてくれている点には嬉しさを感じています。

まとめ

開発者の生産性や体験に関する論文やフレームワークを紹介しました。

SPACEの考え方や整理は納得度も高く、測定基準の選定でチーム・組織で何が重要かを示し行動を促す事も目指すというのは、難しさもありますが、設計のしがいも感じます。
Netflixの生産性チームのメンバーによる記事では、顧客満足度を重視してるがゆえに、生産性指標として顧客満足度を入れているという話は、まさしくSPACEで語られていることと同義です。
ログラスでもFour keysから注力が始まってますが、一側面ではあるので、より多面的に生産性可視化・改善を扱わなければいけないと改めて自戒しました。
SPACEに関しては、論文内で開発者の生産性についての神話と称して、通説に対してコメントしてる部分も良かったです。その部分がSPACEフレームワークの前提になってる側面はあるので、興味がある方はぜひ読んでみてください。

またSPACEとDXフレームワークの両者に通じて言えるのは、多面的に捉える必要性と定性情報の重要性、生産性と満足度が本質的に結びついているという前提です。
「開発者の生産性は重要な1つの指標で把握する事は出来ない」、「開発者が自分の仕事についてどう考え、どう感じ、どう評価しているか」と述べられているように、アクティビティデータだけに頼らず多面的に捉え、定性的な情報も加味しつつ、追う必要があると改めて実感しました。

本記事で紹介した内容も参考にしながら、しばらくは生産性や体験を磨き続ける事に精進できればと思います。
明日、株式会社ログラス Productチーム Advent Calendar 2022 の 21日目は@asakoshiさんによる成果と文化を育てる協働プロダクトマネジメントです！

参考リンク

SPAC

The SPACE of Developer Productivity
SPACE - 開発者の生産性を理解し計測する新フレームワーク
Introducing Developer Velocity Lab to improve developers' work and well-being | OD532

DXフレームワーク

getdx
DX: The Developer Experience Platform

EBM

エビデンスベースドマネジメントガイド
Evidence-Based Management™ (EBM)
エビデンスベースドマネジメントガイド by Scrum.org
EBM(Evidence-Based Management)におけるTime toMarket(T2M)の重要性
EBM入門 - W-G-X edition

株式会社ログラス テックブログ
株式会社ログラス テックブログPublication

株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。

Discussion