2-2 プロジェクトライフサイクル
Project Lifecycle
1. フェーズとフェーズゲート
1.1 フェーズの定義
フェーズ(Phase)とは、プロジェクトを論理的に区切った期間であり、 特定の成果物やマイルストーンの完成を目指す作業の集合体である。 フェーズの終了時には、次のフェーズへ進む前にレビューが行われる。
| フェーズ名 | 主な活動 | 主要成果物 |
|---|---|---|
| 構想・企画 | ビジネスニーズの特定、実現可能性の検討 | プロジェクト憲章、ビジネスケース |
| 計画 | スコープ定義、スケジュール・予算策定 | プロジェクト管理計画書、WBS |
| 設計 | システム設計、アーキテクチャ決定 | 基本設計書、詳細設計書 |
| 開発・実装 | コーディング、単体テスト | ソースコード、テスト結果 |
| テスト | 結合テスト、システムテスト、UAT | テスト報告書、不具合一覧 |
| 導入・移行 | 本番環境構築、データ移行、教育 | 移行完了報告書、操作マニュアル |
| 終結 | プロジェクト評価、知見の文書化 | 完了報告書、教訓登録簿 |
1.2 フェーズゲート(Stage Gate)
フェーズゲートとは、フェーズの終了時に設けられる意思決定ポイントである。 ここで成果物のレビューを行い、次のフェーズへ進むか、手戻りするか、 プロジェクトを中止するかを判断する。
| ゲート判定 | 意味 | アクション |
|---|---|---|
| Go(承認) | 基準を満たしている | 次フェーズへ進行 |
| Conditional Go | 軽微な課題あり | 条件付きで進行、並行して課題解決 |
| Hold(保留) | 重大な課題あり | 課題解決まで進行停止 |
| Kill(中止) | 継続不可能 | プロジェクト終了手続き |
フェーズゲートは「後戻りできない決定」を行う前のチェックポイントである。 ゲートを厳格に運用することで、問題の早期発見と手戻りコストの削減が可能になる。 ただし、形式的なレビューに陥らないよう、実質的な評価を行うことが重要である。
1.3 フェーズ間の関係
フェーズ間の関係には、順次関係(Sequential)と重複関係(Overlapping)がある。 順次関係では前フェーズ完了後に次フェーズが開始されるが、 重複関係では一部のフェーズが並行して進行する。
| 関係タイプ | 特徴 | 適用場面 |
|---|---|---|
| 順次関係 | 明確な区切り、リスク低 | 要件が明確、変更が少ない |
| 重複関係 | 期間短縮、調整コスト増 | スケジュール制約が厳しい |
| 反復関係 | フィードバック反映、柔軟 | 要件が不明確、変更が多い |
2. 予測型ライフサイクル(Predictive)
2.1 予測型の特徴
予測型ライフサイクル(Waterfall、計画駆動型とも呼ばれる)は、 プロジェクトの初期段階でスコープ・スケジュール・コストを詳細に計画し、 計画に従って順次的に進行するアプローチである。
| 特性 | 予測型の特徴 |
|---|---|
| 計画タイミング | プロジェクト初期に詳細計画を策定 |
| 変更への対応 | 変更管理プロセスで厳格に管理 |
| 成果物の提供 | プロジェクト終盤に一括提供 |
| 顧客の関与 | 主にマイルストーン時点でレビュー |
| ドキュメント | 詳細なドキュメントを重視 |
2.2 ウォーターフォールモデル
ウォーターフォールモデルは予測型の代表的なモデルであり、 要件定義→設計→実装→テスト→導入の各フェーズを 滝(Waterfall)のように上流から下流へ順次進行する。
ウォーターフォールが適するプロジェクト
要件が明確で変更が少ないプロジェクト、規制やコンプライアンス要件が厳しいプロジェクト、 大規模インフラ構築、パッケージ導入などに適している。 一方、要件が不明確な新規サービス開発や、市場変化の激しい領域には不向きである。
2.3 V字モデル
V字モデルはウォーターフォールの派生形であり、開発フェーズとテストフェーズを 対応させて品質を確保するアプローチである。左側で設計を進め、 右側で対応するテストを実施する。
| 開発フェーズ(左) | 対応するテスト(右) |
|---|---|
| 要件定義 | 受入テスト(UAT) |
| 基本設計 | システムテスト |
| 詳細設計 | 結合テスト |
| 実装 | 単体テスト |
各設計フェーズで対応するテスト計画を同時に作成するため、 テスト漏れを防ぎ、要件のトレーサビリティを確保しやすい。 特に品質要求が厳しいシステム(医療、金融、航空など)で採用される。
3. 適応型ライフサイクル(Adaptive)
3.1 適応型の特徴
適応型ライフサイクル(アジャイル型)は、短い反復サイクルで 動作するソフトウェアを継続的にリリースし、フィードバックに基づいて 要件や計画を適応的に調整するアプローチである。
| 特性 | 適応型の特徴 |
|---|---|
| 計画タイミング | 反復ごとに詳細計画を策定(ローリングウェーブ) |
| 変更への対応 | 変更を前提として柔軟に受け入れ |
| 成果物の提供 | 反復ごとにインクリメントを提供 |
| 顧客の関与 | 継続的に関与、頻繁なフィードバック |
| ドキュメント | 動くソフトウェアを重視、必要最小限のドキュメント |
3.2 イテレーション(反復)とインクリメント(増分)
適応型では、イテレーションとインクリメントという2つの概念が重要である。 両者は組み合わせて使用されることが多い。
| 概念 | 定義 | 例 |
|---|---|---|
| イテレーション | 固定期間(タイムボックス)での反復開発サイクル | 2週間スプリント |
| インクリメント | 各反復で追加される動作可能な成果物 | 新機能、機能改善 |
3.3 適応型の種類
適応型ライフサイクルにはいくつかのバリエーションがある。
| タイプ | 特徴 | 代表的手法 |
|---|---|---|
| 反復型(Iterative) | プロトタイプを繰り返し改良 | スパイラルモデル |
| 増分型(Incremental) | 機能を段階的に追加 | 段階的リリース |
| アジャイル型 | 反復と増分を組み合わせ | Scrum、XP、Kanban |
適応型が適するプロジェクト
要件が不明確または変化しやすいプロジェクト、革新的な製品開発、 スタートアップでの新規サービス開発、ユーザーフィードバックが重要なプロジェクト などに適している。逆に、規制が厳しい環境や、固定価格契約には調整が必要である。
4. ハイブリッド型ライフサイクル
4.1 ハイブリッド型とは
ハイブリッド型ライフサイクルは、予測型と適応型を組み合わせたアプローチである。 プロジェクトの特性や組織の状況に応じて、最適な要素を選択・統合する。 実際の現場では純粋な予測型や適応型よりも、ハイブリッド型が採用されることが多い。
4.2 ハイブリッドのパターン
ハイブリッドアプローチには様々なパターンがあり、プロジェクトの特性に応じて選択する。
| パターン | 説明 | 適用例 |
|---|---|---|
| Water-Scrum-Fall | 要件定義・設計は予測型、開発はアジャイル、テスト・導入は予測型 | エンタープライズシステム開発 |
| アジャイル+予測型(並行) | コンポーネントごとに適切な手法を選択 | UI(アジャイル)+ インフラ(予測型) |
| 段階的アジャイル導入 | 最初は予測型、徐々にアジャイル要素を追加 | 組織のアジャイル移行期 |
| アジャイル+ゲートレビュー | スプリントで開発、主要マイルストーンでフォーマルレビュー | 規制産業でのアジャイル |
4.3 ライフサイクル選択の指針
プロジェクトの特性に基づいて、適切なライフサイクルを選択する必要がある。
| 評価軸 | 予測型に向く | 適応型に向く |
|---|---|---|
| 要件の明確さ | 明確、安定している | 不明確、変化しやすい |
| 技術的不確実性 | 低い、実績ある技術 | 高い、新技術 |
| ステークホルダー関与 | 限定的で良い | 継続的関与が必要 |
| 変更の頻度 | 少ない | 多い |
| リリース戦略 | 一括リリース | 段階的リリース |
| 契約形態 | 固定価格 | 準委任、T&M |
| 規制要件 | 厳格なドキュメント必要 | 柔軟性がある |
「アジャイルが流行っているからアジャイルで」という理由で選択するのは危険である。 組織の成熟度、チームのスキル、顧客の協力体制、契約形態など、 多角的な視点から最適なアプローチを選択すべきである。 また、プロジェクト途中でのライフサイクル変更は大きなリスクを伴う。
4.4 テーラリング(適合化)
どのライフサイクルを選択する場合も、プロジェクトの特性に合わせて 手法をカスタマイズする「テーラリング」が重要である。 標準的な手法をそのまま適用するのではなく、必要な要素を取捨選択する。
プロジェクト規模、複雑性、リスクレベル、チーム経験、組織文化、 規制要件、ステークホルダーの期待などを考慮してテーラリングを行う。 PMBOK第7版でも「テーラリング」は12の原則の1つとして重視されている。
プロジェクトライフサイクルの理解を深めたら、次は「2-3 プロセス群」で プロジェクトマネジメントの具体的なプロセスについて学習しよう。
[1] PMI (2021). PMBOK Guide 7th Edition.
[2] PMI (2017). PMBOK Guide 6th Edition.
[3] Royce, W. (1970). Managing the Development of Large Software Systems.