5つのプロセスはプロジェクトの開始から終結までの流れ（立上げ、計画、実行、監視・コントロール、終結）、

10個の知識エリアは統合、スコープ、スケジュール、コスト、品質、資源、コミュニケーション、リスク、調達、ステークホルダーとなっており、計49のプロセス（手順／処理）があります。

PMBOKでは、プロジェクトの状況により実施するプロセスを選択することを推奨しています。小規模プロジェクトなどでは必要なプロセスを選択すればよいということです。これは該当プロジェクト用に仕立て直すという意味合いでテーラーリングとも言われています。

また、マネジメントとして何をやるべきか、何をやらないのか、漏れは無いかという観点でのチェックリストとして活用できます。

PMBOK活用の注意点

プロジェクトマネジメント技法として優れたPMBOKですが、プロジェクトを推進する「人」に関しては、あまり触れられていません。

プロジェクトを推進するのはPM（プロジェクトマネージャー）やPL（プロジェクトリーダー）です。推進する人にどのような能力（スキル）が必要なのかは触れられていないのです。

さらにプロジェクトメンバも人です。プロジェクトは人の集まりです。いかに思い通りに動かない人を思い通り動いてもらうか、これがプロジェクト推進の神髄と言っても過言ではありません。

経験豊富なPM/PLであれば、これまでの経験や人との関係でうまく推進できるでしょう。しかし経験の浅いPLはどうでしょう。

プロジェクトの中には様々な人がいます。年長者、声の大きい人、無口で何を考えているか分からない人、技術力が高い人などです。さらに視野を広げると利用部門や発注者など多くの人が関わります。

プロジェクトを成功させるためには、プロジェクトマネジメント技法の習得だけではなく、ヒューマンスキル（対人能力）も重要だということです。

PMBOKの計画プロセス

計画プロセスとは、その名の通りプロジェクトの計画を立てることです。
つまり、システム構築プロジェクトであれば、システム構築の実作業を行う前に実施しておくべきことです。

計画プロセスは全ての知識エリアにおいて計画を実施する必要があります。では、計画を行うとはどういうことでしょうか。

私たちは、限られた資源を最大限に活用し、利用者（ユーザー）が求めるシステムを、高い品質で、決められた期限までに作り上げることが求められています。無計画にプロジェクトを進めるのではなく、成功させるための計画を立ててプロジェクトを進めることが大切です。

スコープ・マネジメント

計画プロセスでの「スコープ」知識エリアでは、4つのプロセスが定義されています。

スコープ・マネジメントの計画
要求事項の収集
スコープの定義
WBSの作成

スコープとは、要求事項の範囲と、成果物や作業の範囲のことです。
つまり、要求者（ユーザーや利用者、発注者）の要求事項をどの範囲まで対象とするのか。その要求事項をシステム化するために、どういう成果物が必要で、そのためにどういう作業が必要なのか、を明確にするということです。

不十分なスコープ・マネジメント

スコープが不明確・合意できていない状況では、多くの場合がトラブルもしくはそれに近い状況になっています。

例えば要求事項のスコープが合意されない状態でプロジェクトが進み、設計や製造のフェーズになって「この機能が足りない」、「この画面が無いと業務が回らない」といった追加要求が発生した場合、トラブルの元となります。

また、作成する成果物が不明確だった場合は、「この設計書が無いと製造ができない」ということで、新たな成果物を作成することになります。
計画していない要求事項や成果物を対象にするということは、計画したリソースでは対処できないということです。このような事象は私自身も経験がありますし、周りのプロジェクトでもよく見られる事象です。

スコープとは、プロジェクト活動の範囲です。この範囲が変動するということは、コストや納期を守れないことを意味します。

逆にコストと納期を守ろうとすれば品質を犠牲にすることになります。

つまり「QCD（品質、コスト、納期）を守れない＝トラブルになる」とも言えるでしょう。
プロジェクト活動においてスコープとは、それほど重要なものだということをご理解下さい。

スコープ・マネジメントの計画

プロジェクト活動の範囲を定めるものであり、プロジェクト活動中に計画範囲を維持しているかどうかを判断する拠り所となります。

また、プロジェクト企画書やRFPに記述されたプロジェクトの範囲をより詳細化することを目的としています。

プロジェクト・スコープとして、システム開発のみか、それとも導入やシステム利用教育、データ移行も対象とするのか。

ここで大切なことは、「実施しないことは何か」を明確にするということです。要求者は「やってくれると思ってた」、受託者は「対象外のつもりだった」ということがあってはスコープが合意できたと言えません。そして、要求事項のスコープ（範囲）が変わったときにはどのような対応を行うのか、なども明確にします。

要求事項の収集

要求事項の収集は各社様々な方法を活用されていますが、代表的なものは要求者からのインタビュー（打合せ等）になるでしょう。その際に業務フローを活用したり、ユースケースを活用したりして、スコープの認識を合わせることが大切です。

スコープの定義

プロジェクト計画の中核業務であるスケジュール計画、資源計画、費用計画を設定するための基本情報となるものです。

プロジェクトのアウトプットとなる全ての成果物を明確にする
成果物を作成するために必要な作業構造を概要レベルで構造的に把握する
概要レベルの作業要素ごとに役割を決定する

WBSの作成

WBS（Work Breakdown Structure）はその名の通り、必要となる作業（Work）をトップダウン的に分析（Breakdown）し、階層構造（Structure）で表したものです。

プロジェクトに必要な全ての作業を洗い出し、抜け漏れが無いようにしなければなりません。「必要な全ての作業」ですから要求者の作業、受託者の作業の全てを洗い出すことが望ましいです。導入作業やデータ移行、システム利用教育などは忘れがちなので注意が必要です。

また、プロジェクトリーダーが実施するマネジメントに関する作業も洗い出すようにしましょう。このあとWBSをもとにスケジュールを計画します。マネジメント作業もWBSで明確にしておかないと、スケジュール化されなくなり、想定外の時間を費やすことになってしまいます。

スケジュール・マネジメント

計画プロセスでの「スケジュール」知識エリアは、５つのプロセスが定義されています。

スケジュール・マネジメントの計画
アクティビティの定義
アクティビティの順序設定
アクティビティの所要期間見積もり
スケジュールの作成

スケジュール・マネジメントは、スコープ・マネジメントで定めた要求事項範囲の成果物作成や作業をいつ・誰が、どれだけの時間を掛けて行うのかを具体的にします。

無理なスケジュールは立てない

担当者に作業を割り当てる際には、担当者の能力や生産性なども考慮する必要があります。経験の浅いメンバや能力が十分でないメンバに難しい作業を割り当てると見積もった工数・期間では完了できない場合が多いので以下の点に考慮が必要です。

- 経験の浅いメンバには所要時間を1.5～2倍にする

- サポートメンバを付ける

- 難易度の高い機能要件や作業の場合は所要時間や期間の余裕を十分に持たせる

- 利用するDBや開発言語がメンバにとって未経験のものであれば、教育や学習時間の考慮をする

仮にメンバの1人が計画した期日通り完成できなかった場合、それは遅延となりそのメンバの後続作業も遅れます。他メンバの作業にも影響する可能性があります。当然のことながら後工程にも大きく影響する可能性が高くなります。

大切なことは、無理なスケジュールは立てない、出来るスケジュールを計画するということです。

スケジュール・マネジメントの計画

スケジュール・マネジメント計画書を作成します。計画書では以下の内容を明確にする必要があります。

スケジュールの計画・策定基準

以下の内容を参考に設定します。

生産性基準

　精度の高い生産性基準を適用

全体スケジュールの単位分画と単位ごとの計画・評価

　長期プロジェクトでは全行程の詳細スケジュールを計画するのは困難です。フェーズごとに詳細計画をたてる手法も有効（PPP：Phased Project Planning（段階的プロジェクト計画法）

作業割り当てと責任の明確化

　工程や成果物に対して、承認者や実施者を明確にする(TRM：Task Responsibility Matrix)

日程計画の多段化

　大日程（月レベル）、中日程（週レベル）、小日程（日レベル）など粒度を分ける。これにより全体進捗を見るときは大日程で、詳細進捗は小日程で、という使い分けが可能

マイルストーンの明確化

　工程別の成果物完成時期やイベントなどを明確化

進捗管理の方法

管理指標の明確化

　各工程の進捗状況を計る指標を明確にします（設計書完了数、プログラム完成数、テスト消化率、バグ発生数と解決数、など）

期限管理と消化率管理

　予定・実績の定量的把握を行うための管理方法を取り決めます（50/50法や各社独自の進捗率定義など）

監視・コントロールプロセス実施の方針および手順

進捗管理の徹底

　日々の進捗実績登録、短期サイクル（週単位など）での進捗ミーティング、進捗状況報告書作成（定量的・具体的な現状把握、遅延状況、問題発生状況など）を定めます

遅延・問題発生時の迅速な対策・対応

　遅延や問題が顕在化したとき報告ルートや報告資料等を明確にするとともに、問題種類ごとの対応策方針を明確にします

アクティビティの定義

アクティビティの順序設定

アクティビティの所要期間見積もり

WBSをブレークダウンした最下位レベルの成果物を生み出す作業項目をワークパッケージと呼び、ワークパッケージを完了するために必要な作業のことをアクティビティと呼ぶ。

ワークパッケージ毎に必要となるアクティビティの洗い出しを行い、アクティビティの実施順序を明確にするとともに、各アクティビティの所要時間の見積りを行う

スケジュールの作成

スコープ・マネジメントで作成したWBSと定義したアクティビティ（順序設定、所要期間見積り済み）により、プロジェクトとしてやる事が明確になりました。
これをスケジュール管理ツール（Excelやタスク管理製品など）で明文化します。アクティビティ毎に担当者の割り当てを行い、開始日・終了日も明確にする必要があります。

コスト・マネジメント

計画プロセスでの「コスト」知識エリアは、３つのプロセスが定義されています。

コスト・マネジメントの計画
コストの見積り
予算の設定

コスト・マネジメントは、スコープ・マネジメントで定めたWBSおよびスケジュール・マネジメントで定めたアクティビティを実行するための費用を算出します。

コスト見積りは難しい

見積りを正確に行うことは困難です。例えばこれから要件定義を始めようとするタイミングで見積りを行った場合、プロジェクトが終了した時点での実績値と比較すると大きな乖離がでることが多くあります。

要件定義はシステムとしてどのようなシステム機能が必要となるのかを具現化する工程です。要件定義を行う中で「この機能が必要、こんな画面があれば業務効率が上がる」などの理由でシステム機能数は増減します。すなわち不確実な状態を見積もっているということです。

特に見積りを一人で行った場合、私の周辺ではこの傾向が多いように感じます。人によって感じ方受け止め方は様々です。一人の目線で見積りをすると見逃しや認識違いが発生するためだと思っています。
しかしながら、予算確保のためには見積りは必要不可欠です。出来る限り正確な見積りを行うためには以下に留意することをお勧めします。

複数名が各々見積りを行い、全員で精査する
過去の類似プロジェクトでの生産性などを活用する

コスト見積りは上流工程になればなるほど実態との乖離幅が広がる可能性があると言われています。この特性を表すのが「不確実性コーン」 です。

中央の実線が実際に掛かるコストとしたとき、要定義完了時点でコスト見積りを行うと0.67～1.5倍の範囲で誤差が発生する可能性があるというものです。詳細設計が完了した時点で0.9～1.1倍まで誤差は狭くなります。
つまり要件定義でシステムとして必要なシステム機能を洗い出せたとしても、基本設計や詳細設計でシステム機能を設計していく中でコスト見積りが変動する場合があるということです。

見積りを行うタイミングで見積りの正確性が変動することを認識しておいてください。

コスト・マネジメントの計画

コスト・マネジメントの計画書を作成します。
計画書には測定単位（人時、人日など）と監視のための閾値を定めます。
必要に応じて費用の追加・変動時の資金調達方法なども取り決めておきます。
また、為替変動への対応が必要であれば、変動時の対処なども定めておきます。

コストの見積り

アクティビティに必要な資源（人的資源、物的資源）のコストを算出します。
システム開発プロジェクトにおいては、多くの場合「工数」として人時、人日、人月などで算出します。
コストの算出には様々な見積り技法が存在しますが、各社各様で独自の技法を使用しています。
以下は代表的な見積り技法です。コスト見積りの際には見積りの根拠となる情報も残しておきます。

予算の設定

コスト見積りの結果をスケジュールに合わせて時系列に予算配分し、ステークホルダーの承認を得ます。

品質マネジメント

計画プロセスでの「品質」知識エリアは、１つのプロセスが定義されています。

品質マネジメントの計画

品質目標を達成するための方針や手順、実施方法や資源などを計画書に記述します。

品質のポイントは「上流工程で予防」する

品質を向上させる手段として「レビュー」と「テスト」があります。
- レビュー・・・不具合の混入を予防する目的で実施する
- テスト　・・・不具合を検出する目的で実施する

テストをしっかり実施すれば品質が良くなるからテストに注力しよう。という考え方もありますが、私はレビューをしっかり実施して不具合の混入を防ぐ手段にも注力することをお勧めします。

下の図はテスト工程で発見した不具合が、設計工程で混入した「設計不良」だった場合の例です。
発見はテスト工程ですが、混入は設計工程です。この例では設計工程まで戻ってシステム設計を変更し、関連するプログラムを変更して、改めてテストを実施し直しています。

設計・製造・テストをやり直すということは、想定外のコストと時間を掛けることになります。下流工程で不具合を発見するということは、上流工程まで手戻りする可能性があるということです。

この「設計不良」を設計工程で発見できていればどうでしょう。

設計工程で発見できれば、工程を跨いだ手戻りはありません。不具合への対応は最低限のコストと時間で済みます。

下流工程で発見する不具合は手戻りによるロス（コストと時間）が大きくなります。いかに上流工程で不具合を発見するかが大切ということです。
つまり、要件定義や設計工程でしっかりとレビューを実施し、不具合を予防することで、プロジェクト資産であるコストと時間のロスを減らすことができると言えるでしょう。

テストも重要な品質向上の手段ですが、レビューとの組み合わせで更なる品質向上が見込めます。品質マネジメントの計画では、プロジェクトに応じて適切な予防（レビュー）と検出（テスト）の計画を立てる必要があります。

品質マネジメントの計画

品質マネジメントの計画書を作成します。
計画書には品質目標、対象とする成果物と実施プロセス、使用するツールなどを記述します。
つまり、どの様に品質確保するのか、どれぐらいのコスト（工数）を掛けるのかを検討します。

記述内容は以下を参考にして下さい。

記述内容	説明
使用する品質基準	自社の品質基準やシステム/ソフトウェア製品品質（JIS X 25010:2013）など、どのような品質基準を適用するのか検討する
品質目標	対象成果物毎に定量的な指標を定義する。レビュー指摘密度、テスト密度、バグ密度などを設定する
品質に関する役割と責任	レビューやテストなど品質保証活動の実施責任者や品質保証責任者などを定義する
対象となる成果物とプロセス	工程ごとの成果物に対して、品質保証活動の対象要否とプロセス（レビュー手法やテスト技法など）を定める
品質マネジメントの活動	成果物毎の品質評価指標を設定し品質合否の閾値を定め、品質管理のプロセスを検討する
品質ツール	品質管理を行うためのツールを検討する
基準不適合や是正処置への対処手順	品質保証活動（レビューやテストなど）で「品質が悪い」と判断した場合の改善方針などを定める

資源マネジメント

計画プロセスでの「資源」知識エリアは、２つのプロセスが定義されています。
• 資源マネジメントの計画
• アクティビティの資源見積り

資源マネジメントはプロジェクト資源（人的資源、物的資源）に関する計画を行います。
-   人的資源　…　プロジェクトメンバ（ビジネスパートナーメンバも含む）
-   物的資源　…　開発マシン、サーバー（開発用、テスト用、本番用など）、
   ネットワークおよびネットワーク機材、ソフトウェア（開発ツール、運用ツールなど）、開発場所など

資源マネジメントの計画

資源マネジメント計画書、チーム憲章の作成およびプロジェクト文書の更新を行います。

＜資源マネジメント計画書＞
資源をマネジメントするための内容を文書化する。重要と思われるものを下記に列挙しました。

記述内容	説明
役割と権限	プロジェクト活動において個人が担う役割を具体化し、それぞれの権限も明確にする役割：設計者、製造者、レビュー担当、テスト担当など権限：プロジェクト資源の投入や意思決定、承認などの権限
プロジェクト体制図	メンバへの指揮命令およびメンバからの報告ルートが明確になるよう図示する
トレーニング	メンバへのトレーニングが必要な場合は方針や方法、時期などを明確にする（設計手法、開発言語、利用装置、業務理解など）

＜資源マネジメント計画書＞
資源をマネジメントするための内容を文書化する。重要と思われるものを下記に列挙しました。

記述内容

チームの価値観

コミュニケーションのガイドライン

意思決定の基準とプロセス

コンフリクト（意見の対立など）の解決プロセス

会議のガイドライン

チーム憲章は、チームメンバ全員が合意できるようにしましょう。
合意することによりプロジェクト初期段階で明示的な規範となり、誤解が減り生産性の向上が期待できます。リーダーが一方的に提示するのではなく、チームメンバと議論をして合意形成して下さい。

アクティビティの資源見積り

プロジェクト活動において必要な人的資源と物的資源を見積ります。
つまり、各工程においてのメンバ数（SE何名、PG何名など）や機材（開発PC、開発サーバー、ソフトウェアライセンス数など）を明確にし、コスト・マネジメントの「コストの見積り」プロセスとも密に連携します。

コミュニケーション・マネジメント

計画プロセスでの「コミュニケーション」知識エリアは、１つのプロセスが定義されています。
• コミュニケーション・マネジメントの計画

コミュニケーション不足が起因するミスやロスを低減するため、コミュニケーション・ルールを設定しましょう。

コミュニケーション・マネジメントの計画

プロジェクト活動における会議体や情報の伝達、収集、配布の方法などを計画します。

＜会議体の代表例＞

会議体
キックオフミーティング	内部進捗会議	各種テスト計画会議
要件確認会議	ユーザ進捗報告会議	本番稼働判定会議
仕様確認会議	ステアリングコミッティ	プロジェクト完了報告会議
各種レビュー会議	課題検討会議

リスク・マネジメント

計画プロセスでの「リスク」知識エリアは、５つのプロセスが定義されています。

リスク・マネジメントの計画
リスクの特定
リスクの定性的分析
リスクの定量的分析
リスク対応の計画

プロジェクトで発生しうるリスクをマネジメントするための計画を行います。

リスクとは「今後発生する可能性がある、プロジェクトの成功を阻害する、個人では解決できない事象・状況」です。
プロジェクト発足時から様々なリスクがプロジェクトには存在すると言われています。
早い段階で発生しうるリスクを特定し、リスク顕在化時に適切な対応を行えるようにしましょう。

リスク管理表テンプレート

リスク管理表テンプレート（Excel形式）をダウンロードする

リスクと課題の違い

リスクと課題を混同されているケースがありますが、明確な違いがあります。
- リスク　…　まだ発生していない事象・状況
- 課題　…　既に発生している事象・状況
リスクが顕在化したら、その事象・状況は「課題」となり、課題解決の取り組みを行う必要があります。

リスク・マネジメントの計画

リスク・マネジメントのための計画書を作成します。
計画書には、リスク・マネジメントの具体的手法、役割や責任、タイミングなどを明記します。

リスクの特定

計画段階で想定されるリスクを特定し、リスク登録簿に記載します。
リスクはプロジェクト活動中不定期に発生しうるので、随時再評価し、リスクの特定に注力しましょう。

関連資料：リスク管理表テンプレート（Excel形式）

リスクの定性的分析、リスクの定量的分析

特定したリスクが顕在化する確度（発生確率）とリスク顕在化の際の影響度をもとに、リスクの重要度（リスク・ポイント）を評価します。
確度、影響度、重要度は分析結果としてリスク登録簿に記載し、緊急度・優先度も記載します。

リスク対応の計画

リスク分析の結果による方針に従って、「予防策／軽減策／監視策（期限、担当者）」をリスク登録簿に記します。

調達マネジメント

計画プロセスでの「調達」知識エリアは、1つのプロセスが定義されています。
• 調達マネジメントの計画

プロジェクト活動に必要な人的資源（内製時の人材・外製時の委託）や物的資源（機材・ソフトウェアライセンス・サービス等）を外部から調達するための計画を行います。

スケジュール・マネジメントの「スケジュール作成」、資源マネジメントの「アクティビティ資源の見積り」とも密に連携します。

調達マネジメントの計画

プロジェクトにおいて、何が必要なのか、いつ調達するのか、どのように調達（契約形態など）するのか、を決定します。

＜物的資源で必要な物の例＞

※教育用、移行用、本番用も同様

＜人的資源で必要な物の例＞

※ビジネスパートナーとのコミュニケーションの取り決めも必要です。

ステークホルダー・マネジメント

計画プロセスでの「ステークホルダー」知識エリアは、1つのプロセスが定義されています。
• ステークホルダー・エンゲージメントの計画

ステークホルダーの協力度合い（興味や関与の度合い）によりプロジェクトの状況が変化する場合があります。ステークホルダーと関係性も意識しておきましょう。

ステークホルダー・マネジメントの計画

プロジェクトとステークホルダーが協力しあい、互いに貢献していくことが重要です。
そのために、プロジェクトに関わるステークホルダーを特定し、ステークホルダーの分析を行い、ステークホルダーとの効果的なコミュニケーションを行うための計画を行います。

※「ステークホルダーの特定」プロセスは立上げプロセス群で実施するものですが、合わせてここで説明しています。

ステークホルダーは「利害関係者」です。つまり利害が生じる全ての人がステークホルダーとなります。

エンゲージメントは「会社への愛着心」です。言い換えれば「プロジェクト活動への思い入れ」とも言えます。

＜ステークホルダーの例＞

＜ステークホルダーの分析＞

特定したステークホルダーの権力とプロジェクトへの関心度でマッピングし、コミュニケーションを効果的に行います。

結合マネジメント

計画プロセスでの「統合」知識エリアでは、1つのプロセスが定義されています。
• プロジェクトマネジメント計画書の作成

統合とは、これまでお伝えしてきた計画プロセスの各知識エリアで検討した内容をまとめることです。つまり、プロジェクトの全体計画を作成します。
言い換えれば、プロジェクト成功のためのシナリオを作成するということです。

プロジェクトマネジメント計画書は成功のためのシナリオ

プロジェクト計画書はプロジェクトで実施すべきプロセスが定義されており、プロジェクト成功のためのシナリオとも言えます。
また、プロジェクト計画書はプロジェクト開始時点でのベースラインとなり、プロジェクト活動中に計画範囲から逸脱していないかを判断する基準にもなります。

プロジェクトマネジメント計画書の作成

これまで検討してきた計画プロセス群の各知識エリアの計画内容を統合し、プロジェクト計画書を作成します。
プロジェクト計画書には、プロジェクトの背景や目的、制約事項、各知識エリアでの計画内容など、プロジェクト活動に必要な計画をすべて盛り込みます。

計画プロセス群のまとめ

何から始める

プロジェクトを計画する場合、最初に行うのが「スコープ・マネジメント」です。
スコープとは要求の範囲や作業の範囲、成果物の範囲です。スコープが決まってから「スケジュール」や「資源」、「費用」などを計画します。つまりスコープがその他主要計画のインプットになります。

スコープが曖昧

スコープが曖昧だったり、未確定の状態では計画自体が曖昧な状態となります。
活動中にあれが足りない、これを追加、となれば計画見直しが必要となり、本来不要な時間や労力が必要となります。
ステークホルダ（要求を提示する人）と合意を取っておくことが重要なポイントといえます。

1日でプロジェクトマネジメントの基礎が学べる！
プロジェクトリーダー研修入門編「PL教室」の詳細はこちら

PMBOKの実行プロセス

実行プロセスとは、プロジェクト活動の開始前および初期・活動中に実施するものです。主に計画プロセスで立てたことを実行します。
実行プロセスは8つの知識エリア（統合、品質、資源、コミュニケーション、リスク、調達。ステークホルダー）が定義されており、監視・コントロールプロセスと密に関係しています。

結合マネジメント

実行プロセスでの「統合」知識エリアでは、２つのプロセスが定義されています。
• プロジェクト作業の指揮・マネジメント
• 知識のマネジメント

プロジェクト活動が円滑に行われるように作業指示やマネジメントを行います。また、プロジェクト活動を通して必要な知識および知りえた知識をマネジメントします。

プロジェクト作業の指揮・マネジメント

プロジェクトマネジメント計画書に基づいてプロジェクトを推進します。
また、統合変更管理プロセスからの変更があればそれを実施します。

知識のマネジメント

プロジェクト目標の達成に向けて知識を活用します。

※知識には形式知と暗黙知があり、有用な暗黙知はドキュメント化するなど形式知にすることが望ましい。