【PMstyle Kit No.3】プロジェクトをライフサイクルで管理する《一般》
【目的】プロジェクトを支配する構造を作り、活用する
【用途】マネジメントと組織のサポートを確立する
【効用】プロジェクトコントロールの強化、関連プロジェクトとの調整
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
◆プロジェクトライフサイクルの重要性
プロジェクトは上位組織から権限移譲され、実行されるが、上位組織の業務とまったく無関係ではない。というよりも、上位組織は業務を実行するために、プロジェクトを立ち上げて実施するわけで、プロジェクトは独立した活動であるという側面があると同時に、組織の行う業務の手段でもある。
組織の行う業務の手段として考えたときに、重要になってくるのがフェーズであり、ライフサイクルである。組織がプロジェクトをコントロールするためには、節目節目のタイミングでチェックをする必要があり、そのためにプロジェクトにフェーズを設ける。そして、フェーズを完了して、次のフェーズに移行する際にフェーズの成果物やプロジェクトの状況をチェックする。
そしてフェーズの集合をライフサイクルと呼ぶ。
フェーズはどのような小規模のプロジェクトでも組織のワークフローと整合させると必要になる。たとえば、プロジェクトの企画のフェーズと実行のフェーズが必ず存在する。大規模なプロジェクトであれば、フェーズは組織の管理に大きなメリットがあり、なくてはならないものである。
◆プロジェクトライフサイクルとプロダクトライフサイクル
フェーズは、プロジェクト基盤の一つであると位置づけることができ、プロジェクトの立ち上げの際に定義され、プロジェクト憲章に明記される。プロジェクトマネジメントや業務管理、開発管理などの標準化の進んでいる企業では、標準的なフェーズ設定も決まっていることが多い。
この際に注意しなくてはならないのは、プロジェクトライフサイクルとプロダクトライフサイクルは密接な関係があるが、別物だということだ。日本の企業はプロダクトマネジメントの概念が希薄であるので、日本人の書いたプロジェクトマネジメントの教科書でも、この２つを混乱していることが多い。
たとえば、ＩＴのプロジェクトを例にとって考えると、
要件定義 → 基本設計 → 詳細設計 → 製造 → 試験 → 運用 →廃棄
というライフサイクルであることが多い（説明のために少し細かくフェーズをとっているが、基本設計～製造までは一つのフェーズであることが多い）。
これに対して、プロジェクトライフサイクルは
プロジェクト要求分析 → 計画 → ビジネス分析
→要件定義 → 基本設計 → 詳細設計 → 製造 → 試験 → チェックアウト
というライフサイクルになることが多い。
ＩＴに限らず、プロジェクトスコープをどの範囲でとるべきかという相談を受けることがあるが、まず、プロダクトライフサイクルを明確に定義し、その上でプロジェクトライフサイクルを決定し、そして、プロジェクトスコープを決めていく必要がある。
◆プロジェクトライフサイクルの種類
プロジェクトライフサイクルは、おおざっぱに分けると３つのパターンがある。
・直線型
・提案型
・螺旋型
直線型は、繰り返し行うようなプロジェクトに適したライフサイクルで、ウォーターフォールである。たとえば、
＜プロジェクト開始＞ → 要求分析 → 計画→
＜ビジネス上の意思決定＞ → 要件定義 → 設計 → 開発 → テスト→
＜プロジェクト終了＞
といったライフサイクルが定義されることが多い。ここでポイントになるのは、ビジネス上の意思決定で、この決定により計画（あるいは、修正された計画）がベースラインが設定され、また、リソースの提供がコミットされると同時に、成果物のコミットをする。
提案型は、保守や運用プロジェクトに適したライフサイクルで、たとえば、
＜プロジェクト開始＞ → 立ち上げ → 計画／提案 →入札／選定→
＜ビジネス上の意思決定＞ → 実行→
＜プロジェクト終了＞
というライフサイクルになる。
三番目の螺旋型は、小さなソフトウエア開発プロジェクトなどに適したライフサイクルで、たとえば、
＜プロジェクト開始＞ → 立ち上げ → リリース計画 →
＜ビジネス上の意思決定＞ → サイクル１ → … → サイクルＮ →終結 →
＜プロジェクト終了＞
といったライフサイクルになる。
冒頭に述べたようにライフサイクルは、組織がプロジェクトをコントロールする手段であるが、プロジェクト側からは組織（マネジメント）支援を受ける機会であり、また、組織意思決定を最適化する手段にもなる。その意味で、プロジェクトの立ち上げにおいていは、必ず、検討する必要がある。
| | 
|
コメント