The Pragmatic Engineer Newsletterの著者であるGergely Orosz氏は最近、Measuring Developer Productivityという記事を発表した。DXのCEOであり、DevExフレームワークの共同開発者であるAbi Noda氏との共著である。この記事では、Noda氏が有名ハイテク企業の幅広い分野で使用されているエンジニアリング・メトリクスを調査した結果を分析している。Noda氏は、DORA やSPACEメトリクスを全面的に採用するのではなく、使用されている指標には多くのコンテキスト固有の定性的・定量的メトリクスが含まれていることを発見した。Noda氏とOrosz氏は、イネーブルメントチームが求める成果から逆算して、そのようなメトリクスを定義するためのガイダンスを提供した。
Noda氏は、「17の有名ハイテク企業で開発者の生産性測定を担当するチームにインタビューした」と書いている。この記事では、Noda氏とOrosz氏は4つの組織規模に焦点を当て、10万人規模のGoogle、1万人規模のLinkedIn、1万人未満のPeloton、そして1000人未満のNotionやPostmanのようなスケールアップ企業を選んだ。使用された指標は、典型的なPRやCIの指標から、Google社における方法論的に選択された指標まで多岐にわたる。
Noda氏は、実際には「DORAとSPACEのメトリクスは、全面的に採用されているのではなく、選択的に使用されている」と見ている。Noda氏は、今回の調査で「どの企業もそれぞれに合わせたアプローチを持っている」ことが明らかになったが、「どのような規模（組織）であっても、Google社の全体的なフィロソフィとアプローチを採用できる」と考えを述べた。Noda氏は、Google社のアプローチは、「スピード、容易さ、品質 」に関する3つの測定クラスに基づいて指標を選択することを記述した。彼は、これら3つの次元の間には 「緊張関係 」が存在し、「潜在的なトレードオフを表面化させるのに役立つ 」と記述している。
Noda氏は、Google社の測定は、「定性的および定量的な測定 」を使って指標を計算することで、「可能な限り全体像を把握する 」ことができると書いている。Noda氏は、満足度調査から 「ログを使った測定 」まで、Google社が使用しているさまざまな情報収集アプローチを挙げている。同氏はこう記述している。
ツール、プロセス、チームのいずれを測定するにしても、Google社のデベロッパー・インテリジェンス・チームは、 単一の指標で生産性を把握することはできないという信念を支持している。その代わりに、スピード、容易さ、品質という3つの側面から生産性を見ている。
同様に、Noda氏とOrosz氏は、LinkedInが四半期ごとの開発者満足度調査と定量的な評価指標をどのように組み合わせて使っているかを説明した。Noda氏は、LinkedInのDeveloper Insightsチームが、「主要な開発者の活動から生じるコンフリクト」を減らすというミッションを推進するために使用しているさまざまな指標に記述している。このチームが使用している指標には、CIの安定性指標、デプロイの成功率、ビルド時間のP50やP90、コードレビューのレスポンスタイム、CIパイプラインを通るコミット時間などがある。Noda氏は、ビルド時間を 「開発者がビルドにどれだけ満足しているか 」と比較する例を用いて、チームがこのような定量的メトリクスを定性的な洞察で補強する方法を説明した。LinkedInでは、客観的な数値メトリクスも「winsorized mean」を使ってノイズ除去している。
つまり、99パーセンタイルを割り出し、99パーセンタイル以上のデータポイントをすべて捨てるのではなく、切り取るのだ。つまり、99パーセンタイルが100秒で、110秒のデータポイントがあった場合、110を消して100と書く。
Noda氏は、3000~4000人規模の組織を代表するPeloton社では、当初は「開発者体験調査による定性的な洞察」を収集していたが、定量的な指標も取り入れるように進化したと記述している。例えば、スピードを測定するために、リードタイムやデプロイ頻度といった客観的なプロキシが使われている。彼は、Pelotonのメトリクスには、定性的なエンゲージメントスコア、サービス復旧までの時間、「250行未満のPR、ラインカバレッジ、変更失敗率」の割合で測定されるコード品質も含まれていると書いた。
NotionやPostmanのような小規模な 「スケールアップ 」組織について、Noda氏は、これらの組織はしばしば 「可動メトリクス 」の測定に焦点を当てていると記述した。Noda氏は、このメトリクスは、イネーブルメント・チームが 「自分たちの仕事によってポジティブまたはネガティブな影響を与えるかによって動かすことができる 」繊細なメトリクスであると説明した。その例が 「デリバリーのしやすさ 」だ。Noda氏は、この指標は「認知的負荷とフィードバックループ」を反映し、「開発者が自分の仕事をするのが簡単か難しいか」を把握できるため、動かすことができると書いている。もうひとつのよくある移動可能な指標は、「障害物やコンフリクトのせいで失われた開発者の時間の割合」である。Noda氏は、このようなメトリクスの力について、その価値を伝える側面から記述している。
この指標はドルに換算できる！これは大きなメリットだ！これにより、ビジネスリーダーはタイムロスを理解しやすくなる。例えば、エンジニアの人件費が1,000万ドルある組織が、ある取り組みによってタイムロスを20％から10％に削減した場合、それは100万ドルの節約につながる。
このようなエンジニアリング・メトリクスの文脈的性質を考慮し、Noda氏は、ゲージの定義を目指す組織に対して4つのステップを推奨している。
- ミッション・ステートメントで目標を定義し、「なぜ開発プロダクツチームが存在するのか？」を説明する
- 目標から逆算して、スピード、容易さ、品質に基づいた「トップレベルのメトリクス」を定義する
- 具体的なプロジェクトや客観的な主要成果（例えば、特定の開発者の生産性を向上させるサービスの採用率など）に結びついた「運用指標」を定義する
Noda氏は例を挙げながら、選択するメトリクスは「スピード、容易さ、品質」の次元を念頭に置いて作成するべきだと指摘した。Noda氏は、開発者が容易にしたいと定める目標が「高品質のソフトウェアを提供する」であった場合、結果として得られるメトリクスには、「デリバリの速さの認知」、「デリバリのしやすさ」、「インシデント発生頻度」が含まれることを例示して説明した。
Orosz氏とNoda氏の記事は、「Kent Beck氏との共同執筆である、Measuring developer productivity? A response to McKinsey（開発者の生産性を測ることとは：Mckinsey社に向けて）」の補足内容として書かれたものである。これは、 Mckinsey社の「Yes, you can measure software developer productivity（ソフトウェア開発者の生産性は測定できる）」に異議を唱え、検証したものである。 Mckinsey社の記事では、「製品の提供方法を改善するために何ができるか、そしてその改善にはどのような価値があるのかを特定するため」に、「機会に焦点を当てた」メトリクスと呼ばれるものを提案している。この記事には、DORAとSPACEの「上に」重ねる開発者の生産性メトリクスについての議論も含まれている。 Mckinsey社の記事には、個々の開発者のパフォーマンスの効率を最適化するようリーダーに奨励する提言が含まれている。例えば、「デザインセッションのようなノンコーディング活動」である。提案されている測定基準には、「個人による貢献」の追跡や、「タレント・ケイパビリティ・スコア」の測定などがある。
Beck氏は、提供された成果ではなく、個人の生産性を測定することに伴う危険性を警告し、このような測定基準が「（金銭と地位によって）測定基準を変更するインセンティブを与える」ために使用されているのを見た経験を語った。彼は、これが「行動変容」をもたらす可能性がある一方で、ゲーミフィケーションの対象にもなり、「測定値を改善する創造的な方法」を奨励することにもなると話した。Beck氏とOrosz氏は、その代わりに「努力」ではなく「影響」の測定に焦点を当てるようリーダーに勧めた。Beck氏は特に、このような測定基準は、測定対象者の継続的な改善フィードバックループ以上のことに使うべきではないと提言した。彼はまた、個人を測定するメトリクスの誤用によって引き起こされる安全性の問題に警告を発した。
なぜ質問するのか、測定される人や人々とどのような力関係があるのかを明確にすること。権力を持つ人が権力を持たない人を測定する場合、歪みが生じることになる......データを収集するのと同じレベルでデータを分析することで、負のインセンティブを避けられる。私が分析できるのは自分のデータであり、私のチームが分析できるのはそのチーム固有の集計データであるということだ。
Noda氏はまた、CTO、VPE、エンジニアリング・ディレクターのレベルでは、開発者のパフォーマンス指標を求められた場合、適切なレベルで報告するようにした方が良いと警告した。Noda氏はこれを行うには、「ビジネスインパクト」、「システムパフォーマンス」、「エンジニアリング組織」レベルの「開発者の有効性」を代表するメトリクスを選択することを推奨している。例としては、プロジェクトレベルのメトリクス、「ユーザーNPS」、摩擦に対する「週間タイムロス」などが挙げられる。Nodaはシニアリーダーにこうアドバイスした。
この場合、私の最善のアドバイスは、問題を捉え直すことだ。リーダーシップ・チームが求めているのは、完璧な生産性指標を見つけ出すことではなく、エンジニアリングへの投資を適切に管理しているという自信を持つ ことだ。
Mckinsey社の報告書に対する回答の中で、Orosz氏とBeck氏は、グッドハートの法則（"尺度が目標になったとき、それは良い尺度でなくなる"）を引用した痛烈なミームを共有した。