プロジェクトライフサイクル：5つのフェーズをわかりやすく解説（事例つき）

プロジェクトの監査に立ち会うと、同じパターンが繰り返されていることに気づきます。チームが立ち上げフェーズを飛ばして実行に直行し、最初のスコープを検証しないまま終結を迎えているのです。プロジェクトライフサイクルは、まさにこうした事態を防ぐために存在します。チーム、スポンサー、ステークホルダー全員が共通の構造で進められるよう、すべてのプロジェクトに統一されたフレームワークを提供します。

プロジェクトライフサイクルとは何か

プロジェクトライフサイクルとは、プロジェクトが正式に開始してから正式に終結するまでに通過する一連のフェーズを指します。Project Management Institute（PMI）は、**PMBOK Guide（Project Management Body of Knowledge）**において、5つのプロセスグループを定義しており、これがライフサイクルの5フェーズに対応しています。立ち上げ（Initiating）、計画（Planning）、実行（Executing）、監視・コントロール（Monitoring & Controlling）、**終結（Closing）**の5つです。

PMBOK Guideの第7版（2021年）では、プロセスグループから原則とパフォーマンスドメインを中心とした体系に移行し、より柔軟な実践が可能になりました。しかし、5フェーズの構造は業界横断の共通語彙として、資格試験やプロジェクト管理ソフトウェアでも引き続き広く使われています。実際の作業にアジャイル手法を採用している組織でも、プロジェクトのワークフローをこの構造に基づいて組み立てているケースが大半です。

なお、混同されやすい2つの概念を整理しておく必要があります。プロジェクトライフサイクルは作業のフェーズ（何をいつ行うか）を表します。プロダクトライフサイクルは製品が企画から退役に至るまでの各段階を表します。1つのプロダクトライフサイクルの中に、リリース、移行、改善などのプロジェクトに対応する複数のプロジェクトライフサイクルが含まれるのが通常です。

重要なポイント

PMIのPMBOK Guide第7版（2021年）はガイダンスを12の原則と8つのパフォーマンスドメインを中心に再構成しましたが、5つのプロセスグループ（立ち上げ、計画、実行、監視・コントロール、終結）はPMI資格試験および多くの組織のプロジェクトフレームワークの基盤であり続けています（Project Management Institute, 2021）。

PMIの「2024 Pulse of the Profession」によると、プロジェクトマネジメントが成熟した組織では76%の確率で当初の目標を達成しているのに対し、成熟度の低い組織では54%にとどまります。この22ポイントの差は、構造化されたライフサイクルフェーズを一貫して活用しているかどうかに直結しています（PMI, 2024）。

Standish Groupの「CHAOS Report（2023年）」によると、成功裏に納品されたプロジェクト（期限内、予算内、要求品質を満たす）は全体の31%にすぎず、失敗の主な要因として計画不足とスコープ管理の不備が挙げられています。いずれも、立ち上げフェーズと計画フェーズが本来防ぐべき問題です。

5つのフェーズを詳しく解説

フェーズ1：立ち上げ（Initiating）

立ち上げは、プロジェクトが正式に承認されるフェーズです。主要な成果物はプロジェクト憲章です。これはプロジェクト名、ビジネスケース、高レベルの目標、主要ステークホルダー、そしてプロジェクトマネージャーが組織リソースを活用する権限を明記した簡潔な文書です。

このフェーズではステークホルダーの特定も行います。プロジェクトに関心を持つ、または影響を与える全員をステークホルダー登録簿にまとめます。この作業を誤ると、重要なステークホルダーがスコープに同意していなかったことを最悪のタイミングで発覚させる事態につながります。

なお、立ち上げをビジネスケースの策定と混同しないでください。ビジネスケースの策定は通常、プロジェクトが正式に開始される前に行われます。立ち上げフェーズが始まる時点で、組織はすでにそのプロジェクトを実施する価値があると判断しています。立ち上げはその判断を正式なものにする段階です。

主な成果物：プロジェクト憲章、ステークホルダー登録簿、高レベルの前提条件と制約事項。

フェーズ2：計画（Planning）

計画は最も多くの文書を作成するフェーズです。チームはプロジェクトマネジメント計画書を策定します。これは実際にはスコープ、スケジュール、予算、品質、資源、コミュニケーション、リスク、調達、ステークホルダーエンゲージメントにわたる複数のサブ計画書の集合体です。

計画の核となるのがスコープベースラインです。これは作業分解構成図（WBS）、WBS辞書、スコープ記述書から構成されます。プロジェクトが生み出すすべての成果物はここで定義されます。スコープベースラインに含まれないものは、正式に対象外となります。

スケジュールベースラインはこれに続く形で構築されます。通常はクリティカルパス法（CPM）を使用し、期間に不確実性が高いプロジェクトではPERTチャートを活用します。Ganttチャートはチームとスポンサーに向けてスケジュールを視覚化するために使います。

計画は完全に終わることはありません。実行中に新たな情報が得られるたびに計画は更新されます。しかし、最初の段階で強固な計画を立てることで、情報が遅れて発覚することによる混乱を大幅に減らすことができます。

フェーズ3：実行（Executing）

実行は実際の作業が行われるフェーズです。プロジェクトマネージャーの役割は計画立案者から統合者へと変わります。人員の調整、ベンダー管理、意思決定の促進、そしてチームが成果を届けられるよう障害を取り除くことが主な仕事になります。

主な活動には資源管理（適切な人材と資材を必要なタイミングで確保すること）、チーム育成（共通の規範づくり、衝突の解決、コーチング）、品質保証（成果物を後から検査するだけでなく、正しい結果を生み出すプロセスであることを事前に確認すること）が含まれます。

実行フェーズはプロジェクト予算の大部分を消費します。だからこそフェーズ4は実行が終わってからではなく、並行して進めます。

ここではステークホルダーエンゲージメントも活発になります。スポンサーは進捗報告を求め、クライアントはデモを要求し、変更依頼が届き始めます。すべての変更依頼は、ベースラインに反映される前に統合変更管理のプロセスを経る必要があります。

フェーズ4：監視・コントロール（Monitoring and Controlling）

監視・コントロールは実行フェーズの終了後ではなく、実行と並行してプロジェクト全体を通じて進みます。実際のパフォーマンスを計画と比較し、差異を検知し、それが危機に発展する前に是正措置を講じることがこのフェーズの役割です。

主要ツールは**アーンドバリュー管理（EVM）**の指標です。スケジュール効率指数（SPI）とコスト効率指数（CPI）を使うことで、スケジュールと予算の両面でプロジェクトが進んでいるか遅れているかを同時に把握できます。

このフェーズではまたスコープコントロール（スコープクリープの防止）、スケジュールコントロール（必要に応じたスケジュールの圧縮または調整）、リスク監視（新たなリスクへの警戒とリスク対応策の効果確認）も管理します。

このフェーズの重要な成果物は変更ログです。承認、却下、保留されたすべての変更依頼の記録です。これがないと、最終的な成果物が当初の計画と異なる理由を誰も把握しないまま終結を迎えることになります。

フェーズ5：終結（Closing）

終結は最も頻繁に省略されるフェーズでありながら、組織の長期的な学習にとっては最も価値があるフェーズです。プロジェクトを正式に終了させ、成果物を引き渡し、チームが得た学びを記録します。

主な活動としては、クライアントまたはスポンサーからの正式な受け入れ承認の取得、ベンダーとの契約の終了、プロジェクトリソースの組織への返却、プロジェクト文書のアーカイブ、そして教訓（レッスンズラーンド）セッションの実施が挙げられます。

教訓登録簿は、何がうまくいったか、何がうまくいかなかったか、次のチームが何を改善すべきかという組織の知的資産です。終結を省略する組織は、同じ失敗を何度も繰り返す傾向があります。その知識が記録されないためです。

プロジェクトを正式に終結させることで、プロジェクトマネージャーの正式な権限も解除されます。適切な終結を行わないと、チームメンバーはプロジェクトが完了したのか単に一時停止しているのかわからないまま曖昧な状態に置かれます。

フェーズ別の主要成果物

ライフサイクル全体にわたる工数・コスト・リスクの変化

5つのフェーズは同じ量のリソースを消費するわけでも、同じ水準の不確実性を持つわけでもありません。これらの変数がライフサイクルを通じてどのように変化するかを理解することは、プロジェクト計画において最も実践的な洞察の一つです。

工数とコストは立ち上げで低く始まり、計画を通じて増加し、実行でピークに達し、終結に向けて下がっていきます。プロジェクト予算の大部分はフェーズ3で消費されます。だからこそ正確な計画が重要です。大きな支出が発生する段階では、方向修正のコストも高くなります。

リスクと不確実性は逆の曲線を描きます。プロジェクト開始時は、これから取り組む作業について最も情報が少ないため、不確実性が最も高くなります。チームが計画し、設計し、実行するにつれて未知の要素が解消され、リスクは低下していきます。これを**不確実性のコーン（cone of uncertainty）**と呼び、ソフトウェアエンジニアリング分野でBarry Boehmが提唱し、プロジェクトマネジメント全般で広く採用されています。

ステークホルダーの影響力は立ち上げ時が最大です。スポンサーやクライアントはフェーズ1において非常に低いコストでプロジェクトの方向性を根本的に変えることができます。同じ変更をフェーズ3で行うと、完成済みの作業のやり直しが発生するため、コストは大幅に増加します。

変更コストはプロジェクトが進むにつれて急上昇します。立ち上げ段階のスコープ変更は会話一つで済みます。実行段階でのスコープ変更は手戻り、スケジュール遅延、予算超過を招きます。だからこそ、うまく進められているプロジェクトは実行に飛び込むのではなく、計画への投資を前倒しで行うのです。

実践的な示唆として、フェーズ1と2を省略または短縮しようとするプレッシャーには抵抗してください。短期的な時間節約は、ほぼ例外なくフェーズ3またはフェーズ4での問題として返ってきます。そのコストは節約した分をはるかに上回ります。

予測型・適応型・ハイブリッドのライフサイクル

PMIはすべてのプロジェクトが同じライフサイクル構造から恩恵を受けるわけではないと認識しています。PMBOK Guide第7版と付属のAgile Practice Guideは、完全な予測型から完全な適応型までのスペクトラムを説明しています。

予測型（Waterfall）： スコープ全体を最初に定義します。5つのフェーズはほぼ順番に進み、各フェーズは文書化された成果物を生み出し、次のフェーズが始まる前にベースライン化されます。要件が安定しており、技術が実証済みで、クライアントがコストの確実性を求める場合に適しています。建設業、製造業、コンプライアンスが重視される業界では予測型が主流です。

反復型・インクリメンタル型： プロジェクトをイテレーション（Sprint、フェーズ、リリース）単位で計画します。各イテレーションではステークホルダーが評価できる成果物を作成します。イテレーションとイテレーションの間にスコープを調整できます。予測型と適応型の中間に位置するアプローチです。

適応型（アジャイル）： 計画はローリングウェーブ方式で行います。チームは次のSprintまたはイテレーションにのみコミットし、スコープ全体を最初に確定しません。要件はステークホルダーのフィードバックをもとに継続的に進化します。Scrumやアジャイル手法はこの形式で動作します。要件が不明確または変化しやすく、事前の確実性よりも迅速なフィードバックが重要な場合に適しています。

ハイブリッド型： 実際のプロジェクトの多くはアプローチを組み合わせています。例えばソフトウェア製品のロールアウトでは、インフラとコンプライアンス作業には予測型フェーズを使いながら、機能開発にはアジャイルSprintを採用するケースがあります。金融サービス、医療、航空宇宙などの規制産業ではハイブリッドモデルが一般的で、ガバナンスと文書化には予測型を、デリバリーには適応型を採用しています。

ライフサイクルの選択は好みの問題ではありません。要件の性質、ステークホルダー関与の度合い、規制の文脈、不確実性に対する許容度との適合性の問題です。

事例：CRMロールアウトの5フェーズを追う

ある中規模B2B企業（従業員300名、営業チーム2つ）が、スプレッドシートによるリード管理をCRMプラットフォームに移行することを決定しました。プロジェクトライフサイクルがこのロールアウトをどう形作るかを見ていきましょう。

立ち上げ： VP of Salesが、現行システムではリードの手作業での引き継ぎミスにより約15%のリードが失われているとするビジネスケースを作成します。プロジェクト憲章にはプロジェクトマネージャーの指名、予算の概算、6ヶ月以内に両営業チームが完全に導入することを成功の定義、そして主要ステークホルダーとしてVP Sales・IT Director・Sales Operations Manager・両チームリーダーが記載されます。

計画： プロジェクトマネージャーは、ロールアウトをベンダー選定、データ移行、設定とカスタマイズ、マーケティングオートメーションツールとの統合、トレーニング、ゴーライブに分解したWBSを作成します。Ganttチャートで22週間のスケジュールを可視化します。リスク登録簿ではベンダー遅延、データ品質の問題、ユーザーの低い採用率を上位3つのリスクとして特定し、それぞれに対応策を設けます。

実行： チームはベンダー選定（1〜4週目）、契約締結、過去データ移行（5〜8週目）、CRMの設定（9〜14週目）、営業担当10名のパイロットグループで並行テストを実施（15〜18週目）、トレーニングを実施（19〜21週目）という流れで進めます。

監視・コントロール： 週次状況報告でデータ移行完了率（実績対計画）、設定タスク（ベンダー遅延によりSPIが継続的に0.92）、パイロットグループの採用指標を追跡します。VP向けのカスタムダッシュボード追加の変更依頼が提出され、評価・承認を経て、2週間のスケジュール影響を加えた形で計画に組み込まれます。

終結： 22週目にゴーライブを迎えます。プロジェクトマネージャーはVP of Salesから書面による承認を取得し、システムをIT Operationsに引き渡して継続的なサポートを依頼し、ベンダー契約を締結します。教訓セッションでは、データ品質チェックを5週目ではなく2週目から開始すべきだったことが明らかになります。これにより移行が3週間遅れ、期限を危うくさせました。

フェーズ別のよくある失敗

立ち上げ

• プロジェクト憲章を省略して計画に直行する（後で権限の混乱を招く）
• 明らかなステークホルダーだけを特定し、調達、法務、エンドユーザーグループを見落とす
• ビジネスケースとプロジェクト憲章を同じ文書と扱う（目的が異なる別々の文書です）

計画

• WBSを完成させる前にスケジュールを構築する（定義されていない作業はシーケンス化できません）
• リスクバッファを設けずに楽観的に見積もる
• 誰も読まないコミュニケーション計画を作成する。配布したうえで確認をとるべきです

実行

• 変更依頼を統合変更管理のプロセスを経ずに非公式に処理する
• スケジュールのプレッシャーを理由にチーム育成活動を省略する
• プロジェクトマネージャーが調整役でなく作業担当者になってしまう

監視・コントロール

• アーンドバリュー指標ではなく感覚で状況を報告する
• 差異分析を意思決定の材料ではなく責任追及の場として扱う
• 根本原因が確認される前に課題を早期にクローズする

終結

• 成果物を引き渡した時点でプロジェクトを完了と宣言し、正式な受け入れを取得しない
• チームがすでに次のプロジェクトに移っているという理由で教訓を省略する
• このプロジェクトのテンプレート、見積もり、リスクデータを組織のプロセス資産に反映しない

よくある質問

プロジェクトライフサイクルはプロセスグループと同じですか？

完全に同じではありませんが、密接に関連しています。PMIのプロセスグループ（立ち上げ、計画、実行、監視・コントロール、終結）はプロジェクトマネジメントプロセスのカテゴリーです。プロジェクトライフサイクルはプロジェクトの実際の作業フェーズ（何を、いつ生み出すか）を指します。実際にはプロセスグループとライフサイクルフェーズが1対1で対応することが多いため、同じものとして扱われることがよくあります。主な違いは、プロセスグループがプロジェクトマネージャーが何をするかを表すのに対し、ライフサイクルフェーズはプロジェクトが何を、いつ生み出すかを表すという点です。

5つのフェーズは必ず順番通りに進むのですか？

そうとは限りません。例えば監視・コントロールは実行の後に続くのではなく、プロジェクト全体を通じて実行と並行して進みます。多くのプロジェクトでは、詳細が明確になるにつれて計画が初期の実行と並行して続きます。各フェーズは重点の一般的な順序を表すものであり、厳格な引き渡しではありません。ただし、立ち上げは常に計画より先に来る必要があり、終結は常に最後でなければなりません。

アジャイルにおけるプロジェクトライフサイクルはどう違いますか？

Scrumのようなアジャイルフレームワークでは、5つのフェーズは引き続き存在しますが、圧縮されて繰り返されます。各Sprintにはそれ自体のミニ立ち上げ（Sprintプランニング）、実行（Sprint作業）、監視（デイリースタンドアップ、バーンダウンチャート）、終結（Sprintレビューとレトロスペクティブ）があります。プロジェクト全体としては、正式なキックオフから最終的な終結まで進みます。変わるのは、計画が事前ではなくローリングウェーブ方式で行われること、そして成果物が最後にまとめてではなくインクリメンタルにリリースされることです。

実行が順調な場合も監視・コントロールは必要ですか？

監視・コントロールは引き続き実施します。すべてが順調であれば、その成果物は確認情報となります。グリーン指標を示す状況報告書、未解決項目のない変更ログ、新たにエスカレートされたリスクのないリスク登録簿がそれです。この文書は監査証跡として重要です。スポンサーやステークホルダーは、プロジェクトマネージャーの言葉だけでなく、データによってプロジェクトが順調であることを確認できます。また、順調な実行中に丁寧な監視を行うことで、何かが狂い始めた際の早期警告サインを見つけやすくなります。

プロジェクトライフサイクルの構造を理解するだけですべてのプロジェクトが成功するわけではありません。しかし、成功が設計される段階のフェーズを誤って飛ばしてしまうことを防ぐ力は確実にあります。