反復型ライフサイクルのリアル・プロジェクトへの採用の条件


前の記事では反復型ライフサイクルの優位性(*)について解説しました。

(*)反復型ライフサクルのメリットがアダプティブ(適応型)。対立としてプレディクティブ(予測型)

ウォーターフォールや予測型(プレディクティブ)と呼ばれる従来型のライフサイクル・モデルに比べれば、リスクは早期に軽減できるわ、要求を叶えやすいわで、良いことづくめのようです。

しかし、反復型を採用するには超えなくてはいけない壁があります。

 

1. スポンサーからの承認が得られない

プロジェクトの最初に全てを計画しないということは、最終成果物の詳細なイメージがなく、最終的にコストがいくらかかるのかも分からないということです。

多くの場合、組織がお金を出すには予算化が必要で、予算化にはプロジェクトの効果を示さないといけません。

ここがあやふやだとすれば、現場がいくら反復型の有効性を解いても、上級マネジメントの承認を得ることはできません。

特に依頼側と開発側が別の組織である場合(PMBOKではこれを ”外部プロジェクト” と呼びます)は、契約をどうするかが問題になります。
反復型は、全体のスコープや終結の時期がはっきりしないからです。

少なくとも売り手である開発側から買い手である依頼側に反復型ライフサイクルを提案するのは難しいでしょう。

採用されるのはこんなプロジェクト

ということで、反復型が採用されるとすれば、社内プロジェクトということになります。

実装を外部委託することはあるでしょうが、あくまで依頼側が反復型を企画したということです。

外部に発注する場合でも定額契約ではなく実費償還契約T&M契約が相応しいといえます。

その社内プロジェクトも、マネジメント層が反復型のメリットを理解し易い、前例のない商品開発や、本格的な投資に先駆けてのパイロット的なプロジェクトということになるでしょう。

 

2. 求められる依頼側の強い関与

反復型のライフサイクルでは、プロジェクトの全期間を通じて、成果物を受け取る側、つまりプロジェクトへの依頼側、外部プロジェクトでは顧客の強い関与が求められます。

予測型やウォーターフォールでは、要求を計画に落とし込む初期と、成果物を受け入れる最終局面で依頼側の強い関与が求められる一方で、プロジェクト期間の大半を占める中盤は、プロジェクト・チームが主役となって、依頼側の関与度は下がります。

ところが反復型ライフサイクルでは、計画と受け入れが何度も訪れます。
依頼側はその都度、成果物の受け入れ、要求のフィードバックと計画への反映など、その役割を果たしていかないといけません。

採用されるのはこんなプロジェクト

反復型のライフサイクルが機能するにはプロジェクトの全期間を通じてプロジェクトに常駐できる依頼側の意思決定者が必要です。

 

3.  大規模チームに向いていない

規模が大きいプロジェクトでも反復型の採用は難しくなります。
携わるスタッフが多く、指示命令系統が階層化されているプロジェクトほど、成果物に対する要求を隅々まで浸透させるのは容易ではありません。

その頻度が多い反復型では、そのためのコストが嵩み、コミュニケーション・エラーのリスクが高まるからです。

採用されるのはこんなプロジェクト

密接なコミュニケーションが取れる小規模のチームで反復型のライフサイクルは機能します。

 

3. そもそもムリ

例えば、建築物は事前に完成イメージについて当局の承認を得なくてはなりません。
反復的に勝手に増築なんてしていたら事業免許取り消しです。

また、広くユーザーに配布する商品にも反復型ライフサイクルは適しません。
再配布に掛かるコストが見合わないからです。

機能やデザインの追加や改善は、プロモーションや販売までを含めた別プロジェクトとして再定義すべきです。

採用されるのはこんなプロジェクト

法規制の影響を受けないプライベートなプロダクト、
配布の必要ないプロダクト、
もしくはユーザーの範囲が非常に限定されたプロダクト。

反復型ライフサイクルを採用するには、こうしたプロダクトである必要があります。

 

PMP試験でも単純にライフサイクルどうしを比較して優劣を選ばせる設問はありません。
優劣はケース・バイ・ケースだからです。

言い換えると、なんらかのシナリオが示された上で優劣を訊かれるということです。




icon-exclamation-circle本気になったら、講座でお会いしましょう!
icon-arrow-down icon-arrow-down icon-arrow-down

スキマ時間でPMPを取るためのチューター付き通信講座



コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です