スケジュール管理の“理想と現実”｜WBSからマイルストーンまでの正しい流れ

 
システム開発において、スケジュール管理は「わかっているようで実は難しい」領域です。
WBS・ガントチャート・マイルストーンといった基本を知っていても、
現場では理想どおりに進まず、後になって問題が表面化することも少なくありません。
 

はじめに

こんにちは。クラウドソリューショングループのmoro.tです。
これまで複数のWebシステム開発に携わり、要件定義～製造・テストまで幅広い工程を経験してきました。
特に直近の案件では、PLとしてスケジュール策定やリスク管理を担当し、「理想どおりに進まないスケジュール」と何度も向き合うことになりました。
この記事では、私自身が実務の中で感じた スケジュール管理の理想と現実、そしてWBS・ガントチャート・マイルストーンをどう使い分ければよいのかについて、失敗談も交えながらまとめています。

• スケジュール管理の3つの基礎：WBS・ガントチャート・マイルストーン（役割と関係）
• 理想のスケジュール管理（あるべき姿）
• 現場でよく起きる実際のスケジュール管理
• よくある失敗とその原因：私が実際に経験した2つの落とし穴
• スケジュール管理の最重要ポイント
• まとめ

スケジュール管理の3つの基礎：WBS・ガントチャート・マイルストーン（役割と関係）

まず、この3つは「別々の管理手法」というより、スケジュール管理を構成する3要素として関連しています。

① WBS（Work Breakdown Structure）

→ 仕事を抜け漏れなく分解するための設計図

• プロジェクト全体を細かいタスクに分解する
• 抜け漏れを防ぐための構造化されたリスト
• 「何をやるか」を正式に定義する段階

用途:

プロジェクト開始時のタスク洗い出し、スコープ確認、見積もりの基盤。

② ガントチャート

→ WBSで分解した作業を時間軸に並べた実行計画

• タスクごとの期間、順序、依存関係を見える化
• 工数配分やリソース計画の調整に使う

用途:

プロジェクトの進行管理、調整、リスク発見、タスク同士の衝突確認。

③ マイルストーン

→ プロジェクトの節目を示すチェックポイント

• 要件定義完了、設計完了、リリース判定など「主要な合意点」
• 期間ではなくポイントで管理する
• 関係者間の認識合わせにも使われる

用途:

関係者間の合意形成、進捗確認の基準、遅延検知。

【まとめ：3つの関係性】

• WBS …「何をやるか」
• ガントチャート …「いつやるか」
• マイルストーン …「どこが重要な節目か」

つまり、1 → 2 → 3 の順番で使うことで、初めて破綻しにくいスケジュールが作れるという関係です。

理想のスケジュール管理（あるべき姿）

本や研修で語られる「理想のスケジュール管理」はこんな状態です。

• WBSで全体が漏れなく整理されている
• ガントチャートは常に最新
• リスクは事前に検知される
• マイルストーンで判断が適切に行われる
• 関係者が共通のスケジュールを見ている
• 変更は正しく管理されている

言い換えると、

「プロジェクトが計画どおりに進み、想定外が最小化された状態」です。

現場でよく起きる実際のスケジュール管理

対して、実際の現場ではこんなことが起きやすいです。

ケース①：WBSがただの「箇条書きのToDo」になりがち

• 粒度が統一されていない
• 担当者ごとに認識が違う
• 抜け漏れに気づくのは作業が始まってから

→結果：後工程での手戻りや遅延につながる

ケース②：ガントチャートが初期だけ綺麗問題

• 更新されない
• 進捗報告が口頭ベースになり形骸化
• リスクの早期発見ができない

→結果：気づいたときには遅延が発生している状態に陥る

ケース③：マイルストーンが「日付があるだけ」問題

• 判断基準が曖昧
• どこまで終わったら完了なのか定義されていない
• 関係者の合意形成が遅れる

→結果：節目でのズレが蓄積し、後半で爆発する

よくある失敗とその原因：私が実際に経験した2つの落とし穴

ここでは、私が実際にプロジェクト現場で経験した「スケジュール破綻の典型パターン」を2つ紹介します。同じようなミスを避けるためのヒントになれば幸いです。

失敗談①：概算見積もりの根拠を確認しないままスケジュールを作成してしまった

私が PL として別の案件に途中参画した際、
すでに開発リーダーから「本開発の概算工数」を提示されており、私はその数字をそのままカレンダーに当て込んでスケジュールを作りました。
参画直後でキャッチアップに必死だったこともあり、
「なぜその工数になるのか？」
「どの要素にどの程度の時間が必要なのか？」
などの根拠確認を怠ってしまったのです。
結果として、顧客から
「この工数の理由は？なぜその期間が必要？」
と聞かれた際に、自分の言葉で答えられないという状況に陥りました。
この経験から学んだのは、
工数見積もりの根拠を理解していないスケジュールは“説明できないスケジュール”であり、PL の責任を果たせないということです。

失敗談②：基本設計・詳細設計での追加工数を軽く見て、後半でスケジュール破綻

別のケースでは、
要件定義時にガントチャートでスケジュールを作り、顧客と合意済みでした。
しかし基本設計や詳細設計の段階で：

• 追加要望の発生
• 要件達成のために必要な作業が増加
• 想定より工数がかかる箇所が判明

といった変更が多く発生。
ただ、基本設計・詳細設計フェーズとしては期間内で収まっていたため、私はスケジュール調整を行いませんでした。
しかし当然ながら、その影響は後工程にも及びます。
そのまま実装フェーズに入った結果、
「設計時の増加工数が実装にも影響している」
と現場で判明し、実装中に全体スケジュールを見直す必要が生じてしまいました。
つまり私は、
設計の遅れは “設計フェーズ内の話” で終わらない
という当たり前の原則を見落としていたのです。

スケジュール管理の最重要ポイント

数多くの経験から言えるのは、次の3つが最重要ということです。

① WBSは丁寧に作る（8割はここで決まる）

WBSが甘いと、その後の管理すべてが破綻します。

「分解するのが目的」ではなく

抜け漏れを無くし、全体像を正しく描くことが目的。

② スケジュールは更新して初めて意味がある

ガントチャートは作った瞬間が最良になりがち。

本当に重要なのは 運用。

• リスク検知
• 調整
• リカバリー
• 変更管理

これらができて初めてスケジュール管理。

③ マイルストーンは判断基準まで定義する

ただ日付を置くだけでは価値が半減。

「何ができていたら完了？」

を必ず明文化する。

まとめ

スケジュール管理は「理想どおりにやらないと意味がない」というわけではありません。

むしろ、多くの現場は理想と現実の間で揺れています。

だからこそ、

• WBS→ガント→マイルストーンの正しい流れを理解すること
• 最低限押さえるべきポイントを明確にすること
• 現場特有の事情に合わせて柔軟に運用すること

これができれば、

「破綻しないスケジュール管理」 に近づけます。