1.10 エンジニアリングの有効性と開発者の生産性

概要と動機

大規模なソフトウェア組織のリーダーは、いずれ同じ問いの変奏にたどり着きます。私たちはソフトウェアを作るのが上手になっているか、そしてそれをどうやって知るのか。本章は、それに正直に答えることを扱います。エンジニアリングの有効性とは、組織がエンジニアリングの労力を、価値があり信頼できるソフトウェアにどれだけうまく変えられるかです。開発者の生産性とは、その個人とチームの側面です。開発者がどれだけ有用な成果を出せるか、そして作業環境が開発者の時間と注意を、奪うのではなくどれだけ返してくれるか。

問題は、誰かがこれを単一の数字に還元しようとした瞬間に始まります。コードの行数を数えれば、人はより多くのコードを書きます。ストーリーポイントを数えれば、見積りは膨らみます。コミット、プルリクエスト、机にいた時間を数えれば、進捗ではなく動きに報いることになります。知識労働者の生産性は、部品の個数ではありません。一万行のデッドコードを削除した開発者や、同僚が本番障害を避けられるよう一日をペアリングに費やした開発者は、素朴な指標では捉えられない優れた仕事をしています。「私たちはどれだけ生産的か」への正直な答えは多次元であり、仕事に対する開発者の体験を、柔らかいシグナルではなく本物のシグナルとして扱います。

これは規模が大きくなるほど、より重要になります。数十のチームを持つ企業では、小さな摩擦(遅いビルド、不安定なテストスイート、環境を二日待つこと)が、何百人ものエンジニアにわたって掛け算され、莫大な失われた能力になります。成果に市場価格のない政府では、リスクは「成果の芝居」です。作成された文書や閉じられたチケットを測りながら、公共の価値が測られないままになります。本章の目標は、操作、監視、人どうしのランク付けなしに、エンジニアリング組織の有効性と、開発者の日々の体験を測定し改善することを助けることです。

主要原則

生産性は多次元です。 単一の数字では捉えられません。その指標として提示される指標は、どれも間違っています。
人をランク付けするためではなく、摩擦を取り除くために測ります。 測定の対象は個人ではなくシステムです。
三角測量します。 開発者が仕事をどう感じるかと、システムが実際に記録していることを組み合わせます。
開発者の体験はデータです。 フィードバックループ、認知負荷、フローは、測定可能で、改善する価値があります。
あらゆる指標は操作されると想定します。 複数の次元と誠実な意図で、グッドハートの法則に対抗して設計します。
成果に慎重に結びつけます。 有効性はビジネス価値に連なるべきですが、腐敗させる目標になってはいけません。

推奨事項

単一指標の罠を拒む

最初の規律は、一つの数字を生産性と名指しするのを拒むことです。コードの行数、コミット数、ストーリーポイントのベロシティ、記録された時間は、すべて致命的な欠陥を共有しています。活動を測っていて価値を測っておらず、活動は簡単に膨らませられます。これはグッドハートの法則の実例で、ある指標が目標になった途端、それは良い指標ではなくなるという原則です。ベロシティは、チーム自身の予測のための補助として発明されました。マネージャーがあるチームのポイントを別のチームのものと比べた瞬間、チームは見積りの尺度を静かに調整し直し、その数字は無意味になります。誰かが単一の生産性KPIを要求したら、それを満たすべき要求ではなく、作り直すべき要求として扱ってください。代わりに、小さなバランスの取れた集合を提示し、なぜ一つの数字が彼らを誤導するのかを説明します。

SPACEで測るものを構造化する

SPACEフレームワークは、一緒に保持する価値のある五つの次元を与えます。Satisfaction and well-being(満足とウェルビーイング)、Performance(パフォーマンス)、Activity(活動)、Communication and collaboration(コミュニケーションと協働)、Efficiency and flow(効率とフロー)です。SPACEの要点は、少なくともいくつかの次元を選ぶべきで、一つだけにせず、すべてを同じカテゴリから選ぶこともしない、ということです。活動の指標(コミット、デプロイ)は集めやすいので魅力的ですが、それだけでは歪みます。満足のシグナルとパフォーマンスのシグナルと組み合わせれば、他が暴露することなしには、どの次元も操作できません。デプロイが増える一方で満足度が急落し、変更失敗率が上昇しているチームは、より生産的ではなく、バランスの取れた集合はそれをすぐに示します。

開発者体験を、フィードバックループ、認知負荷、フローとして扱う

開発者体験(DevEx)とは、ここでエンジニアリングの仕事をするのがどんな感じかであり、聞こえるよりも具体的です。測定でき、改善できる三つのものに基づいています。フィードバックループは、開発者が何かがうまくいったかを知るまでに待つ時間です。ローカルのビルド時間、テストスイートの所要時間、コードレビューの折り返し、デプロイ時間。遅いループは、コンテキストの切り替えと待ちぼうけを強います。認知負荷は、タスクが要求する精神的な労力の総量で、単純な変更をするために、開発者があまりに多くのツール、文書化されていないシステム、絡まった依存関係をやりくりしなければならないとき、増大します。フローは、焦点を絞った生産的な没入の状態で、細切れのカレンダーと絶え間ない中断が壊します。フィードバックループを短くし、開発者が頭に保たなければならなかった概念を一つ取り除き、集中できる時間のブロックを守れば、活動の数が決して記録しない形で生産性を改善したことになります。これは、プラットフォームエンジニアリングが整備された道とセルフサービス(8.4章)によって応える、同じDevExの関心事です。

知覚をシステムの指標と三角測量する

単一のデータ源だけでは信頼できないので、二種類を組み合わせます。知覚データは、開発者体験サーベイを通じた開発者自身からのものです。出荷にどれだけ自信を感じるか、どこで時間を失うか、何に苛立つかを尋ねる、定期的で大半は匿名のアンケートです。システムデータはツールから来ます。パイプラインのタイミング、レビューの遅延、インシデントの頻度。それぞれが他方を補正します。サーベイは、士気を下げるオンコールのローテーションや恐れられるレガシーサービスなど、計器が見逃す痛みを捉えます。システムの指標は、人々が当たり前にして報告をやめた問題を捉えます。サーベイがビルドは苦痛だと言い、パイプラインのデータが15分の中央値のビルドを裏付けるとき、優先順位が付いた、説明可能な投資が得られます。サーベイは一定の周期で実施し、短く保ち、それによって何が変わったかを示して、必ずループを閉じてください。

DORAは順位表ではなく、デリバリーのシグナルとして使う

四つのDevOps Research and Assessment(DORA)指標(デプロイ頻度、変更のリードタイム、変更失敗率、サービス復旧時間)は、デリバリー能力についての、研究に裏付けられた強力な読みで、速度と安定性を組み合わせ、どちらも他方のために犠牲にされません。深い議論は11.5章にあり、それらが測るデリバリーパイプラインは11.2章で扱うので、そこで使ってください。ここでのガイダンスは、それらをどう扱うかについてです。DORAを、チームやに個人をランク付けする成績表ではなく、デリバリーシステムが改善しているかを示すチームレベルの健全性のシグナルとして扱います。DORAの数字が誰かの人事評価に現れた途端、チームは頻度を水増しするためにデプロイを分割し、失敗率を守るためにインシデントを隠し始め、シグナルは死にます。

システムを測り、個人を監視しない

これは越えてはならない線です。指標をチームと組織のレベルに集約し、摩擦を見つけて取り除くために使います。コミット、時間、「生産性スコア」で開発者をランク付けするダッシュボードを作ってはならず、個人のテレメトリを報酬や昇進に反映させてもなりません。監視は、効果的なエンジニアリングが依存する心理的安全性と信頼を破壊し、人々に仕事ではなく指標に最適化することを教えます。個人の成長と評価は、キャリアラダーとマネージャーとの対話という、別の人間的な仕組み(1.3章)のものです。有効性の測定は、「私たちのチームを遅くしているものは何か」と問います。「最も遅いエンジニアは誰か」とは決して問いません。

雑務と摩擦に直接対処する

時間がどこで漏れているかを見えるようにできたら、それを取り戻して使います。有効性を制約するものの多くは雑務(トイル)、つまり成長に比例して増え、持続的な価値をもたらさない、手作業で反復的で自動化可能な作業です(9.1章)。遅いレビューも摩擦なので、より小さな変更と明確な期待でコードレビュー(2.5章)を合理化すれば、中核のフィードバックループが短くなります。整備された道とセルフサービスのプラットフォーム(8.4章)は、待ちと認知負荷のカテゴリ全体を一度に取り除きます。また、技術的負債、つまり過去の近道の累積コストで、将来のあらゆる変更に課税されるものに対して予算を組んでください。誰も安全に変更できないコードベースは、生産性の最も深い落とし穴だからです。

トレードオフ: 長所と短所

アプローチ	長所	短所
単一の生産性指標(LOC、ベロシティ、コミット)	安く簡単。リーダーのための一つの数字	すぐに操作される。価値でなく活動を測る。信頼を蝕む
SPACE型のバランスの取れた集合	操作に強い。現実を反映	集めるのに手間がかかる。一つの数字に要約しにくい
DevExサーベイ(知覚)	計器が見逃す実感された痛みを捉える	主観的。誠実さを保つには信頼とフォロースルーが必要
システム指標(DORA、パイプラインのタイミング)	客観的で継続的。集計では偽造しにくい	士気と文脈に盲目。個人に適用すると危険
両方の三角測量	各データ源が他方を補正する。頑健	ツールとサーベイの規律への投資が必要

中心的な緊張は、厳密さと誠実さです。一つの数字は報告しやすく腐敗させやすく、豊かで多次元の全体像は誠実ですが、忙しい経営幹部には伝えにくいものです。小さなバランスの取れた集合(いくつかのSPACEの次元、サーベイ、デリバリーの読みとしてのDORA)を選び、スナップショットではなく傾向を報告し、数字は人を採点するためではなくシステムを改善するために存在すると明示することで解決します。リーダーシップが「一つのグラフ」を求めるとき、いくつかの補完的なシグナルの傾向を示し、それらを偽りの合成値に潰したい誘惑を退けてください。

チームで議論すべき問い

明日リーダーが単一の生産性の数字を要求したら、何を渡しますか。 この問いは、組織が罠を理解しているかを露わにします。正直な答えは、安全な単一の数字はなく、あなたの仕事は、その要求を、操作に強い小さなバランスの取れた集合に作り直すことだ、というものです。すでに報告している指標を持ち込み、それぞれについて、「賢く皮肉なチームは、より良い仕事をせずにこれをどう膨らませるか」と問うてください。答えが簡単なら、その指標は目標になった途端に危険です。代わりに何を提示するか、そして一つの数字がなぜ誤った最適化へ導くかを、リーダーシップにどう説明するかを議論してください。その会話の質が、測定があなたを助けるか腐らせるかを予測します。
あなたの最も遅いフィードバックループは何で、それは毎日いくらのコストになっていますか。 フィードバックループは、生産性が静かに漏れる場所です。15分のビルド、2日のレビュー待ち、あらゆる緑のチェックへの信頼を損なう不安定なテストスイート。開発者体験サーベイとパイプラインの計器から実際の数字を持ち込み、知覚された痛みと測定された遅延が一致するかを見てください。待ち時間に、それに当たる開発者の数と頻度を掛けて一日のコストを見積もれば、投資の論拠はたいてい自ずと立ちます。どのループを最初に短縮し、誰が修正を担うかを決めてください。自分たちの最も遅いループに名前を付けられないチームは、最も重要なものを測り始めてさえいません。
あなたの測定は、どこで監視のように感じられうるリスクがあり、それをどう防ぎますか。 システムを測ることと人を監視することの違いは、信頼と恐れの違いであり、気づかないうちに越えてしまいやすいものです。すべてのダッシュボードとレポートをたどり、個人をランク付けしたり人事評価に反映されたりしうるものがないか問うてください。何が集約されたままで、何が匿名のままで、何が禁止かを明示的に決め、測られるチームにオープンにそう伝えます。監督と監査の圧力が強い企業や政府では、個人まで掘り下げたい誘惑は絶えないので、ガードレールは願望ではなく、明言された原則でなければなりません。開発者が、数字が自分たちに不利に使われていると信じれば、彼らは数字に最適化し、真実は消えます。
最後に開発者に仕事がどう感じられるかを尋ねたとき、それによって何が変わり、彼らはそれを知りましたか。 目に見える行動を生まないサーベイは、開発者に正直に答えるのをやめることを教えます。そのため二度目の沈黙したサーベイは、一度目より少なく、無難な回答しか集まらず、あなたが依拠する計器は、スケールさせるまさにそのときに劣化します。大きな組織では、無駄が積み重なります。何百人もが摩擦を報告するのに時間を使い、報告書が回覧され、何も出荷されません。前回のサーベイの上位三つの発見、それぞれが引き起こした具体的な作業、そして結果を、それを挙げた人々にどう伝えたかを持ち込んでください。最も声の大きい不満に対応するか、最も広く共有された不満に対応するかという相反する引力を比べてください。それらはしばしば別の問題だからです。サーベイの疲れと協議の過負荷がすでに高い企業や政府では、ループを閉じることをガバナンス上のコミットメントとして扱ってください。誰が応答を担当するかを名指しし、何が変わったかを公開し、応答のないサーベイはないよりも悪いと受け入れます。
正直さを罰する順位表を作らずに、どうやってチームを比較しますか。 大きな組織のリーダーは当然、どのチームが栄え、どのチームが行き詰まっているかを知りたがりますが、生のベロシティ、デプロイ頻度、DORAの数字でチームをランク付けすることは、重く規制された決済チームと新規開発のプロトタイプチームが、別々の世界に住んでいることを無視しています。相反する考慮は本物です。困っているチームを見つけ、うまくいっていることを広める必要はありますが、比較が成績表になった瞬間、チームは見積りの尺度を調整し直し、インシデントを隠し、立場を守るためにデプロイを分割します。組織内でチームの文脈がどう異なるかの具体例と、各チームを隣のチームではなく、自分自身の時間経過の軌跡と比べる提案を持ち込んでください。監査と監督の圧力がチーム間のランク付けに強く押す企業や政府では、何を比較してよいか、何をチームごとの傾向としてのみ読むか、そして不公平な比較を拒否する権限を誰に与えるかを、あらかじめ合意してください。
デリバリーの指標を腐敗させる目標にすることなく、有効性を実際の成果にどう結びつけますか。 価値に連ならない有効性は、リーダーシップには自己陶酔に見えますが、リードタイムやデプロイ頻度のようなデリバリーのシグナルが人事評価で目標になった途端、チームはその数字に最適化し、その数字が代理しようとした成果を放棄します。大きな組織では緊張が鋭くなります。経営幹部はエンジニアリングの労力からビジネスの成果への明確な線を望みますが、正直な線は乱雑で遅れを伴うからです。現在の成果指標、それらに結びつけるデリバリーのシグナル、そしてそれぞれが目標になったらどう操作されうるかの明示的な説明を持ち込んでください。リーダーシップが語り直せる単純な物語と、歪みに耐える真実の全体像との間の引力を比べてください。収益という錨のない政府や非市場の社内プラットフォームでは、成果を、生の活動ではなく、サービスの信頼性、修正のサイクルタイム、公共の利益として定義し、数えやすい成果物を好むかもしれない監督機関に対してその選択を擁護する準備をしてください。

セクター別の視点

スタートアップ。 少数のエンジニアと短いランウェイでは、ダッシュボードを完全に省き、最も速く動く二つのものを測ってください。十問の開発者体験サーベイと、基本的なパイプラインのタイミングです。最大の生産性リスクは、遅いか不安定なテストスイートと絶え間ないコンテキストの切り替えなので、最悪のフィードバックループを見つけて短縮し、先へ進みます。運用する人のいない測定プログラムは立ち上げないでください。一度の正直な、一日がどこで漏れているかについての会話は、その後維持しなければならないどんなツールにも勝るからです。

小規模事業者。 測定の専門家はおらず予算も厳しいので、既存のツールがすでに記録しているもの、すでに支払っているシステムのビルド時間、レビューの遅延、インシデント数に頼ってください。サーベイツールは自作ではなく軽量なものを買い、個人の生産性ダッシュボードというベンダーの売り込みには抵抗してください。それはあなたが惜しむ余裕のない信頼を犠牲にします。この取り組み全体を、誰の一日も無駄にする余裕のない小さなチームのために摩擦を取り除くこととして位置づけます。

大企業。 数十のチームにわたって、見返りは大規模に取り戻される能力であり、危険は、中央のダッシュボードが静かに人のランク付けに滑ることです。バランスの取れたプログラム(四半期ごとのDevExサーベイ、いくつかのSPACEの次元、チームごとのデリバリーの傾向として読まれるDORA)を標準化し、個人のテレメトリが決して収集されないよう統治します。各チームを自分自身の軌跡と比較し、データが明らかにする摩擦に対してプラットフォーム投資(8.4章)を正当化し、順位表になるような指標を拒否する権限を持つ責任者を一人置きます。

政府。 成果に市場価格がなく監督の圧力が強いため、成果の芝居(文書や閉じられたチケットを数える)への引力は絶えず、監査のもとで名指しされた個人を監視する引力はさらに強いものです。代わりに、成果とデリバリー能力を測ってください。サービスが修正をどれだけ速く出荷できるか、どれだけ信頼できるか、そしてスタッフと契約者が匿名のサーベイを通じて仕事をどう体験しているか。公務員と契約者を同じシステムレベルの基準で測定し、測定が何のためにあるかを公開し、チームごとのデリバリーの傾向が、どんな個人のスコアよりも公共の価値についてのより正直な読みだと、立法府に論じる準備をしてください。

事例

スタートアップ。 20人のスタートアップは、全員が忙しいのに出荷が遅くなったことに気づきます。生産性ダッシュボードを導入する代わりに、エンジニアリングリードは十問のDevExサーベイを実施し、基本的なパイプラインのタイミングを引き出します。サーベイとデータは一致しました。テストスイートに22分かかり、ランダムに失敗するため、人々は変更をまとめて待つ間にコンテキストを切り替えています。チームは二週間をかけて不安定なテストを直し、スイートを並列化して4分に縮めます。デプロイ頻度は自然に上がり、次のサーベイで満足度は跳ね上がり、そのために誰もランク付けも採点もされませんでした。

大企業。 40のエンジニアリングチームを持つ銀行が、社内プラットフォームへの継続的な投資を正当化したいと考えています。プラットフォームグループはバランスの取れた測定プログラムを採用します。全チームにわたる四半期ごとのDevExサーベイ、SPACE型のシグナル、そしてデリバリーの健全性の傾向としてチームレベルで読まれるDORA指標(11.5章)です。決定的なのは、チームの文脈が大きく異なるため、チーム同士ではなく、各チームを時間経過に伴う自分自身の軌跡と比べて、公正にベンチマークすることです。データは、整備された道(8.4章)に乗っているチームが、新しいエンジニアを数週間ではなく数日でオンボードし、認知負荷がはるかに低いと報告することを示しています。何百人もの開発者にわたって取り戻された能力として位置づけられたその証拠が、プラットフォームにもう一年分の資金を供給します。個人のテレメトリは、意図して一切収集されません。

政府。 ある連邦のデジタルサービス機関は、成果に市場価格のない環境で、エンジニアリング支出が価値を届けていることを立法府に示さなければなりません。成果の芝居(文書や閉じられたチケットを数える)を退け、代わりに成果とデリバリー能力を測定します。サービスが修正をどれだけ速く出荷できるか、どれだけ信頼できるか、そして人員とその契約者が匿名のサーベイを通じて仕事をどう体験しているか。DORA型のデリバリーのシグナルは、モダナイゼーションが実際にスループットと安定性を改善しているかを示し、生の活動ではなく公共の成果に結びつけられます(11.5章)。測定が個人をランク付けせず、契約者と公務員のスタッフが同じシステムレベルの基準で測定されるため、機関はそのような取り組みを沈める監視と士気の問題を避け、監督機関に価値についての正直な読みを与えます。

ビジネスケース: 動機、ROI、TCO

有効性の測定と改善による見返りは、取り戻される能力であり、大規模では数字は大きなものです。小さな摩擦は大きな組織全体で掛け算されます。百人のエンジニアが一日に何度もぶつかる10分のビルドは、年に数千エンジニア時間が待ちに費やされることを意味します。そのループを短縮すれば、誰も採用せずに意味のある能力を加えたことになります。ここでの主要なROIは、プラットフォームエンジニアリング(8.4章)と同じです。高価なエンジニアリングの時間が、待ちと雑務から、価値ある仕事へと振り向けられます。

総所有コストは控えめですが現実的です。サーベイツールとそれを運用する規律、パイプラインの計装、傾向を読み行動するためのマネジメントの注意に支払います。ROIへのより大きなリスクは、測定をまずくやることです。一つの操作された指標や監視プログラムは、マイナスの見返りを生みえます。実際の成果が停滞する一方で数字に最適化する数か月の労力と、将来のあらゆる変化を難しくする信頼の腐食です。まったく測定しないコストは、拡散していて莫大です。摩擦と雑務は見えないまま積み重なり、シニアエンジニアは避けられる無駄で燃え尽き、リーダーシップは投資が役立っているかを判断できません。リーダーシップには、てこと誠実さとして論拠を示してください。大きな人員がどこで時間を失っているかを見つける、小さく信頼されたバランスの取れた測定プログラムは、最初の発見に対して行動した瞬間に、何倍にも元を取ります。

アンチパターンと落とし穴

単一の生産性指標。 どの一つの数字(LOC、ベロシティ、コミット、時間)も、目標になった日に操作されます。
個人のランク付け。 順位表と個人の「生産性スコア」は信頼を破壊し、人々に指標への最適化を教えます。
監視としての測定。 人事評価に反映される細かい個人のテレメトリは、効果的な仕事が必要とする心理的安全性を蝕みます。
フォロースルーのないサーベイ。 開発者に仕事がどう感じられるかを尋ねながら何も変えないことは、彼らに正直に答えるのをやめることを教えます。
チームの生の数字の比較。 チームの文脈は異なります。チーム間のベロシティやDORAの比較は、正直さを罰し、操作に報います。
成果の芝居。 実際の成果が測られないまま、作成された成果物(文書、チケット、出荷された機能)を数えること。市場価格がない所でよく見られます。
人事評価におけるDORA。 デリバリーの指標が人を採点した途端、チームはインシデントを隠しデプロイを分割し、シグナルは死にます。

成熟度モデル

レベル1、開始: 生産性は、勘や、コードの行数、ベロシティ、時間のような単一の操作可能な指標で判断されます。測定は場当たり的で反応的で、摩擦は見えず、不満は逸話的で、組織が良くなっているかを誰も言えません。
レベル2、発展: 一部のチームが基本的な実践を採用します。少数の指標(多くは活動の数)と、時々の開発者体験サーベイです。実践はチームごとに一貫せず、データは集められても行動に移されることは稀で、生のチーム間比較が忍び込み、個人をランク付けから守る共有の原則はありません。
レベル3、標準化: バランスの取れた測定プログラムが文書化され、組織全体で適用されています。SPACE型の次元、定期的なDevExサーベイ、デリバリーのシグナルとしてのDORA(11.5章)を使います。指標は方針によってチームに集約され、個人はランク付けされず、発見は、フィードバックループを短くし雑務を削る(9.1章)具体的な作業を動かします。
レベル4、管理: プログラムはベースラインに対して測定され、制御されます。フィードバックループの時間、サーベイのスコア、DORAの傾向には合意された目標があり、時間とともに追跡されます。各チームは隣ではなく自分自身の軌跡と比較され、プラットフォームと雑務削減への投資は、取り戻された能力についての前後のデータで正当化され、どのシグナルの後退も、気づかれずに通過するのではなくレビューを引き起こします。
レベル5、オーケストレーション: 測定は信頼され、日常的で、適応的です。知覚データとシステムデータは三角測量され、傾向は継続的な改善を促し、摩擦と認知負荷は積極的に探されて取り除かれ、測定の集合自体が組織の変化に応じて改訂され、有効性はビジネスと公共の成果と統合されますが、どの指標も腐敗させる目標になることは許されません。

議論のためのアイデア

現在の指標のうち、賢明でないチームがより良い仕事をせずに膨らませられるものはどれで、何に置き換えますか。
組織全体で、ちょうど一つのフィードバックループを短縮できるなら、どれが最も多くの取り戻された能力を返しますか。
文脈が異なる多くのチームを、正直さを罰する順位表を作らずに、公正にベンチマークするにはどうしますか。
システムを測ることと個人を監視することの境界線はどこにあり、組織内でそれを執行する権限を持つのは誰ですか。
政府や社内プラットフォームのように、成果に市場価格がない環境で、活動ではなく本当の価値をどう測りますか。
今四半期のサーベイが何かを変えたことを証明するために、開発者に何を見せますか。

要点

エンジニアの生産性は多次元です。グッドハートの法則が操作を保証するので、その指標としての単一の数字(コードの行数、ベロシティ、コミット、時間)を拒みます。
SPACEフレームワーク(満足とウェルビーイング、パフォーマンス、活動、コミュニケーションと協働、効率とフロー)を使って複数の次元を一緒に保持し、どの次元も単独で操作できないようにします。
開発者体験は、フィードバックループ、認知負荷、フローに行き着きます。ループを短くし負荷を取り除くことは、活動の数が決して示さない本物の生産性です。
DevExサーベイからの知覚データを、ツールからのシステムデータと三角測量します。各データ源が他方を補正します。
DORA指標を、順位表ではなくチームレベルのデリバリーのシグナルとして扱います。その深さは11.5章に、パイプラインは11.2章にあります。
システムを測り、個人は決して測りません。チームに集約し、評価は1.3章の別個の人間的な経路に置き、測定を監視にしてはいけません。
取り戻された時間を、雑務の削減(9.1章)、コードレビューの高速化(2.5章)、道の整備(8.4章)に使います。どの指標も腐敗させる目標にせずに、有効性をビジネスの成果に結びつけます。

参考文献とさらなる読み物

Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler, “The SPACE of Developer Productivity” (ACM Queue, 2021): the multidimensional framework.
Abi Noda, Margaret-Anne Storey, Nicole Forsgren, and Michaela Greiler, “DevEx: What Actually Drives Productivity” (ACM Queue, 2023): feedback loops, cognitive load, and flow.
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (the DORA metrics and their research basis).
DORA, Accelerate State of DevOps Report (annual): the ongoing research programme behind the four metrics.
Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds., Site Reliability Engineering (toil and its elimination).
Matthew Skelton and Manuel Pais, Team Topologies (cognitive load as a first-class design concern).
Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (the origin of flow state).
Tom DeMarco and Timothy Lister, Peopleware: Productive Projects and Teams (focus, interruption, and the human side of productivity).
Goodhart, C. A. E., “Problems of Monetary Management: The UK Experience” (1975): the origin of Goodhart’s law; see also Marilyn Strathern’s widely quoted formulation.
U.S. Government Accountability Office (GAO) guidance on performance measurement: measuring value in non-market public-sector settings.