最新のPMBOK第8版学習シリーズ。今回は「Section 4.1 プロジェクト・フェーズ（Project Phases）」について掘り下げていきます。
前バージョンの第7版では、マインドセットなどの抽象的な概念が中心でしたが、第8版では「実際にどう区切って進めるか」という実務的な枠組みが再び整理されています。
プロジェクトという大きな塊をどう管理し、工程のつなぎ目で何をすべきなのか。現場視点での解説をお届けします。
山脇 弘成（SSAITS代表）
PMP®有資格者・Webプロジェクトマネージャー。
大手メディアや官公庁のWebプロジェクト実績多数。
「技術」だけでなく「対話」を重視し、御社の「ほんとは、こうしたかった」を形にします。
プロジェクト・フェーズとは何か？
プロジェクト・フェーズとは、1つ以上の成果物を完成させるために、論理的に関連する活動をまとめた「段階」のことです。
この概念を理解するには、ウォーターフォール型のプロジェクトを想像するのが一番分かりやすいでしょう。例えば、業務アプリを開発する場合、以下のようなステップを踏んでいきます。
- 要件定義： 何を作るか決める
- 設計： 図面を引く
- 開発： 実際に作る
- テスト： 正しく動くか確かめる
これら一つひとつが「フェーズ」です。各フェーズが終わるごとに、目に見える「成果物」が出来上がることで、プロジェクトは着実に前進していきます。
「関節」としてのフェーズ・ゲート（関所）
フェーズとフェーズの間には、「フェーズ・ゲート（Phase Gate）」と呼ばれるチェックポイントを設けます。「ゲート（関所）」という名前の通り、次の工程に進む前に「本当に準備は整っているか？」を判断する場所です。
このフェーズ・ゲートは、プロジェクトにおける「関節」のような役割を果たします。
例えば「設計」から「開発」へ移る際、設計図をプログラマーに渡して「はい、よろしく」で終わることは稀です。
往々にして、「この図面の意図はどういうこと？」「この機能は今の技術では実装できない」といった調整が必要になります。こうしたフェーズ間の認識合わせや調整こそが、フェーズ・ゲートの実務的な正体です。
ここを「ただの書類承認」として素通りさせてしまうと、後になって致命的な手戻りが発生する原因となります。
時間とともに変化する「3つの特性」
プロジェクトが進行し、フェーズが変わっていくにつれて、プロジェクトを取り巻く状況も変化します。PMBOK第8版では、特に以下の3つの変数の変化に注目しています。
1. コストと要員（Cost and staffing）
最初は少人数でスタートし、実行フェーズ（開発など）でピークを迎え、終わる頃には急速に減っていく「山なり」の形を描きます。
2. リスクと不確実性（Risk and uncertainty）
開始時が最も高く、フェーズが進んで不明点が解消される（決まったことが増える）につれて、右肩下がりに減少していきます。
3. 変更の影響力（Stakeholder influence on change）
「やっぱりここを変えたい」という要望を通せる力は、初期が最も高いです。後半になるほど、すでに出来上がっているものが多いため、変更のためのコストや時間が膨大になり、影響力は低下していきます。
まとめ：早期の調整が成功の鍵
今回の学習ポイントをまとめると以下の通りです。
- フェーズ： 仕事を論理的に区切った単位。
- フェーズ・ゲート： 次に進むための「関所」であり、工程間の「関節（調整）」の場。
- 特性の変化： 後半になるほどリスクは下がるが、変更のためのコストは跳ね上がる。
「設計フェーズの終わりに、開発チームとしっかりゲートでの調整を行っておく」。
この当たり前だけれど忘れがちな「関節のメンテナンス」が、プロジェクト全体をスムーズに動かすための極意です。
次は、プロジェクトの性格を決める「開発アプローチ」について学んでいきましょう！