【Team '26レポ】「10xエンジニアは神話だが、10x組織は実在する」―DX社 CTO Justin Reockが語る、AI時代の開発者生産性の指標とは

Atlassianの公式カンファレンス「Team '26」では、ソフトウェア開発の生産性や、開発者体験に焦点を当てた多くのセッションが行われました。
本記事ではその中から、2025年11月に Atlassian社にジョインした、DX（ディーエックス）社の Deputy CTOであるJustin Reock氏によるセッション「生産性10倍組織をつくりあげる（Building 10x organizations: Modern productivity metrics）」の内容をご紹介します。

本セッションでは、AIコーディングツールの導入が進んだ一方で、その投資効果の測定に多くの組織が苦戦している現状に対し、その「測り方」そのものを見直すための、実践的なフレームワークを提示しています。

1. 登壇者の紹介：Justin Reock氏と DX社の Atlassian参画

Justin Reock氏は、DX社のDeputy CTO（最高技術責任者補佐）です。開発者の生産性（Developer Productivity）と開発者体験（Developer Experience）を専門分野とし、20年以上の経験と、500を超える組織から収集したデータをもとに、エンジニアリング生産性の測定と改善を継続的に研究しています。

2. 製品としての「DX」について

製品「DX」は、Atlassianの Software Collectionを構成する4製品（Rovo Dev／Bitbucket／Pipelines／DX）の1つで、「エンジニアリングインテリジェンスプラットフォーム」として位置づけられています。

その目的は「開発者の生産性と体験を、定量と定性の両面から測り、改善サイクルを回せる状態にする」ことです。具体的には、開発者サーベイによるインサイトと、AIエージェントのワークフロー全体を対象とした生産性指標の2軸で構成されています。

Team '26では、AI投資効果を可視化する新機能「AI Code Insights」も発表されました。
同時に公開された DX社の長期調査データは、重要な示唆に富むものでした。AIコーディングツールの導入率は65%増加した一方、プルリクエストの加重スループット向上はわずか約10%。エンジニアがコーディングに費やす時間は全体の約16%にすぎず、残り84%は要件の明確化・会議・コードレビュー・情報収集などに費やされていることが示されました。

ここから明らかになるメッセージは、コード生成だけでなく、ソフトウェア開発ライフサイクル全体の改善が必要である―本セッションは、この問題意識を、理論と実装の両面から深掘りするものです。

3. 本セッション「Building 10x organizations: Modern productivity metrics」の詳細

本セッションの内容は、多くの組織が開発者の生産性を「間違った方法」で計測している現状を指摘し、成果（アウトカム）ではなく活動量を追いかけている状況に警鐘を鳴らすものです。そのうえで、開発者の生産性をどう測るべきかという長年の問いに対する、DX社独自フレームワークとして「DX Core 4」を紹介しました。

• セッションURL：https://events.atlassian.com/team/session/4010208/building-10x-organizations-modern-productivity-metrics

3.1 「10xエンジニアは神話だが、10x組織は実在する」

セッションの出発点は、長年にわたって語られてきた「10xエンジニア」という幻想の否定です。Justin氏は冒頭で、書籍『Peopleware』に収録された1980年代の「The Coding War Games」研究を引用し、約700名のエンジニア・100組織規模の調査結果を示しました。

そこで明らかになったのは、同一組織内のエンジニア間の生産性差はわずか21%に過ぎない一方、組織間の差は11倍にも及んでいるという事実です。

高パフォーマーは特定の組織に集まっており、低パフォーマーは別の組織に集中している。つまり「優秀な個人が10倍の成果を出す」のではなく、組織のシステムや文化こそが生産性を決めているというのです。

セッションスライドより

ここでJustin氏は、品質管理の権威である、W. Edwards Demingの言葉を引用します。

「組織の生産性の90〜95%は、ワーカーではなくシステムが決定する」。

そのうえで、本セッションの本質は 「開発者体験は人ではなくシステムの問題である」 という点に集約されるのだと述べました。

3.2 制約理論とフローの神経科学

続いて Justin氏は、Eli Goldrattの書籍『The Goal』で提示される制約理論と、フロー状態を支える脳科学の両面から、システム改善の意味とは何かについて掘り下げます。

制約理論とは、ビジネスを「コスト」「インベントリ」「スループット」に分解できる複雑な機械として捉え、コスト削減ではなくスループット（価値の流れ）の最大化を優先すべきだと説くものです。ソフトウェア組織でいえば、コードという在庫をどれだけ早く価値あるアウトカムに変換できるかが本質です。開発組織においては、「コスト削減ではなく、スループット（＝ビジネスにもたらすお金と価値）の最大化を優先せよ」というメッセージです。

セッションスライドより

どうすればエンジニアの集中力を最大化できるか

脳科学では、フロー状態（人が目の前の活動に極限まで没頭し、時間感覚や自我を忘れてしまう心理状態）は、前頭前野と長期記憶の連携によって生まれる高パフォーマンス状態とされています。一つの作業が終わっていないのにすぐに対応しなければならない課題に取り組むなどのコンテキストスイッチが起きると、グルタミン酸が前頭前野に蓄積し、認知疲労を招くことになります。そのため、Justin氏は、重要なポイントとして、コンテキストスイッチを最小化しフローを延ばす設計が、組織の革新能力に直結すると指摘しました。

3.3 生産性指標の系譜と「単一指標の罠」

ここからがセッションの中心テーマである、開発者生産性に関する指標についての話題です。Justin氏は、開発者生産性を測るためのフレームワークの系譜を次のように整理しました。

Justin氏は、フレームワーク「SPACE」について、単なる「指標リスト」だとする誤解を否定しています。「SPACE」は5つの次元であり、複数の指標を緊張関係に置くための枠組みであるとし、単一指標に依存すると、Goodhart's Law（指標が目標になると、その指標は良い指標ではなくなる）の罠に陥ると言います。

セッションスライドより

多くの組織において、現場とマネージャー間で生産性の認識が揃っていない実態があり、この危険性の象徴として「コブラ効果」が引用されました。インド植民地時代、コブラ駆除の報奨金制度を導入したところ、むしろ人々がコブラを養殖するようになり、制度廃止後に問題が拡大した―という話です。単一KPIへの過度な依存が、現実をかえって悪化させることを示すエピソードです。

3.4 DX Core 4 と定性データの威力

セッションのクライマックスが、DX社が提唱する生産性に関するフレームワーク 「DX Core 4」の紹介です。DORA・SPACE・DevEx を統合した、4次元構造になっています。

セッションスライドより

Justin氏は「個人ではなくチームレベルで測ること」を繰り返し主張しました。たとえばメンタリング専任のシニアエンジニアは、個人のPR数こそ少なくとも、チーム全体の生産性に不可欠だからです。

定性データの重要性についても、具体的な数字が共有されました。
DX社のサーベイでは、顧客の約半数が参加率100%、23,000名規模の最大顧客でも97%を達成しているといいます。Justin氏は「これだけ高い参加率があれば、定性データは定量データ以上に信頼できる」と語り、システム指標と定性質問への回答が一致しない場合は、まずシステム側を疑うべきだと指摘しました。

3.5 顧客事例：データを「使う」サイクル

本セッションでは、3社の事例も紹介されています。Vanguard社では、CIOから現場のチームリーダーまで「DX」の測定結果を共有し、全員で改善を議論する文化を構築。John Lewis社においては、チームの困りごとを特定し、支援の優先順位付けに活用。また、Pfizer社では、データを起点に主任エンジニアを設置し、契約社員の入れ替わりが生産性を削いでいる主因であると突き止め、ドキュメント整備と引き継ぎ作業の合理化を進めました。

Justin氏は、各指標をダッシュボードに並べるだけでは意味がないと強調します。「シグナル → 優先順位付け → アクション → 再評価」 という継続的改善のフライホイールを回せる組織だけが、実際の成果を得られる―これがセッションを通じての一貫したメッセージでした。

3.6 AI時代の生産性測定

セッションの後半では、AIの登場が、生産性の測定をどう変えたのかというテーマに移ります。

Justin氏はこの3年間を、
2024年：全開発者へ Copilotを配布した時代
2025年：エージェントを構築した時代
2026年：「活用のためのインフラが準備できていなかった」ことに気づいた時代
として総括しました。

2024年11月〜2026年2月にかけての調査では、AIによる失敗率の推移は企業間で大きくばらついていました。AIの恩恵は均等には行き渡らない―業界平均で語ることの危険性が、ここに表れています。

そこで重要になるのが「AI Readiness」という考え方です。Justin氏は次のように言います。
「人間にとって良いものは、エージェントやLLMにとっても良い」

明確で正確なドキュメント、関係性が直感的なデータ構造、保守しやすい標準化されたコード、高速で信頼できるCIと堅牢なテスト―これらは結局のところ、もともと「よい開発者体験」と呼ばれていたものに他なりません。「AI投資を契機に、ようやくこれらに本気で取り組めるようになったのだ」というのが Justin氏の見解です。

AIに関する測定としては、(1) APIから取れる計測結果、(2) ワークフロー内の細かな経験サンプリング（ESM）、(3) 開発者サーベイ、という3層を組み合わせることが提案されました。計測結果は「何が起きているか」を教えてくれますが、その投資が本当に効いているかどうかは、結局のところ基礎的な生産性指標でしか判断できない、というのが結論です。

セッションスライドより

3.7 セッションの結び

セッションの最後に、Justin氏は次のように締めくくりました。

「生産性を測ること、開発者体験を定義することは、AI登場前から非常に難しい問題だった。しかし、現状で利用可能な最善の方法は見つけられたと思う」

AIによってあらゆる物事が加速するなかでも、「人とシステムをどう設計するか」という本質的な問いは変わらない―これが、本セッションを通じて Justin氏が伝えたかったことだと言えます。

4. リックソフトとしての示唆

本セッションの理論的な枠組みは、当社にとっても示唆に富むものです。「AIコーディングツールの導入は伸びているが、スループットの改善は限定的」というデータは、AIを入れただけでは効果が出にくいという現実を示しています。そのため、測る・可視化する・改善するサイクルを回せる仕組みを実現することこそが、Software Collection（製品「DX」を含む）の価値だと整理できます。

また、今回示された「DX Core 4」は、DORA・SPACE・DevExを統合的に理解するための見取り図でもあります。個人ではなくチーム単位で、定量と定性を両方見るというアプローチは、多くのエンジニアリング組織でも参考になる視点ではないでしょうか。