PM1人とClaude Code 1台。これがマレーシアで実際に動いている開発チームの全員です。
本記事はPMBOK-AIシリーズ第1章「序章 ― 新時代の黎明」のテキスト版です。読むだけでPMBOK-AIの出発点を理解できる内容に仕上げています。動画版も準備中ですので、公開時にはこの記事からリンクします。
この記事で理解できること
- 60年間、すべてのPM手法が共有していた「たった一つの前提」
- その前提が崩壊した具体的なメカニズム
- PM不足という構造的問題と、既存手法の限界
- 生成AIが「便利ツール」ではなく「構造変化」である理由
- PMBOK-AIが必然的に生まれた背景
60年間、誰も疑わなかった前提
1960年代にPERT/CPMが体系化されて以来、プロジェクトマネジメントの手法は目覚ましく進化してきました。ウォーターフォール、アジャイル、スクラム、SAFe、DevOps。名前も思想も異なるこれらの手法は、しかし一つの前提を共有しています。
タスクを実行するのは人間だけ
ウォーターフォールの工程分割は「人間がどの順序で作業するか」を設計するもの。アジャイルのスプリントは「人間がどう協働するか」を最適化するもの。すべてのPM手法は、実行者が人間であることを暗黙の前提としています。
コミュニケーション問題、モチベーション管理、スキル育成、リソース調整。PMが日々格闘するこれらの課題は、すべて「人間系」の課題です。
この前提を、60年間誰も疑いませんでした。疑う必要がなかったからです。
しかし2020年代、生成AIの登場によりこの前提が崩壊しました。
PM不足という構造的危機
前提の崩壊を語る前に、なぜ今この変化が必要なのかを整理します。
プロジェクトは増え続け、PMは増えない
DX推進、クラウド移行、SaaS開発、データ基盤構築。企業が取り組むべきプロジェクトは年々増加しています。PMI（Project Management Institute）の調査によれば、2030年までにプロジェクトマネジメント関連の職種は全世界で2,500万人の新規需要が生まれるとされています。
しかし現場の実感はこうです。
- 1人のPMが3〜5件のプロジェクトを掛け持ちしている
- 経験あるPMの採用は困難を極める
- ジュニアPMを育成する余裕がない（育成する側のPMも忙しい）
プロジェクトの数は10倍に増えたのに、PMの数は増えていない。 これは一時的な需給ギャップではなく、構造的な問題です。
既存手法の限界が見えてきた
ウォーターフォールの問題は明らかです。要件変更に弱く、フィードバックループが遅い。
ではアジャイルはどうか。アジャイルは変化に強い手法ですが、「十分な人数のチームメンバー」を前提としています。スクラムガイドには「開発者は3〜9人」と明記されています。しかし現実には、そのチームを組めない組織のほうが多い。
手法は進化したが、「実行者は人間のみ」という前提は変わらなかった。 だから、人が足りなければどの手法も機能しない。これが既存手法の根本的な限界です。
AIの進化 ― なぜ第3段階が決定的なのか
AIの進化を3つの段階で整理します。
| 段階 | 名称 | できること | PMへの影響 | 例 |
|---|---|---|---|---|
| 第1段階 | 計算知能 | 最適解を求める | スケジュール最適化 | チェス、最短ルート |
| 第2段階 | 認識知能 | パターンを見つける | 異常検知、予測 | 画像認識、音声認識 |
| 第3段階 | 生成知能 | 創造する | タスクを実行する | ChatGPT、Claude、Gemini |
第1段階と第2段階のAIは、PMにとって「便利なツール」でした。ガントチャートの自動最適化、進捗の異常検知。いずれも「人間の判断を支援する」立ち位置です。
第3段階の生成知能は質的に異なります。文章を書き、コードを書き、設計書を起草し、テストケースを作成し、データを分析して示唆を出す。これは支援ではなく、実行です。
つまり、プロジェクトにおいて「タスクをアサインする相手」に、人間以外の選択肢が加わったのです。
具体例：API認証機能の実装で何が変わったか
抽象論だけでは伝わらないので、具体例を示します。
従来のフロー（人間チーム）
- PMがタスクを定義し、バックログに追加
- スプリントプランニングでエンジニアにアサイン
- エンジニアが実装（1〜3日）
- コードレビュー依頼 → レビュアーの空き待ち（半日〜1日）
- レビュー指摘 → 修正 → 再レビュー（半日〜1日）
- マージ・デプロイ
所要時間：3〜5営業日
現在のフロー（PM + AI）
- PMがGitHub Issueにタスクを定義（目的・制約・テスト条件を明記）
- Claude Codeに実装を依頼
- テスト付きの実装が数時間で完成
- PMがレビュー → フィードバック → 即時修正
- テスト確認 → マージ・デプロイ
所要時間：1営業日以内
重要なのは速度だけではありません。PMが全工程を把握し、設計の一貫性を保てるという点が本質的な変化です。
原体験 ― 深夜2時、マレーシアのオフィスで
PMBOK-AIの原点となった体験を共有します。
マレーシアのあるプロジェクト。納期は明後日、人手はゼロ。深夜2時に1人でコードレビューをしていたとき、半ば自暴自棄でClaude Codeにプルリクエストのセキュリティチェックを依頼しました。
5分後、レポートが返ってきました。
そこには「認証トークンの有効期限チェックが欠落している」という指摘がありました。自分が3時間見落としていたセキュリティホールを、AIが5分で発見したのです。
「これはツールじゃない。一緒に仕事ができる相手だ。」
この瞬間、確信しました。AIをプロジェクトの正式なメンバーとして扱うための体系が必要だと。
3つの変化が同時に来ている
| 変化 | 内容 | 影響 |
|---|---|---|
| 社会の加速 | プロジェクト数が爆発、PM不足が深刻化 | 1人のPMが担う範囲が拡大 |
| PM手法の限界 | ウォーターフォールもアジャイルも「人間のみ」が前提 | 人手不足を手法で解決できない |
| 生成AIの登場 | 知的労働ができるチームメンバーの出現 | タスクの実行者の範囲が拡張 |
この3つが同時に来たからこそ、PMBOK-AIという新しいフレームワークが必要になりました。どれか1つだけなら、既存の手法を微調整すれば済んだでしょう。しかし3つが同時に起きたことで、前提そのものの再定義が必要になったのです。
ただし、AIは万能ではない
ここまでAIの可能性を語ってきましたが、重要な注意点があります。
生成AIには明確な限界があります。
- ハルシネーション（幻覚）: AIは自信満々に間違った情報を出力することがある。特にドメイン固有の知識やエッジケースで顕著
- コンテキストの断絶: 長期プロジェクトでは、AIが過去の文脈を完全に把握しきれない場面がある
- 責任の所在: AIの出力に対する最終責任は、常に人間が負う。「AIが言ったから」は言い訳にならない
- 創造性の質: AIは既存パターンの組み合わせは得意だが、真にゼロからの発想は人間に及ばない
PMBOK-AIは「AIに丸投げする」フレームワークではありません。人間の判断力とAIの実行力を、最適に組み合わせるためのフレームワークです。この点を誤解すると、プロジェクトは確実に失敗します。
まとめ：なぜ今、PMBOK-AIなのか
第1章で伝えたかったことを整理します。
- 60年間の前提が崩壊した: 「タスクの実行者＝人間のみ」は、もはや自明ではない
- PM不足は構造的問題: プロジェクトは増え続けるが、PMは増えない。手法の改善だけでは解決しない
- 生成AIは「ツール」ではなく「構造変化」: 支援ではなく実行ができるAIの登場は、PM手法の前提そのものを変える
- だからこそ新しいフレームワークが必要: 人間とAIの協働を前提としたプロジェクトマネジメント体系、それがPMBOK-AI
PM1人 + Claude Code 1台で、マレーシアの現場を実際に回している。これは実験ではなく、日常です。AI社員の実稼働データについてはAI社員の実稼働データはこちらでご確認ください。
次回の第2章では「PMBOK-AIマニフェスト」として、AIは「所詮ツール」なのか？という問いに向き合い、7つの原則と二人三脚プロセスを紹介します。
PMBOK-AIシリーズ
このシリーズでは、人間とAIが協働する時代のプロジェクトマネジメントを実践者の視点から解説していきます。
- 第1章：序章 ― 新時代の黎明（本記事）
- 第2章：PMBOK-AIマニフェスト（近日公開）
PMBOK-AIの基本概念についてはPMBOK-AIとはを、AI活用の失敗と教訓はAI活用で痛感した失敗と教訓で解説しています。
プロジェクトマネジメントやAI開発についてのご相談はお問い合わせからお気軽にどうぞ。