AI時代は「PJM最強説」：プロジェクトマネージャーの重要性が高まる理由

生成AIの進化で、仕事のあり方が大きく変わり始めています。AIはコードを書き、テストを実行し、ドキュメントを作ります。AIエージェントは、調査・分析・設計・実装といった複数の工程を、自律的に進められるようになりつつあります。

こうした変化の中で、エンジニアやコンサルタント、プロジェクトマネージャーの仕事は、どう変わるのでしょうか。

当社は、ひとつの仮説を持っています。

AI時代に最も大きなレバレッジを得る人材のひとつは、プロジェクト設計に長けたプロジェクトマネージャー（PJM）ではないか。

ここでいうPJMは、進捗管理や会議の運営を主な仕事とする管理者ではありません。ゴールを定義し、実現するためのプロセスを設計し、人とAIを組み合わせ、検証と修正を繰り返しながら成果へ導く人材です。

AIが実行を担う時代だからこそ、こうしたPJM型の能力が重要になります。そして、AIで管理業務の負担が減るほど、PJMは顧客との交渉やメンバーの支援といった、人にしかできない仕事に集中できるようになります。

AIで、仕事のボトルネックはどう変わるのか

実行のコストが下がり、ボトルネックは「何を、どう実現するか」の設計に移ります。

これまで、何かを実現するには、多くの人手と時間が必要でした。新しいサービスを立ち上げるなら、市場を調べ、要件を定義し、設計し、開発し、テストします。それぞれの工程に専門家が要り、作業を進めるための調整にも相応のコストがかかっていました。

生成AIは、この構造を変えつつあります。調査、分析、設計、実装、テスト、文書の作成。人が行ってきた知的作業の相当部分を、AIが支援し、場合によっては自律的に実行できるようになってきました。

もちろん、すべての作業がAIに置き換わるわけではありません。品質保証、セキュリティ、組織間の調整、最終的な意思決定は、人の関与が必要な領域として残ります。それでも、仕事を実行するコストが下がっていく方向は明確です。

実行のコストが下がると、成果を生むうえでのボトルネックも変わります。これまでは、実現したいことがあっても、人手や専門スキル、予算が足りずに実行できないことが多くありました。AIで実行の能力が広がると、今度は「何を実現するのか」「どう実現するのか」「何をもって成功とするのか」を決める能力が重要になります。

つまり、ボトルネックが実行（Execution）から、プロジェクト設計（Project Design）へ移っていく可能性があります。

「どうやって作るか」のコストが下がるほど、「何を、何のために、どのようなプロセスで実現するか」を設計する能力が重要になる。

当社は、ここにPJMの新しい可能性があると考えています。

PJMの本質は、進捗管理なのか

PJMの本質は、不確実な状況の中で、ゴールを達成するためのプロセスと検証の方法を設計し、実行することです。

PJMというと、WBS（作業を分解した一覧）を作り、進捗を確かめ、課題管理表を更新し、会議を運営する人を思い浮かべるかもしれません。しかし、それらはプロジェクトマネジメントの手段であって、目的ではありません。

例えば、新しいECサイトを立ち上げるプロジェクトを考えてみます。プロジェクト設計に長けたPJMは、開発のタスクを洗い出してスケジュールを管理するだけではありません。

• そもそも何を実現したいのか。売上を伸ばしたいのか、顧客体験を良くしたいのか、運用コストを下げたいのか
• そのゴールに必要な成果物は何か。どんな制約があるのか
• どこにリスクがあり、何をもって成功と判断するのか
• 計画どおりに進まなかったとき、何を変え、何を諦め、どんな代替手段を取るのか

こうした問いに答えながら、ゴールへの道筋を作り続けます。

私が見ていたのは、コードではなく、顧客と数字だった

私自身、大規模なプロジェクトを統括していたとき、コードは見ませんでした。要件の中身も、ほとんど把握していませんでした。要件の細部は、各工程のリーダーと専門家に任せていました。

その代わりに、顧客のビジネスと、ステークホルダーとの関係は、深く理解していました。顧客がこのプロジェクトで何を実現したいのか。誰が何を気にしていて、どこで誰の合意が要るのか。私が責任を持っていたのは、そこです。

プロジェクトの進み具合は、数字で見ました。各工程のアウトプットの数と進捗率、そしてそれを評価する基準です。例えば開発の工程なら、テストのカバレッジと、変更要求（CR）の件数の推移を見ました。CRの推移を見れば、要件がぶれているのか、収束しているのかが分かります。

基準は、その時々の状況に合わせて決めました。条件は、ステークホルダーに説明できることです。説明できる基準を決められたのは、顧客のビジネスと、ステークホルダーが何を気にしているかを理解していたからです。そのうえで、数字を見て手を打ちました。数字が思わしくなければ、PL（プロジェクトリーダー）に手当てを指示しました。場合によっては、自分が直接入りました。

実際のプロジェクトは、計画どおりに進むことの方が珍しいものです。人には得意・不得意があり、感情があり、利害関係があります。組織には政治があり、情報の偏りがあり、予期しない制約が生まれます。PJMは、交渉、説得、優先順位の変更、スコープの調整、代替案の検討といった手段を使い、ゴールへ近づけていきます。

こうした泥臭い経験こそ、AI時代に大きな意味を持つと考えています。

なぜ、AIエージェントの設計はプロジェクトマネジメントに似ているのか

どちらも、ゴールを定め、実行し、結果を評価して直す、という同じ循環で動くからです。

AIに複雑な仕事を任せるには、「これをやって」と指示するだけでは足りません。目的、前提条件、使える情報、実行の手順、使うツール、期待する成果物、合格の基準を定める必要があります。さらに、結果を評価し、問題があれば直し、必要なら人に判断を戻す仕組みも要ります。

これは、プロジェクトマネジメントの構造とよく似ています。

プロジェクトマネジメント	AIエージェントの設計
ゴール・目的	Goal / Task
要件・前提条件	Context / Instructions
WBS・作業のプロセス	Workflow / Orchestration
役割と責任	Agent / Tool / Handoff
成果物	Output / Artifact
受け入れの基準	Evaluation / Test
品質管理	Guardrail / Quality Gate
レビュー・手戻り	Evaluation / Correction Loop
エスカレーション	Human-in-the-loop

どちらも、次の流れをくり返します。

ゴールを決める → 共通の言葉と情報をそろえる → 計画し、実行し、モニタリングする → 検証し、軌道を修正する → 達成を評価する

前の節の私の経験も、この流れそのものです。コードや要件の細部を見なくても、顧客のゴールを理解し、検証とモニタリングの基準を決め、数字を観測し、外れたら手を打てば、プロジェクトはゴールに近づきます。AIエージェントに仕事を任せるときも、人が見るべきものは同じです。

近年注目されるContext Engineering（AIに渡す情報の設計）やHarness Engineering（AIを動かす環境の設計）も、PJMの考え方をAIの実行環境に広げたもの、と捉えられます。

もちろん、AIエージェントの技術的な設計には、ソフトウェアエンジニアリングやセキュリティの専門知識が要ります。それでも、AIに何を任せ、どんな条件で実行させ、どう評価し、いつ人が介入すべきかを設計する能力は、PJMが培ってきた能力と重なる部分が大きいのです。

AIは、PJMの仕事をどう変えるのか

管理業務の一部をAIに任せることで、PJMは交渉や支援、意思決定といった、人にしかできない仕事に集中できるようになります。

これまでPJMは、進捗の確認、資料の作成、会議の準備、課題の整理、状況の報告といった、多くの管理業務を担ってきました。どれもプロジェクトを進めるうえで必要ですが、PJMがすべて手作業で行う必要はありません。

空いた時間は、例えば次の仕事に使えます。

• 顧客との関係づくりと利害の調整：途中で顧客の要求が変わったとき、変更管理票を作るだけでは解決しません。顧客が本当に求めていることを理解し、関係者の利害を調整し、双方が納得できる着地点を見つける必要があります。
• メンバーの支援：遅れているメンバーに、遅れの理由を報告させるだけでは足りません。技術的な問題なのか、仕事の量が多すぎるのか、心理的な負担があるのかを見極め、必要な支援をします。

こうした仕事には、信頼関係、共感、交渉、判断、責任が伴います。AIは情報の整理や選択肢の提示で支援できますが、人同士の関係を築き、困難な意思決定を引き受ける役割までは、簡単に代わりにはなれません。

AIによってPJMは、人間らしい仕事から解放されるのではない。むしろ、より人間らしい仕事に集中できるようになる。

ここで大事なのは、実行そのものがAIに置き換わるわけではない点です。AIに任せられる実行と、人が担うべき実行が、配分し直されるのです。

PJMの能力は、5つの方向に広がる

これまで、PJMが担当できるプロジェクトの数や規模には、現実的な限界がありました。調査、資料の作成、進捗の確認、関係者の調整を、人が処理しなければならなかったからです。AIで実行・調整・検証のコストが下がると、この制約が緩みます。

方向	広がること
① 数	定型の管理作業や情報収集をAIに任せ、複数のプロジェクトを並行して進めやすくなる
② 規模	大量の情報の整理や進捗の分析をAIが支え、複雑なプロジェクトの状況をつかみやすくなる
③ 深さ	調査、試作、テストを、AIを使ってPJM自身が直接進められる場面が増える
④ 質	複数の代替案を比べ、テストと評価を繰り返し、限られた時間でも品質を高められる
⑤ 領域	マーケティング、営業、採用、業務改革、新規事業の開発といった、IT以外のプロジェクトも進められる

単純にすれば、次のように表せます。

PJMのレバレッジ ＝ プロジェクト設計の能力 × AIの実行能力

これは厳密な数式ではなく、考え方のモデルです。AIの実行能力が高まるほど、それを使いこなせるPJMのレバレッジも大きくなる、という仮説です。

ただし、AIを使えるだけでは足りません。プロジェクトを設計する能力がなければ、AIは間違ったゴールに向かって、大量の成果物を作り続けかねません。逆に、プロジェクト設計に長けたPJMなら、実行の制約が緩むほど、能力を発揮できる範囲が広がります。

これまで実行のリソースの制約で発揮しきれなかったPJMの能力が、AIによって解放される。 ここに「PJM最強説」の核心があります。

すべてのPJMが、同じように強くなるのか

進捗報告の集約、議事録の作成、課題一覧の更新、定型の状況分析が主な仕事なら、自動化の影響を強く受けます。こうした仕事が中心のPJMは、仕事の重心を、設計と人にしかできない仕事へ移す必要があります。

一方で、次の能力を持つ人材は、AI時代にさらに求められると考えています。

• 曖昧な課題から、本当に達成すべきゴールを定義できる
• ゴールを、実現できるプロセスとタスクに分解できる
• 人とAI、それぞれの強みと制約を理解して、仕事を割り当てられる
• 成果を客観的に評価する基準と、検証の方法を設計できる
• 想定外の事態に対して、柔軟に手段を変えられる
• 顧客やメンバーと信頼関係を築き、困難な調整や意思決定を担える
• 成果物の完成ではなく、ビジネスの成果に責任を持てる

これは、管理の能力だけではありません。不確実な状況で、使えるリソースを組み合わせ、ゴールを達成する能力です。

この能力は、プロジェクトマネージャーという役職に限りません。事業責任者、プロダクトマネージャー、コンサルタント、エンジニアにも共通します。「PJM最強説」とは、PJMという肩書きが最強だという話ではありません。PJM型の考え方と実行の能力を持つ人材が、AI時代に大きな競争優位を得るのではないか、という仮説です。

AI時代、人材の競争力を決めるものは何か

AI Literacy（AIを理解して使う能力）と並んで、Project Literacy（課題をプロジェクトとして構造化し、成果へ導く能力）が、競争力を左右すると当社は考えています。

AIの活用が広がるほど、AIツールを操作できること自体は、特別なスキルではなくなっていきます。一方で、何を実現すべきかを見極め、曖昧な問題を構造化し、プロジェクトを設計して成果まで導く能力は、簡単には身につきません。

AIは、経験の浅い人の能力を底上げし、個人の差を縮めるかもしれません。一方で、プロジェクト設計に長けたPJMがAIを使いこなせば、これまで以上の成果を生むかもしれません。AIが、すべての人の能力を一律に引き上げるとは限らないのです。

この変化は、企業の人材戦略にも新しい問いを投げかけます。

PJMの実行能力がAIで広がるなら、企業はその人材をどう評価し、育て、増やしていくべきか。

管理するプロジェクトの規模や人数、稼働率だけで評価するのが適切とは限りません。問われるのは、どれだけのビジネスの成果を生み出せるか。そして、その能力を個人のスキルにとどめず、組織全体に広げられるかです。

AI時代に強いのは、AIより速く仕事をこなす人ではありません。AIを使って、これまで実現できなかった成果を生み出せる人です。

PJMと経営者は、何から始めればよいか

まずは、PJMの仕事を分け、AIに任せる仕事を1つ決めることから始めます。

1. 自分の仕事を、3つに分ける。「プロジェクトの設計」「人にしかできない実行（交渉・支援・判断）」「AIに任せられる作業」です。
2. AIに任せられる作業から、定型の管理業務を1つ選び、AIに任せる。例えば、進捗報告の集約や議事録の作成です。
3. 空いた時間を、顧客との調整とメンバーの支援に使う。
4. 検証とモニタリングの基準を、言葉にしておく。何の数字を見て、どの値なら手を打つのかを、ステークホルダーに説明できる形で決めます。

経営者は、PJMを、管理するプロジェクトの数や稼働率だけでなく、生み出したビジネスの成果で評価することを検討してください。

PJMを成果で評価する考え方は、受託ビジネスの稼ぎ方にも関わります。成果に責任を持つ受託のあり方は、記事「AIが開発する時代、受託ビジネスは「人月」から「成果」へ」で考察しています。