Original paper: https://arxiv.org/abs/2605.04259
Brian Houck, Tim Bozarth, David Liu, Dean Carignan
すべてのエンジニアリングリーダーは、同じ問いを発している。「自分たちの開発者は生産的なのか？」そして「自分たちの生産性は向上しているのか？」。これらの問いは何十年にもわたって重要であり続けてきたが、AI の台頭によって、仕事の進め方そのものが根本的に変わりつつあるため、実存的な緊急性を帯びるようになった。本稿では、ソフトウェア開発の形が進化し続けても意味を持ち続ける、生産性を測定するための持続性のある多次元モデルを提案する。
本稿では、Microsoft で開発された測定・改善システムである Engineering Thrive（EngThrive）を紹介する。EngThrive のテレメトリプラットフォームとサーベイプログラムは、Microsoft の数万人の開発者を対象としている。EngThrive は、多次元的な生産性測定を、Speed（スピード）、Ease（容易さ）、Quality（品質）という 3 つの次元へと運用可能な形に落とし込んでいる。さらに、Thriving（活力ある状態）をガードレールとして置くことで、生産性の向上とともに開発者体験も改善されることを保証する。本稿では、このフレームワークの設計原則、指標、指標の選定方法、測定を支えるインフラストラクチャ、そしてその活用を示す複数のケーススタディについて述べる。また、EngThrive が、開発者ツールや AI だけでなく、組織設計、職場方針、そしてエンジニアが仕事をどう経験するかを形づくる多様な要因に適用できる、汎用的な評価言語として機能することも示す。
本研究は、過去 10 年の生産性研究から得られた中核的な洞察に基づいている。それは、生産性は（職務パフォーマンスとは異なり）個人単位で離散的に測定することはできない、というものである。業界は長らく、各個人の生産性を評価するための単純で還元主義的な方法を探し求めてきたが、このアプローチは機能しない。生産性は、個人の能力と、その人々が活動するシステムの両方を反映する。EngThrive は、システムの生産性を測定し、ボトルネックを特定し、継続的改善を推進し、そのシステム内の個人の有効性を高めるための、明確で実行可能な方法を作ることに焦点を当てている。
EngThrive は、根本的な測定上の問題にも取り組む。組織はしばしば、活動（コード行数、プルリクエスト、タスク）を追跡し、それを成果（提供された価値、スピード、品質）の代理指標として扱う。しかし、これらは同じものではない。両者を混同すると、精密ではあるが誤ったシステムが生まれ、指標のゲーム化や意図しない行動を招き、組織を望ましい成果から遠ざけてしまう。
特に断りのない限り、本稿における知見は、Microsoft のエンジニアリング組織全体を対象として複数年にわたり実施された、社内テレメトリおよびサーベイ調査に基づいている。これには、リポジトリおよびビルドデータ、コラボレーションシグナル、インシデントデータ、大規模な開発者体験サーベイが含まれる。各知見の方法論を完全に扱うことは本稿の範囲を超えるが、個々の指標とその妥当性検証については、以降の各セクションで説明する。
私たちの目的は、Microsoft における EngThrive の経験に基づき、開発者生産性を測定・改善するための、実証済みでスケーラブルなアプローチを提供することである。Speed、Ease、Quality を軸に、フレームワークからオペレーティングシステムへと移行する方法を示し、自組織の働き方のシステムを進化させようとしている組織に対して、具体的で引用可能な参照点を提供する。
私たちが何を構築したのかを述べる前に、何を避けようとしていたのかを理解しておく価値がある。開発者生産性測定の歴史には、善意に基づきながらも誤解を招く結果を生んだ取り組みが数多く存在する。それは、データが誤っていたからではなく、解釈が不完全だったからである。
COVID のパラドックス。 2020 年初頭、Microsoft で在宅勤務が義務化された最初の 2 か月間、開発者 1 人あたりのプルリクエスト数は 20% 以上増加した。株価は 15% 以上上昇した。活動指標やビジネス指標だけを見れば、状況は極めて良好に見えた。しかし同じ時期に、開発者の 78% が燃え尽きていると報告していた [7]。同じ四半期から得られた 3 つのシグナルが、2 つの異なる方向を指していたのである。そのうちどれか 1 つだけを取り出せば、自信に満ちた、しかし完全に誤解を招く物語が語られていただろう。
これは例外的なケースではない。むしろ通常の状態である。生産性シグナルは日常的に乖離する。そして、どのシグナルに注目するかという選択自体が、組織に対して「何が重要なのか」を伝えるシグナルになる。
ソフトウェアエンジニアリングはコーディング以上のものである。 研究によれば、AI コーディングアシスタントは、特定のコーディングタスクの完了時間を最大 56% 短縮できる [5]。しかし、この数字は誤解を招きやすい。エンジニアリングリーダーは「56% 速い」と聞くと、「50% 多くのイノベーションを出荷できるはずだ」と外挿してしまう。この外挿は 2 つの誤解に基づいている。第一に、リーダーは開発者の 1 日のうち、コードを書く時間がどれほどの割合を占めるかを大幅に過大評価している。研究では一貫して、平均的な開発者の 1 日のうち新しいコードを書く時間は約 15% にすぎないことが示されている。テストとデバッグを含めても、その割合は 25〜30% にしか上がらない [3, 6]。第二に、開発者のタスクは複雑さの点で非常に多様である。AI ツールは、ボイラープレート、スクリプト作成、定型的なリファクタリングといった、小さく反復的なタスクに費やす時間を減らすことには非常に有効である。一方で、最も価値の高いエンジニアリング作業を構成する、複雑で新規性があり、微妙な判断を要する問題にはそれほど有効ではない。1 日の一部のうち、あるカテゴリの一部に含まれる、さらにその一部の作業における 56% の短縮は、スライド上の単一の数字が示唆するようには一般化できない。
単一指標の罠。 より深い問題は構造的なものである。どのような単一指標も、ゲーム化され、誤解され、あるいは文脈によって無意味になり得る。コード行数はエレガンスを罰する。品質を伴わないベロシティは単なる churn（空回り）である。アウトプットを伴わない満足度は自己満足である。業界はこのことを何十年も前から知っているにもかかわらず、単一の「生産性」目標指標への需要は根強く残っている。教訓は、測定が不可能だということではない。フレームワークを欠いた測定は、シグナルを装ったノイズを生み出すということだ。さらに悪いことに、それは誤った確信を生み、確信を持って誤った行動を取らせる。組織がこうした誤解を招くシグナルに基づいて行動すると、生産性を改善できないだけではない。誤った成果を高い確信で最適化することによって、生産性を能動的に劣化させるのである。
EngThrive の知的基盤は、ここ数年の複数の研究系譜に由来する。それらはいずれも、開発者生産性が本質的に多次元であり、単純に還元できないことを示している。SPACE フレームワーク [1] は、Satisfaction（満足度）、Performance（パフォーマンス）、Activity（活動）、Communication（コミュニケーション）、Efficiency（効率）という 5 つの次元を提案し、単一の指標では全体像を捉えられないと論じた。その後の開発者体験に関する研究 [2] は、フロー状態、フィードバックループ、認知負荷といった要因と、個人・チーム・組織レベルの成果との統計的関係を定量化した。さらに最近の、AI が開発者ワークフローへ与える影響に関する研究 [3] は、最も変革的な新しいツールであっても、その効果は複数の次元にまたがり、単純な要約を拒むことを確認した。
SPACE フレームワークは、生産性が純粋に活動量に関するものである、生産性は個人だけに関するものである、1 つの指標で十分である、といった根強い神話を否定した。そして、信頼できる測定アプローチは少なくとも 3 つの次元をカバーし、少なくとも 1 つの知覚的測定を含み、適切に選ばれた指標同士は自然に生産的な緊張関係を生むはずだと提案した。これらはすべて、EngThrive が実践に移している中核原則である。
DevEx in Action [2] は、これらの原則を実証的に基礎づけた。同研究は、開発者体験を改善することが、個人の生産性と創造性、チームのコード品質と技術的負債、組織のリテンションと収益性を改善することを示した。この研究は、EngThrive のような投資が組織の成功にとってどれほど重要かを定量化した。
DORA [11] は、業界で最も一般的な測定フレームワークの 1 つに貢献した。Deployment Frequency（デプロイ頻度）、Lead Time for Changes（変更のリードタイム）、Change Failure Rate（変更失敗率）、Mean Time to Recovery（平均復旧時間）という 4 つの指標である。これらは、速度と安定性の両方を含むソフトウェアデリバリーパフォーマンスを厳密に捉える。これらの指標は、無数の組織に、自分たちのエンジニアリングシステムがどの程度うまく機能しているかを理解するための最初の実証的な足場を与えてきた。EngThrive は、この基盤を置き換えるのではなく、その上に構築される。DORA がデリバリーパイプラインの健全性を測るのに対し、EngThrive は、人間要因、開発者体験、そして強いデリバリーパフォーマンスが持続可能な生産性へとつながるかどうかを形づくる、より広い組織的文脈まで視野を拡張する。
これらのフレームワークは、何について考えるべきかを教えてくれる。EngThrive は、その次の問いに答えようとする試みである。では実際に何をすればよいのか。
EngThrive の主要な目的は、優れた仕事をすばやく簡単にできるようにすることである。これを捉えるために、EngThrive の指標は Speed、Ease、Quality という 3 つの測定次元を中心に整理され、Thriving が主観的な継続的改善を保証するガードレールとして置かれている。各次元を説明する前に、その選定を導いた設計原則を概説する。
図（4 ページ）の要旨: Engineering Thrive は、Speed（どれだけ迅速にイノベーションを届けられるか）、Ease（体験はどれだけ摩擦が少ないか）、Quality（成果はどれだけ良いか）という 3 つの歯車を中心に置き、Thriving（仕事において力を発揮でき、活力を得ていると感じること）をガードレールとして支える構造として描かれている。
各次元の中で、私たちは 1〜2 個の North Star 指標を特定する。これらは、最終的に気にかけるべき対象を捉える、成果志向の測定であり、診断的な詳細と実行可能なレバレッジを提供するサブ指標によって支えられる。North Star は「私たちは良くなっているのか？」に答える。サブ指標は、North Star の具体的な活動や構成要素を掘り下げ、「なぜ良くなっているのか、あるいはなぜ良くなっていないのか？」を理解することを可能にする。
実務上、North Star 指標には成熟したクロスシステムのテレメトリが必要になることが多く、ほとんどの組織は初日からそれを持っていない。サブ指標は開始点である。しかし、操舵すべき先では決してない。組織は、まだ測定できない段階であっても早期に North Star を定義し、それに向かって反復的に構築すべきである。成果指標によるアンカーなしに活動サブ指標の変動を管理対象にしてしまうことが危険である。その道は、進歩ではなく動きそのものを最適化する。
Measures と Metrics。 私たちは measures（測定値）と metrics（指標）を意図的に区別している。measure は現実を記述する。すなわち、データポイントであり、観測であり、世界に関する事実である。metric は何が重要かを決める。すなわち、ある組織が、それは最適化する価値のある何かを反映していると判断したために選定され、文脈化され、目標を与えられた measure である。すべての measure が metric になるべきではない。measure を metric に昇格させる行為は、価値観の表明であり、慎重に扱われるべきである。
害をなさない。 Speed、Ease、Quality は三つ組として定義されている。各指標は他の指標の文脈の中に存在し、相互に補強し合うように設計されている。ある指標が改善されたとみなされるのは、他の 2 つを維持または向上させる場合のみである。これにより、改善がコストの再配分や隠蔽ではなく、付加的なものであることを保証する。この原則はシステムの軸である。生産性が進歩するのは、三つ組がともに動くときであり、1 つの次元が全体を犠牲にして改善されるときではない。この原則は理論にとどまらない。6.3 節では、Speed 指標上はコストが高いように見えたが、実際には無償であり、Thriving 指標上は極めて価値が大きかった介入について述べる。三つ組がなければ、その介入は失敗と判断されるか、そもそも試されなかっただろう。
ゲーム化の整合。 生産性指標に対するよくある反論は、それらがゲーム化され得るというものだ。私たちはこれを、防ぐべき欠陥ではなく、受け入れるべき設計制約として扱う。適切に設計された指標は、ゲーム化行動を意味のある成果に整合させる。新入社員の Time-to-First-PR を考えてみる。ある組織が、初日に些細な PR を割り当てることでこの指標を意図的に「ゲーム化」したところ、そのゲーム化自体が、持続的な良い成果を生んだ。ゲーム化されたにもかかわらずではない。ゲーム化する行為が、まさに正しい行動を強制したからである（6.2 節）。目標は、ゲーム化が単なる活動の変化ではなく、改善そのものになるような指標を選ぶことである。
混合手法。 EngThrive のすべての測定レベルは、客観的テレメトリ（システムログ、リポジトリデータ、カレンダーシグナル）と主観的サーベイデータ（満足度、障壁、知覚された体験に関する開発者の自己報告）を組み合わせている。どちらか一方だけでは不十分である。テレメトリは、ある開発者のフォーカスタイムが減少したことを示せるが、その理由を説明することはできない。サーベイは、開発者がデプロイメントパイプラインに不満を感じていることを明らかにできるが、その問題の規模を数万人のエンジニア全体で定量化することはできない。両者の組み合わせは、単なる足し算以上のものである。それは、症状を見ることと、状態を理解することの違いである。
Speed は、開発者とチームが意図を提供された仕事へと変換する速度を捉える。主に「経過カレンダー時間」を単位として測定される。リーダーも開発者もスピードを直感的に理解しており、この次元の指標は即座に解釈できるよう設計されている。
主要指標: Idea-to-Customer（I2C）。 I2C は、最初の計画成果物から、作業が顧客の手元に届く瞬間までの経過時間を測定する。これは Speed の North Star である。なぜなら、パイプライン全体を捉えるからであり、その一部だけを捉えるものではない。チームの PR ベロシティが速くても、要件が不明確であったり、レビューがボトルネックになっていたり、デプロイが手動承認プロセスに阻まれていたりすれば、チーム全体としては遅い可能性がある。だからこそ、PR ベロシティは興味深い活動測定ではあるが、それ単体では Speed の代理指標として不十分である。それはプロセスの 1 段階におけるスループットを捉えるが、最初のコミットの前や最後のマージの後に費やされる時間については何も語らない。I2C はそれらすべてを見る。リーダーが本当に気にしている問い、すなわち「意図をインパクトに変えるのにどれだけ時間がかかるのか？」に答える。
現在、開発者が生み出す成果物はコード中心であり、私たちの Speed 指標の多くもその現実を反映している。私たちは、これが進化すると予想している。AI 支援開発が成熟するにつれて、ワークフローはますます仕様駆動、意図駆動になり、コードは著作の主要単位ではなく生成された成果物になっていくだろう。その移行が進むと、プルリクエストの意味は変化する。しかし I2C は、単一の中間成果物ではなくエンドツーエンドの成果に根ざしているため、安定して残る。
主要サブ指標
Time to Nth PR は、新しいエンジニアがどれだけ速くチームのコードベースに貢献し始め、一定のチェックインマイルストーンに到達するかを測定する。私たちの目標は意図的に野心的である。最初の PR は 7 日以内、10 個目の PR はその後数週間以内である。新入社員が 10 個目のプルリクエストに到達する頃には、その後 2 年間のコーディングアウトプットパターンを 50% を超える確率で予測できる。これは単なるスピード指標ではない。長期的なエンジニアリング軌道の先行指標である。
この指標が特に興味深いのは、初期の PR の中身は、それが発生するという事実に比べてはるかに重要でないという点である。タイポ修正や設定ファイルの更新のような些細な最初の貢献であっても、長期的には良い成果を生む。コードそのものがポイントではない。PR を提出するという行為が、開発者に環境をセットアップさせ、コードベースを探索させ、チームのレビュー慣習を学ばせ、何かを出荷させるのである。これらはそれぞれ独立に価値がある。この動態については 6.2 節でさらに検討する。
PR Completion Time は、PR 作成からマージまでの経過時間を測定する。これは、レビュー・ループに関する開発者の体験であり、「自分のマシンでは完了した」状態から「マージされ、価値を届けている」状態へと作業が移る速度を決めるフィードバックサイクルである。大規模な PR ライフサイクル分析により、強い結合が確認された。完了時間を短縮することは、単に気分を良くするだけではない。システム全体にわたり、測定可能なスループット向上を生む。PR Completion Time は、I2C の中で最も直接的に実行可能なサブ指標の 1 つである。なぜなら、チームがローカルに対処できるボトルネックを可視化するからである。
Ease は、開発者が不要な摩擦、中断、単調な労苦なしに仕事を遂行できる程度を捉える。Speed が前進の速度を測るなら、Ease は何が邪魔をしているかを測る。この次元の指標は、主に「開発者時間」を単位としている。
主要指標: Innovation Time Ratio。 Innovation Time は、平均的な期間（例えば 1 週間）において、価値創造に費やす時間と、「事業運営」または「ビジネス上のオーバーヘッド」タスクに費やす時間の比率を測るものである。
Innovation work には、新しい価値を生む活動が含まれる。プロダクト機能の構築、ユーザー体験の改善、労苦のクラスを排除する自動化への投資、品質向上のためのテストおよびリリースパイプラインの強化などである。「Run the business」作業は、システムを稼働させ続ける。移行、オンコール対応、インシデント対応、バグの診断と修正、既存サービスの保守などである。Business overhead は、調整および管理上の負荷を捉える。定例のステータス会議、報告、コンプライアンスおよびセキュリティタスク、プロセス上のオーバーヘッド、その他、組織を運営するために必要だが、プロダクト価値の創造や維持には直接結びつかない作業である。
私たちは Focus Time から出発し、インシデント作業、ビルド失敗、会議負荷、コンプライアンスタスクなど、Innovation Time を侵食する開発活動をテレメトリで特定し、それらを総フォーカスタイムから差し引くことで Innovation Time を推定する。これにより、価値創造のために保護された時間について、方向性を示すシステムレベルの測定値が得られる。
テレメトリは、簡潔なサーベイで補完する。例えば、「1 週間のうち何パーセントを、イノベーション、事業運営、オーバーヘッドに費やしていますか？」と問う。サンプルサイズが小さくても、これらのサーベイは非常に実行可能性が高く、チームレベルでテレメトリベースの推定を検証し、校正するのに役立つ。
主要サブ指標
Perceived Ease of Delivery は、現在のシステム内で仕事を完了することが開発者にとってどれほど難しいかを、サーベイを通じて捉える。これは Innovation Time Ratio に対する主観的な補完である。テレメトリは、開発者が会議やビルド失敗によって何時間を失ったかを示せる。しかし、残った時間が生産的に感じられたのか、それとも不明確な要件、承認待ち、無関係なタスク間のコンテキストスイッチに費やされたのかは、開発者本人にしか語れない。Perceived Ease が Innovation Time Ratio と乖離するとき、テレメトリだけでは検出できないシステム上の問題が浮かび上がる。
Anti-Innovation Time Factors は、テレメトリ側の方程式を分解する。私たちは、会議負荷、インシデント対応時間、コンプライアンスおよびセキュリティ義務に費やす時間を、別個の侵食カテゴリとして追跡する。それぞれ独立に測定可能であり、実行可能である。この分解により、Innovation Time Ratio は単なる記述指標ではなく、診断的な指標になる。
Quality は、実施されている作業が、持続性があり、信頼できる結果を生んでいるかどうかを捉える。品質を伴わないスピードは単なる churn である。高速に出荷するが頻繁に壊すチームは、生産的なのではなく、手戻りを生み出しているのである。Quality 自体は多面的である。本番環境へ流出する欠陥、問題発生時の回復速度、そして最終的には提供されたものに対する顧客満足を含む。私たちが選んだ指標は、品質のあらゆる側面を単一の測定で捉えようとするのではなく、開発者体験と持続可能なエンジニアリングに最も直接結びつく次元に焦点を当てている。
この次元では、互いに補完する 2 つの North Star を用いる。1 つは品質関連の中断頻度（PRs-Per-Incident）を捉え、もう 1 つはそれらの中断のコスト（Incident Mitigation Time）を捉える。
主要指標: PRs-Per-Incident。 PRs-Per-Incident は、前進（完了したプルリクエスト）と運用上の中断（登録されたインシデント）の比率を捉える。実質的には、変更失敗率に対する私たちの枠組みである。失敗を引き起こしたデプロイの割合を測るのではなく、チームが生み出す中断に対して、どれだけ将来志向の作業を完了しているかを測る。高いほど良い。インシデント 1 件あたり 20 件の PR を完了しているチームは、3 件しか完了していないチームとは根本的に異なる状況にある。
PRs-Per-Incident が Quality の North Star であるのは、最も重要なバランスを捉えるからである。すなわち、私たちはより多く壊すことなく、より速く構築できているのか、という問いである。この指標は意図的に両面性を持っている。比率が低い場合、インシデントが多すぎること（品質問題）を示している可能性も、PR が少なすぎること（速度問題）を示している可能性もある。診断価値は比率にあり、分子や分母のどちらか一方にあるのではない。このため、Speed 側の I2C と自然に補完し合う。両者はあわせて、チームが持続可能な形でイノベーションを届けているかどうかという問いに答える。
主要指標: Incident Mitigation Time。 Incident Mitigation Time は、ライブサイト問題について、インシデント検出から軽減までの経過時間を測定する。あらゆる実質的な意味で、これは標準的な業界指標である MTTM の私たち版である。重要なのは、この指標が、顧客向け品質そのものではなく、開発者体験への中断の測定として位置づけられている点である。ライブサイトインシデントが発生すると、開発者は計画していた作業から引き離され、フォーカスタイムが破壊され、不満が生じる。より速い軽減は、エンジニアリングシステム全体への中断を小さくする。Incident Mitigation Time は、品質が高いかどうかだけでなく、品質が損なわれたときにチームにどれだけのコストがかかるかを教えてくれる。
Thriving は、Speed、Ease、Quality と並ぶ第 4 の次元ではない。それはガードレールであり、S/E/Q の最適化が、仕事をしている人々を犠牲にしていないことを確認するためのチェックである。この領域の指標は、開発者の幸福度を単位として測定される。
主要指標: NSAT。 私たちは、2 つの補完的な手段によってセンチメントを測定する。第一は NSAT（Net Satisfaction）であり、エンジニアリング体験サーベイから導かれる。これは、開発者がエンジニアリングシステム、すなわちツール、プロセス、ワークフローにどれだけ満足しているかを捉える。第二は、Microsoft の従業員センチメントプログラム [10] から得られるより広い Thriving スコアであり、従業員が自分の最高の仕事をする力を与えられていると感じているか、自分のしていることから活力を得ているか、自分の仕事に意味があると感じているかを測定する。
このガードレールが重要である理由を示す証拠は明白である。仕事に不満を持つ開発者は、自分が非生産的であると報告する可能性が 25 倍高く、1 年以内に退職する可能性が 2 倍高い [4]。これは「ソフト」な懸念ではない。エンジニアリング組織の能力と継続性を直接予測するものである。私たちは Thriving を実務的に扱う。ある介入が Speed、Ease、Quality の指標を改善しても Thriving が低下するなら、その介入には何か問題がある。ガードレールはそれを捕捉し、ボトルネックと実際の開発者体験に関する私たちの理解が、どこで不完全または誤っているのかを検討できるようにする。
主要指標: Bad Developer Days（BDD）。 NSAT が開発者が自分の体験についてどう感じているかを捉えるのに対し、BDD は実際に何が起きたかを捉える。BDD は、Google で最初に開発された考え方を拡張した複合指標であり、日々の開発者の労苦を定量化する。BDD の概念は普遍的に適用可能だが、BDD に含まれる具体的なサブ指標は各事業ごとに異なる。
「悪い日」とは、特定されたサブ指標の任意の組み合わせにより、しきい値を超える量の摩擦に開発者が遭遇した日のことである。過度なコンテキストスイッチ、インシデント対応とライブサイトの労苦、ビルド失敗やビルドの遅さ、不十分なフォーカスタイム、コンプライアンスおよびセキュリティ義務などが含まれる。
BDD は Thriving の North Star である。なぜなら、開発者の多様なフラストレーションを、リアルタイムに収集できる単一の比較可能な数値へと集約するからである。組織全体で BDD を計算したところ、その結果は厳しいものだった。すべての開発者日の 52% が「悪い日」に該当した。週に 3 日以上の悪い日を経験する開発者は、悪い日が少ない同僚と比べて、退職する可能性が 3 倍高く、コード生産量が 20% 少なかった。BDD は本質的に労苦税であり、私たちが別の場所で論じたように、労苦はイノベーションに対する税である [8]。開発者が不安定なビルドと戦ったり、不必要なコンテキストスイッチから回復したりするために費やす 1 時間は、組織が実際に必要としている創造的で高価値な仕事に使われない 1 時間である。
BDD が実行可能で有益であり続けるためには、以下の基準を満たさなければならない。複合指標に含める指標数は少数でなければならない（実験では、合計 6 指標を超えると混乱が増えることが示されている）。また、各指標は他の指標と同じ時間枠（すなわち日次）で独立に測定可能でなければならない。これらの条件は、複合指標が過度に抽象的になることを防ぐために不可欠である。
BDD を通じた Thriving の枠組みは、意図的に実務的である。私たちは、開発者が喜びに満ちているかどうかを問うているのではない。システムが彼らに逆らうことなく、彼らが仕事をできるかどうかを問うているのである。この区別は重要である。喜びは摩擦を取り除いた結果であり、それ自体を目的にすべきものではない。
インフラストラクチャを伴わないフレームワークは、単なる願望である。Microsoft 内で EngThrive を現実のものにするために、私たちは多次元データをアクセス可能で、実行可能で、安全なものにするための完全な測定システムを構築した。
ダッシュボード、サーベイ、分析が有用になる前に、私たちには基盤が必要だった。すなわち、数十の異なるシステムから開発者テレメトリを取り込み、単一で一貫性のある正規化されたレイヤーへ統合する、統一データプラットフォームである。GitHub からのソース管理データ、社内 CI/CD システムからのビルドテレメトリ、Outlook と Viva からのカレンダーシグナル、インシデント管理データ、コンプライアンス追跡などが、共通データモデルへ結合・照合される。このプラットフォームは、その後のすべてを支える岩盤である。指標は組織をまたいで一貫して計算され、サーベイ回答はより深い分析のためにテレメトリで補強でき、研究者は、会議負荷と PR ベロシティの関係のように、単一のデータサイロでは検出不可能なクロスシステムの関係を調査できる。この投資がなければ、EngThrive が依存する混合手法アプローチは、大規模には機能しなかった。
また、このシステムが 1 日で包括的なデータプラットフォームとして出現したわけではないことも重要である。それは反復的に構築された。各ステップは、EngThrive の North Star 指標のより包括的な像を具体化できるように優先順位づけされた。
EngThrive Engineering Experience Survey は、Microsoft のグローバルなエンジニアリング人材全体を対象に実施される。これは Speed、Ease、Quality の各次元を中心に構成され、各セクションにはリッカート尺度項目と障壁特定の質問の両方が含まれる。開発者は、どの具体的な障壁が自分の体験に最も影響しているかを報告する。例えば、デプロイメントの摩擦、ビルド信頼性、会議負荷、不明確な要件などである。これらの障壁に関する回答は、満足度スコアと直接結びつけられ、どの介入が最大のインパクトを持つかを特定する。
サーベイは時間配分も捉える。開発者は、1 週間のうちどの割合をイノベーション（新機能、改善）、事業運営（保守、運用作業）、オーバーヘッド（会議、コンプライアンス、管理タスク）に費やしているかを推定する。この分解は分析上強力である。なぜなら、構造的な問題を浮き彫りにするからである。開発者が 30% の時間をオーバーヘッドに費やしている組織は、30% を運用上の労苦に費やしている組織とは根本的に異なる課題を抱えている。たとえ両者が同じ全体満足度を報告していたとしてもである。
AI 関連の質問は、独立したセクションに切り出すのではなく、既存の次元構造の中に織り込まれている。これは意図的な設計選択である。AI は Speed、Ease、Quality に影響を与えるツールであり、独立して測定すべき体験の別次元ではない。
EngThrive データは、異なるペルソナ向けに設計されたダッシュボードエコシステムを通じて提示される。組織ダッシュボードは、ソフトウェアエンジニアの個人貢献者が 50 人以上いるグループのリーダー向けであり、トレンド、チーム間比較、戦略的なリソース配分を重視する。チームダッシュボードは、5 人以上のメンバーを持つグループのマネージャーやテックリード向けであり、障壁の特定とローカルな改善機会を重視する。
この階層に存在しないものがある。個人レベルのダッシュボードである。これは設計上の選択である。EngThrive 指標は個人のパフォーマンス測定ではなく、個々のエンジニアを評価、ランク付け、比較するために使われることは決してない。このシステムが測定するのは、開発者が働く環境であり、開発者本人ではない。マネージャーとリーダーは、自分たちが作り出す環境に対して責任を持つ。ダッシュボードは、その責任を反映するように設計されている。
プライバシーは第一級の設計制約である。組織ダッシュボードはより大きな母集団に対して集計され、チームダッシュボードはそのチーム自身のデータに限定される。集計しきい値により、小規模グループで個人が特定されることを防ぐ。これは単なるコンプライアンス要件ではない。信頼の基礎であり、信頼はデータ品質の基礎である。
Speed、Ease、Quality が EngThrive が何を測るかを記述するなら、3 つの柱は変化が実際にどのように起こるかを記述する。EngThrive は、相互に補強し合う 3 つの柱を通じて機能する。
文化 は、測定データが実際に変化を生むかどうかを決定する組織規範、リーダーシップ行動、共有された期待を含む。データが明らかにしたことにリーダーが行動するか、チームが安全に問題を表面化できるか、改善が報われるか、といった点である。
洞察 は、サーベイ、テレメトリ、分析、理解を生み出す研究といったデータそのものを含む。
インフラストラクチャ は、洞察を大規模にアクセス可能かつ実行可能にするツール、ダッシュボード、システムを含む。
いずれの柱も単独では機能しない。文化を伴わない洞察は shelfware（棚に置かれるだけの成果物）を生む。誰も行動しない美しいダッシュボードである。洞察を伴わない文化は直感を生む。善意のリーダーが暗闇の中で意思決定をする状態である。どちらも伴わないインフラストラクチャは、目的を欠いた能力を生む。システムは、3 つすべてがともに機能するときに機能する。
以下のケーススタディは、EngThrive の原則が実践でどのように機能するかを示すものであり、データから洞察へ、洞察から行動へ、行動からインパクトへという流れを例示する。
研究によれば、「会議が多すぎる」ことは、ソフトウェアエンジニアの間で業界全体を通じて 2 番目に頻繁に挙げられる職場課題である [12]。これに関連して、深い作業のために十分な時間が確保されている開発者は、そうした専用時間がない開発者と比べて、自分が 50% 生産的であると感じている [2]。
2025 年後半、数千人の開発者を擁する Microsoft CoreAI 組織は、不要な会議負荷を減らし、開発者のフォーカスタイムを増やすための専用イニシアチブを開始した。エグゼクティブリーダーシップは明確な目標を設定した。開発者の下位 20 パーセンタイルを、週あたり少なくとも 25 時間のフォーカスタイムに引き上げることである。これを推進するため、隔週のリーダーシップレビュー、共有トラッキング、チーム横断のコラボレーションチャネルを設けた。
チームは、5 つの一般的な介入パターンを特定し、実装した。コラボレーションを指定された時間帯に集約することでカレンダーの断片化を減らすこと、必須アジェンダと辞退の明示的許可によって会議衛生を改善すること、カレンダーツールと「午前は同期、午後は思考」という規範によって深い作業のブロックを保護すること、ダッシュボードデータを用いて外れ値のチームをコーチングすること、オンコールパターンや予定外の中断のような構造的障壁に対処することである。
8 週間以内に、成果指標は複数の EngThrive 次元で改善した。フォーカスタイムは開発者 1 人あたり週 2.1 時間増加し（対照群の 2 倍）、Bad Developer Days は 25% 減少した。これらが重要な結果である。なぜ改善したのかを理解するには、成果の向上と整合する形で変化した支援的な活動指標を見る。PR ベロシティは 13% 上昇し（対照群の約 4 倍）、これは約 350 人の追加開発者のアウトプットに相当した。しかし重要なのは速くなることだけではない。BDD の改善のうち、フォーカスタイム増加（BDD の構成要素）で説明できるのは半分だけである。残りは、チームが追加された能力を、悪い日を引き起こしていた技術的負債の削減に使ったことから来ているように見える。ステータス会議は 10% 減少し、会議中のマルチタスクは 8% 低下した（低品質な会議の代理指標）。一方で、マネージャーとの 1on1 は増加し、より強いリーダーシップ関与を示した。全体として、パターンは明確である。成果指標が改善し、活動指標がそのメカニズムを説明している。低品質なコラボレーションが減り、保護されたフォーカスが増え、より高品質な相互作用が増えた。それは他の次元を押しのけることなく起きた。
このケーススタディは、EngThrive の運用モデルを示している。妥当性検証済みの指標が可視性を生み、可視性がリーダーシップの注意を可能にし、リーダーシップの注意がチームにローカルな解決策を特定・実装する力を与え、改善が指標の価値を強化する。あるチームリードはこう述べた。「指標が問いを生み、問いが改善を生み、改善が指標の価値を強化した。」
Time-to-First-PR を「ゲーム化」しようとしたある実験は、興味深い結果をもたらした。約 4,000 人の開発者からなるある組織は、新入社員のオンボーディングを加速するため、意図的に些細な最初のプルリクエストを割り当てた。彼らは、この指標をゲーム化したいと思えばできることを発見した。Time-to-First-PR は 30% 改善した。しかし驚くべきことに、指標をゲーム化しても長期的には良い成果が生じた。この実験に参加した新入社員の開発者は、対照群と比べて、最初の 12 か月間に 23% 多くのプルリクエストを作成した。実験参加者へのインタビューは、その根本原因を明らかにした。最初のプルリクエストは、新入社員にとって、コードそのものに関するものではない。それは環境をセットアップすることに関するものだった。ツールとプロセスを学ぶことに関するものだった。チームの言語を学ぶことに関するものだった。
さらに、FirstMate と呼ばれる AI 支援オンボーディングツールは、Time-to-First-PR を 65% 短縮した。この効果は、最初の PR を容易にしたことによるものではなく、従来は新入社員を数日から数週間遅らせていた環境セットアップ、ドキュメント発見、コードベース理解を自動化したことによるものだった。
このケーススタディは、「成果」指標に焦点を当てる EngThrive の力を示している。たとえそれらが「ゲーム化」されても、その結果のインパクトは、優れたプロダクトをより速く、より簡単に構築するという成果を生み出す。
2020 年の燃え尽き危機の間、ある組織は、すべての開発者に「Health Days」と呼ばれる予定外の休暇を 2 日与える実験を行った。その期間中、予想通りプルリクエストのアウトプットは低下した。しかし「失われた」プルリクエストは 14 日以内にすべて取り戻され、一方で燃え尽きの緩和効果は 14 週間続いた [4]。これは Thriving ガードレールが機能している例である。Speed 指標ではコストが高く見えたウェルビーイング介入が、Speed 指標上は実際には無償であり、Thriving 指標上は非常に価値が高かったのである。両方を測定していなければ、その介入は失敗と判断されるか、そもそも試されなかっただろう。
EngThrive は開発者体験を測定するために構築された。しかし開発者の体験は、IDE、CI/CD パイプライン、AI コーディングアシスタントだけによって形づくられるわけではない。集中した、意味のある、高品質な仕事を行う能力に影響するすべての要因によって形づくられる。その中には、ソフトウェアとは無関係な要因も含まれる。これらすべての要因がエンジニアリングリーダーの変更権限内にあるわけではない。しかし、それらの影響を測定できることには価値がある。Speed、Ease、Quality、または Thriving への定量化された効果は、リーダーが、それを変えられる人々に主張するための証拠になる。
オフィス設計。 私たちは、より現代的なオフィスビルに移る開発者が、より協力的になり、よりエンゲージし、より生産的になることを測定している。そのメカニズムは謎ではない。自然光やより良い HVAC システムへのアクセスは、基本的な人間のニーズを満たす。それらのニーズが満たされると、人々のパフォーマンスは向上する。換気が悪く日光の少ない古い建物で開発者が働くと、コードが違うからではなく、人間が違う状態に置かれるため、エンジニアリングシステムが損なわれる。社内研究では、建物設計が開発者の全体的なエンゲージメントに最大 10% の差をもたらすことが示されている。
天候。 米国本土で最北の大都市であるシアトルでは、冬季の開発者のコーディングパターンを見ると、どの日が雪の日だったかが分かることがある。社内研究によれば、アウトプットが約 18% 低下するからである。理由は複合的である（育児、通勤の乱れ、気分）。しかし効果は実在し、AI ツールを評価するのに使われるのと同じ Speed 指標によって測定可能である。天候は変えられないかもしれないが（他のグローバルな健康イベントと同様に）、その影響を理解することは、計画目的やデプロイメントベロシティの予測に有用かもしれない。
方針。 組織の官僚主義が強いと知覚している開発者は、他社への転職を積極的に探している可能性が 70% 高い [12]。多くのリーダーがアウトプットを減らすのではないかと恐れる休暇時間は、アウトプットを減らさず、燃え尽きに対する意味のある防御を提供する。これらは技術の問いではなく、方針の問いである。しかし、同じフレームワークを通じて評価できる。
組織構造。 理想的な PM 対開発者比率、適切なマネージャーの管理範囲、出社義務化の影響。これらはエンジニアリングシステムではなく、人間システムに関する問いである。しかし、いずれも Speed、Ease、Quality、Thriving に影響し、EngThrive は他のあらゆるものに用いるのと同じ測定手段と分析アプローチによって、その影響を測定できる。
この普遍性は偶然ではない。EngThrive が持続的である理由である。ソフトウェアツールの影響だけを測定するフレームワークは、そのツールが変われば陳腐化する。エンジニアリング作業を行う人間の体験を測定するフレームワークは、どのようなツール、方針、組織構造が導入されていても関連性を保つ。なぜなら、その背後にある人間のニーズは変わらないからである。
私たちが話すすべてのエンジニアリングリーダーは、同じ問いを発する。AI は自分たちの開発者の生産性にどのような影響を与えているのか。EngThrive の強みは、AI が仕事の進め方を根本的に変える中でも、このフレームワークが持続性を保つことである。この持続性は、エンドツーエンドの開発者体験をまたぐ成果指標である Speed、Ease、Quality に焦点を当てていることに由来する。AI は、ボトルネックを取り除くことも、開発作業の進め方を再形成することもできる強力な新しいツールを導入する。AI は大きな改善可能性を提供するが、新しいオンボーディングプログラムや会議方針といった他の介入と同じフレームワークおよび指標を用いて評価されるべきである。問題は異なるかもしれないが、改善と変革を測定する原則は一貫している。
とはいえ、AI の影響は詳細に検討する価値がある。なぜなら、本稿全体で議論してきた多くの課題を浮き彫りにするからである。
開発者が報告していること。 AI ツールを定期的に使用している開発者のうち、88% はそれがタスクスループットを高めると述べ、82% は効率を高めると述べ、71% は顧客およびビジネス価値を届ける能力を高めると述べ、62% は仕事満足度を高めると述べ、49% は効果的に協働する能力を改善すると述べている [3]。影響は各次元で均一ではない。しかし、すべての次元に存在している。1 つの次元だけを捉える測定アプローチは、効果の大部分を見逃すことになる。
データが示すこと。 複数の研究は、AI の利用が PR ベロシティを高めていることを示している [3, 5, 9]。これは開発活動に意味のある変化が起きていることを示すが、あくまで活動シグナルであり、成果ではない。プルリクエストの増加は、それ自体では、より多くの価値が提供されたこと、インシデントが減ったこと、イノベーションが速くなったことを意味しない。まさにここで EngThrive の North Star 指標が重要になる。それらは、単に動きが増えているかではなく、私たちが進歩しているかを問うことを可能にする。Microsoft の 3,000 人の開発者を擁するあるエンジニアリング組織は、ライブサイト問題管理による労苦を減らすために Azure SRE Agent の採用に注力した。その組織では、Quality の North Star である Incident Mitigation Time が、会社全体の 2.4 倍の速さで改善した。これは統制実験ではなかったが、特定の問題に適用されたエージェント型 AI ツールが、活動の変化だけでなく、成果の測定可能な改善を生み得ることを示す証拠を提供している。
効果を調整するもの。 AI の影響は一様ではない。個人の利用頻度が重要である。AI を毎日使う開発者は、ときどき使う開発者と比べて、その便益に対する信頼を大幅に高く報告する。チームでの採用も重要である。同じチーム内で AI を使う同僚が増えるほど、個々の開発者が知覚する生産性向上も増える。これは、共有学習によって駆動される複利的なフライホイール効果を示唆している。そして組織文化も重要である。AI 採用を積極的に推進するチームでは、AI の生産性インパクトに対する信頼が約 10% 高い。正式なドキュメントを提供するチームでは、その信頼が約 3% 高い [3]。AI ツールを取り巻く文化は、ツール自体と同じくらい重要かもしれない。
AI 時代における活動と成果。 AI を考えるとき、インプットとアウトカムの区別は特に重要である。活動指標は、AI 支援作業が発生する条件を捉える。採用率、利用頻度、モデル選択、トークン消費などである。成果指標は、提供された価値を捉える。Idea-to-Customer time、Bad Developer Days、PRs-per-incident などである。重要な洞察は、AI が新しい活動指標を導入し、いくつかの活動成果物の再解釈を強いる一方で（例えば、AI 支援で書かれた PR は、完全に手作業で書かれた PR とは異なるが、どちらも価値を届ける）、成果指標は安定したまま残るということだ。成果こそが、AI が進捗を加速すべき North Star である。
最も重要な点はこれである。ツールがどれほど高度であるかは重要ではない。問いは依然として人間に関する問いである。人々はそれをどのように使っているのか。どのような文化がそれを可能にしているのか。どの摩擦が残っているのか。仕事は良くなっているのか。人々は大丈夫なのか。これらは、EngThrive がオフィスビルや会議方針について問うのと同じ問いである。AI はフレームワークの例外ではない。現在最も目立つ応用なのである。
多次元的な測定アプローチを採用しようとする組織に対し、私たちは自分たちの経験と、数十のエンジニアリング組織と協働した経験から得た実践的な指針を提供する。
不完全なデータでも始める。 すべての作業項目、コミット、コードレビュー、ビルド、デプロイ、フィーチャーフラグについて、精密でテレメトリ駆動のデータを持っているだろうか。もしそうなら、EngThrive に飛び込むには非常に恵まれた位置にいる。しかし、そのようなシグナルがまったくなくても、EngThrive に特化した具体的なサーベイと基本的なテレメトリを通じて、この領域に素早く入ることができる。サーベイはリアルタイムテレメトリを提供しないが、システム内の最大のボトルネックをすばやく理解し、Speed + Ease + Quality の North Star EngThrive 指標に関連する正確な測定セットを作成することを可能にする。
各次元につき 1〜2 個の指標を選ぶ。 各次元について、主観的シグナルと客観的シグナルのバランスをとる少数の指標を選ぶ。テレメトリから得たスピード指標と、サーベイから得た満足度質問を組み合わせる方が、テレメトリ指標を 5 つ並べるよりも有益である。指標の規律は重要である。指標が多すぎると焦点が希薄になり、実際に何が変化しているのかを特定しにくくなる。
継続的改善に焦点を当てる。 すべての指標には数値がある。しかし EngThrive の文化は継続的改善に焦点を当てる。第一歩は、自分たちが持っているデータを理解し、変化を生み出す介入を形成し、その変化を時間の経過とともに測定することである。
ゲーム化を予期し、それに合わせて設計する。 成果に焦点を当てる指標を選ぶ。正しいことを行うことで指標が改善できるなら、それを「ゲーム化」することは本物の改善と区別がつかない。誤ったことを行うことによってしか改善できないなら、別の指標を選ぶべきである。
反復する。 指標は生きたシステムである。今日あなたの組織にとって重要なものが、1 年後にも重要であるとは限らない。流行を追うためではなく、それらが依然として実際の優先事項や課題を反映していることを確認するために、定期的に指標を見直す。もはや有益でない指標は廃止する。現在の指標で捉えられない新しい課題が現れたなら、慎重に 1 つ追加する。
開発者生産性は多次元であり、深く人間的であり、単純な測定に頑固に抵抗する。研究コミュニティは、DORA、SPACE、DevEx を通じて、このことを確立するうえで大きな進歩を遂げた。
EngThrive は次の一歩を表している。原則から実践へ、フレームワークからオペレーティングシステムへ。Speed、Ease、Quality を中心に測定を整理することで、私たちは、実装できるほど具体的で、適応できるほど柔軟で、特定の技術サイクルを超えて持続できるほど堅牢な構造を提供する。
本稿で示したケーススタディは、このアプローチが機能することを示している。成果志向の指標を、リーダーシップの注意とチームのエンパワーメントと組み合わせることで、複数の次元にわたる測定可能な改善が同時に生まれる。また、それらは、単一次元かつ「活動」志向の測定が持つ危険性も示している。そうした測定は、意図しない副作用を生み、不完全な理解を与える。
おそらく最も重要なのは、EngThrive が単なる開発者ツール測定システムではないという点である。それは、開発者体験を形づくるあらゆるものを評価するための言語である。AI コーディングアシスタントからオフィスの HVAC システムまで、オンボーディングプログラムから組織の官僚主義までである。要因は変わる。しかし、スピード、容易さ、品質に対する人間のニーズは変わらない。
私たちは EngThrive を最終解としてではなく、優れた仕事をより速く、より簡単にできるようにし、さらにそれが機能していることを測定することが可能であるという、具体的な実証として提示する。私たちは、コミュニティがこの取り組みを採用し、適応させ、批判し、拡張することを歓迎する。
EngThrive の構築と運用に大きく貢献した Alex Kyllo と EngThrive チーム全体に感謝する。また、EngThrive の立ち上げを支援してくれた Jay Parikh、Lindsay Folk、Outi Rentola、People Analytics チームの協力者、EngThrive AI Impact Squad、Caitie McCaffrey、Nicole Forsgren、そして Microsoft 内外のすべてのパートナーにも感謝する。
[1] Forsgren, N., Storey, M.-A., Maddila, C., Zimmermann, T., Houck, B., and Butler, J. “The SPACE of Developer Productivity.” ACM Queue, 19(1), 2021.
[2] Forsgren, N., Kalliamvakou, E., Noda, A., Greiler, M., Houck, B., and Storey, M.-A. “DevEx in Action.” ACM Queue, 2024.
[3] Houck, B., Lowdermilk, T., Beyer, H., Clarke, K., and Hanrahan, C. “The SPACE of AI.” 2025.
[4] Houck, B. “SPACE in the Age of AI: Measuring What Matters for Developers.” Presented at STACK Conference, 2024.
[5] Peng, S., Kalliamvakou, E., Cihon, P., and Demirer, M. “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” arXiv preprint, 2023.
[6] Zimmermann, T., et al. “Time Warp: How Developers Actually Spend Their Time.” Microsoft Research, 2023.
[7] Teevan, J., Baym, N., Butler, J., Hecht, B., Jaffe, S., Nowak, K., Sellen, A., and Yang, L. (Eds.). “The New Future of Work: Research from Microsoft into the Pandemic's Impact on Work Practices.” Microsoft Research Tech Report, 2021.
[8] Houck, B. and Nachi, S. “Developer Productivity Engineering Summit.” Panel Discussion, 2025.
[9] DeBellis, D., Storer, K., Harvey, N., Beane, M., Edwards, R., Fraser, E., Good, B., Kalliamvakou, E., Kim, G., Maxwell, E., D'Angelo, S., Inman, S., Murillo, A., and Villalba, D. “DORA 2025 State of AI-assisted Software Development Report.” DORA, Google, 2025.
[10] Klinghoffer, D. and McCune, E. “Why Microsoft Measures Employee Thriving, Not Engagement.” Harvard Business Review, June 2022.
[11] Forsgren, N., Humble, J., and Kim, G. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.
[12] Houck, B., Yelin, H., Butler, J., Forsgren, N., and McMartin, A. “The Best of Both Worlds: Unlocking the Potential of Hybrid Work for Software Engineers.” Microsoft Research, 2023.