Money Forward Developers Blog

株式会社マネーフォワード公式開発者向けブログです。技術や開発手法、イベント登壇などを発信します。サービスに関するご質問は、各サービス窓口までご連絡ください。

20230215130734

令和最新版 開発生産性指標のトレンド

この記事は、Money Forward Engineers Advent Calendar 2024の12月20日の記事です。12月19日はちーずさんで「React Flowで叶える柔軟なフローチャートの実装方法」でした。

CTO室の高井といいます。

みなさん、開発生産性を高めていますか？　はたして「推測するな、計測せよ」という言葉がこの文脈で適用できるのかはさておき、開発生産性の測定は大きなトピックです。当社では、ソフトウェア生産性の可視化のために Four Keys を採用していたり、開発者体験サーベイ を行ったりしてきました。それでもまだ、開発生産性をどのように捉え、測定するのか悩んでいます。

本記事では、現代的な開発生産性指標を理解するために、 Four Keys からはじまるエンジニアリングの生産性に関わる指標について、ざっと再確認をしていきたいとおもいます。なお、海外では Four Keys のことを DORA メトリクス と呼ぶことが一般的になってきているようですので、以降ではそのように表記します。

DORA メトリクス

DORA メトリクス は、Nicole Forsgren 博士を中心に開発されたフレームワークです。このフレームワークは、書籍『LeanとDevOpsの科学［Accelerate］』（原題：Accelerate）によって広く知られるようになりました。この書籍は、リーンソフトウェア開発と DevOps の実践が、組織のパフォーマンス向上にどのように寄与するかを、大規模な調査研究に基づいて科学的に分析したものです。

Accelerate では、ソフトウェアデリバリのパフォーマンスを定義し、それを向上させるための主要なケイパビリティが特定されています。このソフトウェアデリバリのパフォーマンスを測定する指標が、DORA メトリクス です。この名称は、Nicole Forsgren 博士が設立した DevOps Research and Assessment (DORA) に由来しています。

DORA メトリクス は、以下の四つの指標で構成されています：

  1. デプロイ頻度（Deploy Frequency） ソフトウェアを本番環境にデプロイする頻度を示します。
  2. 変更の平均リードタイム（Lead Time for Changes） コード変更がリポジトリにコミットされてから、本番環境にリリースされるまでの平均時間を測定します。
  3. 変更の失敗率（Change Failure Rate） 本番環境にデプロイされた変更のうち、障害や不具合を引き起こした変更の割合を示します。
  4. サービス復旧時間（Time to Restore Service） 障害やインシデント発生後、サービスを復旧させるまでにかかる平均時間を測定します。

DORA メトリクスの利点は、研究調査に基づく科学的な裏付けがある点です。この指標を活用することで、開発チームのパフォーマンスを明確に把握し、改善活動につなげることが可能になります。さらに、DORA メトリクス を測定するためのツールセットも提供されています。 DORA メトリクスでは、測定結果の評価基準が明示されているため、結果に基づいた具体的な改善活動を進めやすいという特徴があります。

DORA メトリクスが、広く受け入れられた背景には、 DevOps のプラクティスが組織のパフォーマンス向上に役立つということを証明したことにあります。システムメトリクスを計測することで、チームや組織の状態を明らかにできるという発見は、多くの組織によって歓迎されました。

SPACE

SPACE は、開発者の生産性を多面的に評価するために DORA メトリクスの考案者である Nicole Forsgren 博士によって提案された開発生産性指標のフレームワークです。このフレームワークの詳細は、「The SPACE of Developer Productivity」という論文にまとめられています。この論文は、Nicole Forsgren 博士が GitHub に所属していたときに執筆され、大学やマイクロソフトリサーチの研究者との共同研究の成果です。

従来のエンジニアリングの生産性は「コミット数」や「コード行数」といった単一の活動量に依存して評価されることが一般的でした。しかし、これらの指標は生産性のごく一側面しか捉えておらず、開発全体の生産性を正確に評価するための基準としては不十分です。たとえば、エンジニアあたりのコード行数が多い場合、そのチームが高い生産性を持つように見えることがあります。しかし、そのコードの品質が低かったり、冗長な実装であったりした場合、むしろプロダクト全体の価値を損なう可能性があります。

SPACE フレームワークは、従来の生産性指標が抱える課題を解決するための新たなアプローチを提供します。このフレームワークは、複数のカテゴリから指標を選び、バランスよく評価することを提案しています。このフレームワークは以下の五つのカテゴリーで構成されており、それぞれの頭文字が「 SPACE 」の由来です。

  1. Satisfaction and Well-being（満足度と幸福感）
  2. Performance（成果）
  3. Activity（活動量）
  4. Communication and Collaboration（コミュニケーションと協力）
  5. Efficiency and Flow（効率性とフロー）

また、指標を複数の次元から取得することの重要性も強調されています。次元とは以下の三つを指します。

  1. 個人（開発者一人ひとりのパフォーマンスや体験）
  2. チームもしくはグループ（チーム全体の協力や成果）
  3. システム（全体のプロセス、例としてコードの作成からデプロイまで）

SPACE の考え方は、この五つのカテゴリと三つの次元を組み合わせた枠組みから適切な指標を選択し、開発者生産性を総合的に評価する指標を構築するというものです。このとき、システムメトリクスだけでなく、認知的な側面を取り入れることが推奨されています。この点が SPACE の興味深い特徴と言えます。

SPACE を導入することで、開発者生産性に関する包括的な指標を作成し、より深い洞察を得ることが可能になります。しかし、SPACEはあくまでフレームワークであり、「そのまま箱から出して利用できるツール」ではありません。具体的な指標の選定や運用方法は、各組織やチームの状況に合わせて設計しなければなりません。

オンラインで SPACE について解説をしている記事はたくさん見つかるものの、それを具体的に適用し、運用しているという事例はほとんど見つかりません。

DevEX

開発者の認知的な側面にフォーカスを当てた研究として、Abi Noda 氏の論文「DevEx: What Actually Drives Productivity」があります。彼は、ソフトウェアエンジニアであり起業家です。彼が立ち上げた企業であるPull Panda は GitHub に買収されています（なお、Pull Panda の機能は現在、 code review assignment 機能として GitHub に統合されています）。また、この論文の共著者には Nicole Forsgren 博士も名を連ねています。

この論文の主なポイントは、開発者体験（DevEx）を理解するための実践的なフレームワークを提供していることです。 SPACE でも開発者の認知的な側面について注目されていました。この研究は、その認知的側面に一歩踏み込み、開発者体験として定義付けたというのがポイントです。

DevEx は、開発者からのフィードバックと、彼らが使用するエンジニアリングシステムに関するデータを組み合わせた測定手法を提示しています。特に、開発者の日常業務における具体的な経験やコンフリクトに焦点を当てており、システムメトリクスだけでは把握しきれない開発者体験を明らかにすることが特徴です。

論文では、開発者体験を構成する三つの要素として以下を挙げています。

  1. フィードバックループ
  2. 認知的負荷
  3. フロー状態

これらを測定するためには、それぞれについて認知（perceptions）とワークフローの両側面を考慮した指標を設計する枠組みが提案されています。

DevEx は、メトリクスのためのフレームワークであるという意味で SPACE に似ていますが、より具体的に開発者体験に焦点を当てているため、実際の指標を設計しやすいというメリットがあります。マネーフォワードの開発者体験サーベイは、この論文を基に設計していました。

さらに、 Nicole Forsgren 博士が主著を務めた関連論文「DevEx in Action」も注目に値します。この論文は、ワークデザイン理論を応用し、開発者体験の三つの要素を改善することが、開発者の生産性、学習、創造性の向上につながることを示しています。これにより、チームのコード品質や技術的負債の削減、さらには組織全体の収益性や目標達成能力の向上が期待できることが論じられています。

DX Core 4

DX Core 4 は、 DORA 、 SPACE 、 DevEx フレームワークの要素を統合し、開発者の生産性を測定するために設計された統一フレームワークです。このフレームワークは、Abi Noda 氏が新たに立ち上げた企業 DX によって提唱されています。

SPACE フレームワークは、包括的な開発者生産性の指標を提供するものでしたが、実際には各組織が独自の具体的な指標を設計する必要があるという課題がありました。一方、DX Core 4 は、これまでの先行研究に基づいて設計されており、 SPACE フレームワークの具体例として捉えることもできます。さらに、ビジネス目標との結びつきを強調し、指標を簡潔かつ戦略的に絞っているというのが実務でも利用しやすい点です。

DX Core 4 は以下の四つの要素で構成されています。

  1. スピード（Speed）: エンジニア1人あたりのコード差分数（PRs または MRs）
  2. 効果（Effectiveness）: 開発者体験指数（DXI）
  3. 品質（Quality）: 変更失敗率（Change failure rate）
  4. ビジネスへの影響（Business Impact）: 新機能開発に費やした時間の割合

この指標の特徴は、多次元的な指標となっているので、各要素がトレードオフの関係にある点です。たとえば、スピードと品質、新規機能開発の割合と開発者体験といった要素には緊張関係があるため、どれか一つの数値を都合よく操作することが難しく設計されています。

ただし、開発者体験指数（DXI）に関しては注意が必要です。この指標は、DX 社が提供するサービスを通じて計算されるものであり、そのまま採用することはできません。しかし、この指標は開発者体験サーベイやパルスサーベイの結果で代替することが可能です。

さらに、DX Core 4 を採用する大きなメリットの一つとして、業界のベンチマークを利用できる点があります。私たちのパフォーマンスが業界平均と比較して優れているのか劣っているのかを具体的に把握することができます。これにより、現状を正確に評価し、適切な目標を設定するための参考情報が得られます。

まとめ

この記事では、エンジニアリング生産性を測定する主要な指標として、 DORA メトリクス、 SPACE 、 DevEx 、そして DX Core 4 を紹介しました。これらの指標を一連の流れとして見ると、それぞれが独立しているわけではなく、進化の過程として位置づけられることが分かります。

DORA メトリクスは、ソフトウェアデリバリパフォーマンスの向上に焦点を当て、科学的な裏付けのある指標を提供しました。このフレームワークは、主にデリバリーのパフォーマンスを定量的に評価するもので、現代的な開発生産性の指標の基礎を築きました。

SPACE フレームワークは、開発者生産性にフォーカスするためのアプローチを提案しています。開発者生産性を個人、チーム、組織という多元的に捉えることで、包括的に評価可能なフレームワークを構築しました。システムメトリクスばかりではなく、認知的な側面も重視しているのが特徴です。

DevEx は、その認知的な側面を開発者体験として定量的に測定するための枠組みを提供しています。これにより、開発者の日常業務の実体験やコンフリクトを可視化し、組織改善の具体的な手がかりを得られるようになりました。

最後に、DX Core 4 は、SPACE や DevEx が指標のためのフレームワークであるのに対し、より具体的で導入しやすい指標として設計されています。DX Core 4 は、スピード、効果、品質、ビジネスへの影響という四つの要素で構成されており、具体的に採用するべき指標が示されています。

本記事が、それぞれのメトリクスについて理解し、みなさんの職場で活用するための参考となれば幸いです。