「PMBOKを読み込んだのに、実際の案件で何も使えなかった」
これは、私が事業責任者としてIT受託開発を統括していたころ、何人もの若手PMから聞いた言葉です。PMBOKを丁寧に勉強して試験に合格した。なのに、現場に立つと「あの知識はどこで使うんだろう」という感覚になってしまう。
正直に言います。これはあなたのせいではありません。PMBOKは「そういう設計」になっているからです。
私自身、240人月・29案件を統括してきた経験から、受託開発PMに本当に必要なスキルは、PMBOKの勉強では体系的に身につかないと断言できます。では何を学べばいいのか。この記事でその正体を整理します。
PMBOKが現場で「使えない」と感じる3つの理由
1. 汎用すぎて「受託開発の文脈」がない
PMBOKはプロジェクトマネジメントの知識体系を整理したものです。ソフトウェア開発だけでなく、建設・製造・研究開発・社内DXまで、あらゆる業界・業種を対象にしています。
その汎用性こそが強みである反面、受託開発PMが日々直面するリアルな状況、例えば追加要望を断れない営業との板挟みや、曖昧な要件で始まる案件の前提整理、赤字化しかけている案件の立て直しなどには直接対応していません。
PMBOKを読んでも、「で、明日の朝一の顧客MTGで何を言えばいいか」という答えは出てこないのです。
2. 知識の整理はできても「判断の訓練」にならない
PMBOKで学べるのは「WBSとはこういうものだ」「リスク管理にはこういう手順がある」という知識の体系です。しかし実務では、知識があるだけでは不十分で、状況を読んで自分で判断する力が求められます。
- スケジュールが2週間遅れているとき、納期交渉すべきか、夜間対応で巻き返すか
- 顧客から仕様変更の要望が来たとき、受け入れるか、範囲変更として交渉するか
- バグが多発して品質ゲートを通過できないとき、リリースを延期するか、段階リリースに切り替えるか
こういった判断は、PMBOKを暗記していても出てきません。判断軸は、ケースを重ねる中で体に染み込んでいくものです。
3. 「受験→合格→忘れる」のサイクルで定着しない
PMPを取得した直後は知識が頭に残っています。ところが、現場でそれを使う機会がないまま数ヶ月経つと、ほとんど抜けてしまいます。これは記憶の問題ではなく、知識が実務の文脈に紐づいていないからです。
人間の記憶は「状況」と一緒に保存されます。「あのとき炎上案件でスコープを整理して顧客と合意した」という体験があって初めて、スコープ管理の知識が使えるものとして定着します。
受託開発PMに本当に必要な3つのスキル
では、受託開発PMが実際に身につけるべきスキルとは何か。私が29案件を通じて実感したのは次の3つです。
スキル1：前提条件を整理・合意する力
受託開発の案件は、スタート地点の認識のズレから炎上します。「この要件で開発する」という合意があっても、顧客と自社エンジニアで「前提」が全く違う、ということが起きます。
具体的には、次のような力です。
- 何が決まっていて、何が決まっていないかを可視化できる
- 曖昧な要件を顧客と一緒に言語化できる
- 決めた前提を議事録・仕様書として合意文書に落とせる
PMBOKの「スコープ管理」はこれを扱っていますが、受託開発特有の「営業フェーズで曖昧なまま受注した案件をどう整理するか」という文脈はありません。
スキル2：変化に対して根拠を持って判断する力
案件が進むと、必ず「想定外」が起きます。仕様変更、遅延、人員離脱、品質問題。このとき、PMに求められるのは「どうすれば一番ダメージが小さいか」を判断し、顧客・チームに説明できることです。
感情的に動いてしまったり、上司に丸投げしてしまうPMと、根拠を持って判断できるPMの差は大きい。この力は、判断の根拠となるフレームワークを持っているかどうかで決まります。
スキル3：ケースで鍛えた判断の引き出し
1と2は「知識として持っている」だけでは不十分で、過去に似たケースを経験したり疑似体験したりしているかどうかが判断の速さと精度を左右します。
よくベテランPMが「場数が必要」と言うのはここです。ただし、実際の場数を積むには時間がかかるし、炎上案件で痛い目を見ながら学ぶのは自分だけでなくチームや顧客にも迷惑をかけます。
判断力は「場数」ではなく「設計された練習」で身につく
ここが重要なポイントです。場数を積まなければ判断力が身につかない、というのは半分正しくて半分間違いです。
必要なのは「経験の量」ではなく、「判断を迫られる状況に何度も入り、振り返る機会」です。これは実案件でなくても設計できます。
スポーツで言えば、試合経験だけで上手くなるのではなく、練習で「この場面ではこう判断する」を繰り返すことで試合での判断が速くなる、という感覚に近いです。
架空プロジェクトでケース演習する
私が有効だと考えているのが、架空プロジェクトのケースを使った判断演習です。
「要件が途中で迷走してきた。あなたはPMとしてどう対処するか」「スケジュールが崩れかけている。原因は何で、どの選択肢を選ぶか」といったケースを、実案件とは別に繰り返し練習する。
リスク・スコープ・スケジュール・コスト・品質・ステークホルダーの各マネジメントについて、典型的な「判断が必要な場面」を演習形式で学べれば、実案件での判断は明らかに速くなります。
受託開発に特化した体系で学ぶ
加えて、受託開発特有の流れ、つまり案件の立ち上げから計画、実行管理、完了までを一貫して学べる体系が必要です。PMBOKは汎用的すぎるため、受託開発PMが直面するシチュエーションが抜け落ちています。
「営業から受注した案件を、最初にどう整理するか」「顧客との合意をどのタイミングでどう取るか」「利益を守りながら変更要望を処理するか」といった受託開発ならではの判断軸は、受託開発を前提にした体系でしか学べません。
まとめ PMBOKを超えるための学習設計
PMBOKやPMPの勉強が無駄だとは言いません。知識の語彙を整えるという意味では価値があります。
ただ、受託開発PMとして実際に案件を主導するためには、PMBOKの勉強とは別の学習が必要です。
具体的には、次の3点です。
- 受託開発の文脈に特化した体系で学ぶ（汎用知識ではなく受託開発PM実務の体系）
- 判断を迫られるケースを繰り返し演習する（場数を待たずに判断軸を作る）
- 体系学習からケース演習の順で学ぶ（知識をまず整理し、次に使える状態にする）
この3つを一気通貫で設計した講座として、PJMシリーズ（受託開発PM実務の体系）とIPJシリーズ（架空PJで鍛えるケース演習）があります。
PJMシリーズでは受託開発のPM基礎から計画づくり・実行管理まで、受託開発特有の判断軸を体系的に学べます。IPJシリーズでは、リスク・スコープ・スケジュールなど各マネジメント領域の典型ケースを架空プロジェクトで演習します。「場数を積むしかない」と言われていた判断力を、設計された練習で身につける。それがこの2シリーズのコンセプトです。
「PMBOK勉強したけど現場で使えなかった」という経験がある方ほど、両シリーズの体験が新鮮に感じられると思います。まずはPJM-101（受託開発のPM基礎）から始めてみてください。