フェーズ。
あえて和訳するなら、「工程」でしょうか。
プロジェクトに従事する人にとっては、すっかり定着している用語です。

PMBOKの捉え方とズレていないか確認しておきましょう。

フェーズはプロジェクト・ライフサイクルを時間軸で分割したものです。
これはトップダウン的な言い回し。

ボトムアップ的に言い直せば、フェーズの集合がプロジェクト・ライフサイクルに成る、となります。

いずれにしても、フェーズは開始日と終了日を持ちます。（その時点で決まっているか決まっていないかは別です）

そして、たいていは頭に何某かの枕詞がつけられます。
第一フェーズ、第二フェーズとか。
あるいは、設計フェーズ、テストフェーズとか。

ここまでは問題ないですね。

では、素朴な質問。
どうしてフェーズに分割するんでしょうか？

こういう日頃考えもしないが故に答え方に詰まる素朴な質問が大好きなPMP試験。

フェーズの機能

一言で言うと、分割することで管理（コントロール）レベルを上げることができるから。

コストや所要期間、資源の見積もりの精度が上がるのもその一つです。
大きなものを見積もるよりも小さなものを見積もる方が実績との差は小さくて済みます。

他には、たとえば進捗管理において、今日１日で終わらせないといけない仕事があるとして、１日で管理するよりも、午前と午後とで２つのフェーズに分ければ、午前が終わった段階で仕事の進み具合を確認し、午後のフェーズに反映させることができます。

それによって、一日の目標を達成する可能性が高くなるわけです。

つまり、チェックポイントとしての機能です。

もっとも、フェーズに分割するとき、このような時間軸だけを観点に分けることはありません。

３ヶ月のプロジェクトを、一月づつ３つに分けて第一、第二、第三フェーズなどとはしないわけです。

時間軸の単位なのに、時間を観点に分けないとはこれ如何に？

フェーズが期間を表わすのはあくまで結果に過ぎません。

では何を観点にフェーズに分割するかというと、それは成果物です。

フェーズの要件

PMBOK®ガイドにはフェーズの要件としてこうあります。

成果物を受持ち、移管によってフェーズが終結する。
＜PMBOK®ガイド＞

フェーズは、例外なく（ココ重要）、受け持つアウトプットを持っています。
このアウトプットのことを、成果物（deliverables）と言います。

形あるモノとは限りません。
作業の結果であって、なんらかの状態を指す場合もあるでしょう。

フェーズを時間軸の区分と言いましたが、成果物で区切った区分とも言えるわけです。

その成果物についてもPMBOK®ガイドで再定義されています。

成果物の定義

成果物は、測定可能かつ、検証可能なプロダクト、またはサービスの実行能力
＜PMBOK®ガイド＞

フェーズは予定された期日が来たから終わるわけではありません。
フェーズの終結は、あくまで受け持った成果物の出来・不出来で判断されます。

「測定可能かつ検証可能」というのは、フェーズが終わった・終わっていないということが明確に判定できるということです。
そうでなければ、チェックポイントの機能を果たせません。

・なめらかに研磨された部材、
・詳細な取扱い説明書、
：

こういう形容詞的な言い回しだけではフェーズの成果物として機能しないということを試験向けに押さえておいてください。

理由は測定ができない、あるいは判断が人によってブレることになるからです。

実際のプロジェクトでは「なめらか」や「詳細」の数値化を図ります。

では、成果物が完成したらフェーズが終わるのかというと、そこもまた微妙に違うのです。

フェーズ終結の要件

移管によってフェーズが終結する。
＜PMBOK®ガイド＞

フェーズのアウトプットは後続フェーズのインプットになります。

後続フェーズとしては不確かなものを受け取るわけにはいきません。
そのためにフェーズの終結において行われる手続きが、「レビューと承認」です。

そして、レビューと承認を経て後続フェーズが成果物を受け取ることをtransferred、移管（管理が移る）と言うわけです。
フェーズの終結のあるべき姿として押さえておいてください。

フェーズ終結の別称とその意図

こうした手続きの意味をこめて、フェーズの終結は、いくつか別の言い方がされます。

• フェーズの関門
• フェーズの出口
• フェーズ・ゲート
• ステージ・ゲート
• マイルストーン
• 意思決定ゲート
• 中止点

上３つは単に表現の違い。

その下の4つはフェーズの役割としてのメッセージが込められています。

マイルストーンとは道に埋め込まれている標石、日程上の目印です。
フェーズの区切れは進捗管理の最たる局面だということです。

フェーズ内のスケジュールは担当者内でどうにでもなりますが、フェーズの開始日、終了日は、チーム間、部署間、企業間など、影響範囲に程度の差こそあれステークホルダーとの合意なわけです。

意思決定ゲートとは、次のフェーズに進むのは意思決定に他ならないということです。

さっきは、レビューと承認が欠かせないと言いましたが、本来ここに意思決定は必要ありません。

そもそも、成果物の特性に「測定可能かつ検証可能」を求めるのは、人の判断に依らないようにするというPMBOKのメッセージです。

フェーズ終結における意思決定とは？

では、この意思決定というのは何を意味するのかというと、プロジェクトの現場レベルではなく、大所高所からの投資続行の判断を意味しています。

母体組織にとってプロジェクトは投資です。(*1)

一旦決めた投資判断はまだ正しいのか？
プロジェクトに投資し続けることがポートフォリオにとって最適か？

組織、あるいはポートフォリオ・マネジャーは、これを絶えず問うていかなければならないわけですが、新たなフェーズに進むときこそ、そのタイミングだということです。(*2)

(*1)ポートフォリオ。プロジェクトの源流
(*2)立上げプロセス群。役割はプロジェクトの最初だけではない。

そういう意味では、これを論じるときのフェーズとは、現場レベルの作業フェーズではなく、上級マネジメントや、顧客と共有するハイレベルのフェーズと捉えると理解し易いかと思います。

意思決定の結果、もしかしたらプロジェクトへの投資は止められるかもしれません。

これが、上で列挙した別称のうちの最後、”kill point”「中止点」につながるわけです

その判断は外部環境も当然に考慮します。

フェーズの成果物に何の問題がなくても、
レビューと承認が得られても、
プロジェクトは中止されてしまうということです。

PMBOK®ガイドにこうあります。

フェーズの終局は、中止するのに適した局面である。
＜PMBOK®ガイド＞

プロジェクトは最後までやり遂げなければならない。
こう捉えていた人にとってはスンナリと受け入れられないかもしれませんし、プロジェクト・マネジャーはそれでいいかもしれません。

でもオーナーは、プロジェクトの続行の可否を絶えず天秤に掛けています。

「プロジェクトを中止するのに適している」
PMBOKらしさが実に良く出ている表現だと思います。