PMPの学習を始めた頃、私が最も混乱したことの一つが、

「PMBOKのプロセス群」と「システム開発工程」はどのような関係なのか？

という点でした。

実務でも混同されることがありますが、実は役割がまったく異なります。

---

まず結論

PMBOKは、

「プロジェクトをどのように管理するか」

を体系化したプロジェクトマネジメントのガイドです。

一方、システム開発工程は、

「システムをどのような手順で開発するか」

を示した開発プロセスです。

つまり、

• PMBOK＝プロジェクトマネジメント
• 開発工程＝システム開発ライフサイクル

という違いがあります。

そのため、

PMBOKの5つのプロセス群と、要件定義・設計・開発・テストといったシステム開発工程は、1対1に対応するものではありません。

---

PMBOK第6版の全体像

PMBOK第6版では、プロジェクトは

• 5つのプロセス群
• 10の知識エリア
• 49のプロセス

で構成されています。

☆10の知識エリア

• 1. プロジェクト統合マネジメント
• 2. プロジェクト・スコープ・マネジメント
• 3. プロジェクト・スケジュール・マネジメント
• 4. プロジェクト・コスト・マネジメント
• 5. プロジェクト品質マネジメント
• 6. プロジェクト資源マネジメント
• 7. プロジェクト・コミュニケーション・マネジメント
• 8. プロジェクト・リスク・マネジメント
• 9.プロジェクト調達マネジメント
• 10.プロジェクト・ステークホルダー・マネジメント

【プロセス群】

立上げ
　↓
計画
　↓
実行
　↓
終結

※監視・コントロールは全工程で継続して実施

しかし、このプロセス群はシステム開発工程そのものではありません。

---

PMBOKの5つのプロセス群

① 立上げ（Initiating）

プロジェクトを正式に開始するための活動です。

代表的な成果物

• プロジェクト憲章
• ステークホルダー登録簿

ここでは

「何を開発するか」

だけではなく、

「なぜこのプロジェクトを実施するのか」

を明確にします。

☆PMBOK該当（プロセス）内容

• 1.1 プロジェクト憲章の作成→ プロジェクト開始を正式に承認する文書を作成する。
• 10.1 ステークホルダーの特定→ プロジェクトに影響を与える関係者を洗い出す。

---

② 計画（Planning）

プロジェクトを成功させるための計画を策定します。

ここでは10の知識エリアに関する計画が作成されます。

例えば、

• スコープ管理計画
• WBS
• スケジュール
• コスト計画
• 品質管理計画
• 資源管理計画
• コミュニケーション計画
• リスク管理計画
• 調達管理計画
• ステークホルダーエンゲージメント計画

つまり、

「どのようにプロジェクトを管理・運営するか」を決定するフェーズです。

☆PMBOK該当（プロセス）内容

• 2.1 プロジェクトマネジメント計画書の作成→ プロジェクト全体の管理計画を作成する。
• 2.2 スコープ・マネジメントの計画→ スコープをどのように管理するか決める。
• 2.3 要求事項の収集→ 顧客・利用者の要求を整理する。
• 2.4 スコープの定義→ プロジェクトで実施する範囲を明確にする。
• 2.5 WBSの作成→ 作業を細分化し管理しやすくする。
• 3.1 スケジュール・マネジメントの計画→ スケジュール管理方法を決める。
• 3.2 アクティビティの定義→ 必要な作業を洗い出す。
• 3.3 アクティビティの順序設定→ 作業の前後関係を決める。
• 3.4 アクティビティ期間の見積り→ 各作業の日数を見積もる。
• 3.5 アクティビティ資源の見積り→ 必要な人員・設備を見積もる。
• 3.6 スケジュールの作成→ ガントチャートなどを作成する。
• 4.1 コスト・マネジメントの計画→ コスト管理方法を決める。
• 4.2 コストの見積り→ 必要な費用を算出する。
• 4.3 予算の設定→ プロジェクト予算を確定する。
• 5.1 品質マネジメントの計画→ 品質基準・品質活動を決める。
• 6.1 資源マネジメントの計画→ 人員・設備の管理方法を決める。
• 6.2 アクティビティ資源の見積り→ 各作業に必要な資源を見積もる。
• 7.1 コミュニケーション・マネジメントの計画→ 報告・会議・連絡方法を決める。
• 8.1 リスク・マネジメントの計画→ リスク管理方法を決める。
• 8.2 リスクの特定→ 想定されるリスクを洗い出す。
• 8.3 定性的リスク分析→ 発生確率・影響度で評価する。
• 8.4 定量的リスク分析→ 数値でリスク影響を分析する。
• 8.5 リスク対応の計画→ リスク対策を決める。
• 9.1 調達マネジメントの計画→ 外部調達の方法を決める。
• 9.2 ステークホルダー・エンゲージメントの計画→ 関係者との関わり方を決める。

---

③ 実行（Executing）

ここで各成果物を作成します。

システム開発では、

• 要件定義
• 基本設計
• 詳細設計
• コーディング
• テスト
• リリース準備

などが実施されます。

ただし、

PMBOKでいう「実行」は、

「プログラムを書くこと」ではありません。

計画に基づき、人員・品質・コミュニケーション・調達などをマネジメントしながら成果物を作り上げる活動全体を指します。

☆PMBOK該当（プロセス）内容

• 1.3 プロジェクト作業の指揮・マネジメント→ 計画どおりにプロジェクトを実行する。
• 1.4 プロジェクト知識のマネジメント→ 経験・ノウハウを共有・活用する。
• 5.2 品質マネジメント→ 品質を作り込む活動を実施する。
• 6.3 資源の獲得→ 必要な人員・設備を確保する。
• 6.4 チームの育成→ スキル向上・チーム力向上を図る。
• 6.5 チームのマネジメント→ チームを運営・支援する。
• 7.2 コミュニケーションのマネジメント→ 情報共有・報告を実施する。
• 8.6 リスク対応の実行→ 計画したリスク対策を実施する。
• 9.2 調達の実行→ ベンダー契約・発注を行う。
• 10.3 ステークホルダー・エンゲージメントのマネジメント→ 関係者との合意形成・期待値を管理する。

---

④ 監視・コントロール（Monitoring & Controlling）

PMBOKで最も重要であり、最も誤解されやすいプロセス群です。

監視・コントロールは最後に行うものではなく、

プロジェクト開始から終了まで継続して実施します。

例えば、

• スケジュール差異分析
• コスト管理（EVMなど）
• 品質レビュー
• テスト結果分析
• リスク監視
• 課題管理
• 変更管理
• ステークホルダーへの報告

などが該当します。

監視・コントロールは、実行フェーズだけの活動ではありません。立上げ・計画・実行・終結を通じて、プロジェクト全体を継続的に確認し、計画との差異を把握して必要な是正措置や変更管理を行う、PMBOKの横断的なマネジメント活動です。

つまり、

プロジェクトを計画どおりに進めるための管理活動です。

☆PMBOK該当（プロセス）内容

• 1.5 プロジェクト作業の監視・コントロール→ プロジェクト全体の状況を把握する。
• 1.6 統合変更管理の実施→ 変更要求を評価・承認する。
• 3.7 スケジュール・コントロール→ スケジュール差異を管理する。
• 4.4 コスト・コントロール→ 予算超過を防ぐ。
• 5.3 品質コントロール→ 成果物の品質を確認する。
• 6.6 資源のコントロール→ 人員・設備を適切に調整する。
• 7.3 コミュニケーションの監視→ 情報共有が適切か確認する。
• 8.7 リスクの監視→ リスク状況を継続的に確認する。
• 9.3 調達のコントロール→ 契約履行状況を確認する。
• 10.4 ステークホルダー・エンゲージメントの監視→ 関係者との関係性を確認・改善する。

---

⑤ 終結（Closing）

成果物を完成させるだけではプロジェクトは終わりません。

終結では、

• 成果物の正式引渡し
• 契約完了
• Lessons Learned（教訓）
• プロジェクト完了報告
• 組織プロセス資産への反映
• 保守運用への引継ぎ

を行います。

ここまで実施して、初めてプロジェクトは正式に終了します。

☆PMBOK該当（プロセス）内容

• 3.7 プロジェクトまたはフェーズの終結→ プロジェクトを正式に終了する。

---

PMBOKとシステム開発工程の関係

PMBOKはプロジェクト全体を管理する考え方であり、システム開発工程はその中で実施される開発作業です。

PMBOK（プロジェクト管理）

立上げ
　│
計画
　│
──────────────────────────
　　　システム開発工程

　要件定義
　　　↓
　基本設計
　　　↓
　詳細設計
　　　↓
　コーディング
　　　↓
　単体テスト
　　　↓
　結合テスト
　　　↓
　総合テスト
　　　↓
　受入テスト
　　　↓
　リリース
──────────────────────────

↑ PMBOKの全工程を通して
監視・コントロール

終結
　↓
保守・運用

さらに重要なのは、

各システム開発工程においても、

工程ごとに計画・実施・レビュー・承認などのマネジメント活動が行われます。

例えば基本設計では、

設計計画
　↓

設計実施
　↓

設計レビュー
　↓

指摘事項対応
　↓

設計完了承認

という流れで進めることが一般的です。

これは、

PMBOK第6版が示す

計画・実行・監視・コントロール

の考え方を、

各開発工程へ適用した実務上の運営例と言えます。

各システム開発工程においても、工程ごとの計画・実施・レビュー・承認などのマネジメント活動を行います。

ただし、

PMBOK第6版の49プロセスを各工程ですべて繰り返すわけではありません。

例えば、

要件定義ではスコープ定義や要求事項収集などの計画系プロセスが中心となります。

一方、テスト工程では品質・進捗・リスク・変更管理など、監視・コントロール系プロセスの比重が高くなります。

つまり、

プロジェクトフェーズに応じて適用するプロセスは異なりますが、PMBOKのマネジメントの考え方はプロジェクト全体を通して一貫して適用されます。

---

例えば、

開発工程	主に適用されるPMBOKプロセス
要件定義	要求事項収集、スコープ定義、WBS作成、見積り、リスク特定
基本設計	品質マネジメント、資源マネジメント、コミュニケーション、レビュー
開発	チームマネジメント、品質マネジメント、進捗管理、変更管理
テスト	品質コントロール、リスク監視、スケジュールコントロール、ステークホルダー対応
リリース	プロジェクト終結、成果物引渡し、契約完了

---

PMが本当に管理しているもの

PMは開発工程そのものを管理しているのではありません。

PMBOK第6版では、10の知識エリアを横断的に管理します。

これらをバランス良くマネジメントすることが、PMの重要な役割です。

---

まとめ

PMBOK第6版は「システムをどう作るか」を定義したものではありません。

「プロジェクトをどう管理するか」を体系化したガイドです。

システム開発工程は、その管理対象となる開発プロセスです。

実務では、

PMBOKのプロジェクトマネジメントとウォーターフォールやアジャイルなどの開発手法を組み合わせることで、品質・コスト・納期・スコープ・リスクをバランス良く管理し、プロジェクトを成功へ導いています。

PMBOKを理解すると、「開発を管理する」のではなく、「プロジェクト全体をマネジメントする」というPMの本質が見えてきます。