フェーズの集合がプロジェクト・ライフサイクル(*)だとして、具体的なフェーズの切り方、並べ方は当然ながらプロジェクトによって違うわけですが、あらゆるプロジェクトに当てはまる汎用的なレイヤをプロジェクト・ライフサイクル・モデルと呼んでいます。

^{(*)フェーズ。使い慣れた用語こそPMBOKの思想をしっかり押さえよう}

実はここは昨今、比較的動きが激しい領域でもあります。
新しいコンセプトが次々と出てきてPMBOK®ガイドも版を重ねるごとに積極的にそれを反映しています。

別の記事で順次紹介していきますが、その前にまずは昔っからあるスタンダードなものから押さえておきましょう。

直列型

最もスタンダードなプロジェクト・ライフサイクル・モデルです。

作業順序に従ってフェーズを一列に並べ、先行フェーズの完全なる終了をもって後続フェーズをスタートさせるやり方です。

読んでお分かりのとおり、改めてモデルと言うのも憚（はばか）れるくらい、無意識に使っています。

私たちはフェーズのインプットが先行フェーズのアウトプットであること、そして次のフェーズとの間には、成果物の受け渡しのための「レビューと承認」が必要であることを押さえたわけですが(*)、これにならってフェーズを並べれば、おのずとそれは直列型になります。

^{(*)フェーズ。使い慣れた用語こそPMBOKの思想をしっかり押さえよう}

直列型の特徴

無意識に使っている直列型ですが、あえてその特徴を言うなら、
「確実ではあるが、硬直的で効率性に欠ける」

確実というのは、上で言ったように成果物の出来についてしっかりレビューを挟みながら次フェーズに移っていくやり方を指します。

その後ろにはネガティブな言葉が続きますが、ここでの効率性とはスケジュールに対する特性で、つまり長めになるということです。
この後で紹介する重複型などとの相対的な評価です。

「柔軟性に欠け、非効率である」とも言い換えられますが、いずれにしても、欠点というよりは、確実性のために効率性を犠牲にするという押さえ方が適切です。

 直列型の比喩表現　ウォーターフォール

直列型では先行フェーズが終わらない限り、後続フェーズを開始しません。
同時に、後続フェーズから先行フェーズに後戻りすることはありません。

ちなみに、「ありません」というのは金輪際あり得ないという意味ではなく、色んな言い回しが考えられますのでPMP試験向けに注意しておいてください。

それこそコストとスケジュールに糸目はつけないということであれば、いくらでも先行フェーズのやり直しは利きますから。

つまり、多くのプロジェクトでは、”経済的に”、”コスト制約によって”　先行フェーズへの後戻りが許されないわけです。

ですから、
「後戻りには多大なコストを要する」
というマイルドな言い回しでもOKです。

いずれにしても、直列型の後戻りの困難さに着目した別称がウォーターフォール型です。

ウォーターフォールとは滝。

フォールは落ちる。
ただし２単語ではなく複合語による単語です。

ここで例えている滝は、決してナイアガラの滝ではなく、川の上流付近で見かける、小さな滝の連続を思い浮かべるといいでしょう。

流れが緩やかな平らに近い部分がフェーズで、段差がフェーズの区切れです。

プロジェクトの特性と相容れない直列関係

プロジェクトに限らずやり直しを歓迎する仕事はありません。

直列型が、フェーズの後戻りを許さないということをわざわざ言わないといけないのは、言い換えれば、プロジェクトにおける後戻りが特別なことではないということに他なりません。

ミスや、コミュニケーション上の食い違い、あるいは要求そのものの変化等。
後戻りの理由は色々ですが、こうしたことはどうしても起きてしまいます。

そうなると、そもそもプロジェクトを計画する際、後戻りを想定して計画することはありませんから、後戻りの要請はイレギュラーとなります。

ウォーターフォールなどの比喩表現まで使って特性を強調するのは、直列型はこうしたイレギュラーに対応しずらいから、くれぐれも注意せよというメッセージです。

そのためにも、フェーズ間のレビューをしっかりやるということです。
後戻りが頻発するプロジェクトはまずはここを見直す必要があるでしょう。

もっとも、このフェーズ間のレビューの厳格さには濃淡があっていいかもしれません。
実際、少しでも不備があれば先行フェーズに突き返す場合もあれば、先行フェーズの完了報告を鵜呑みにするだけの場合もあります。

同一プロジェクトにおいても、厳格さには濃淡があって、それは後戻りのし易さに関係しています。

例えば同じ実装段階における、しかも先行フェーズと後続フェーズとで携わるメンバーもほとんど変わらないようなフェーズ間では、それほど厳格なレビューは求めないかもしれません。

先行フェーズへの後戻りが生じたとしても、それほどのコストを要しないからです。

これに対して、メンバーがガラッと入れ替わるフェーズ間だとか、組織間の受け渡しとなるフェーズ間では厳しいレビューが必要になってきます。

その最たる局面が、プロジェクトの主体者が、依頼者からプロジェクト・チームに本格的に移るときです。

つまり、要求事項を確定させて、「これでよろしく」とプロジェクト・チームに渡す局面です。

プロジェクト・チームとしては要求事項に変更が生じると多大な影響が出るため、それを避けるために、あるいは後戻りする場合のコストを依頼者側に負担させるために、きっちりとした承認をとってから後続フェーズに移行するわけです。

まさに後戻りを許さないウォーターウォールの面目躍如です。

が、

PMBOKはプロジェクトが段階的詳細化の産物であると言っています。
プロジェクトの初期に要求を寸分たがわず顕在化させることができるなら、それはもはや独自性を持ったプロジェクトではありません。(*)

^{(*)プロジェクトの独自性。人や組織によって異なるものさし}

直列型のライフサイクル・モデルはここに大きな矛盾を抱えているわけです。

どんなに厳しいレビューを実施し、承認を得たとしても、それはあくまでその時点のことに過ぎません。

変更が起きるのがプロジェクトです。

後戻りが頻発する原因の一つとしてフェーズ間のおざなりのレビューを戒める一方で、段階的詳細化と直列型モデルとの間に存在する矛盾は、昔から現在に至るまでプロジェクトを苦しめてきました。