結論から言うと、置き換えない。AI PMは人間のPM業務のうち、反復的で構造化できる部分(リクエストの受付、タスクの整理、ステータスの追跡、ドキュメント化)を素早く肩代わりするが、政治的な判断や信頼にもとづく交渉、あいまいな優先順位を最終的に決める仕事は、依然として人間の役割だ。だから今の時点でもっとも正確な言い方は「置き換え(代替)」ではなく「拡張」、つまり人間のPMの能力を広げてくれるツールに近い、ということになる。この記事では人間のPMの仕事を一つずつ分解し、そのうちどこまでをAI PMが実際にこなせるのか、ONTLEのような派遣型AI PMモデルがこの境界をどう扱っているのかを見ていく。
「プロジェクトマネージャー」という一つの肩書きでひとくくりにされがちだが、実務におけるPMの仕事は、性質のまったく異なる五つに分けられる。この区分がこの記事全体の骨格になる。
| 業務領域 | 具体的にやっていること | 性質 |
|---|---|---|
| スケジュール管理 | マイルストーン設定、締め切り調整、ボトルネック予測 | 構造化できる |
| コミュニケーションのハブ | リクエスト受付、担当者アサイン、進捗の伝達 | 構造化できる + 関係性 |
| リスク・課題トラッキング | 問題の早期発見、深刻度の判断、エスカレーション | 半分は構造化できる |
| ステークホルダー調整 | 相反する要求のあいだで合意点を探す | 関係性・政治 |
| 優先順位の判断 | 何を先にやり、何を捨てるかを決める | 判断・責任 |
この五つを一つの職務としてまとめて扱ってきたこと自体が、むしろ問題だった。スケジュール管理と優先順位の判断はまったく種類の違う仕事なのに、一人の人間のPMがこの両方を同時に担うことで、肝心の判断が必要な場面でも反復業務に時間を奪われるケースが多かった。この表を基準に、AI PMが得意な領域と、まだできない領域を分けてみよう。
PMを空港の管制塔にたとえると分かりやすい。管制塔は二つの仕事をしている。一つは決められた手順どおりに離着陸の順番を割り振り、滑走路の状態を絶えず確認する仕事(構造化できる仕事)、もう一つは突然の悪天候や機体トラブルの状況で、どの航空機を先に着陸させるかを瞬時に判断する仕事(判断・責任の仕事)だ。前者はマニュアルと反復的な訓練でかなりの部分を自動化できるが、後者はその結果に責任を負える人間が最終的なシグナルを出さなければならない。AI PMはまさに前者の領域、つまり管制手順の自動化にあたる。
人間のPMは勤務時間のなかでしかリクエストを受けられない。夜に思いついたアイデアや、週末に生じた急ぎの修正依頼は、次の勤務日まで待たなければならない。AI PMは時間帯に関係なく、チャット画面が開いているかぎりリクエストをその場で受け付ける。これは能力の差ではなく可用性の差だが、実務ではこの可用性の差こそ、体感としてもっとも大きい。リクエストした時点と受け付けられた時点のあいだの間隔がなくなると、依頼者からすれば「言った瞬間に記録された」という確信が生まれる。
人がプロジェクトマネージャーに話すときは、たいてい整理されていない文章で投げてくる。「このあいだ話したあのページをちょっと直したいんだけど、色がなんかイマイチなんだよね」といった文章だ。この文章には、どのページなのか、どの色がどうイマイチなのか、いつまでに必要なのかが、すべて抜け落ちている。人間のPMはこれを聞き返したり、自分の記憶で補ったりするが、その過程で時間がかかり、誤解も生じる。
AI PMは会話の文脈(過去のリクエスト履歴、プロジェクトのヒストリー)を参照して、こうしたあいまいな文章を具体的なタスク項目へとその場で変換できる。会話をしながら足りない情報はすぐに聞き返し、その結果をタスクキューに登録される項目として整理する。
要件が整理されたら、次は実際に何かが出てこなければならない。企画ドキュメント、ドラフト、画面のモックアップ、あるいはサブドメインですぐに確認できる成果物まで、この変換プロセスそのものをAI PMが担えるという点が、派遣型モデルの核心だ。人間のPMが「このリクエストはデザイナーに、このリクエストは開発者に」と人員を割り振る代わりに、AI PMがリクエストを受けて成果物まで作り上げ、結果をプロジェクト専用のアドレスですぐに見せてくれる。
人間のPMが毎日こなすのを負担に感じる仕事の一つが、「このタスクが今どのあたりまで来ているのか」を絶えず確認することだ。とくに複数のプロジェクトを同時に抱えていると、どの項目が何日も止まっているのかを見落としやすい。AI PMはタスクキューの状態を常に見ているので、停滞している項目を見落とさず、必要なタイミングで通知やお知らせとしてリマインドできる。人間の記憶力に依存しないという点が、この領域での最大の違いだ。
ここからがこの記事の核心だ。AI PMが得意な領域を並べるコンテンツは多いが、なぜ特定の領域はできないのかを説明するコンテンツはまれだ。理由をはっきり理解してこそ、「いつAI PMに任せ、いつ人間が介入すべきか」を判断できる。
プロジェクトには、表面的な要件の裏に組織内部の利害が隠れているケースが多い。「この機能を先に入れてほしい」というリクエストが、実は部署間の力関係の産物かもしれないし、「予算を削ってほしい」という言葉が、実際には別のプロジェクトにリソースを集中させるためのシグナルかもしれない。こうした文脈は会話ログに明示的には現れない。AIが会話に表れた相手の意図を推論することは可能だが、ログの外にある組織内部の力学まで把握し、それにもとづいて決定を下し責任を負う仕事は、依然として人間の役割だ。
「今回は急ぎのお願いだが、次回はこちらが譲る」といった暗黙の取引は、人と人のあいだの信頼関係の上に成り立つ。AIに交渉能力そのものがないわけではない — MetaのCICEROは、ボードゲームのディプロマシーという限定された環境で、相手の意図を推論し、人間と交渉・同盟を結んでみせた(開発陣の公開資料)。ただし、それがルールの明確なゲームを離れて、実際の組織の信頼関係にそのままつながるという意味ではなく、後続研究はこうした交渉能力が特定の条件に大きく依存するという限界を指摘している(限界を分析した後続論文)。AI PMは会話の内容を記録し、約束が履行されたかどうかを追跡することはできるが、長年の信頼関係の上で無形の価値を賭けて相手を説得し、その結果に責任を負う仕事までを肩代わりするのは難しい。交渉はロジックの問題であるだけでなく、関係性の問題であることのほうが多いからだ。
タスクキューに十件のリクエストが積まれていて、リソースは三件しか処理できないとき、「何を先にやるか」はデータだけでは決まらない。締め切り、重要度、依頼者の影響力、そして組織が今どこに力を入れたいと考えているか、それらが入り混じった判断だ。AI PMは各項目の締め切りや依存関係といった事実情報を整理して見せることはできるが、最終的に「これを先にやる」という決定と、それに伴う責任は人間が負わなければならない。
もっとも根本的な違いはここにある。決定が間違っていたとき、その結果を引き受ける主体がいてこそ組織は回る。AI PMがどれほど精緻にタスクを整理しても、最終承認とそれに伴う責任の所在は人間に残る。これは技術がさらに発展すれば自動的に解消される問題ではなく、そもそも性質の異なる問題だ。
まとめるとこうなる。人間のPM業務の五つのうち、スケジュール管理とコミュニケーションのハブ役、そしてリスク・課題トラッキングのかなりの部分は、AI PMが引き継げる。一方、ステークホルダー調整と優先順位の最終判断は、依然として人間の領域に残る。
この構図を「AIがPMを置き換える」と表現すれば誇張だし、「AIは単なるツールにすぎない」と縮小すれば、それも不正確だ。正確な表現は「拡張」だ。人間のPMが反復的な受付・整理・追跡の業務から解放されれば、まさに人間にしかできない判断と調整に使える時間とエネルギーが増える。一人のPMが管理できるプロジェクト数が増えるのも、この拡張の結果だ。
| 業務領域 | AI PMの役割 | 人間の役割 |
|---|---|---|
| スケジュール管理 | 締め切り追跡、ボトルネック通知 | 例外的な状況の最終調整 |
| コミュニケーションのハブ | 24時間の受付、構造化、進捗の伝達 | デリケートな会話、関係の維持 |
| リスク・課題トラッキング | 異常の兆候の検知、状態の記録 | 深刻度の最終判断、エスカレーションの決定 |
| ステークホルダー調整 | リクエスト内容の整理・共有 | 合意点の導出、説得 |
| 優先順位の判断 | 事実情報の整理(締め切り・依存関係) | 最終決定と責任 |
ONTLEは、プロジェクトを作るとそのプロジェクト専任としてAI PMが一人アサインされる派遣型の構造を採っている。ここで「派遣型」という表現が重要で、複数のプロジェクトが一つのAIを共有する方式ではなく、プロジェクトごとに独立した担当者が付くという意味だ。人の組織でプロジェクトごとに担当PMをアサインするやり方と同じ構造を、AI PMにもそのまま適用したものだ。
この専任のAI PMがやる仕事は、さきほど説明した「AI PMが得意なこと」の実際の実装だ。
逆に、ONTLEのAI PMが肩代わりしない領域も明確だ。複数のステークホルダーのあいだの最終合意、プロジェクトの方向を変える大きな決定、そしてその決定に対する責任は、依然としてプロジェクトを運営する人間の役割として残る。ONTLEはこの境界を消そうとはしない。むしろAI PMが反復業務を確実に引き受けることで、人間が判断だけに集中できる環境をつくる、という方向に近い。
AI PMの導入を検討するとき、「自分たちのプロジェクトに合うか」を判断する基準を整理すると、次のようになる。
| 状況 | AI PMが効果的 | 人間のPMがより必要 |
|---|---|---|
| リクエストが頻繁に、不定期に入ってくる | そうだ(24時間受付) | - |
| リクエスト内容が反復的なパターンを持つ | そうだ(構造化の学習) | - |
| 複数ステークホルダーの意見の食い違いの調整が多い | - | そうだ |
| 小規模プロジェクトで専任人員のアサインが負担 | そうだ | - |
| 成果物(ドキュメント・画面)を素早く確認したい | そうだ(即時公開) | - |
| 組織の政治・予算交渉が絡んでいる | - | そうだ |
| 進捗を見落とさず追い続ける必要がある | そうだ | - |
要は「仕事がどれだけ構造化できるか」だ。リクエストのパターンが反復的で、成果物の形がある程度決まっていて、進捗を見落とさないことが重要なプロジェクトほど、AI PMの効果は大きい。逆に、毎回違うステークホルダーとの調整が必要で、正解の決まっていない判断が多いプロジェクトなら、AI PMは補助的な役割にとどまり、人間のPMの比重が依然として大きくなければならない。
実務では、ほとんどのプロジェクトがこの二つの両極のどこかにある。だから「AI PMか人間のPMか」を二者択一で見るのではなく、反復できる業務はAI PMに任せ、判断が必要なポイントでだけ人間が介入する構造を設計するのが、現実的なアプローチだ。
いいえ。AI PMは受け付けたリクエストを整理してタスク化し進めますが、プロジェクトの方向や優先順位を変える決定は、プロジェクトを運営する人間の承認を経ます。
可能です。AI PMが反復的な受付・整理・追跡の業務を担い、人間のPMは調整と最終判断に集中する、という形で一緒に運用できます。
プロジェクトごとのナレッジ ONTLEに蓄積され、その後のリクエストを判断する際に文脈として参照されます。毎回ゼロから説明する必要が減る理由です。
会話で改めてリクエストすれば大丈夫です。AI PMがフィードバックを新しいタスクとして登録して反映し、結果を再び確認できるようにします。
むしろ小規模プロジェクトのほうが効果が大きいことがあります。専任人員をアサインするのが負担な規模でも、リクエスト受付から成果物の公開までつながる流れを維持できるからです。
プロジェクトを作ると専任のAI PMがアサインされ、リクエストの受付からタスク管理、成果物の公開までを一緒に進めます。反復業務はAI PMに任せ、判断が必要な瞬間にだけ集中したいなら、https://ontle.kr で直接ご確認ください。