何が起きたか

LayerXのエンジニア杉野和馬が「開発生産性のその先へ、AI生産性について語りたい」と題したイベントで発表した資料が注目を集めている（Speaker Deck公開資料）。

40を超える国内外の事例を調査し、「個人は速くなったが組織は速くなっていない」というパラドックスを構造的に解剖した内容だ。DORA 2025の5,000名調査では主観的に+20%速くなったと感じている一方、客観的な実測では-19%という逆の結果が報告されているという衝撃的なデータが示されている。

杉野はこの状況を江戸時代の医学に例える。当時の解剖図（五臓六腑図）は実際の臓器配置と大きくずれていたが、解剖実験によって初めて正確な知識が得られた。同様に、AI生産性も「体感知」ではなく「実測による腑分け」が必要だというのが発表の核心だ。

6層の生産性モデルを詳解する

杉野が提示するフレームワークは6つの層で構成される。重要なのは「各層に抵抗があり、自動的に上位層へ波及しない」という構造だ。

graph TD L1["L1: ツール導入
GitHub Copilot・Cursor導入"] L2["L2: 個人生産性
体感速度 +20%
（実測 -19% の乖離）"] L3["L3: 接続・調整
チーム間の摩擦
レビューキュー膨張"] L4["L4: チーム・プロセス
CI/CD整備・WIP制限
Booking.com → +16%"] L5["L5: 組織デリバリー
システム全体の協調
大半が未到達"] L6["L6: ビジネス価値
実際のアウトカム
計測困難"] L1 -->|抵抗あり| L2 L2 -->|抵抗あり| L3 L3 -->|最大の壁| L4 L4 -->|抵抗あり| L5 L5 -->|抵抗あり| L6 style L3 fill:#ff9999,stroke:#cc0000 style L4 fill:#99ff99,stroke:#009900

L1 ツール導入: GitHub CopilotやCursorの導入が該当する。現在もっとも熱狂的に進んでいる層で、企業の大半はここに集中している。しかしツールを入れるだけでは組織は速くならない。

L2 個人生産性: 体感速度の向上。DORA 2025では5,000名の回答者が+20%速くなったと主観的に感じている。しかし客観的な計測では-19%という逆の結果が出ており、「速くなった気がする」という錯覚が問題を隠蔽する可能性がある。

L3 接続・調整: チーム間の摩擦が「組織の天井」として機能する層。個人がAIで実装速度を上げても、コードレビューのキューが詰まったり、要件定義が曖昧だったりすると、ここでブロックされる。多くの組織が越えられない最大の壁だ。

L4 チーム・プロセス: 構造的な整合性が整っている組織が到達できる層。Booking.com（3,500名超）はCI/CDの成熟とリーンプロセスの定着によってここに到達し、+16%のスループット改善を実現した。

L5 組織デリバリー: システム全体の協調が実現できる層。戦略・要件定義からデプロイ・運用まで、ライフサイクル全体でAIが機能している状態。大半の組織は未到達。

L6 ビジネス価値: 実際のビジネスアウトカムへの貢献。計測が困難で、ここまで到達している組織は世界的にも稀だ。

データが示す矛盾と「鏡と増幅器」

複数のデータソースが同じ矛盾を裏付けている。

データソース 調査規模 主な発見
DORA 2025 5,000名 主観 +20% vs 実測 -19%（体感と現実の逆転）
METR RCT（発表当時） 16名のOSS開発者、246タスク 個人PR +98%増加、しかし組織デリバリーは横ばい
Faros AI 10,000名超 コードチャーン率 3.1%→5.7%（AI導入後に悪化）
Faros AI（同） 同上 コピーペースト重複 1.5倍に増加
GitClear 2.11億行分析 CEO/CFO回答者の80%超が「AIは生産性に影響なし」
Booking.com 3,500名超 L4到達後 +16%スループット改善（成功例）

METR RCTのデータは特に示唆深い。16名のOSS開発者が246タスクで個人PRを+98%増加させた（これは公開されたランダム化比較試験の実際の結果として提示されている）。にもかかわらず、組織デリバリーは横ばいだった。この「98%増加しても組織は速くならない」という事実が、6層モデルの核心を証明している。

杉野はこれを 「鏡と増幅器」 の効果と表現する。AIは組織の既存の強みと弱みを増幅する。

  • 強みのある組織: 成熟したCI/CDとリーンプロセスを持つBooking.comは+16%改善
  • 弱みのある組織: レビュープロセス未整備 → レビューキューが膨張、テスト自動化不十分 → コードチャーン増大
「AIが組織を速くしない」のではなく「AI以前に必要なものがある」
杉野のメッセージは「AIを入れるな」ではない。L1-L2は必要な投資だが、そこで止まると鏡・増幅器効果で既存の問題が悪化する。L3-L4の基盤整備（自動化・プロセス・計測）と並行してAIを導入することが、組織全体の速度向上につながる。

自組織のAI導入層を診断する

#!/bin/bash
# DORAメトリクスを使った組織の現在地診断スクリプト（概念例）
# 実際にはGitHub Actions + データウェアハウスの連携が必要

# デプロイ頻度: L4以上の組織は週1回以上
DEPLOY_FREQ=$(git log --oneline --after="30 days ago" --merges | wc -l)
echo "過去30日のマージ数（デプロイ頻度の代理指標）: $DEPLOY_FREQ"

# リードタイム: コミットからデプロイまでの時間
# CI/CDが整備されていれば1日以内が目標
echo "--- リードタイム確認 ---"
git log --format="%H %ai %s" --merges -20 | head -5

# コードチャーン率の計算（AI導入前後の比較）
# Faros AI等のツールで計測する場合の指標
echo "--- コードチャーン率（概算） ---"
# 追加行数に対する削除・修正の割合
git diff --stat HEAD~30..HEAD | tail -1

# WIP（作業中アイテム）の状態確認
# GitHubのオープンPR数が多すぎる場合はL3以下で詰まっている
OPEN_PRS=$(gh pr list --state open --json number | jq length 2>/dev/null || echo "gh CLIが必要")
echo "現在のオープンPR数（WIP指標）: $OPEN_PRS"
自組織のAI導入レイヤー診断チェックリスト
L1: AIコーディングツール（Copilot/Cursor等）を導入済みか
L2: 個人の実装速度が体感で上がっているか（ただし主観バイアスに注意）
L3: コードレビューの平均待ち時間が48時間以内か。要件定義の曖昧さが頻発していないか
L4: CI/CDが全フロー自動化されているか。テストカバレッジは維持されているか。DORAメトリクスを計測しているか
L5: AIが要件定義・設計・デプロイ・運用まで関与しているか
L6: AI投資がビジネスKPI（売上・コスト・顧客満足）に紐づいて計測されているか

40+事例が示すAI投入の偏り

杉野が40超の事例を分析した結果、AI導入の集中地点が明確になった。座標軸（横軸：スコープ＝個人/チーム/組織、縦軸：ライフサイクル工程）にプロットすると、「実装×個人」の象限に極度に集中している。

一方でほぼ空白なのが以下の領域だ。

  • 戦略・要件定義: AI活用事例がほぼ存在しない
  • デプロイ・運用: Infrastructure as CodeへのAI適用は増えているが、まだ少数派
  • チーム・組織スコープ: 個人ツールのチーム適用事例は増えているが、組織全体の変革事例はほぼない

この「空白領域が次の投資機会」というのが杉野のメッセージだ。競合がまだ気づいていない場所にAIを適用できれば、差別化要因になり得る。

OpenHands のようなAIコーディングエージェントも、個人の実装速度向上という「L2」の事例だ。それをチーム・プロセスレベル（L4）まで組織的に展開できるかが、2026年の開発組織の差別化要因になるだろう。

エンジニアリーダーへの実践的示唆

このフレームワークをどう実務に活かすか。

まず診断から始める: 自組織が今どのレイヤーにいるかを可視化する。上記の診断チェックリストを使って「L3の壁」を特定する。

L3の壁を突破する: コードレビューの待ち時間短縮（レビュー担当者のアサイン自動化、PR分割の徹底）、要件定義のテンプレート化・自動チェック、テスト自動化の強化。これらがL4への入り口だ。

AI投入と並行してプロセス整備: AIツールを導入しながら、同時にCI/CD・テスト・監視の整備を進める。順序ではなく並行実施が重要。「基盤が整ってからAIを入れる」では遅い。

計測する: 「速くなった気がする」だけでは不十分。DORAメトリクス（デプロイ頻度・リードタイム・変更失敗率・復旧時間）を計測し、体感バイアスを排除する。

Apache Airflow などのワークフロー自動化ツールも、L4以上の組織が「データパイプライン全体のAI化」に取り組む際の基盤として機能する。インフラの自動化・可観測性の向上がL4突破の鍵になる。

参照ソース