AI時代のエンジニアリングマネージャーは何が変わったか——EMの仕事が増えた理由

「AIを入れたのに、チームが速くなった実感がない」。そう感じているEMは、実はデータ的に正しい感覚を持っている。2025年7月にMETRが発表したRCT（ランダム化比較試験）では、大規模オープンソースリポジトリに5年以上貢献してきた熟練開発者16名がAIツールを使って246件のタスクに取り組んだところ、完了時間が19%増加（つまり遅くなった）していた。一方で開発者自身はAIツール使用前に「24%速くなる」と期待し、使用後も「20%速くなった」と自己評価していた。

この認知ギャップこそが、AI時代のEMが直面している本質的な問題だ。「減った仕事」と「増えた仕事」の対比を軸にEMに何が起きているかを整理し、今週から始められる具体的な行動を示す。

AIツールを入れたのに、チームは速くなっていない

Jellyfish「2025 State of Engineering Management Report」によると、AI開発ツールの採用率は90%（前年比61%から急増）に達した。生産性向上を報告した組織も62%に上る。ところが、そのAI活用の効果を「測定している」組織はわずか20%にとどまる。

この数字が示すのは単純な話だ。「使っている」と「効果がある」の間に、誰も橋を架けていない。

さらにGitClearが約2億1100万行のコード変更データを分析した2025年の研究報告では、AIツール普及と連動して気になる指標が浮かび上がっている。書いてから2週間以内に廃棄されるコードの比率（コードチャーン）は2020年の3.1%から2024年には5.7%へと増えた。コピー&ペーストとみなされるコード比率も8.3%から12.3%に上昇し、リファクタリング比率は24.1%から9.5%に落ちた。

「速く感じる」と「速く出荷できる」の決定的な違い

AIツールは個人のタスク完了数を押し上げる。Jellyfish 2025の調査では、AIツール採用率が高い組織ほどPRスループットが大幅に向上するというデータがある。一見すると生産性が大きく改善したように見える。

しかし組織全体のデリバリーメトリクスは横ばいが続く。PRが増えてもレビューキューが詰まり、AI生成コードの品質チェックに時間がかかり、結果的にリードタイムが縮まらない。「個人の速さ」と「チームの速さ」は別の話だ。

なぜこのギャップが生じるのか。構造的に言えば、AIが定型業務を吸収することで残る業務は本質的複雑性（ビジネス要件・組織設計・人間関係の難しさ）に集中する。そしてその本質的複雑性を扱えるのはEMしかいない。この因果を踏まえずにAIを導入しても、チームは加速しない。

Claude Codeをチームに導入する際のEM視点の設計手順は、こうした導入判断の具体的な補助線になる。

なぜEMだけがこの計測ギャップを埋められるのか

チームメンバーは自分の仕事の速さしか観測できない。経営層は定量的な売上・コスト指標しか見ていない。組織全体のデリバリーと個人の体感の間にいて、両方の言語を話せるのがEMだ。計測の責任を誰かが担わなければ、投資は続くが効果は見えないまま、という状態が続く。

そもそもEMとは何を「管理する」仕事か——4Pフレームで整理する

AIの話に入る前に、EMの仕事の輪郭を一度確認しておく。

EMの責任領域は大きく4象限に整理できる。People（採用・育成・1on1・心理的安全性）、Product（プロダクト理解・ステークホルダー調整）、Process（アジャイル運営・デリバリー管理）、Technology（技術的意思決定の支援・アーキテクチャ理解）だ。

広木大地氏（レクター取締役）は類似の整理を「4P（ピープル・プロジェクト・プラットフォーム・プロダクト）フレームワーク」として提唱し、EMConf JP 2025（2025年2月27日）の基調講演で「EMは4つすべてができるスーパーマンである必要はないが、理解している必要がある」と述べた。

TL・TLM・EMの違いと「全部できる人は不要」の原則

テックリード（TL）はICとして最高技術判断を担う。People管理は原則行わない。TLM（テックリードマネージャー）はその小規模版で、IC業務を兼務する。そしてEMはPeople管理が主軸で、チームのアウトカムと育成・組織設計を担う。

EMに求められるのは「技術者として最強である」ことではなく、「チームが機能するシステムを設計・維持する」ことだ。AI時代においてこの定義は変わらないが、システムの中に「AIエージェント」という新しいメンバーが加わった。

AIが「減らした」EMの仕事——コードレビュー定型と育成の答え合わせ

AIが確かに減らしたものは存在する。そこは正直に認めるべきだ。

コードレビューの定型部分はAIへ、アーキテクチャ判断はEMへ

GitHub Copilot Code Review（2025年4月にGAリリース、公開プレビュー開始から1か月強で100万人超が利用）の登場で、スタイルガイド違反・バグパターン・単純な論理エラーはAIが自動検出するようになった。

ただし「レビュー文化を捨てていい」という話ではない。CodeRabbitの調査ではAI生成コードは人間記述コードより1.7倍多くの論理・正確性バグを含む。AIが見落とすのは定型エラーではなく、アーキテクチャ上の判断ミス・ビジネスコンテキストの逸脱・セキュリティの思慮不足だ。EMの役割は「何をAIに任せ、何を人間がレビューするか」の設計に移行した。

AIをコードレビュアーとして組み込む具体的な実装手順はAIをコードレビュアーとして組み込む3段階の実装パターンに詳しい。

「コードを貼るだけで理解しない」問題への対処

定型的なメンタリング時間も減った。AIツールを活用したオンボーディングでは、新人エンジニアのファーストPRまでの時間が大幅に短縮されたとの報告が複数ある。「この関数の意味は何か」「なぜこの実装にしたのか」という定型質問をAIが即答するためだ。

しかしMicrosoft社の2025年調査では、AIを日常的に使う開発者は「クリティカルシンキングの必要性が下がった」という自己評価を持ち、問題解決への主体的関与度も低下する傾向が示された。コードを貼るだけで理解しないジュニアエンジニアが増えるという、育成の新たな課題がEMに生まれた。

答え合わせが得意なAIと、なぜそうなるかを一緒に考えるEMの役割は、むしろはっきり分かれた。ジュニアエンジニアの育成設計については「コードを貼るだけで理解しない」を防ぐ育成設計で扱っている。

AIが「増やした」EMの仕事——ガバナンス・計測・エージェント境界設計

ここが記事の核心だ。EMの仕事が増えた理由は、AIが定型業務を吸収した結果、残った仕事が全て「本質的複雑性」（ビジネスの曖昧さ・組織の摩擦・人間の感情）になったからだ。

AIが減らした仕事 vs 増えた仕事

カテゴリAIが減らした仕事AIが増えた仕事
コードレビュー定型エラー検出・スタイル違反指摘アーキテクチャ審査設計・Tier分類
育成・メンタリング定型Q&A・コード説明クリティカルシンキング指導・AI依存リスク管理
生産性管理ステータス更新・会議サマリー作成AI効果の客観計測・DORA × AI指標設計
コード品質単体テスト生成（一部）コードチャーン監視・AI起因バグ追跡
エージェント管理—（新領域）Tier A/B/C境界設計・ガバナンスポリシー

AI生成コードのリスクをTier A/B/Cに分類する

まずEMが手をつけるべきは、AIガバナンスのガードレール設計だ。

Augment Codeが提唱する「Agentic Engineering Operating Model」の三層モデルが参考になる。Tier A（人間のみ）はアーキテクチャ決定・セキュリティポリシー。Tier B（AI生成→人間承認）は要件検証・コード承認。Tier C（自動実行）はユニットテスト・依存関係更新だ。

この分類がなぜ必要かは数字が示している。CodeRabbitの調査ではAI支援コードは人間記述コードより1.7倍多くの論理・正確性バグを含む。Veracodeが2025年に100以上のLLMをテストしたところ、全体の脆弱性率は45%、Javaでは72%の失敗率が確認された。「AIが書いたから大丈夫」という発想を組織レベルで放置すると、EMは後になってインシデント対応に追われることになる。

DORA + リワーク率 + AI帰属インシデント率の3点測定

もう一つ、客観的な計測体制の構築がある。

従来のDORAメトリクス（デプロイ頻度・変更リードタイム・変更失敗率・平均復旧時間）は、AI時代において「個人のコード出力増加 → 組織のデリバリー改善」という単純な相関が成り立たなくなってきている。DORA自身も「Rework Rate（手戻り率）」と「Reliability（信頼性）」を新たな指標として追加した。

EMが計測すべき指標は絞って考えたほうがいい。DORAの基本4指標でベースラインを確認し、AI支援PR比率とコードチャーン率（GitClearの警戒水準5.7%超を参照）、そしてAI帰属インシデント率、つまりAIが関与したPRから発生したインシデントの比率を見る。この3つで十分だ。

METRのRCTが示した「19%遅くなる」という衝撃の背後には、計測していないからこそ見えていなかった遅さがある。自己申告の生産性感覚を鵜呑みにしないための計測設計は、今やEMの基本職務だ。AIツールのROIを経営層に説明するフレームワークとして「効果あるんですか」に数字で答えるROI計測フレームワークも参照してほしい。DORAメトリクスとAI活用を組み合わせた具体的な計測手順はDORAメトリクスでAI時代のチーム速度を測る具体的方法にまとめた。

「何を人間が判断し、何をエージェントに任せるか」の境界設計

三つ目の領域は、AIエージェントのオーケストレーション設計だ。

LangChain「State of Agent Engineering 2025」調査（2025年11〜12月、1,340人回答）によると、AIエージェントを本番稼働させている組織は57.3%に達したが、大企業以外では評価・実験段階にとどまるケースが多い。しかしClaude Codeをはじめとするエージェントが「チームの一員」として機能し始めた今、EMには「どこまで任せるか」の境界を明文化する責任が生まれた。

Amazonは2024〜2025年にかけてICとマネージャーの比率を少なくとも15%引き上げる方針を打ち出し、Morgan Stanleyは約14,000の管理職ポジションが削減される可能性があると試算している。エージェントが一部の中間管理的業務（ステータス更新・進捗追跡・会議サマリー）を担い始めた結果、「AIの仕事を整理する人間」の価値が高まっている。

「全エンジニアがEMになる」——広木大地が示した本物のEM像

EMConf JP 2025基調講演（2025年2月27日）で広木大地氏はこう述べた。

「全てのエンジニアは、AIをメンバーに持つエンジニアリングマネージャーになる」

AIツールが普及し、各エンジニアがAIに指示してコードを生成させる存在になるとき、個々のエンジニアは委譲・フィードバック・タスク分割というマネジメント的思考を日常的に行う。

「偶有的複雑性」をAIに、「本質的複雑性」をEMに

ここで登場する重要な概念が「偶有的複雑性」と「本質的複雑性」だ。偶有的複雑性とは、技術的な制約や実装上の難しさだ。ライブラリの使い方、テストの書き方、定型コードの記述など。本質的複雑性とは、ビジネス要件の曖昧さ・組織の利害対立・人間の感情や動機の複雑さだ。

AIが削減しつつあるのは前者の偶有的複雑性だ。後者の本質的複雑性、「このプロダクトは何を解決すべきか」「このメンバーはどんな成長を望んでいるか」「チームの心理的安全性が下がっている根本原因は何か」、これはAIには扱えない。

「AIで自分の仕事はなくなるのでは」という不安を持つEMは少なくない。それは誠実な問いだが、なくなるのは定型的な調整業務であって、本質的複雑性を扱う仕事ではない。むしろ偶有的複雑性をAIが吸収した分、本質的複雑性に集中できる環境が整いつつある。

ハイブリッド化するEM、技術理解なしのEMが切られる理由

LeadDevの調査によると、2023年のレイオフで削減された管理職の比率は32%に上る。背景にはGitHubの分析が示すCopilot導入後のプロジェクト管理活動の25%低下がある。ステータス更新・進捗追跡・会議のサマリー作成という「調整業務中心のEM」の存在価値が薄れた。

生き残るEMに求められるのは、アーキテクチャ・パフォーマンス・スケーリングへの技術的理解と、AIツールを活用したプロトタイピング・チケット処理能力、そしてステークホルダーへの技術的な説明力だ。非技術系EMの終焉は、EMの仕事が「管理」から「技術的コンテキストを持つオーケストレーション」へシフトしていることを意味する。

LeadDev 2025 Engineering Leadership Reportでは65%の経営陣が責任範囲の拡大を報告し、40%がより多くの部下を管理していると回答している。少ないシートにより多くの責任。この構造に対応できるEMだけが価値を発揮できる。

今週やること。AI時代のEMが始める3つのアクション

論考はここまでにして、具体的な行動に移る。

アクション1: AIツール採用率の基準値を測る

チームのAIツール月次アクティブユーザー率（MAU）と日次アクティブユーザー率（DAU）を計測する。エリート組織のベンチマークはMAU 80%以上、DAUのPower user density 40%以上だ。まずは現状把握から始める。GitHubや社内の利用ログから取れる場合は今週中に数値を出す。取れない場合は簡単なアンケートでも構わない。「測定していない20%」から抜け出すことが最初のステップだ。

アクション2: AI帰属インシデント率を可視化する

直近3ヶ月のインシデントを振り返り、「AI支援PRが関与していたか」を分類する。完璧な精度は最初から求めなくていい。「AIが書いたコードが含まれていたか」という粒度でも構わない。CodeRabbitの調査ではAI生成コードは人間記述コードより1.7倍多くのバグを含む。自チームでAI関与PRからのインシデントが増えていると感じるなら、Tier A/B/Cの設計に着手するタイミングだ。GitClearのような外部ツールでコードチャーン率を確認することも判断材料になる。

アクション3: Tier分類でレビュー責任を再設計する

チームのコードレビュー基準を「Tier A（人間のみ）」「Tier B（AI生成→人間承認）」「Tier C（自動実行可）」の3区分に整理する。最初は仮設定でいい。重要なのは「何を自動化してよくて、何は人間が見なければならないか」をチームで合意することだ。これがないと、AIへの委譲は各エンジニアの判断に委ねられ、ばらつきが生まれる。1時間の設計会議でドラフトを作り、2週間試してみる。

AIはEMの仕事を奪うのではなく、EMの仕事の輪郭を変えた。定型的な調整業務は薄れ、本質的複雑性のオーケストレーションが濃くなった。AIをメンバーに持つ全エンジニアが「小さなEM」になる時代に、本物のEMが担う仕事は広木氏の言う通りメタマネジメントへ移行する。計測、ガバナンス、境界設計。これが今のEMの実務だ。

3つのアクションのうち一つ、今週中に手をつけてほしい。

参考リンク

コメント

タイトルとURLをコピーしました