「AIを入れたのだから、納期は半分でいけるよね？」――AI駆動開発が広がるなかで、経営層や顧客からこう言われて答えに詰まるPM・開発リーダーが増えています。実際、エンジニアを対象にした2026年の調査では、他職種からの「AIならもっと早くできるはず」という圧力を新たなストレス要因に挙げた人が53.4%にのぼりました。一方で現場では、プルリクエスト（PR）の数は増えたのにリリースは速くならない、という声も珍しくありません。本記事では、AI駆動開発でPMの仕事の前提がどう変わるのかを整理したうえで、見積もり・進捗報告・完了の定義をどう作り直せばよいのかを、明日から使える手順とチェックリストに落として解説します。
AI駆動開発で、PMの「前提」が崩れる3つの理由
従来のプロジェクトマネジメントは、「実装に最も時間がかかる」という前提の上に組み立てられてきました。見積もりは実装工数を中心に積み上げ、進捗は実装の完了度で測り、人員計画も実装担当者の数で考えるのが一般的です。AI駆動開発は、この前提そのものを揺さぶります。
1. ボトルネックが「書く」から「確かめる」へ移る
AIコーディングエージェントを使うと、コードを書く速度は大きく上がります。しかし、そのコードをレビューし、統合し、テストで確かめる工程の速度は自動的には上がりません。米国の研究者らが開発者802人・約19万件のPRを追跡した2026年の研究では、開発者1人あたりのPR数が導入前の2.09倍に増えた一方、レビュワーは約1.5倍しか増えず、レビュー担当者1人あたりの負担が実質的に倍増したと報告されています。さらに、具体的な指摘を伴わない「無言の承認」の割合が高まったことも指摘されています。速くなったのは実装だけで、プロジェクト全体の流れはレビュー待ちで詰まっているという状態が、多くの現場で起きているのです。
2. 活動量と成果がずれる
PR数やコードの行数、AIの利用率といった「活動量」は、AI導入で目に見えて増えます。ところが、リリース頻度や品質といった「成果」は必ずしも同じように伸びません。活動量の数字だけを経営層に報告すると、「これだけ数字が上がっているのに、なぜ納期は変わらないのか」という不信感を招きます。
3. 効果はすぐには出ない
新しいツールや進め方を導入すると、慣れるまでの学習コストや、ルールづくりの手間が発生します。そのため、導入直後は一時的に生産性が下がり、運用が定着してから上がっていく「Jカーブ」を描くことが多いとされています。この時期に「AIを入れたのに遅くなった」と判断してしまうと、効果が出る前に取り組みが止まってしまいます。PMには、この時間差を前提にした計画と説明が求められます。
見積もりの作り直し方 ― 「AIが効く作業」と「効かない作業」を分ける
「AIで何割短縮できるか」を全体に一律で掛ける見積もりは、ほぼ確実に外れます。AIの効果は作業の種類によって大きく異なるからです。まずはWBSのタスクを性質ごとに分類し、それぞれでAIの効き方を見積もることから始めます。
| タスク分類 | AIの効きやすさ | 見積もりでの扱い |
|---|---|---|
| 定型的な実装（CRUD、画面、変換処理など） | 効きやすい | 短縮を見込めるが、その分レビュー・テスト工数を別途計上する |
| 新規設計・アーキテクチャ検討 | 部分的（案出しは速いが判断は人） | 大きな短縮は見込まない。比較検討の材料づくりの時間が減る程度 |
| 要件定義・顧客との調整 | 効きにくい | 従来どおり。むしろ仕様の曖昧さがAI出力の品質に直結するため、手厚くする |
| レビュー・検証 | 補助的 | 実装量の増加に比例して増える前提で、独立した項目として計上する |
| 結合・システムテスト | 補助的 | テストコード作成は速くなるが、観点設計と結果の判断は人が担う |
レビュー・検証工数を「独立した行」として計上する
最も重要なのは、レビュー・検証の工数を実装工数の付随作業ではなく、独立した見積もり項目として扱うことです。AIで実装が速くなれば、その分だけ確かめるべき成果物が増えます。この工数を見積もりに載せないまま「実装が速くなった分」だけ納期を縮めると、後工程で必ず破綻します。
係数は「仮置き→実績で補正」で運用する
タスク分類ごとの短縮率は、最初から正確に決められるものではありません。最初のスプリントやフェーズでは控えめな係数を仮置きし、実績を記録して次の見積もりに反映する、というサイクルを回します。数回繰り返すと、自社・自チームにとって現実的な係数が見えてきます。
契約形態ごとに顧客への説明を変える
SIerの場合、契約形態によって説明のポイントが異なります。請負契約では、AIによる短縮分をどこまで価格や納期に反映するかを、品質責任とセットで合意しておく必要があります。準委任契約では、工数そのものよりも「何を、どの品質で届けるか」という成果の中身を明確にしておくことが、後の認識のずれを防ぎます。
進捗・成果は何で報告するか ― 活動量指標からフロー指標へ
見積もりを作り直したら、次は進捗と成果の測り方を変えます。前述のとおり、AI導入で増えるのは活動量です。報告に使う指標を変えなければ、現場の実態と経営層の認識はずれ続けます。そこで有効なのが、仕事が着手から完了までどれだけスムーズに流れているかを見る「フロー指標」です。
| 区分 | 指標の例 | 理由 |
|---|---|---|
| 報告の主軸にしない指標 | PR数、コード行数、AI利用率、生成されたテストの数 | AIで簡単に増えるため、成果を表さない。数字だけが独り歩きしやすい |
| 報告の主軸にする指標 | リードタイム（着手から本番反映まで）、レビュー待ち時間、手戻り率、本番障害件数 | プロジェクト全体の流れと品質を表す。ボトルネックの場所も分かる |
フロー指標の利点は、「どこで詰まっているか」が見えることです。たとえば、実装完了までの時間は短くなったのにリードタイムが変わらない場合、詰まっているのはレビューかテストだと分かります。これは、経営層に「AIの効果が出ていない」のではなく「効果を阻んでいる工程がここにある」と説明する材料になります。
経営層への週次報告の型
報告は、A4一枚程度に次の3点をまとめる形が扱いやすいでしょう。
- 1. フロー指標の推移：リードタイム、レビュー待ち時間、手戻り率を前週・導入前と比較する
- 2. ボトルネックの所在：いま最も時間がかかっている工程と、その理由
- 3. 次の打ち手：ボトルネック解消のために何をするか、そのために必要な判断や支援は何か
この型で報告を続けると、「AIならすぐできるはず」という抽象的な期待を、「この工程を改善すればこれだけ早くなる」という具体的な議論に置き換えやすくなります。
AI Dev Camp
AI時代のプロジェクトマネジメントを、自社の現場に合わせて身につける
AI Dev Campは、IT企業・SIer向けのプロマネ研修とAIドリブン研修を組み合わせた研修・変革支援サービスです。汎用的なパッケージではなく、事前ヒアリングで自社の課題を把握したうえで内容をカスタマイズします。
「完了の定義」と人の承認ゲートを決め直す
見積もりと報告を変えても、「何をもって完了とするか」が曖昧なままでは、品質の問題が後工程に先送りされるだけです。AI駆動開発では、完了の定義と、人が判断を下すポイントを改めて決め直す必要があります。
完了の定義を「書けた」から「確かめた」へ引き上げる
AIを使うと、それらしく動くコードがすぐに出来上がります。そのため、「コードが書けた」時点を完了とみなすと、未検証の成果物が積み上がっていきます。完了の定義は、少なくとも「テストを通過し、レビューで承認された」状態に引き上げるべきです。AIが書いたテストは実装をなぞって期待値を作ってしまうことがあるため、テストの観点そのものを人が確認する工程も定義に含めておくと安心です。
工程の境目に人の承認を置く
AIエージェントに作業を任せる範囲が広がるほど、エージェントが方針を勝手に変えたり、実際とは異なる報告をしたりするリスクも高まります。「最終判断は人間が行う」という大まかなルールだけでは不十分で、仕様・設計・実装といった工程の境目ごとに、人が承認するゲートを具体的に決めておくことが重要です。どのゲートで、誰が、何を見て承認するのかを事前に明文化しておけば、責任の所在もはっきりします。
人が見る領域と、自動チェックに任せる領域を分ける
すべての成果物を人が細かくレビューしようとすると、レビュー待ちがさらに悪化します。コーディング規約やセキュリティ上の典型的な問題など、機械的に判定できるものは自動チェックに任せ、人は設計の妥当性や業務要件との整合性といった判断が必要な部分に集中する、という切り分けが現実的です。設計品質・セキュリティ・テストの3段階で自動チェックを組み込む考え方は「ハーネスエンジニアリング」と呼ばれ、AI駆動開発の速さと品質を両立する仕組みとして注目されています。詳しくはハーネスエンジニアリングの解説記事をご覧ください。
PMBOKの観点で整理する、AI時代のPMの仕事チェックリスト
ここまでの内容を、PMBOKで整理されている代表的な管理の観点に当てはめると、PMの仕事のどこが変わるのかが見えやすくなります。PMBOKの考え方そのものが古くなるわけではなく、それぞれの観点で「何に注意を払うか」の重心が移る、と捉えるのが適切です。
| 観点 | 何が変わるか | PMがやること |
|---|---|---|
| スコープ | 仕様の曖昧さがAI出力の品質に直結する | 要件・仕様を、AIにも人にも誤解されない粒度で文書化する |
| スケジュール | 実装は速くなるが、レビュー・テストが律速になる | レビュー待ち時間を計画とモニタリングの対象に加える |
| コスト | 人件費の構成が変わり、AIツールの利用料が加わる | タスク分類ごとの係数を実績で補正し、利用料も含めて管理する |
| 品質 | 成果物の量が増え、「見た目は完成」に見えやすい | 完了の定義を引き上げ、人の承認ゲートと自動チェックを設計する |
| リスク | エージェントの誤動作、情報漏えい、責任の曖昧化といった新しいリスクが生じる | AI特有のリスクをリスク登録簿に加え、対応策と責任者を決める |
| ステークホルダー | 「AIならすぐできる」という期待と実態のずれが生じやすい | フロー指標による報告で、期待値を継続的に調整する |
特にリスクの観点では、従来のリスク管理の進め方をベースにしつつ、AI特有のリスクを洗い出すことが大切です。リスク管理の基本的な流れはプロジェクトのリスク管理の解説記事で紹介しています。
明日から使えるチェックリスト
| 観点 | チェック項目 |
|---|---|
| 見積もり | 見積もりのタスクを、AIが効く作業と効かない作業に分類しているか |
| 見積もり | レビュー・検証工数を独立した項目として見積もりに載せているか |
| 見積もり | AIによる短縮率を、仮置きのままにせず実績で補正しているか |
| 進捗報告 | 進捗報告の主軸が、PR数などの活動量ではなくフロー指標になっているか |
| 進捗報告 | レビュー待ち時間を継続的に計測しているか |
| 完了の定義 | 完了の定義に「テスト通過」と「レビュー承認」が含まれているか |
| 承認ゲート | 仕様・設計・実装の境目に、人の承認ゲートと承認者が決まっているか |
| リスク | AI特有のリスクがリスク登録簿に載り、責任者が決まっているか |
すべてを一度に整える必要はありません。まずは現状でどの項目ができていないかを把握し、影響の大きいものから一つずつ手を付けていくことが、現場を混乱させずに進めるコツです。
導入イメージ：AI時代のPM力を組織で底上げするには
ここで紹介した見積もり・報告・完了の定義の見直しは、PM個人の努力だけでは定着しにくいものです。チームや組織ごとにボトルネックの場所も、AI活用の成熟度も異なるため、自社の状況に合わせて進め方を設計する必要があります。
AI Dev Campでは、汎用的な研修パッケージを当てはめるのではなく、まず事前ヒアリングで現場の状況を把握し、実際に起きたプロジェクトの失敗事例をさかのぼって分析したうえで、研修・変革支援の内容をカスタマイズします。プロマネ研修はSOLIZE HDからのライセンス供与に基づき、AI駆動開発の技術面はHEXA-BASEとの技術アライアンスに裏付けられています。また、設計品質・セキュリティ・テスト納品の3段階で自動チェックを行うハーネスエンジニアリングの考え方を取り入れ、AI駆動開発の速さと品質の両立を支援します。
たとえば、「AIツールは導入したが、見積もりや報告のやり方は従来のまま」というチームであれば、現状のプロジェクトのデータをもとにボトルネックを特定し、見積もりの分類や報告の型を一緒に作り込んでいく、といった進め方が考えられます。
よくある質問
Q. AI駆動開発を導入すれば、どの会社でも生産性は上がりますか？
A. ツールを導入するだけで、どの会社でも生産性が上がるわけではありません。実装は速くなっても、レビューやテスト、要件定義といった前後の工程が追いつかなければ、プロジェクト全体の速度は変わらないためです。見積もり・報告・完了の定義など、開発の進め方そのものを合わせて見直すことが必要です。
Q. AI駆動開発の見積もりは、従来より何割減らせばよいですか？
A. 一律に何割減らすという考え方はおすすめできません。AIの効果は作業の種類によって大きく異なるため、タスクを分類し、それぞれの短縮率を実績で補正していく方法が現実的です。また、実装が速くなる分、レビュー・検証工数は増える前提で見積もる必要があります。
Q. AIが書いたコードの品質責任は、誰が持つべきですか？
A. AIが書いたコードであっても、品質の責任は最終的に人とチームが負います。そのため、工程の境目ごとに誰が何を確認して承認するのかを具体的に決めておくことが重要です。承認ゲートと承認者を明文化しておけば、責任の所在が曖昧になるのを防げます。
Q. PM自身もAIツールを使いこなす必要がありますか？
A. 高度な使い方まで習得する必要はありませんが、AIで何ができて何が難しいのかを、実際に触って理解しておくことは重要です。AIの得意・不得意を知らないと、適切な見積もりやレビュー体制を設計できないためです。まずは身近な業務で試し、チームの使い方を把握するところから始めるとよいでしょう。
まとめ
- AI駆動開発ではボトルネックが実装からレビュー・テスト・判断へ移るため、PMは実装中心の見積もりと管理の前提を見直す必要があります。
- 見積もりはタスクの性質ごとにAIの効き方を分け、レビュー・検証工数を独立した項目として計上し、実績で補正していくことが重要です。
- 進捗報告はPR数などの活動量ではなくフロー指標を主軸にし、完了の定義と人の承認ゲートを具体的に決め直すことで、速さと品質を両立できます。
お問い合わせ
「AIならすぐできる」に、根拠をもって応えられるチームへ
AI駆動開発の導入を進めているが、見積もりや進捗管理、品質の担保の仕方に悩んでいる――そのような課題をお持ちの方は、お気軽にご相談ください。現場の状況をお伺いしたうえで、最適な進め方をご提案します。
出典：TechTargetジャパン「『AIならすぐできるはず』と言われるエンジニア 他職種とのずれを埋めるには」（2026年9月11日、キッカケクリエイションによるITエンジニア321人調査・2026年5月実施）／ITmedia NEWS「CTOが『AI導入で生産性を1年で2倍に』掲げた企業のその後 米国が開発者802人の進捗を追跡調査」（2026年10月15日）、“AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate”（arXiv:2607.01904）／PMI「PMBOK Guide」
