Zenn
Open16

Developer Productivity Engineering

space
dpe
開発生産性
とりいとりい

面白い記事

デプロイの頻度 - 組織による正常な本番環境へのリリースの頻度
変更のリードタイム - commit から本番環境稼働までの所要時間
変更障害率 - デプロイが原因で本番環境で障害が発生する割合（%）
サービス復元時間 - 組織が本番環境での障害から回復するのにかかる時間

Championed by Gradle Inc., Developer Productivity Engineering (DPE) is an approach to increasing software development team productivity that focuses on automation technologies and tools, rather than management metrics and best practices. Specifically, this new software development discipline uses acceleration technologies to speed up the software build and test process, and data analytics to make troubleshooting and software quality assurance more efficient. The aim is to achieve faster feedback cycles, more reliable and actionable data, and a highly satisfying developer experience. And, as DPE dovetails with iterative Agile approaches, it yields faster feedback cycles as well. DPE is here to stay.

開発者の生産性を重要なひとつの指標で測ることは出来ず、またひとつの指標のみに注目してしまうと、意図していない結果を引き起こすことがリスクとして挙げられています。
そのようなリスクを避け、バランスよく生産性指標を選定するための方法として、SPACEフレームワークは定義されています。

何につながる

  • 開発組織の生産性向上、開発者体験向上(開発・テストからデプロイ、運用監視までフルサイクルな体験向上)
    • 開発者にフォーカスした取り組みであることで、エンゲージメント向上やEVP向上にもつながる。
  • 組織に合わせた指標とFBモデルを定義することで、ビジネス観点でのアウトカム向上までデザインできるかも
    • 定量的+定性的指標
    • 開発領域に近い指標と組織が重視する包括的な生産指標(目標)との紐付け(ストーリー)が大切

SPACEとは

開発者生産性エンジニアリング（DPE）に関連するフレームワークの一種です。

  • DPEは開発者の生産性と開発者体験を向上させることに焦点を当てた新しいソフトウェア開発手法です。生産性は管理原則やベストプラクティスによって対処できるという従来型とは異なるアプローチで生産性を向上させます。開発者にフォーカスして、周囲を取り巻くペインを取り除き幸福にするアプローチを心がけます。
  • 開発者の生産性を重要なひとつの指標で測ることは出来ず、またひとつの指標のみに注目してしまうと、意図していない結果を引き起こすことがリスクとして挙げられています。そのようなリスクを避け、定量的・定性的バランスよく生産性指標を選定するための方法として、SPACEフレームワークは定義されています。
  • SPACEフレームワークは、開発者の生産性だけでなく、開発者を取り巻く環境を迅速に評価するためのいくつかのデータポイントを定義しようとするものです。開発者の生産性を様々な側面から捉え、生産性がアクティビティの量やツール、個人のパフォーマンスによって測られるという考え方などの誤りを否定するために作られました。元の論文: https://queue.acm.org/detail.cfm?id=3454124

どうやって測定の定義・運用・改善をまわすか

  • SPACEのフレームワークに則って組織に合わせた定義を考えるのがまるそう(Four keysも可能な範囲で内包できそう)
  • 組織を良くする(自律自走可能な成長モデルに載せる)ために上記が使えていれば
  • SPACEのフレームワークに則って組織に合わせた定義(指標)を考える。いきなり全部が揃わなくても、可能なものを測定しサイクルを回してみる。
    • stage1: 観測対象となるデータや指標、さらに初期での基準をざっくり定義　※初期は全ての観点を定義できなくて良い
    • stage2: csvやスプレッドシートで良いので定期的にデータ収集し、都度可視化
    • stage3: 基準に対する実測値を比較。ここで、そもそもの基準見直し
    • stage4-1: stage2,3を繰り返す。繰り返しを容易にするため、リアルタイムな観測・可視化、自動データ収集等、サイクルの改善も並行して実施
    • stage4-2: 合わせて、未定義の観点に指標を追加定義してstage2～進める
  • SPACEの中で定性的な指標、特に開発者体験に関連するアンケートは並行して実施したい

注意点

  • 個人の評価には使用しない
    チームや組織の健康診断的なもの。現状を正しく把握するために使う。
  • 組織を良くする(自律自走可能な成長モデルに載せる)ための判断材料として使う。
  • メンバーに理解してもらう必要がある
    FBの重要性を説く必要がある。チームや組織が進む際、その道を調整するためのもの。
とりいとりい

Read Later

  • gradleのDPE_Handbook_2022.pdf

Unblocking Workflows: The 2023 Guide to Developer Productivity

https://mattermost.com/guide-to-developer-productivity-2023/#part-1-key-productivity-challenges

  • コミュニケーションツールを作っている会社の記事という前提

情報のサイロ化が開発者の効率的な共同作業を妨げる
開発チームは、ソフトウェアの開発、出荷、保守に複数のツールを使用していますが、これらのツールはサイロ化し、同期を保つのが難しくなっています。情報は常に、さまざまなツールで作成されているため、チームのスピードが低下しています。

Cybersecurity strategy is a non-negotiable part of every business

Complex, fast DevOps workflows have reached a breaking point
今後、生産性の最適化を目指すチームは、ツールスタックを簡素化し、合理化するための技術選択を行うことが予想されます。統合の強化や観測可能なツールなど、スタックの信頼性を高めることに注力する必要があります。

Platform engineering is on the rise
プラットフォームエンジニアリングへの移行です。社内向けと顧客向けの両方のソフトウェアプラットフォームを構築・維持しなければならない開発者にとって、インフラ管理は気が抜けないものです。プラットフォームエンジニアリングは、開発チームの作業を効率化するサービスやツールを幅広くサポートすることで、開発者の生産性と満足度を向上させるチームを確立する役割を担っています。

Hiring and retention challenges continue to impact productivity
優秀な人材を確保するための計画を立てると同時に、開発者を効果的に雇用し、オンボーディングするための計画を立てる必要があります。

Better integrations are the missing link in many teams’ toolchains
回答者に「今、あったらいいな」と思うものを聞いてみました。最も一般的な答えは、特定のツールチェーンやテクノロジーではなく、ツール間のより良い統合でした。

Is remote work good or bad for collaboration? The jury’s still out.
43％の回答者がリモートワークによってコラボレーションが向上したと答えている一方で、33％の回答者はリモートワークによってコラボレーションが悪化したと答えています。

Invest in systems that support your workflows rather than generic tools
チーム固有のニーズに対応できるオープンソースソフトウェアに投資する。
適切な投資を行うには、チームのニーズを十分に理解する必要があります。どのような統合をすれば日々の業務が効率化されるのか？インシデント発生時や通常の製品リリース時に直面する最大の障害物はどこか？チームのニーズを把握することで、より優れたツール、より堅牢なプロセス、その他の変更が効果を発揮する可能性のある領域を評価することができます。

Consider future-facing tools and platforms
「未来志向」のプラットフォームを取り入れましょう。例えばGitHub CopilotのようなAI支援ツールは、すでに開発者の生産性向上に貢献することが分かっています。

Refine automation initiatives
To get the most out of your automation initiatives in 2023, don’t take a more-is-more approach. Instead, focus on using automation to accelerate and streamline critical moments in your team’s workflows.

To accelerate productivity, focus on improving collaboration
開発者は集中的に作業する時間が必要ですが、進捗を維持するために定期的にコラボレーションを行う必要があります。コラボレーションを可能な限り簡単かつシームレスにすることで、効果的なコミュニケーションと共同作業が可能になり、より早くコーディングに戻ることができるようになります。
開発者が直面する固有の問題に対応し、開発者の気を散らさないようにするツールが必要なのです。

3 Key Themes To Take Away From the First-Ever DPE Summit

https://www.spiceworks.com/tech/devops/guest-article/developer-productivity-engineering-summit-key-takeaways/

DPEは、開発者の生産性と幸福度を最大化するために、業界を問わず一流企業が採用しているソフトウェア開発手法です。自動化、実用的なデータ、高速化技術に依存し、フィードバックサイクルの高速化、ビルドやテストの失敗の解決時間の短縮など、測定可能な結果を提供します。

これは、生産性を「人」の問題ととらえ、管理命令やベストプラクティスによって最もよく対処できる問題とする従来のアプローチとは対照的です。

Netflix は、ビルドと CI プロセスをより統合し、ローカル開発ループに集中することで、ビルドを高速化した方法を紹介しました。LinkedIn は、チームがクラウドで新しいリモート開発環境を構築し、初期設定とビルドにかかる時間を 10 ～ 30 分からわずか 10 秒に短縮した方法について説明しました。

An IT Executive Introduction To Developer Productivity Engineering

https://www.forbes.com/sites/forbestechcouncil/2022/12/08/an-it-executive-introduction-to-developer-productivity-engineering/?sh=6a8e06b472ab

開発者生産性エンジニアリング（DPE）は、開発者の生産性と開発者エクスペリエンスを向上させることに焦点を当てた新しいソフトウェア開発手法です。DPEは、生産性は主に「人」の問題であり、管理原則やベストプラクティスによって対処できるという前提で始まる従来の取り組みとは異なるアプローチで、生産性を向上させます。

企業の競争力を左右するのは、ソフトウェア人材を惹きつけ、維持する能力であることがますます増えています。そのためには、開発者がより多くの時間を革新と創造に費やせるように、労力とフラストレーションを生むビルドプロセスのボトルネックを取り除くツールを使用することがしばしば必要となります。
優れた開発者エクスペリエンスを提供することが競争上不可欠であることも含まれます。

DPEは、長いフィードバックサイクルや非効率的なトラブルシューティングに関連する非生産的な待ち時間を削減することで、確実な節約を実現することを目的としています。
ビルド時間を数分短縮するだけで、節約になることが分かっています。

Developer Productivity Engineering – The Next Big Thing in Software Development by Amanda Martin

https://www.youtube.com/watch?v=4b91Ex4A4SU

  • 開発者にフォーカスして、ペインを取り除き幸福にする。例えば、開発に関わるツール群を改善することでコンテキストスイッチを減らし、集中できる状態を維持する。
    • ビルド時間を減らす(ビルドキャッシュの活用)
    • マージ時のコンフリクトを減らす
    • 自動テストの設計を見直す(並列化やフレイキーテストへの対応)
    • CI/CDでのエラー原因がすぐにわかるようにする
  • 上記を監視(観測)できる環境整備
  • 他にも開発者体験向上につながる施策は身近にある

5 Challenges Every Engineering Manager Must Overcome

https://www.hatica.io/blog/engineering-manager-challenges/?utm_source=twitter&utm_medium=social&utm_campaign=content+distribution

  • EMの立場から「DPEとDXを向上させるためには」という紹介記事。
    生産性可視化製品への導線記事ですが、重要なポイントと概要が大まかに整理されている。
とりいとりい

What is developer productivity and how to measure it?

https://axolo.co/blog/p/developer-productivity

What is the SPACE framework?
SPACEフレームワークは、開発者の生産性だけでなく、開発者を取り巻く環境を迅速に評価するためのいくつかのデータポイントを定義しようとするものです。開発者の生産性を様々な側面から捉え、生産性がアクティビティの量やツール、個人のパフォーマンスによって測られるという考え方などの誤りを否定するために作られたと著者らは述べている。

https://axolo.co/blog/_next/image?url=%2Fblog%2Fstatic%2Fimages%2Fproductivity%2Fspace_framework.png&w=1920&q=75

Statisfaction and well-being among developers
仕事、チーム、ツール、文化にどれだけ満足しているかを意味し、幸福度とは、どれだけ幸せで健康か、また、仕事が健康や幸福にどのような影響を与えるかを意味します。
生産性を理解し、予測するためには、満足度と幸福度を測定することが有効です。例えば、生産性と満足度は連動しているため、満足度が生産性の先行指標として機能する可能性があります。

(Software developer) Performance
ソフトウェアは複数の開発者の貢献の総和であることが多く、特定の開発者の効果を測定することはさらに困難です。ソフトウェアは、ほとんどの企業や組織で、個人ではなくチームによって書かれています。その結果、パフォーマンスはアウトプットではなく、成果(outcomes)で測られることが多い。例えば

  • Impact: Customer satisfaction, adoption and retention, feature usage, and cost reduction are all factors to consider.
  • Quality: Reliability, the absence of bugs, and the overall health of the service.

Activity
以下は、一般に測定および定量化が容易な開発者活動の一部である。

  • Design and coding: The number of design papers and specs, work items, pull requests, commits, and code reviews, as well as their volume or count.
  • Operational activity: Count or distribute the number of incidents/issues based on severity, on-call involvement, and incident mitigation.
  • Continuous integration and deployment: Build, test, deployment/release, and infrastructure utilization are all counted.

個人またはチームの生産性に関する選択を行うために単独で使用するべきではありません。これらの指標は、企業の要求や開発環境に応じて適応させるべきであり、あくまでも出発点として利用するものです。

Communication and collaboration
チームメンバーの活動やタスクの優先順位を高い透明性で認識することは、互いの仕事にうまく貢献し、統合する効果的なチームにとって不可欠です。コミュニケーション、コラボレーション、コーディネーションを定量化するためのプロキシとして利用できる尺度の例として、次のようなものを考えてみましょう。

  • The speed with which work is assimilated.
  • Network measurements that reveal who and how people are connected.
  • Discoverability of documentation and expertise.
  • Quality of reviews of work contributed by team members.
  • Time spent onboarding new members and their prior experience.

Efficiency and flow
個人またはシステムの一部として、中断や遅延を最小限に抑えて仕事を終わらせる、または進行させる能力を指します。
例えば、集中的に時間を遮断するなどの境界線を設定することは、個人の効率性（フロー）にとって重要である。個人の生産性は、中断のない集中時間や、価値を生み出すアプリの使用時間で評価されることが多い。

The SPACE of Developer Productivity

https://queue.acm.org/detail.cfm?id=3454124

とりいとりい

Enabling and Measuring Developer Productivity at Ambassador Labs

https://www.getambassador.io/kubernetes-expert-interviews/measure-developer-productivity

  • Ambassador Labsでの事例紹介

The SPACE of Developer Productivity: There’s more to it than you think

https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/

SPACE framework: 5 dimensions to measure developer productivity

https://blog.codacy.com/space-framework/

  • codacy pulseの宣伝も兼ねたSPACEの簡単な説明

Your organization’s guide to the SPACE framework

https://www.swarmia.com/blog/space-framework/

  • 「Best practices for using the SPACE framework」以降の記載が具体的な導入に向けたもので参考になりそう

4 strategies for optimizing productivity for technical and operational teams

https://mattermost.com/blog/4-strategies-for-optimizing-technical-productivity/

経済が不安定な時期には、賢明な企業は生産性と投資収益率（ROI）を最適化する方法を探します。生産性の向上とは、より少ない人員でより多くの仕事をこなし、人員を増やさずに新たなイノベーションを実現することです。ROI の向上とは、大規模な設備投資を行わずに、既存のリソースを最大限に活用することです。

これらの目標を達成するための効果的な方法のひとつは、チームのコラボレーションを向上させることであり、特に技術スタッフと業務スタッフのコラボレーションが重要です。

生産性の向上とエンゲージメントの向上は、ROIをさらに高める好循環を生み出します。ギャラップ社によると、エンゲージメントの高い社員は生産性が14%高く、会社に留まる可能性が18%高いと言われています。エンゲージメントは生産性を向上させ、生産性はエンゲージメントを強化するのです。

とりいとりい

Platform Engineering

https://techblog.ap-com.co.jp/entry/2023/01/18/170829

Dynamic Logging

The paradox of debugging with static logs: Get dynamic or go home

https://techbeacon.com/app-dev-testing/paradox-debugging-static-logs-get-dynamic-or-go-home
従来のロギングの問題点から動的ロギングの解説まで記載されている

従来型

何をログに残すかわかっていれば、すでにバグは解決しているのです。

Dynamic logs

This capability is provided by an agent that is installed alongside your application. The agent communicates with a server that tells it which logs to add and where to add them.

The agent then adds the required code using byte-code instrumentation. When your application executes that code, the corresponding log entry is sent back to the server that can either display it to a client application or pipe it to another tool such as an advanced log analyzer.

とりいとりい

Swarmia

https://www.swarmia.com/

  • GitHub, Jiraと簡単に連携できて便利
  • チームで守りたい基準を”Working Agreements”という形で定義できる。仮にSlackと連携したら、デイリーレポートやアラート通知も行える。
    • 例: バックログの完了期間、PRの同時Open数、PRのレビュー着手までの空き時間、etc...
  • Insightsで定量的なActivityを連携したGitHubリポジトリから収集して勝手に可視化してくれる
  • Work Logでチームの活動量が色々と見える。リポジトリごとや、人、Jiraのissue単位とか、レーンを簡単に分けられる
  • Pull Requests画面ではダッシュボードを含めたざっくりとしたサマリーが確認できる
    • In Progress: PR をオープンしてから、あるいは最初のコミット (どちらか早い方) から、最初のレビュー要求あるいは PR マージ (何もない場合) までの平均時間
    • Cycle time := Work In Progress + Review + Merge;
      1回目のコミットからレビュー依頼まで、またはプルリクエストがオープンされてからレビュー依頼までのうち、どちらか早い方～マージされるまでの時間
  • ここから得られたデータやインサイトをどう活用していくか、そこに尽きる。
    SPACEを強調しているわりには定性的な部分に対する機能が薄いので、そこは別途考える必要がある。(そちらはNotion側でなんとかするべきか…)
  • より効率的かつ意味のある集計を行うため、GitHubやJiraの運用は見直すべき。
    例：GitHub: ラベルの活用によるissue, PRのカテゴライズ。 Jira: Epicの終了日と完了ステータスの活用。

The ultimate guide to developer experience

https://www.swarmia.com/blog/developer-experience-what-why-how/

  • DX(開発者体験)についてWhat, Why, Howがきれいにまとまっている
とりいとりい

ELTV (employee lifetime Value)

https://note.com/haruki_m/n/nc68ec98843d5

オンボーディング期間を短縮し、早期にアウトプットが出せる状態になりパフォーマンスを向上させ続けることで理論的にはELTV、つまり一般的に従業員が稼ぎ出す生涯価値は大きくなる

記事で登場する図など、なんとなく頭でわかっていたことが上手く可視化されていて参考になる。

とりいとりい

Inside Look: Measuring Developer Productivity and Happiness at LinkedIn

https://engineering.linkedin.com/blog/2023/inside-look--measuring-developer-productivity-and-happiness-at-l

To solve this problem we developed a new internal product called the Developer Insights Hub (iHub). It visualizes developer experience and happiness metrics describing key developer activities such code building, reviewing, publishing, as well as the sentiment towards the tools being used. Our product provides engineering leaders with a comprehensive view of the team's work, allowing them to identify areas for improvement and make more informed decisions about how to optimize their developers' productivity.

We called it the Developer Experience Index (EI) and it became a critical element of our product design. To compute an overall experience index for a team we average the values for each of the metrics. We found that a simple average of the experience indexes best matched what developers on the team were actually experiencing, based on development sentiment gathered via our developer productivity surveys.

とりいとりい

DevEx: What Actually Drives Productivity

https://queue.acm.org/detail.cfm?id=3595878

開発者体験と開発生産性についての論文

Taken together, feedback loops, cognitive load, and flow state encapsulate the full range of friction types encountered by developers. Although DevEx is complex and nuanced, teams and organizations can take steps toward improvement by focusing on these three key areas.

フィードバックループ、認知負荷、フロー状態といった観点に加えて、レイヤーごとにどういった指標が考えられるか、それらの測定方法についても言及がある

とりいとりい

What McKinsey got wrong about developer productivity

https://leaddev.com/process/what-mckinsey-got-wrong-about-developer-productivity

“Most importantly, how to develop the intuition throughout the engineering organization. Data is fantastic, but you need humans who can use the data to make good quality decisions.”

「最も重要なのは、エンジニアリング組織全体でいかに直観力を養うかということだ。データは素晴らしいものだが、そのデータを使って質の高い意思決定ができる人間が必要だ。"

マッキンゼーのフレームワークに対する反対意見を紹介しつつ、最近の開発生産性トレンドを上手く解説している印象。
引用した部分が特に深く感じた。チームとして直感力を養うこと、それに寄与できる個人を評価するのは定量目線でも、場合によっては定性目線でも見落としそうな部分なため。