【2026年版】エンジニアリングマネージャー×AI 完全ガイド|チーム生産性とDORA計測

※本記事はアフィリエイト広告を含みます

結論ファースト(30秒で分かる EM×AI)

• AIは「増幅器(amplifier)」: 2025年のDORAレポート(Google Cloud・約5,000人調査)はAIを 増幅器/鏡 と表現。強い組織はさらに伸び、弱い組織は弱点が露呈する。回答者の 90%が業務でAIを使用(前年比+14pt)
• EM=生産性の「翻訳者」: EMの新しい仕事は 個人の生産性向上をチーム・製品の成果へ変換すること。AI成功はツールの問題ではなく システム(組織変革)の問題
• 体感を信じてはいけない: METR研究では経験者がAIで実際は 19%遅く なったのに、本人は20%速くなったと体感(約39ポイントの認識ギャップ)。一方GitHub Copilot公式実験は 55%高速化。数値が割れるから客観計測が必須
• 計測の土台はDORA4指標: デプロイ頻度・変更のリードタイム・平均修復時間(MTTR)・変更失敗率。これを SPACE5次元(満足度/パフォーマンス/活動量/コミュニケーション/効率)で補完する
• AIは技術的負債を増やしうる: CodeRabbit調査ではAI作成PRは人間より 約1.7倍多く 問題検出(10.83件 vs 6.45件)。速く書けてもレビューで滞留する「AIパラドックス」
• 新概念「理解負債/認知負債」: 「動くが理由を説明できない」コードへの組織的対策が必要。EMは ゴールデンパス・アーキテクチャレビュー・バージョン管理強化 で対応
• 1on1・評価へのAI活用: 議事録自動化・根拠データ整理は任せ、評価判断と信頼関係構築はEM自身 が担う線引きが原則
• 定着は「現場推進役」から: マネージャーではなく草の根の推進役を選抜(ランドスタッド)。日本企業のROI実感は 57%(グローバル82%)とPwC調査が示す
• EMの需要は拡大: 年収相場は 700万〜1,600万円(JAC調査の転職者平均は約1,100万円前後)・キャリアパスはエンジニア→テックリード→EM→VPoE(あくまで一例・個人差あり)

【🎯 チームのAI内製化・育成を始めるなら】EMがチームにAIコーディングを定着させる第一歩は体系的な学習設計から → キカガクの公式サイトを見る ※冒頭CTA

[!info] 出典は公式情報+一次調査ベース
本記事は Google Cloud / DORA 2025レポート・DORA.dev・GitHub Blog・METR・CodeRabbit(Zenn)・@IT(ITmedia)・PwC Japan・CyberAgent Developers Blog・Randstad・Geekly Media 等の公式情報・一次調査に基づきます。開発生産性ツールや組織論は急速に進化中のため、最新仕様・数値は必ず公式ドキュメントを参照してください。年収・キャリア・コストに関する記述はあくまで一例で、企業フェーズや個人差があり、最終判断は専門家相談前提でお願いします。

---

この記事でわかること

• エンジニアリングマネージャー(EM)の役割(ピープル×テクノロジーの2軸)とAI時代の再定義
• 2025 DORAレポートの核心「AIは増幅器」とEMの役割(90%がAI利用・システムの問題)
• 開発チームの生産性をどう計測するか(DORA4指標とSPACE5次元の使い分け)
• AIコーディング導入のリアル(Copilot 55% vs METR 19%遅い・認識ギャップ)
• AI生成コードの技術的負債とレビュー負荷(1.7倍問題・理解負債/認知負債と組織的対策)
• 1on1・評価・採用へのAI活用と「人が担う領域」の線引き
• AIコーディングのチーム導入設計(ゴールデンパス・CLAUDE.md標準化・実装は別記事へ)
• AI活用をチームに定着させるロードマップ(現場推進役・多角的成果測定)
• 「EM(評価者・運用側)」と「個人(被評価者)」の棲み分け
• EMのキャリアと市場価値(年収相場・VPoEへの道・学習リソース)
• よくある質問(FAQ)とAI時代の3つの行動指針

---

1. エンジニアリングマネージャー(EM)とは|ピープル×テクノロジーの2軸とAI時代の再定義

1-1. EMが担う2つの軸

エンジニアリングマネージャー(EM)は、ひとことで言えば 「人」と「技術」の両方をマネジメントする職種 です。プロダクトコードを書く比重が下がり、チームの成果を最大化することに責任を持ちます。

軸	主な業務	具体例
ピープルマネジメント	エンジニアの 採用・育成・評価	1on1・目標設定・評価・心理的安全性の確保
テクノロジーマネジメント	技術選定・アーキテクチャ決定・技術的負債の解消計画	設計レビュー・負債返済のロードマップ策定

[!info] EMの前提と立ち位置
EMの中心業務は 1on1・目標設定・評価・心理的安全性の確保 で、EMになるとプロダクトコードを書く比重は下がります。一般に 5年以上のSWE(ソフトウェアエンジニア)経験 が求められます(出典: Geekly Media)。

1-2. AI時代にEMの定義はどう変わるか

AIが個々のエンジニアの手元の作業を肩代わりするようになると、「コードを書く量」では成果を測れなくなります。ここで本記事が立てる再定義はシンプルです。

[!success] EM=「個人の生産性向上をチーム成果へ変換する翻訳者」
AIによる個人の生産性向上は、放っておくと チームや製品の成果には直結しません。2025 DORAレポートはこの変換装置として バリューストリームマネジメント(VSM) を「フォースマルチプライヤー(力の増幅装置)」と位置づけています(出典: DORA.dev 2025)。局所的な速さを、チームの安定したデリバリーへ翻訳する ことが、AI時代のEMの中核的な仕事です。

1-3. 企業はEMをどう位置づけているか

企業/組織	EMの位置づけ
サイバーエージェント	EMを 「組織の成果を最大化させる要」 と定義。AIを活用した新しい開発プロセスの構築・変化に対応できる強いチーム作り・次世代育成にコミットする役割。2028年の「開発プロセス完全自動化」 を見据えた組織構造改革を推進(出典: CyberAgent Developers Blog)

→ コーディングの一部をAIが担っても、計測設計・組織変革・人の育成・意思決定 はEMの中核として残る、というのが各社共通の見立てです。

---

2. 2025 DORAレポートが示す核心|「AIは増幅器(amplifier)」とEMの役割

2-1. 2025 DORAレポートの全体像

開発生産性を語る上で2026年時点の最重要ソースが、Google Cloudが公表した 2025年のDORAレポート(State of AI-assisted Software Development) です。

項目	内容
調査規模	約5,000人の技術専門家 の回答 + 100時間超のインタビュー
AI利用率	回答者の 90%が業務でAIを使用(前年比 +14ポイント)
核心メッセージ	AIは組織の強みも弱みも増幅する 「増幅器(amplifier)/鏡(mirror)」
結論	AI成功はツールの問題ではなく、システム(組織変革)の問題

[!success] 「鏡」としてのAI
AIは組織の実態を映す「鏡」でもあります。強い組織はAIでさらに伸び、課題を抱える組織は弱点が露呈する。だからこそ、ツールを入れただけで成果が出ると考えるのは誤りで、組織の仕組みを整えるEMの設計力が問われます(出典: Google Cloud Blog / DORA 2025)。

2-2. AI導入の「光と影」: スループットは上がるが安定性は下がりうる

DORA 2025は、AI導入の効果を一方向に評価していません。

観点	AI導入との関係
ソフトウェアデリバリーの スループット	プラスの関係
製品パフォーマンス	プラスの関係
デリバリーの 安定性	マイナスの関係(=高速化が下流の弱点を露呈させうる)

[!warning] 速さは弱点を露わにする
AIで書く速度が上がると、レビュー・テスト・リリースといった 下流工程のボトルネックが一気に表面化 します。2025 DORAはここで バリューストリームマネジメント(VSM) が、局所的な生産性向上をチーム・製品の成果へ変換する「フォースマルチプライヤー」として機能すると指摘しています(出典: DORA.dev 2025)。

2-3. DORA AI Capabilities Model|AIの便益を増幅する7つの基盤能力

2025 DORAは、AIの便益を増幅するために組織が備えるべき 7つの基盤能力 を「DORA AI Capabilities Model」として提示しました。EMはこのチェックリストで自組織の準備度を点検できます。

#	基盤能力	EM視点での意味
1	明確なAIポリシー	何にAIを使ってよいか/いけないかの線引き
2	健全なデータエコシステム	AIが拠り所にできるデータの質
3	AIがアクセスできる社内データ	グラウンディングの土台
4	強固なバージョン管理	AI生成コードの追跡・巻き戻し前提
5	スモールバッチでの作業	小さく出して安定性を担保
6	ユーザー中心の視点	これを欠くチームはAIでむしろ悪化
7	質の高い社内プラットフォーム	開発者が乗る「土台」の整備

[!warning] ユーザー中心視点を欠くと逆効果
2025 DORAは、ユーザー中心の視点を欠くチームはAI導入でむしろ悪影響を受ける と明言しています(出典: 2025 DORA AI Capabilities Model Report)。「とりあえずAIを入れる」が最も危険なパターンであり、7つの基盤能力のどこが弱いかを見極めるのがEMの仕事です。

---

3. 開発チームの生産性をどう計測するか|DORA4指標とSPACE5次元の使い分け

3-1. なぜ計測がEM必須スキルなのか

後述するMETR研究が示すように、個人の「速くなった体感」は当てになりません。EMは体感ではなく、客観的な指標でチームを把握する必要があります。その土台となるのが DORAメトリクス と SPACEフレームワーク の2つです。

3-2. DORAメトリクス4指標(デリバリー能力の土台)

指標	何を測るか
デプロイ頻度	どれだけ高頻度に本番リリースできているか
変更のリードタイム	コミットから本番反映までの時間
平均修復時間(MTTR)	障害発生から復旧までの時間
変更失敗率	デプロイのうち障害につながった割合

→ DORA4指標は 組織のデリバリー能力を客観把握する「土台」 です。前半2つがスピード、後半2つが安定性を表し、両者のバランスを見ます。

3-3. SPACEフレームワーク5次元(人間中心の補完)

次元	内容
S: 満足度(Satisfaction)	開発者の幸福度・燃え尽きの兆候
P: パフォーマンス(Performance)	成果・品質
A: 活動量(Activity)	アウトプット量
C: コミュニケーション(Communication)	協働・連携
E: 効率(Efficiency)	フロー・割り込みの少なさ

[!tip] DORAとSPACEの使い分け
DORAは「デリバリー能力の土台」、SPACEは「人間中心の多次元計測で土台を補完」 します。例えば 活動量(A)は高いのに満足度(S)が低ければ、エンジニアが疲弊しているサイン。EMは両方を組み合わせ、単一指標で生産性を語らない ことが重要です。

3-4. 計測を「監視」に使ってはいけない

[!warning] 指標はシステム改善のため、評価・監視のためではない
2025 DORAは可視化の副作用を防ぐため、エンジニア自身を計測設計に巻き込む文化的アプローチ を推奨しています。指標を メンバーの監視・ランク付け に使うと、数字を取り繕う「ゲーミング」や不信を招き、計測そのものが機能しなくなります。指標は「個人の評価」ではなく「システム改善」のために使う のが鉄則です(出典: DORA.dev 2025)。

---

4. AIコーディング導入のリアル|個人の生産性向上が組織成果に直結しない

4-1. 数値が割れる: Copilot 55%高速化 vs METR 19%遅い

AIコーディングツールの効果を語る数字は、出典によって大きく食い違います。EMはこの「食い違い」自体を理解しておく必要があります。

研究	対象・設計	結果
GitHub対照実験	JavaScriptでHTTPサーバーを実装するタスク	Copilot利用群が 55%(55.8%)速く 完了(平均1時間11分 vs 2時間41分・P=.0017)。開発者の 87%が反復作業の精神的負担軽減 を実感
METRのRCT(2025年7月)	経験豊富なOSS開発者16名が 自プロジェクトの246タスク に取り組む	AI使用で完了時間が実際には 19%増加(=遅くなった)。本人は事前に24%速くなると予想し、事後も 20%速くなったと推定(=約39ポイントの認識ギャップ)

[!warning] 「速くなった体感」を効果判定に使わない
METRの研究で最も衝撃的なのは、経験者ほど「速くなった」と感じているのに、実測では遅くなっていた 点です。主因は AI出力の検証オーバーヘッド(生成コードを読んで確かめる時間)。EMが「現場が速いと言っているから効果あり」と判断するのは危険です(出典: METR / GitHub Blog)。

4-2. METRは研究設計を見直し中|断定を避けるべき理由

ここで重要なのは、METRの研究結果も「確定した真実」ではないという点です。EMはこの不確実性ごと理解する必要があります。

[!info] METRの2026年2月アップデート
METRは 2026年2月に研究設計の選択効果の問題を認め 結果を更新しました。元参加者のサブセットでは現在 -18%(速くなった) と推定(信頼区間-38%〜+9%)、新規採用開発者では -4%(信頼区間-15%〜+9%)。選択効果が大きいため実験設計を変更中で、当初の「19%遅い」とは方向が変わっています。AIツールは急速に進化しており(2025年初頭はClaude 3.5/3.7 Sonnet使用)、最新ツールでは結果が異なる可能性 がある点に留意が必要です(出典: METR 2026年2月)。

→ つまり「AIは遅くする」とも「AIは速くする」とも断定できないのが2026年時点の実態です。だからこそ、EMは一般論ではなく自チームの実測値で語る べきなのです。

4-3. なぜ個人の速さが組織成果に直結しないのか

段階	何が起きるか
個人レベル	AIでコードを書く速度が上がる(体感も上がる)
チームレベル	大量のPRが レビュー待ち で滞留する(後述の1.7倍問題)
組織レベル	デリバリーの 安定性が低下(DORA 2025の指摘)・ROIが実感できない

[!warning] 日本企業のROI実感は57%
PwC Japan(2025年調査)によると、「AIにより大幅なROIや生産性向上を実感している」と回答した日本企業は57% で、グローバル平均82%より25ポイント低い 結果でした。導入はしているが成果が出ていない企業が多い実態を示します(出典: PwC Japan)。この25ポイントの差を埋めるのが、組織の仕組みを設計するEMの仕事 です。

---

5. AI生成コードの技術的負債とレビュー負荷|1.7倍問題・理解負債/認知負債

5-1. 「AIパラドックス」: 速く書けてもチームでは遅くなる

指標	AI作成PR	人間作成PR
検出された問題数(平均)	10.83件	6.45件
倍率	約1.7倍多い	—

[!warning] AIパラドックス
CodeRabbitの2025年調査では、AIが作成したプルリクエストは人間が書いたPRより約1.7倍多く問題が検出 されました(AIコード平均10.83件 vs 人間6.45件)。コーディング速度は上がっても 後工程のレビュー・修正コストが増え、チーム全体ではむしろ効率が下がる 「AIパラドックス」が指摘されています(出典: Zenn / CodeRabbit JP)。

5-2. 新概念「理解負債」「認知負債」

AI生成コードには、従来の技術的負債に加えて新しい種類の負債が登場しています。

負債の種類	内容
技術的負債(従来)	後で返済が必要な実装上の妥協
理解負債	「動くコード」をそのままコミットすると、リトライ回数やタイムアウト設定の理由をレビューで問われても説明できない 事態
認知負債	AIに任せきりで 自分で考える力が衰える リスク

[!warning] 「動くが説明できない」コードの怖さ
AIが生成した「とりあえず動くコード」をそのままコミットすると、後から 「なぜこのリトライ回数なのか」「なぜこのタイムアウト設定なのか」を説明できない 事態が生じます。これが理解負債です(出典: @IT / ITmedia)。

5-3. EMの組織的対策

個人レベルの対策(一行ごとの意図確認・自分で考える時間の確保)に加え、EMは 組織の仕組み で負債を抑える必要があります。

対策	内容	レイヤー
厳格なコードレビュー	一行ごとの意図確認・「なぜ」を問う文化の維持	チーム文化
バージョン管理の強化	追跡・巻き戻しを前提にした運用(DORA 7能力の1つ)	基盤
テンプレ標準化(ゴールデンパス)	テンプレートで初期構成を標準化し、AIが設計意図を保つ「敷かれたレール」を用意	プラットフォーム
アーキテクチャレビューの定期化	設計の一貫性を組織として担保	プロセス

[!tip] ゴールデンパスと開発者ポータル
@ITは対策として、テンプレートで初期構成を標準化する 「ゴールデンパス」 や 開発者ポータル(Platform Engineering) の整備を挙げています(出典: @IT / ITmedia)。AI時代のEMは、個人にレビュー努力を求めるだけでなく、負債が生まれにくいレールを敷く 役割を担います。

---

6. 1on1・評価・採用にAIをどう使うか|ピープルマネジメント業務の効率化と線引き

6-1. AIに任せられる領域・人が担う領域

ピープルマネジメントは、AIに任せる部分と人が担う部分の 線引きが最も重要 な領域です。

業務	AIの役割(任せる)	EM自身の役割(任せない)
1on1	議事録の文字起こし・要約	信頼関係の構築・傾聴・対話そのもの
評価	評価の根拠データの整理	評価・フィードバックの 最終判断
採用	ジョブディスクリプションの下書き	候補者の見極め・意思決定

[!success] 役割分担の原則
AIには「定型・反復・データ整理」を肩代わりさせ、EMは人と向き合う時間を増やす のが原則です。1on1の議事録自動化や評価の根拠データ整理でAIは補助になりますが、評価・フィードバックの最終判断や信頼関係の構築はEM自身が担う領域 です。

6-2. 1on1議事録の自動化を実務に落とす

1on1の議事録作成は、EMの時間を最も奪う定型作業の一つです。文字起こし・要約をAIに任せることで、EMは「書く」時間を「聴く・考える」時間に振り向けられます。

[!tip] 1on1議事録の自動文字起こし
1on1や面談の文字起こし・要約には、AI文字起こしツールの活用が現実的です。例えば日本語に強い Notta のようなツールを使えば、面談中はメモを取らず対話に集中し、後から要約を確認できます。録音・要約を行う場合は、メンバーへの事前同意とプライバシー配慮、社内のセキュリティポリシー確認が前提 です。

6-3. 注意: 「個人を評価する」のか「個人が評価される」のか

本記事はあくまで EM(評価者・運用側) の視点です。従業員側がAI活用で自分の評価を上げる方法 は、対象読者が異なるため別記事で扱っています。

[!info] レイヤーの違いに注意
「社内AI活用で個人が評価を上げる」ノウハウ(被評価者・個人視点)は 社内AI活用で評価を上げる5つの実践法で解説しています。本記事は EMがチームを評価・運用する 評価者・組織視点に特化しているため、被評価者向けのテクニックは深掘りせず、そちらへ送ります(詳細は第10章で整理)。

---

7. AIコーディングのチーム導入設計|ゴールデンパス・CLAUDE.md標準化(実装は別記事へ)

7-1. EMの仕事は「個人に使わせる」ではなく「チームに標準化する」

AIコーディングツールを「各自で勝手に使ってください」とすると、品質も負債も人によってバラバラになります。EMの役割は、チーム全体で再現性のある使い方を標準化する ことです。

レイヤー	個人(エンジニア)の関心	EM(組織)の関心
ツールの使い方	どうプロンプトを書くか	チームでどう 標準化 するか
設定ファイル	自分用の設定	CLAUDE.md の整備 による委任方針の共有
エージェント	Subagentsの作り方	どの定型タスクを ゴールデンパス に乗せるか

7-2. CLAUDE.md とゴールデンパスの標準化

[!success] CLAUDE.md にチームの委任方針を書く
AIコーディング環境では、CLAUDE.md にチーム共通の委任方針・コーディング規約を記述 することで、メンバー全員が同じレールに乗れます。「XXのときはXX subagentを使うこと」といった方針を明文化すると、AI生成コードの一貫性が増します(実装の詳細は Claude Code Subagents 実践ガイドを参照)。これは第5章のゴールデンパス(テンプレ標準化)と同じ思想です。

7-3. 実装ツールの詳細は専門記事へ

EMが押さえるべきは「どのツールを、どの業務に、どう標準化するか」というマネジメント判断であり、ツールそのものの実装手順は別記事に集約 しています。送客先を整理します。

知りたいこと	参照記事
Subagents(独立コンテキストでの並列タスク委譲)の実装	Claude Code Subagents 実践ガイド
Hooks & Skills(自律エージェント構築)の実装	Claude Code Hooks & Skills 入門
AIエージェントの全体像・3 Tier比較	AIエージェント完全ガイド

[!tip] チーム導入の前提環境
Claude Code を使ったAIコーディングのチーム導入には、Claude Pro/Maxプランが前提になります。まずEM自身が環境を触って勘所を掴んでおくと、チームへの展開判断がしやすくなります → Claude Pro の公式サイトを見る

---

8. AI活用をチームに定着させるロードマップ|現場推進役の育成・多角的な成果測定

8-1. 「マネージャーが旗を振る」より「現場推進役」

[!success] 草の根の推進役を選抜する
ランドスタッドのロードマップでは、AI活用を組織に定着させるため、各チームから マネージャーではなく「現場の推進役」を選抜 し、メンターとして草の根で活用事例を共有する手法が提示されています(出典: Randstad)。トップダウンの号令より、現場の信頼できる仲間が成功事例を見せる 方が定着しやすい、という考え方です。

8-2. 成果測定は多角的に

ランドスタッドは、成果測定を財務ROIだけで判断しないことを推奨しています。

測定軸	内容
財務ROI	コスト削減・売上貢献
導入率	実際にどれだけ使われているか
生産性	コードサイクルタイム等
品質	不具合・手戻りの変化
従業員満足度(センチメント)	現場の納得感・疲弊度

→ これは第3章のSPACE(満足度を含む多次元計測)と整合します。財務ROIだけ見て「効果なし」と切り捨てると、定着途中の芽を摘む ことになります。

8-3. 段階的フェーズで進める

[!tip] 「小さく始めて、計測しながら広げる」
PwC調査が示すように、日本企業の57%しかROIを実感できていません(グローバル82%)。この差を埋めるには、いきなり全社展開せず、推進役を起点に小さく始め、DORA/SPACEで計測しながら段階的に広げる のが現実的です。EMの設計力が定着の鍵になります(出典: Randstad / PwC Japan)。

---

9. EMのキャリアと市場価値|年収相場・VPoEへの道・学習リソース

9-1. EMの年収相場とキャリアパス

[!info] 数値はあくまで一例・個人差があります
以下の年収・キャリアに関する記述は、出典に基づく相場の一例です。企業フェーズ・担当規模・地域によって大きく異なり、個人差があります。転職判断は専門家・エージェントへの相談を前提にしてください。

項目	内容
年収相場	700万〜1,600万円(企業フェーズと担当規模で大きく異なる)
JACリクルートメント調査	EM転職者の 平均年収は1,100万円前後・最高約2,600万円
Forkwell Jobs掲載求人	上限最高値 2,700万円
初EM	未経験に近い場合 600〜700万円スタート も多い
キャリアパス	エンジニア→テックリード→EM→VPoE

(出典: IT関連サービスのレビュー / Geekly Media)

9-2. AI時代にEMが学ぶべきこと

EMがチームにAIを広げ、自身の市場価値を保つために押さえるべき領域を整理します。

領域	内容	関連記事
実装ツール理解	Subagents・Hooks/Skills等をチームにどう標準化するか	Claude Code Subagents / Claude Code Hooks & Skills
計測知識	DORA4指標・SPACE5次元	本記事 第3章
Platform Engineering	ゴールデンパス・開発者ポータル	本記事 第5章
AIエージェントの全体像	主要プラットフォームの俯瞰	AIエージェント完全ガイド

9-3. 体系的に学ぶ・チームに広げる

[!tip] チームのAI内製化・育成を体系化する
EMが「自分が使える」から「チームが使える」へ進むには、属人的な試行錯誤より体系的な学習設計が有効です。チームのAI内製化・育成を進めるなら、以下のようなAI開発スクールやチーム研修を検討材料にできます(費用・カリキュラムは変動するため、各社の最新情報・無料相談で確認してください)。

スクール	強み
キカガクの公式サイトを見る	機械学習・AIアプリ開発に強み(チームの内製化基礎に応用可)
AIジョブカレの公式サイトを見る	AIエンジニア育成・自律エージェント実装にも対応
DMM 生成AI CAMP の無料カウンセリングを予約する	生成AI実務活用・チームの底上げに応用可

→ EM自身のキャリア(VPoEへの道)や、これからエンジニアを目指すメンバーの育成については 未経験からAIエンジニア転職ロードマップも参考になります(対象が「これからエンジニアになる個人」のため、EMは育成・採用の文脈で参照する位置づけです)。

---

10. レイヤーの整理|「EM(評価者・運用側)」と「個人(被評価者)」の棲み分け

本記事の立ち位置を、関連記事との関係で明確にしておきます。同じ「AI×職場」のテーマでも、誰の視点で書かれているか で内容が大きく変わります。

視点	主語	主な関心	該当記事
評価者・組織視点(本記事)	EM	1on1運用・メンバー評価設計・チーム技術負債マネジメント・AIのチーム導入	clu_2_32(本記事)
被評価者・個人視点	一般従業員	自分の評価を上げる・市場価値を高める	社内AI活用で評価を上げる5つの実践法
実装ツール視点	エンジニア	Subagents/Hooks/Skillsの作り方	Claude Code Subagents / Claude Code Hooks & Skills
これからエンジニアになる視点	未経験者	転職ロードマップ	未経験からAIエンジニア転職ロードマップ
AIエージェント全体像	全読者	主要プラットフォーム比較	AIエージェント完全ガイド

[!success] 本記事はあえて「個人のノウハウ」を深掘りしない
「AIで自分の評価をどう上げるか」は重要ですが、それは 被評価者(個人)のテーマ であり、EM(評価者)が読むべき内容とは別物です。本記事は チームを評価・運用する側 の設計に絞り、個人向けのテクニックは 社内AI活用で評価を上げる5つの実践法 へ送ります。視点を混同しないことが、EMとして正しく機能する第一歩です。

---

11. よくある質問(FAQ)

Q1. エンジニアリングマネージャー(EM)とAIの関係を一言で言うと?

EMは「個人がAIで得た生産性向上を、チームと製品の成果に変換する翻訳者」です。2025年のDORAレポートはAIを 増幅器(amplifier) と表現し、強い組織はさらに強く、弱い組織は弱点が露呈すると結論づけました。回答者の90%が業務でAIを使う時代に、AI導入が組織成果に直結しない原因はツールではなく組織の仕組み側にあり、その仕組みを設計するのがEMの役割です(出典: Google Cloud DORA 2025)。

Q2. AIコーディングツールを入れれば開発生産性は本当に上がりますか?

個人レベルでは上がる証拠が多い一方、組織レベルでは別問題です。GitHubの対照実験ではCopilotで 55%高速化 しましたが、METRのRCTでは経験豊富な開発者が実際には 19%遅く なり、しかも本人は20%速くなったと体感していました(約39ポイントの認識ギャップ)。METRは2026年2月に選択効果を認め設計を見直し中で、最新ツールでは結果が異なる可能性もあります。だからこそEMは体感ではなく DORA/SPACE で客観計測すべきです。

Q3. DORAメトリクスとSPACEフレームワークの違いは?

DORAメトリクス(デプロイ頻度・変更のリードタイム・MTTR・変更失敗率)は組織のデリバリー能力を客観把握する 土台 です。SPACEフレームワーク(満足度S・パフォーマンスP・活動量A・コミュニケーションC・効率E)は人間中心の多次元計測で 土台を補完 します。例えば活動量は高いのに満足度が低ければエンジニアが疲弊しているサイン。EMは両方を組み合わせ、単一指標で生産性を語らないことが重要です。

Q4. AIで書いたコードは技術的負債になりませんか?

なりやすいです。CodeRabbitの2025年調査ではAI作成のPRは人間より 約1.7倍多く 問題が検出されました(平均10.83件 vs 6.45件)。さらに「動くが理由を説明できない」 理解負債、考える力が衰える 認知負債 という新概念も登場しています。EMの対策は、厳格なコードレビュー文化の維持・バージョン管理の強化・テンプレ標準化(ゴールデンパス)・定期的なアーキテクチャレビューで、AI生成コードが設計意図を保つ仕組みを作ることです。

Q5. EMは1on1や評価などのピープルマネジメントにAIをどう使えばいい?

1on1の議事録自動化(文字起こし・要約)、評価の根拠データ整理、採用のジョブディスクリプション下書きなどでAIが補助になります。ただし評価・フィードバックの最終判断や信頼関係の構築はEM自身が担う領域です。AIは「定型・反復・データ整理」を肩代わりさせ、EMは人と向き合う時間を増やす、という役割分担が原則です。なお、従業員側がAI活用で自分の評価を上げる方法は別記事(社内AI活用で評価を上げる5つの実践法)で解説しています。

Q6. AI活用をチームに定着させる進め方は?

ランドスタッドのロードマップでは、各チームからマネージャーではなく 現場の推進役 を選抜し、メンターとして草の根で活用事例を共有する段階的アプローチが推奨されています。成果測定は財務ROIだけでなく導入率・生産性(コードサイクルタイム)・品質・従業員満足度(センチメント)を多角的に測ります。PwC調査では日本企業の 57% しかROIを実感できておらず(グローバル82%)、EMの設計力が定着の鍵です。

Q7. AIが進化したらEMの仕事はなくなりますか?

むしろ重要性が増しています。サイバーエージェントはEMを「AI時代に 組織の成果を最大化する要」と位置づけ、AIを活用した開発プロセス構築・強いチーム作り・次世代育成にコミットする役割としています。コーディングの一部はAIが担っても、計測設計・組織変革・人の育成・意思決定はEMの中核として残ります。EMの年収は 700万〜1,600万円(JAC調査の転職者平均は約1,100万円前後)で需要は拡大傾向です(あくまで一例で、企業フェーズ・担当規模により個人差があります)。

Q8. AIコーディングの導入でEMがやってはいけないことは?

(1)個人の「速くなった体感」だけで効果判定する(METR研究が示す認識ギャップ)、(2)スループット(PR数)だけ見てレビュー滞留や安定性低下を見落とす、(3)計測指標をメンバーの監視・ランク付けに使いゲーミングや不信を招く、の3つです。2025 DORAは可視化の副作用を防ぐためエンジニア自身を計測設計に巻き込む文化的アプローチを推奨しています。指標は「個人の評価」ではなく「システム改善」のために使うのが鉄則です。

Q9. EMになるには・AIスキルをチームに広げるには何を学べばいい?

EMの前提として一般に5年以上のSWE経験が求められ、キャリアパスはエンジニア→テックリード→EM→VPoEが一般的です(あくまで一例)。AI領域では、チームに導入するClaude Code等の実装ツール理解(Subagents・Hooks/Skills)、DORA/SPACEの計測知識、Platform Engineeringの考え方が要点です。体系的に学ぶならAI開発スクールやチーム研修、EM自身の市場価値を客観視するには専門家・エージェントへの相談が有効です(記事内で紹介)。

---

12. まとめ|EMがAI時代に押さえる3つの行動指針

12-1. 結論

• AIは増幅器: 2025 DORAレポート(約5,000人調査)はAIを増幅器/鏡と表現。回答者の90%がAIを使い、強い組織は伸び、弱い組織は弱点が露呈する。AI成功はツールではなくシステム(組織変革)の問題
• EM=翻訳者: 個人の生産性向上をチーム・製品成果へ変換するのがAI時代のEMの核心。VSMが「フォースマルチプライヤー」として機能する
• 体感は当てにならない: METRは19%遅い→2026年2月に-18%へ更新中、GitHub Copilotは55%高速化と数値が割れる。だから DORA4指標+SPACE5次元 で客観計測する
• AIは技術的負債を増やしうる: CodeRabbit調査でAI作成PRは約1.7倍問題検出。理解負債/認知負債への組織的対策(ゴールデンパス・アーキテクチャレビュー・バージョン管理強化)が必要
• 定着は現場推進役から: 多角的な成果測定で小さく始めて広げる。日本のROI実感は57%(グローバル82%)

12-2. 行動指針(3つ)

1. 計測の土台を作る: まずDORA4指標を自チームで取り始める。SPACEで満足度を補完し、「個人の評価」ではなく「システム改善」のため に使う(監視に使わない)
2. 負債が生まれにくいレールを敷く: 厳格なレビュー文化+ゴールデンパス(テンプレ標準化)+CLAUDE.md整備+定期アーキテクチャレビューで、個人の速さをチームの安定したデリバリーへ翻訳する
3. 小さく始めて定着させる: 現場推進役を選抜し、多角的な指標で計測しながら段階的に広げる。AIに定型作業を任せ、EMは人と向き合う時間(1on1・育成・意思決定)を増やす

12-3. 関連記事

• Claude Code Subagents 実践ガイド|並列処理・カスタム設計(チームへの実装ツール標準化)
• Claude Code Hooks & Skills 入門|自律エージェント構築(実装の深掘り)
• 社内AI活用で評価を上げる5つの実践法(被評価者・個人視点の棲み分け先)
• 未経験からAIエンジニア転職ロードマップ(メンバー育成・採用の参考)
• AIエージェント完全ガイド|主要3 Tier比較(AIエージェント全体像)

[!success] 最後に
AI時代のEMの仕事は、ツールを導入することではなく、個人がAIで得た速さを、チームの安定した成果に翻訳する仕組みを設計すること です。体感ではなくDORA/SPACEで計測し、負債が生まれにくいレールを敷き、現場推進役を起点に小さく広げる。この3つを地道に積み上げることが、AIが増幅する組織の強みを最大化します。年収・キャリア・コストに関する記述はあくまで一例で個人差があり、最終判断は専門家相談前提でお願いします。開発生産性ツールや研究結果(特にMETR等)は急速に更新中のため、最新情報は必ず公式を確認 してください。

---

参考リンク

• Google Cloud Blog / 2025 DORAレポート発表
• Google Cloud / 2025 DORA AI Capabilities Model Report
• DORA.dev / State of AI-assisted Software Development 2025
• GitHub Blog / Copilotの生産性・満足度への影響(調査)
• METR / Measuring the Impact of Early-2025 AI on Experienced OS Developer Productivity
• METR / Developer Productivity Experiment Design Update(2026年2月)
• Zenn(CodeRabbit JP)/ DORA最新レポートが示すAIコーディング時代のコードレビューの重要性
• @IT(ITmedia)/ AIコーディングはなぜ後から苦しくなるのか
• Geekly Media / エンジニアリングマネージャーの年収・役割・スキル
• IT関連サービスのレビュー / エンジニアリングマネージャーへの転職完全ガイド2026年版
• PwC Japan / AIはなぜプロジェクト管理で期待された成果を上げられないのか
• CyberAgent Developers Blog / 2028年開発プロセス完全自動化を見据えたエンジニア組織の構造改革
• Randstad / AI時代のエンジニア組織をどう動かすか(3つのフェーズと18ヶ月ロードマップ)

---

著者: AIノート(AI業務改善ノート運営者)
最終更新: 2026年6月1日
監修: 本記事はGoogle Cloud / DORA 2025レポート・DORA.dev・GitHub Blog・METR・CodeRabbit(Zenn)・@IT(ITmedia)・PwC Japan・CyberAgent Developers Blog・Randstad・Geekly Media等の公式情報・一次調査を一次情報源として執筆しています。開発生産性に関する研究結果(特にMETR等)は急速に更新中であり、年収・キャリア・コストに関する数値はあくまで一例で個人差があります。最新仕様・数値は必ず公式ドキュメントを確認し、重要な意思決定は専門家相談を前提に してください。