プロジェクト計画の立て方｜WBS・スコープ定義・マイルストーンの実務テクニック

プロジェクトの成否を決める最大の要因は「計画の精度」です。計画が甘いプロジェクトは、必ずどこかで破綻します。

「プロジェクト開始後にスケジュールがどんどん遅れる」「途中で仕様変更が頻発し、スコープが膨張する」「開発が進んでいるはずなのに成果が見えない」。これらの問題の根本原因は、計画段階での詰めの甘さにあります。

しかし、計画を立てただけで安心してはいけません。計画とは立てるだけでなく、運用し続けなければ意味がないものです。計画は「変更されることが前提」であり、状況に応じて適切に修正しながらプロジェクトを前進させる必要があります。

本記事では、プロジェクト計画の具体的な立て方を解説します。WBS・スコープ定義・マイルストーン設定の基本から、計画を現実的に運用するための実践的な手法までを取り上げます。

---

1. なぜプロジェクト計画が重要なのか？

1-1. 「計画なしで成功するプロジェクトはない」

プロジェクト管理でよく言われるのが、「計画がないプロジェクトは失敗する運命にある」という言葉です。これは単なる理論ではなく、実際の現場でも多くの失敗事例から証明されています。計画がない、もしくは計画が杜撰なまま進行すると、以下のような問題が発生します。

• スケジュールが破綻する — 計画がないと、どのタスクにどれくらいの時間がかかるのか見積もれず、納期遅延が発生しやすくなります。
• リソースが足りなくなる — 途中で開発メンバーが不足する、サーバー容量が足りない、外部ベンダーの納品が遅れるなど、計画の不備によるリスクは多岐にわたります。
• タスクの優先順位が不明確になる — どの作業を先に進めるべきかが曖昧になり、チームが迷走します。
• スコープが膨張し、プロジェクトが炎上する — 最初に「何を作るのか」を明確に定義しないと、次々と新しい要件が追加され、収拾がつかなくなります。

計画がないまま進めると、プロジェクトの成功どころか、炎上や頓挫が現実のものとなります。では、計画がしっかりしているプロジェクトとそうでないプロジェクトでは、具体的に何が違うのでしょうか。

1-2. 計画を軽視すると何が起こるのか？（失敗事例から学ぶ）

実際に「計画が不十分だったために失敗したプロジェクト」を確認します。

事例1：要件定義を甘く見た結果、大幅な仕様変更が発生

プロジェクト概要：とある企業向けの業務システム開発プロジェクト。クライアントは「業務の効率化を図るための新しいシステム」を求めていました。

失敗の原因：

• 初期段階でクライアントの要求を十分に整理せず、「ざっくりとした方向性」で開発をスタートした。
• 実際に開発が進むにつれて、「この機能も欲しい」「あの機能も追加してほしい」と次々に要望が増加した。
• 追加要件が増えるたびに開発スケジュールが遅延し、最終的にプロジェクトが破綻した。

教訓：最初にスコープを明確に決めなければ、プロジェクトは迷走します。クライアントと合意した「作るべきもの」を最初にしっかり定義し、計画に落とし込むことが必須です。

事例2：スケジュール見積もりの甘さが致命傷に

プロジェクト概要：モバイルアプリ開発プロジェクト。開発チームは「3か月でリリース可能」と見積もっていました。

失敗の原因：

• 「3か月で開発可能」という見積もりが根拠のない楽観的な予測だった。
• 実際に開発を進めると、API開発の遅れ、データベース設計の不備、UIデザインの修正が重なり、予定よりも2か月遅延した。
• リリース直前で致命的なバグが発覚し、修正に時間がかかり、結果的にリリースが半年以上遅延した。

教訓：開発スケジュールを立てる際は、過去の実績を元に現実的な見積もりを行います。バッファ（余裕期間）を適切に確保し、遅延リスクを考慮した計画を立てることが重要です。

事例3：プロジェクトの進捗管理が機能せず、破綻

プロジェクト概要：企業向けのSaaS開発プロジェクト。マネージャーは進捗報告を軽視し、メンバーの進捗状況を正確に把握していませんでした。

失敗の原因：

• 各メンバーが「なんとなく進んでいる」と思っていたが、実際には多くのタスクが遅延していた。
• 定例会議では「問題ない」と報告されていたが、実際には開発が想定以上に難航していた。
• 最終的に納期直前で「このままでは間に合わない」と発覚し、大急ぎで開発を進めるも、品質が犠牲になり、クライアントからの信用を失う結果になった。

教訓：計画を立てた後も、定期的に進捗をチェックし、問題を早期に発見・対処することが不可欠です。「うまくいっているはず」ではなく、「どこまで進んでいるのか」を数値やタスク管理ツールで可視化することが重要です。

1-3. 計画の精度がプロジェクトの成否を決める理由

これまでの事例からわかるように、プロジェクト計画の精度がそのまま成功・失敗を左右します。では、どのような計画を立てればプロジェクトの成功率を高められるのでしょうか。

1. タスクを適切な粒度に分解する（WBSの活用） — プロジェクト全体を「実行可能な小さなタスク」に分解することで、進捗管理がしやすくなります。細かすぎると管理が煩雑になるため、適切な粒度を意識します。
2. スコープを明確にし、関係者と合意を取る — 「何を作るのか」を最初にクライアント・開発チーム・関係者全員で明確にし、ドキュメント化します。途中で追加要件が発生した場合のルールも決めておきます。
3. 現実的なスケジュールを策定し、バッファを確保する — 楽観的なスケジュールではなく、「最悪のケース」を考慮した計画を作ります。開発やテストの遅延を見越して、余裕を持ったスケジュールを設計します。
4. 進捗を定期的にモニタリングし、必要に応じて計画を修正する — 計画は一度立てたら終わりではなく、進捗状況に応じて随時更新します。チームメンバーと定期的に状況を確認し、問題が発生したら早めに対処します。

プロジェクト計画がしっかりしていれば、スムーズな進行が可能になり、予期せぬトラブルにも柔軟に対応できます。次のステップとして、プロジェクト計画の具体的な立て方（WBS、スコープ定義、マイルストーン設定）について解説します。

---

2. プロジェクト計画の基本（WBS、スコープ定義、マイルストーン設定）

2-1. WBS（Work Breakdown Structure）とは？

プロジェクト計画の第一歩は、「何をするべきか」を明確にすることです。そのために用いられる代表的な手法がWBS（Work Breakdown Structure：作業分解構成）です。WBSは、プロジェクトのタスクを階層構造で細かく分解し、管理しやすい単位にする技術です。

たとえば、企業向けのWebシステムを開発するプロジェクトを考えます。WBSを作成すると、以下のようにタスクを分解できます。

（例）Webシステム開発プロジェクトのWBS

1. 要件定義 — 1.1 クライアントヒアリング / 1.2 競合調査 / 1.3 画面遷移図作成 / 1.4 非機能要件の整理
2. 設計 — 2.1 UIデザイン設計 / 2.2 DB設計 / 2.3 API仕様書作成
3. 実装 — 3.1 フロントエンド開発 / 3.2 バックエンド開発 / 3.3 API開発
4. テスト — 4.1 単体テスト / 4.2 結合テスト / 4.3 UAT（ユーザー受け入れテスト）
5. リリース — 5.1 サーバーセットアップ / 5.2 本番環境デプロイ / 5.3 運用マニュアル作成

このように、プロジェクトの全タスクを体系的に整理することで、漏れを防ぎ、進捗管理をしやすくするのがWBSの目的です。

タスクを適切な粒度に分解する技術

WBSを作成する際に重要なのが、「タスクをどこまで細かく分解すべきか」という問題です。タスクを細かくしすぎると管理が煩雑になり、逆に粗すぎると進捗を正しく把握できなくなります。

適切な粒度を見極めるポイントは以下の3つです。

1. 「1つのタスクにかかる工数が適切か？」 — 一般的には、1つのタスクが1〜5日程度の作業になるようにします。10日以上かかるタスクは、さらに分割を検討します。
2. 「成果物が明確になっているか？」 — 各タスクの成果物（アウトプット）が明確であることが必要です。例：「API開発」ではなく「ログイン認証APIの実装完了」のように具体的にします。
3. 「責任者を特定できるか？」 — WBSの各タスクには担当者を紐付けることが重要です。誰が責任を持つのかを明確にし、タスクの管理をしやすくします。

【図：WBSの階層構造】

実務では、このWBSに担当者・フェーズ合計工数・開始終了日を加えることで、ガントチャートやリソース計画へと発展させます。WBSは完成物ではなく、プロジェクト管理の起点です。

2-2. スコープ定義の重要性

プロジェクトの失敗原因のひとつに「スコープの曖昧さ」があります。スコープ（Scope）とは、プロジェクトで実施する範囲（作るもの・作らないもの）のことです。

スコープが曖昧なプロジェクトでは、以下のような問題が発生します。

• 途中でクライアントから「追加でこの機能も作ってほしい」と言われる
• 開発チームが「この仕様も必要では？」と勝手に判断してしまう
• 納期直前に「これがないとリリースできない」と判明し、炎上する

これらの問題は、すべて「スコープを最初に明確に定義しなかったこと」が原因です。

クライアントやチームと合意を取るためのポイント

スコープを明確にするためには、「作るもの・作らないもの」を明確に定義し、関係者と合意を取ることが重要です。以下の手順でスコープを定義します。

1. スコープ文書を作成する — 「このプロジェクトで作るもの」を明確に文書化します（例：要件定義書）。機能一覧、対象範囲、制約などを明記します。
2. スコープ外の項目も明確にする — 「今回のプロジェクトでは作らない機能」も明示します。例：「モバイルアプリの開発はスコープ外」「レガシーシステムとの連携は対象外」など。
3. スコープ変更のルールを決める — 途中で新しい要件が出てきた場合の対応ルールを決めます。例：「追加要件は別途見積もり」「スケジュール調整が必要」などを明記します。

2-3. マイルストーン設定のベストプラクティス

マイルストーンとは、プロジェクトの重要な進捗ポイントを示す基準点です。単なる「タスクの完了」ではなく、プロジェクトの大きな節目となる成果物を基準に設定します。

例えば、Webシステム開発プロジェクトにおけるマイルストーンは以下のようになります。

1. 要件定義完了 — クライアントと要件定義書の最終合意が完了。
2. UIデザイン確定 — デザインカンプ（Figmaなど）を確定し、開発チームと合意。
3. 基本設計完了 — システムアーキテクチャ、DB設計、API設計が確定。
4. 開発完了 — コーディングが終了し、単体テストを完了。
5. 結合テスト完了 — 各機能を統合し、結合テストを完了。
6. UAT（ユーザー受け入れテスト）完了 — クライアントによる最終テストが完了。
7. リリース — 本番環境にシステムをデプロイし、運用開始。

マイルストーン設定のコツ

1. 主要な成果物を基準に設定する — 「設計完了」「開発完了」のように、目に見える成果物を基準にします。
2. 関係者と合意を取る — マイルストーンの期日はクライアント・開発チームと事前に合意します。
3. 遅延リスクを考慮し、調整可能なバッファを設ける — 例えば「開発完了」のマイルストーンの前に「コードフリーズ（開発停止）」を設定することで、品質を確保できます。

これらのプロジェクト計画の基本をしっかり押さえることで、プロジェクトの成功率を大幅に向上させることができます。

【図：マイルストーンとタスクの関係】

---

3. 現場で使える計画策定のフレームワーク

プロジェクト計画を策定する際には、単なる勘や経験則ではなく、体系的なフレームワークを活用することで精度を向上させることができます。本章では、現場で実際に使える代表的な計画策定のフレームワークを解説します。

3-1. トップダウン vs ボトムアップ：どちらが適切か？

計画を策定するアプローチには、大きく分けてトップダウン方式とボトムアップ方式の2つがあります。プロジェクトの特性やチームの状況によって使い分けることが重要です。

1. トップダウン方式

経営層やプロジェクトマネージャーが大枠の計画を決め、それに基づいてチームが詳細を詰める方式です。大規模プロジェクトや、組織の意思決定が強く影響する案件でよく使われます。

• メリット：全体像を最初に明確にできるため、方向性がブレにくい。スケジュールやリソースの見積もりを早い段階で確定しやすい。
• デメリット：現場の実態と乖離した計画になりやすい。現場のエンジニアやデザイナーの意見が反映されにくい。

適用例：経営層の承認が必要な案件、既存のプロジェクトテンプレートを流用できる場合、規模が大きく標準化された進め方が求められる場合。

2. ボトムアップ方式

チームメンバーが作業レベルのタスクを洗い出し、それを統合してプロジェクト全体の計画を作成する方式です。実際の作業を担当するエンジニアやデザイナーが積極的に関与します。

• メリット：現場のリアルな作業量や課題を反映した計画が立てられる。メンバーの納得感が高まり、計画に対するコミットメントが強くなる。
• デメリット：大枠のスケジュールや全体の戦略が後回しになり、調整に時間がかかる。部門間の調整が難しくなることがある。

適用例：アジャイル開発など現場主導のプロジェクト、専門性が高くトップダウンでは正確な計画が立てにくい場合、スモールスタートのプロジェクト。

3-2. 実務で役立つ計画策定フレームワーク

プロジェクトの計画を立てる際に活用できる代表的なフレームワークを紹介します。

1. MoSCoW法：優先度を明確にする

MoSCoW法は、プロジェクトの要件やタスクの優先度を明確にするためのフレームワークです。プロジェクト計画で重要なのは、すべての要求を満たそうとしないことです。優先順位を適切に整理し、「何を最優先にすべきか」を決める必要があります。

• M（Must Have）：絶対に必要なもの（これがないとプロジェクトが成立しない）
• S（Should Have）：可能な限り実装すべきもの（重要だが、Mustほどではない）
• C（Could Have）：あれば良いもの（優先度が低く、スケジュールが厳しくなったら削減可）
• W（Won’t Have）：今回は実装しないもの（スコープ外）

クライアントやチームと合意形成を行い、「Must」と「Should」の境界をはっきりさせます。「Won’t Have」の項目も明確にし、後から追加されるのを防ぎます。

2. SMARTの法則：目標設定を具体的にする

プロジェクト計画では、目標が曖昧で測定不能なものにならないようにすることが重要です。SMARTの法則は、目標設定を具体的かつ現実的にするためのフレームワークです。

1. S（Specific）：具体的であること（例：「売上を上げる」ではなく「月間売上を20%増やす」）
2. M（Measurable）：測定可能であること（数値や達成基準が明確である）
3. A（Achievable）：達成可能であること（現実的な計画である）
4. R（Relevant）：関連性があること（ビジネス目標と一致している）
5. T（Time-bound）：期限があること（いつまでに達成するのか明確にする）

各タスクに対して、SMARTの5つの要素をチェックし、曖昧なものを修正します。計画書に「なぜこの目標が重要か」も明記することで、メンバーの納得感を高めます。

3. PERT（Program Evaluation and Review Technique）：スケジュール見積もりの精度を上げる

PERT法は、プロジェクトのタスクの所要時間を3つの見積もり値を使って算出する手法です。

1. 楽観見積もり（O：Optimistic） — 最も早く終わる場合
2. 最頻見積もり（M：Most Likely） — 一般的なケース
3. 悲観見積もり（P：Pessimistic） — 最も時間がかかる場合

PERTの計算式：予測時間 = (O + (4×M) + P) / 6

過去のプロジェクトのデータを活用し、見積もりの精度を上げます。必ずバッファ（余裕時間）を考慮し、スケジュールの遅延リスクを抑えます。

PERT図によるスケジュール可視化

PERT図（Program Evaluation and Review Technique 図）は、タスクとその依存関係を視覚的に表したネットワーク図です。スケジュール計画や所要時間の見積もりを精度高く行うために使用されます。

PERT図は、以下の3つの要素で構成されます。

• ノード（Node） — 作業（タスク）を表す円や矩形です。各ノードには作業名や所要時間を記載します。
• 矢印（Arrow） — 作業間の依存関係（順番）を示します。矢印の方向が作業の実行順序です。
• クリティカルパス（Critical Path） — プロジェクト完了までに最も時間がかかる経路です。この経路上のタスクが遅れると、プロジェクト全体の納期に影響します。

例として、「新規Webサイト開発」のPERT図を考えます。

作業	作業内容	所要日数	先行作業
A	要件定義	5日	なし
B	デザイン作成	7日	A
C	フロントエンド開発	10日	B
D	バックエンド開発	12日	B
E	結合テスト	8日	C, D
F	リリース準備	5日	E

【図：PERT図の例（Webサイト開発）】

この例では、クリティカルパスは「A → B → D → E → F」で合計37日です。この経路上のタスクが遅れると、プロジェクト全体のスケジュールが遅延します。一方、タスクCには2日の余裕（フロート）があり、多少の遅れはプロジェクト全体に影響しません。

PERT図のメリットは以下の4点です。

• プロジェクトのボトルネック（最も時間のかかる工程）を明確にできる
• タスクの依存関係を視覚化し、並行作業が可能な部分を特定できる
• スケジュールの余裕（バッファ）がどこにあるかを把握できる
• リスク管理がしやすくなる

項目	PERT図	ガントチャート
目的	依存関係とスケジュールの最適化	スケジュールの進捗管理
表現方法	ネットワーク図	横棒（バー）
特徴	クリティカルパスを特定しやすい	進捗を可視化しやすい

計画時にはPERT図で依存関係とクリティカルパスを把握し、進捗管理にはガントチャートを使うのが効果的です。両方を併用することで、計画精度と管理の両面でプロジェクトを強化できます。

計画を「チームが理解し、実行しやすい形に落とし込む」コツ

• 計画は文書化し、チーム全員が確認できる形で共有する
• ツール（JIRA、Trello、Redmineなど）を活用してタスクの見える化をする
• 週次・月次で計画の進捗をレビューし、必要に応じて調整する

これらのフレームワークを活用することで、現実的かつ実行可能なプロジェクト計画を策定できます。

---

4. 計画の「落とし穴」とその回避策

プロジェクト計画を立てることは重要ですが、計画を作成しただけで成功するわけではありません。多くのプロジェクトでは、計画そのものに問題があるために失敗することがよくあります。本章では、プロジェクト計画で陥りやすい代表的な落とし穴と、それを回避するための実践的な対策を解説します。

4-1. 見積もりが甘い → バッファの設定方法

落とし穴：楽観的な見積もりがプロジェクトを破綻させる

プロジェクト計画の中でも特に重要なのがスケジュールとリソースの見積もりですが、多くのプロジェクトではこの見積もりが甘いために失敗しています。

• 「楽観的すぎるスケジュール」を立てた結果、納期直前で焦りが生じ、品質が犠牲になる
• 「この作業なら1週間で終わるはず」と見積もったが、実際には2週間以上かかることが判明
• 外部ベンダーの納品遅延など、外部要因のリスクを考慮せずにスケジュールを組んでしまう

典型的な失敗例として、バグ修正の時間を考慮していなかったケースがあります。開発が終わってからテストを開始したものの、想定以上にバグが発生し、修正に1か月かかり納期が大幅遅延しました。開発チームのスキルレベルを過大評価し、新しい技術スタックの学習コストを考慮せずに計画を立てた結果、作業が進まなかったケースもあります。

回避策：PERT法を活用し、バッファを適切に確保する

見積もりの甘さを防ぐには、悲観的なケースも考慮した見積もりを行うことが重要です。そのために役立つのがPERT法（Program Evaluation and Review Technique）です。

PERT法では、3種類の見積もりを使ってスケジュールを算出します。

• O（Optimistic）：最も早く終わる場合
• M（Most Likely）：通常のケース
• P（Pessimistic）：最も遅くなる場合

予測時間 = (O + (4×M) + P) / 6

この方法を使うことで、「最悪のケース」を考慮した現実的なスケジュールを作成できます。

バッファ（予備期間）の設定方法：

• 開発スケジュールの10〜20%をバッファとして確保する
• 重要なマイルストーンの前にチェックポイント（例：コードフリーズ日）を設ける
• 「開発は3か月で完了」ではなく、「開発は3か月だが、1か月の予備期間を設ける」という形でスケジュールを組む

【図：PERT法による見積もりとバッファ】

4-2. 仕様変更が止まらない → スコープクリープの防ぎ方

落とし穴：スコープが膨張し、プロジェクトが炎上する

スコープクリープとは、プロジェクトの進行中に仕様変更が頻繁に発生し、プロジェクトが収拾がつかなくなる現象を指します。

• クライアントから「この機能も追加してほしい」と言われる
• チーム内で「この機能も必要では？」という意見が出る
• プロジェクト終盤になって「これがないとダメ」と言われる

典型的な失敗例として、当初の計画ではなかった機能を追加した結果スケジュールが崩壊するケースや、実装してからクライアントが要件を変更し作り直しが発生するケースがあります。

回避策：スコープを最初に文書化し、変更ルールを明確にする

1. スコープ定義書を作成し、「作るもの・作らないもの」を明確にする — 例：「今回のプロジェクトではモバイルアプリの開発は含まない」と明記する
2. スコープ変更プロセスを定める — 例：「新しい要件が追加される場合は、納期・予算・リソースへの影響を分析し、承認が必要」
3. MoSCoW法を活用して優先順位を明確にする — Must（必須）、Should（できれば）、Could（余裕があれば）、Won’t（今回はやらない）の4段階で整理する

4-3. 関係者間で認識がズレる → 認識合わせのテクニック

落とし穴：関係者ごとに異なる認識を持ち、混乱が生じる

プロジェクトには様々な関係者が関わります。

• クライアント：「できるだけ高機能にしてほしい」
• 開発チーム：「最小限の機能でリリースしたい」
• マネージャー：「スケジュール通りに終わらせたい」

関係者ごとに優先するポイントが異なるため、明確な合意が取れていないとプロジェクトの方向性がブレてしまいます。クライアントが「こんなはずじゃなかった」と不満を抱えたり、開発チームが「この仕様は聞いていなかった」と混乱したり、マネージャーが「なぜこんなに遅れているのか」と焦ったりする事態に陥ります。

回避策：関係者間の認識を揃えるための3つの手法

1. プロジェクト憲章（Project Charter）の作成 — プロジェクトの目的、スコープ、マイルストーン、関係者の役割を明文化します。クライアント、マネージャー、開発チーム全員がレビューし、合意を得ます。
2. 週次ミーティングの実施 — 進捗状況の共有、認識ズレの解消、新たなリスクの発見を目的とします。議事録を必ず作成し、関係者に共有します。
3. ユーザーストーリーとプロトタイプの活用 — 要件を「ユーザーの視点」で整理し、ストーリーボードやプロトタイプを作成します。例：「ユーザーがログインして、商品を購入できる」という流れを、具体的な画面イメージとともに説明します。

4-4. 計画は固定ではなく、動的に調整するもの

計画は立てたら終わりではなく、プロジェクトの進捗に応じて柔軟に調整することが重要です。

動的な計画調整のポイント

• 定期的に「計画の見直しタイミング」を設定する（例：1か月ごとに再評価）
• リスクが発生した場合は、即座に影響範囲を分析し、計画を修正する
• 計画変更時には関係者全員と合意を取る（マネージャー・開発チーム・クライアント）

プロジェクト計画は単なるドキュメントではなく、プロジェクトを成功に導くための「生きた指針」です。最初に計画の落とし穴を意識し、適切な対策を講じることで、失敗のリスクを大幅に減らせます。

---

5. アジャイル VS ウォーターフォール：最適な適用方法

プロジェクト管理の手法には、大きく分けてウォーターフォール型とアジャイル型の2つがあります。どちらの手法も長所と短所があり、プロジェクトの特性に応じて適切な手法を選択することが重要です。

ここでは、アジャイルとウォーターフォールの違いを説明し、それぞれの手法が適しているプロジェクトの条件、さらにハイブリッドアプローチの実例について解説します。

5-1. 「ウォーターフォールだからダメ」「アジャイルだから成功する」は誤解

近年、特にソフトウェア開発の分野では「アジャイルが主流」「ウォーターフォールは時代遅れ」と言われることが多くなっています。しかし、これは誤解であり、どちらの手法も適切な状況で使用すれば高い効果を発揮します。

ウォーターフォール型の特徴

ウォーターフォール（Waterfall）型は、プロジェクトを順番に進めていく計画重視の開発手法です。

プロセス：

1. 要件定義（すべての機能・仕様を明確に決定する）
2. 設計（システムアーキテクチャ・データベース・画面設計など）
3. 実装（コーディングを開始）
4. テスト（単体テスト → 結合テスト → 総合テスト）
5. リリース（本番環境にシステムをデプロイ）

ウォーターフォールは、一度決めた計画通りに進めることを前提としているため、途中での仕様変更が難しいという特性があります。

メリット：

• 計画が明確であり、プロジェクトの全体像を最初に把握しやすい
• 大規模なプロジェクトや規制の厳しい業界（医療、金融など）では適している
• ドキュメントが整備されるため、後からプロジェクトを引き継ぎやすい
• 開発コストやスケジュールが管理しやすい

デメリット：

• 開発中に仕様変更が発生すると、大きな手戻りが発生する
• ユーザーのフィードバックを開発途中で反映しにくい
• 初期の要件定義が曖昧な場合、後半で「思っていたものと違う」という問題が発生する

アジャイル型の特徴

アジャイル（Agile）型は、プロジェクトを短い開発サイクル（イテレーション）で進め、柔軟に対応する開発手法です。

プロセス：

1. スプリント計画（2週間〜1か月の短期間で開発する機能を決定）
2. 開発（設計・コーディング・テストを繰り返しながら進める）
3. レビュー（開発した機能をクライアントやユーザーと確認）
4. リリース（動くものを早期に提供し、フィードバックを得る）

アジャイルでは、ユーザーやクライアントからのフィードバックを元に柔軟に仕様を変更できるという特徴があります。

メリット：

• 仕様変更が発生しても柔軟に対応できる
• ユーザーのフィードバックを早い段階で得られる
• チームメンバーの主体性が高まり、モチベーションが向上しやすい
• 小さなリリースを繰り返すことで、リスクを低減できる

デメリット：

• 計画を厳密に決められないため、スケジュール管理が難しい
• 長期的なコスト見積もりが困難
• クライアントやステークホルダーとの密なコミュニケーションが必要
• 大規模プロジェクトでは管理が煩雑になることがある

【図：ウォーターフォール型 vs アジャイル型 プロセス比較】

5-2. プロジェクトの特性ごとの適切な手法選択

どの手法を選ぶかは、プロジェクトの特性によって決まります。以下の表は、それぞれの適用範囲をまとめたものです。

プロジェクトの特性	適用しやすい手法
仕様が事前に明確で変更が少ない	ウォーターフォール
要件が不確実で頻繁に変わる	アジャイル
規制や監査が厳しい（医療・金融など）	ウォーターフォール
小規模チーム・スタートアップ	アジャイル
クライアントと頻繁にコミュニケーションが取れる	アジャイル
長期的な計画が必要	ウォーターフォール
MVP（Minimum Viable Product）を短期間で作成	アジャイル

ケース1：エンタープライズ向け基幹システム開発

• 選択すべき手法：ウォーターフォール
• 理由：仕様が厳格に決まっており変更が難しい。長期的なスケジュールが求められる。厳密なテストと文書化が必要。

ケース2：スタートアップのWebサービス開発

• 選択すべき手法：アジャイル
• 理由：仕様変更が頻繁に発生する。早い段階でユーザーのフィードバックを得る必要がある。スモールチームで開発を進めやすい。

5-3. ハイブリッドアプローチの実例紹介

最近では、ウォーターフォールとアジャイルを組み合わせた「ハイブリッドアプローチ」が採用されるケースが増えています。

ハイブリッドアプローチの例

• 要件定義・設計はウォーターフォール、開発・テストはアジャイル — 要件や全体の仕様は最初に確定し（ウォーターフォール）、その後、各機能の開発はアジャイルで進めます。
• クリティカルな部分はウォーターフォール、それ以外はアジャイル — 例：金融系システムでは決済部分はウォーターフォール、それ以外のフロントエンドはアジャイルで進めます。

実際の企業での導入例

• 大手ECサイトのリニューアル — インフラ構築やデータ移行はウォーターフォール、新しいUXデザインの開発はアジャイルで実施。
• モバイルアプリ開発 — コア機能はウォーターフォールで事前に設計し、追加機能はアジャイルで柔軟に対応。

ウォーターフォールとアジャイルは、それぞれ適したプロジェクトが異なります。「どちらか一方が優れている」という考えは誤りであり、プロジェクトの特性に応じて適切な手法を選択することが成功の鍵です。

最近では両者のメリットを組み合わせたハイブリッドアプローチも効果的に活用されています。重要なのは、手法を決めたら固定するのではなく、状況に応じて柔軟に最適な方法を選択できることです。

---

6. 今日からできるアクション

1. WBSを作成し、作業を細分化する
2. マイルストーンを設定し、進捗の節目を決める
3. 計画の変更管理ルールを作り、関係者と共有する

---

次回の記事

次回の第3回では、「リスクマネジメントの実践」をテーマに解説します。

第3回：リスクマネジメントの実践｜「想定外を想定する」ITプロジェクトのリスク管理プロセス

プロジェクトマネジメントシリーズ 記事一覧

• 第1回：プロジェクト管理の本質とは？スケジュール管理を超えた「価値を生むPM」の考え方
• 第2回：プロジェクト計画の立て方｜WBS・スコープ定義・マイルストーンの実務テクニック（この記事）
• 第3回：リスクマネジメントの実践｜「想定外を想定する」ITプロジェクトのリスク管理プロセス
• 第4回：プロジェクト進捗管理のコツ｜「順調です」に潜むリスクを見抜く実践手法
• 第5回：プロジェクトのチームマネジメントとリーダーシップ｜フェーズごとに変わるPMの役割
• 第6回：ステークホルダーマネジメント｜期待値管理・影響度分析・対立解決の実践ガイド
• 第7回：プロジェクトトラブル対応（火消しスキル）｜炎上の兆候発見から収束まで
• 第8回：品質管理とデリバリー｜「動けばOK」ではない、PMが押さえるべき品質の作り込み方
• 第9回：プロジェクト終了と振り返り｜クロージングから学びを次につなげる仕組みづくり
• 第10回：プロジェクトマネジメントスキルの継続的向上｜エンジニアからPMへのキャリアパスと学習戦略