AI変革はシステムの問題である：DXのJustin Reock氏との対話
この記事では、AI変革が根底にあるシステムの問題を露呈すると論じています。DXの調査ではPR速度の中央値上昇は7.5%ですが、トップパフォーマーはシステム設計により70%に達します。エンジニアがコードを書く時間は16%のみで、AIはその16%にしか影響しません。歴史的・現代の研究は、システム（モジュール化されたコード、高速CI、優れたドキュメント）が生産性を決定することを示しています。リーダーは個人の最適化ではなく、バリューストリームマッピングに注力すべきです。
私が話すすべてのエンジニアリングリーダーは変革を試みています。彼らはチームをAIネイティブにしようとし、ツールを導入し、採用率を追跡し、ダッシュボードを見つめています。しかし、より難しい質問は、ほとんどのリーダーが声に出して尋ねないものです：私たちは実際に何を変えようとしているのか？成功はどのように見えるのか？これについてどのように考えるべきか？
DXのCTOであるJustin Reock氏は、毎日エンジニアリングリーダーとまさにこれらの質問について話し合っています。DXは、数百社の数十万人のエンジニアからのテレメトリーと調査データを収集しており、2024年11月から2025年2月までの500社のPR速度を追跡した長期研究も含まれています。私は最新のエピソード「We Built What」で彼にインタビューしました。データは明確なストーリーを語っています：AIは常に存在していたシステムの問題を露呈しているのです。現在勝利している企業は、それを見抜いている企業です。
データは冷静になるように告げています。また、あなたが間違ったものを見ていたことも示しています。
DXの研究の主要な数字：PR速度の中央値上昇は7.5%、平均は13%、最高パフォーマーは70%に達しました。
「全体の生産性が10%や15%向上するなら、誰が投資しないでしょうか？」とJustin氏は尋ねました。「私たちは10%や15%が実際に成功であるという寛容さを自分自身に許し始める必要があると思います。」
これはほとんどのリーダーが聞く必要のある再調整ですが、データが教えてくれる最も重要なことではありません。
AtlassianのDevEx研究は一貫して、エンジニアが実際にコードを書く時間は約16%であることを示しています。Justin氏はその意味を明確にしました：「書き換えやリファクタリング、レビューが不要で瞬時に完了する100%正確なツールがあったとしても、問題の16%にしかアプローチしていないことになります。」
AIをその16%に向けて残りの84%に触れなければ、一桁台の生産性向上はまさに期待すべき結果です。
システムの教訓はDevExよりも古い
これは新しい発見ではありません。1970年代のコーディング戦争ゲームは、50年にわたって続く何かを見つけました。異なる組織間で、トップパフォーマーは最下位パフォーマーの11倍の成果を上げました。同じ組織内では、個人間の差はわずか20%程度でした。
その数十年前、W. Edwards Deming氏はさらに明確に述べています：組織の生産性出力の90%から95%は、労働者ではなくシステムによって決定される。
Googleも最近同じことを再発見しました。180のチームを調査して最高のチームの要素を特定したところ、チームの構成は重要ではなく、規範が重要でした。同じ個人があるチームで成功し、別のチームで苦労することがあります。パフォーマンスの最強の予測因子は、チームが埋め込まれているシステム、マネージャー、そしてチームです。
AIはこれを変えません。むしろ増幅します。強力なAIツールを遅くて順次的なゲートが多い作業用に設計されたシステムに導入すると、根本的に制約されたパイプラインにわずかな改善をもたらすだけです。同じツールをフロー用に設計されたシステム（モジュール化コード、新鮮なドキュメント、高速CI、実験の心理的安全性）に導入すると、70%の向上が得られます。
「システム」が実際に意味するもの
Justin氏は、DXのデータで最もパフォーマンスの高い企業に共通する点を挙げました：
コードのモジュール性とアクセス可能で最新のドキュメント。古いドキュメントと絡み合ったコードは、エンジニアの痛点であるだけでなく、推論の入力でもあります。
高速なCI/CDパイプライン。ビルドに40分かかる場合、エージェントのフィードバックループも40分かかります。
教育と吸収する時間。DXのデータは直感に反することを示しました：軽度のAI導入は実際に生産性を低下させます。中程度から重度の導入だけが非導入を上回ります。学習曲線は現実であり、時間、安全に失敗できるプロジェクト、実験の心理的安全性が必要です。
エージェントオーケストレーションと優れた推論パイプライン設計。Justin氏の例：高温モデルで品質ルーブリックを生成し、低温推論モデルでそれを検証する。
「人間にとって良いことはエージェントにとっても良いことです。過去10年間、組織が優れた開発者体験のために行う必要があると言われてきたことすべてを、彼らがようやく気にし始めたのは、トークンにあまりにも多くのお金を費やしているからです。」
システムが何かを知ることは一つですが、システム内の摩擦が実際にどこにあるかを知ることは別です。
エンジニアではなくバリューストリームをマッピングする
システムを修正する前に、それを見なければなりません。Justin氏の推奨は、ほとんどのチームがスキップする遅くてコストのかかる作業、つまり実際のバリューストリームマッピングを行うことです。リーダーと座り、アイデアから収益または証明された顧客価値までの価値を追跡します。
ほとんどのチームがこれをしないのは、サイクルタイムの測定が簡単だからです。PR承認からリリース、チケットオープンからクローズ。これらの数字はプロセスの中間の摩擦を示します。しかし、真のボトルネックは通常、別の場所にあります：上流のアイデア出しと優先順位付け、または下流の展開、採用、収益化にあります。
Justin氏はEli Goldratt氏を引用しました：ボトルネックではないものに費やされた1時間は無価値です。
エージェントエクスペリエンスは新しい開発者エクスペリエンス
システムの議論は次の時代にまで及びます。ハイブリッドな人間・エージェントチームはすでに普通です。システムは両方の集団に対して機能しなければなりません。
Justin氏はDXがすでに行っていることを共有しました：彼らは開発者エクスペリエンス調査をエージェントにも送り始めています。エージェントがタスクを完了すると、人間と同じ調査を受けます。彼らはそれをエージェントエクスペリエンスインデックスと呼んでいます。
「開発者エクスペリエンスが開発者生産性の先行指標であるなら、エージェントエクスペリエンスはエージェント生産性の先行指標になるでしょう。」
私たちが人間のために構築してきたクリーンなドキュメント、モジュール化コード、高速フィードバックループは、エージェントのパフォーマンスを決定するまさにその入力です。システムは両方のために機能するか、どちらのためにも機能しません。つまり、開発者エクスペリエンスのためにすでに行った作業はレガシー投資ではなく、エージェント戦略が実行される基盤です。
エンジニアリングリーダーの仕事は依然としてシステムに関するもの
Justin氏は直接的に述べました：開発者エクスペリエンスは人よりもシステムに関するものです。これにより説明責任はリーダーシップに戻ります。あなたの仕事は個々のエンジニアからより多くを引き出すことではなく、エンジニアとエージェントが努力を成果に変換できるシステムを設計することです。
「私たちは個人に焦点を当てすぎて、システムに十分に焦点を当てていません。そしてそれは修正すべきことだと思います。本当に視野を広げれば、これらの投資から望むフローと見返りを生み出すためのより創造的な応用を見つけることができます。」
バリューストリームを追跡し、真のボトルネックを見つけてください。ドキュメント、ビルドパイプライン、モジュール性、学習文化を修正してください。人間とエージェントの両方が繁栄するシステムを構築してください。なぜなら、同じものが両方を生産的にするからです。
コード生成だけではAIネイティブにはなれません。システムがそうさせるのです。
「We Built What」の完全なエピソードを、DXのCTO Justin Reock氏とともにYouTube、Spotify、またはApple Podcastsでお聴きください。7.5%の中央値が良いニュースである理由、エンジニアの一日の間違った16%を最適化する罠、そしてなぜJustin氏が今がソフトウェアエンジニアになるのに最適な時期だと考えるかについて話します。
執筆者：Emma Webb、コミュニケーション責任者、Augment Codeでコミュニケーションを統括。以前はCircleCIとCourseraに在籍。エンジニアリング組織が、クラフト自体が変化する中でどのように仕事を説明するかに関心を持ち、エンジニアリングリーダー向けポッドキャスト「We Built What?」をホストしています。