前回は，計画プロセス群の概要を説明しました。今回は，計画プロセス群の主なプロセスについて，細かく説明していきましょう。

　計画プロセス群のプロセスは，PMBOKのすべての「知識エリア」に含まれています（図1）。当然ですね。すべての知識エリアのプロジェクト活動で計画は必要になりますから。

図1●PMBOKで定義された44個のプロセス
図1●PMBOKで定義された44個のプロセス
[画像のクリックで拡大表示]

　以下では，分かりやすい順番で説明しますが，実際のプロセスは並列に実施されることもありますので，誤解のないようにお願いします。

■スコープ計画プロセス

　「スコープ計画」プロセスでは，「プロジェクト・スコープ・マネジメント計画書」を作成します。この文書には

　　・「プロジェクト・スコープ記述書」の正式版を作成するルール
　　・WBSを作成し，メンテナンスし，承認するルール
　　・プロジェクトで生み出す成果物の検証と受け入れ方法のルール
　　・プロジェクト・スコープ記述書の変更管理のルール

を記述します（PMBOKには「ルール」ではなく「プロセス」と書いていますが同じ意味です）。ここで「プロジェクト・スコープ記述書」とは，プロジェクト・スコープ（プロジェクトの作業）を定義した文書のことです（第3回参照）。また，WBSとはプロジェクト・スコープ記述書に定義されたプロジェクトの作業を階層的に詳細化したものです（詳細は後述）。

　これらのルールがなかったり周知されていなかったら，プロジェクト・メンバーが勝手に成果物を変更してしまったり，勝手にプロジェクト・スコープ（プロジェクトの作業）を変更してしまったりすることは目に見えています。

　プロジェクトが所属する組織や企業に，これらのルールが標準として存在するのであれば，そのルールに従えばOKです。開発標準にこれらのルールが書かれていれば，それに従えばいいと言うことです。しかし，“見ず知らず”の人同士がプロジェクト・チームを結成して仕事をするような場合は，ルールとして文書化して，プロジェクト・メンバーに周知しておく必要があります。

　ただ，ルールがあることと，それが守られているかどうかは別の話です。私の経験でも，ソフトウエアの新バージョンのリリース時に，担当者が自分だけが知っている“隠れバグ”を密かに修正し，それが原因で二次障害を起こしたことがありました。これは，「プロジェクトで生み出す成果物の検証と受け入れ方法のルール」をその担当者が守っていなかったことが原因です。やはりどんな小さな変更でも，変更するかしないかを正式な会議で決めて，しっかりとした検証を行う必要があることは異論のないところでしょう。

　なお，この記事の最後に，プロジェクト・スコープ・マネジメント計画書のサンプルを掲載しましたので，ぜひ参考にしてください。