マスタースケジュールとは？作り方・テンプレート・ガントチャートとの違いを実例で解説

プロジェクトが大規模になるほど、「いつ・誰が・何を・どこまでやるか」を一元管理する仕組みが不可欠になる。その中核を担うのがマスタースケジュールだ。しかし現場では「ガントチャートと何が違うの？」「どう作ればいいかわからない」という声が絶えない。本記事では、マスタースケジュールの定義から作成手順、運用のコツまでを実例とともに徹底解説する。

1. マスタースケジュールとは

定義

マスタースケジュール（Master Schedule）とは、プロジェクト全体の工程・マイルストーン・担当・依存関係を一覧化した最上位レベルの計画表のことを指す。個別の作業レベルではなく、フェーズ・工程・成果物単位で大局を把握することを目的としており、プロジェクトマネージャー（PM）やステークホルダーが全体の進捗を俯瞰するための「羅針盤」として機能する。

PMBOKガイド（第7版）においても、スケジュール管理はプロジェクトパフォーマンス領域の重要な構成要素と位置づけられており、マスタースケジュールはその基盤となるドキュメントに相当する。

ガントチャートとの違い

マスタースケジュールとガントチャートは混同されやすいが、役割・粒度・用途が明確に異なる。下表で整理する。

端的に言えば、マスタースケジュールは「森」を見る地図であり、ガントチャートは「木」を見る詳細図だ。理想的なプロジェクト管理では、マスタースケジュールを頂点に置き、その下にフェーズ別ガントチャートや個人タスクリストを連動させる階層構造を組む。

2. マスタースケジュールの構成要素

実務で使えるマスタースケジュールには、最低限以下の要素が含まれていなければならない。

① フェーズ／工程名

プロジェクトを「企画」「要件定義」「設計」「開発」「テスト」「リリース」「運用移行」などのフェーズに分割し、名称を明記する。フェーズ数は一般的に5〜10程度が視認性のうえで適切だ。

② マイルストーン

フェーズの終了点や重要な意思決定ポイントを菱形マーク（◆）や特定の色で目立たせる。例：「要件定義書承認（XX月XX日）」「ユーザーテスト完了（XX月XX日）」。マイルストーンは完了条件（Definition of Done）とセットで定義するとなお効果的だ。

③ 開始日・終了日・期間

各フェーズの開始日と終了日を明記する。期間は営業日ベースで計算し、祝日・長期休暇は事前に除外しておく。

④ 担当組織・担当者

フェーズごとに「誰が主担当か」「誰がレビュアーか」を記載する。個人名だけでなく部門名・チーム名を併記すると、要員変更時の引き継ぎがスムーズになる。

⑤ 依存関係・前提条件

「設計フェーズは要件定義書の承認が前提」「外部ベンダーへの発注は○月○日までに完了」など、フェーズをまたぐ依存関係や前提条件を記載する。これを省略すると、後工程の遅延原因が追えなくなる。

⑥ バッファ

クリティカルパス上に適切なバッファを組み込む。目安は各フェーズの10〜20%が多いが、リスクが高い工程には20〜30%を確保することも珍しくない。バッファをどこに置くかは、プロジェクトの納期制約とリスク評価に基づいて判断する。

⑦ ステータス管理欄

「予定」「進行中」「完了」「遅延」などのステータスを色分けやラベルで表示する列を設けると、進捗報告が格段に楽になる。RAGステータス（Red/Amber/Green）を採用するプロジェクトも多い。

3. 作成手順 ステップバイステップ

以下では、新規システム開発プロジェクト（期間：6か月、チーム規模：15名）を例に、マスタースケジュールの作成手順を示す。

ステップ1：プロジェクトスコープとゴールを確認する

スケジュールを作る前に、何を・いつまでに・どのレベルで完成させるかを明文化する。プロジェクト憲章やスコープ記述書がある場合は必ず参照し、認識のズレを関係者間でなくしておく。この段階でゴールが曖昧なまま日程を引くと、後から根本的な修正が必要になる。

ステップ2：WBS（作業分解構造）でフェーズを洗い出す

プロジェクト全体をWBSで分解し、マスタースケジュールに載せるフェーズ・工程を決定する。マスタースケジュールはWBSのレベル1〜2に相当する粒度で構成するのが一般的だ。詳細タスクはレベル3以下に落とし、別途ガントチャートや詳細スケジュールとして管理する。

実例：6か月のシステム開発プロジェクトのフェーズ構成

1. プロジェクト準備・キックオフ（2週間）
2. 要件定義（4週間）
3. 基本設計（3週間）
4. 詳細設計（3週間）
5. 開発・単体テスト（8週間）
6. 結合テスト・システムテスト（4週間）
7. ユーザー受け入れテスト（2週間）
8. 本番リリース・移行作業（1週間）

ステップ3：所要期間と依存関係を見積もる

各フェーズの所要期間を、過去の類似プロジェクトデータや三点見積もり（楽観値・最頻値・悲観値）を使って算出する。同時にフェーズ間の依存関係（Finish-to-Start が基本）を明確にし、並行して進められる工程がないかを確認する。並行作業を増やすことで全体期間を圧縮できるが、リソースの過負荷や品質リスクとのトレードオフが生じる。

ステップ4：マイルストーンを設定する

各フェーズの終端に「完了条件を満たした成果物の承認」をマイルストーンとして設定する。マイルストーンは日付ではなく「完了条件」で定義するのが鉄則だ。例えば「要件定義完了」ではなく「要件定義書のステークホルダー全員承認取得」と書くことで、完了の定義が曖昧になるのを防ぐ。

ステップ5：リソースと制約を照合する

フェーズごとに必要な人員・スキル・外部リソース（ベンダー・ライセンス等）を洗い出し、現実的に調達可能かどうかを確認する。この段階でリソース不足が発覚した場合は、フェーズの並行化・外部委託・スコープ削減などのオプションを検討し、スケジュールに反映する。

ステップ6：バッファを組み込み、スケジュールを固める

クリティカルパスを特定し、そのパス上にプロジェクトバッファを設置する。TOC（制約の理論）に基づくクリティカルチェーン法を採用するプロジェクトでは、個別タスクのバッファを削除してプロジェクトバッファとフィーディングバッファに集約する方法も有効だ。バッファを「隠し工期」にせず、計画上で明示することが重要である。

ステップ7：レビューと合意形成

作成したマスタースケジュールをステークホルダーにレビューしてもらい、正式に承認を得る。この合意がないまま着手すると、後から「そんな日程は聞いていない」という問題が生じる。承認記録（サインオフシート・議事録）はプロジェクト期間中、必ず保管しておく。

4. よくある作り方の失敗

失敗1：ガントチャートをそのままマスタースケジュールと呼んでいる

詳細タスクが数百行並んだガントチャートを「マスタースケジュール」として経営層に提示しても、全体像は伝わらない。マスタースケジュールはA3用紙1〜2枚に収まる粒度を目指す。詳細はガントチャートに委ね、マスタースケジュールは「要約地図」としての役割を徹底する。

失敗2：バッファなしの「ぎりぎりスケジュール」を組む

楽観的な見積もりだけでスケジュールを組み、バッファを一切設けないケースが後を絶たない。現実のプロジェクトでは要件変更・メンバーの体調不良・外部依存の遅延など、想定外の事象が必ず発生する。バッファのないスケジュールは「最初から遅れることが決まっているスケジュール」と認識すべきだ。

失敗3：マイルストーンの完了条件が曖昧

「〇〇フェーズ完了」とだけ記載し、何をもって完了とするかを明文化していないケース。結果として「PMは完了したと思っているが、ステークホルダーはまだ作業中と認識している」という混乱が生じる。完了条件は必ず書面で合意しておく。

失敗4：作ったら更新しない「化石スケジュール」

プロジェクト開始時に丁寧に作ったマスタースケジュールが、その後一度も更新されないまま放置される問題だ。実態と乖離したスケジュールは意思決定の妨げになるどころか、チームの信頼を失わせる。変更があった際のスケジュール変更管理プロセスを事前に定義しておくことが重要だ。

失敗5：関係者への周知が不十分

PMだけが把握しているマスタースケジュールはチーム全体の行動指針にならない。完成したスケジュールはキックオフ会議や共有ドライブで全員に周知し、誰でもアクセスできる状態を維持する。「見えないスケジュール」は存在しないのと同じだ。

5. 運用のコツ

コツ1：「定期レビュー」の仕組みをあらかじめ組み込む

マスタースケジュールの見直しタイミングをあらかじめカレンダーに組み込んでおく。フェーズ完了時・月次ステアリングコミッティ・重大なリスク顕在化時などが更新タイミングの目安だ。「何かあったら更新する」では更新が後手に回る。

コツ2：ベースラインとの差分を可視化する

承認済みのスケジュールをベースライン（基準線）として保存し、現在の計画との差分をSV（スケジュール差異）として定期的に計測する。EVM（アーンドバリューマネジメント）を導入しているプロジェクトでは、SPI（スケジュール効率指数）を併用することで客観的な進捗状況を把握できる。

コツ3：「信号機方式」でステータスを直感的に伝える

RAGステータス（Red＝遅延・重大リスク、Amber＝注意・軽微な遅れ、Green＝正常）を各フェーズに付与することで、報告資料の作成工数を削減しつつ、ステークホルダーへの情報伝達を迅速化できる。色覚多様性への配慮として、色だけでなくアイコンや文字も併用することを推奨する。

コツ4：ツールを目的に合わせて使い分ける

マスタースケジュールはExcelやGoogleスプレッドシートで十分なケースも多い。一方、依存関係の管理やリソース平準化まで行うならMicrosoft ProjectやJira、Asanaなどの専用ツールが有効だ。ツールの習熟コストとチームのITリテラシーを考慮し、「使われるツール」を選ぶことが肝要だ。

コツ5：変更管理プロセスとセットで運用する

スケジュールの変更は必ず変更管理プロセスを通じて行う。変更内容・変更理由・影響範囲・承認者をChangeログに記録することで、「なぜスケジュールが変わったのか」の履歴を残せる。この履歴は次回プロジェクトの見積もり精度向上にも役立つ貴重なナレッジとなる。

コツ6：マスタースケジュールを「コミュニケーションツール」として活用する

マスタースケジュールの最大の価値は「計算の正確さ」ではなく、関係者全員が同じ地図を見て話せることにある。定例会議の冒頭でマスタースケジュールを投影し、「今ここにいる」というコンテキストを共有する習慣をつけるだけで、会議の質と意思決定のスピードが劇的に向上する。

よくある質問（FAQ）

Q1. マスタースケジュールとプロジェクト計画書の違いは何ですか？

プロジェクト計画書（Project Management Plan）はスコープ・品質・リスク・コミュニケーションなどの管理方針を包括的に記述した文書であり、マスタースケジュールはその一部として位置づけられます。マスタースケジュールは「時間軸」に特化した計画表であり、プロジェクト計画書の中のスケジュール管理計画と連動して使用されます。

Q2. マスタースケジュールはどのツールで作るのがベストですか？

チーム規模や複雑さによって最適なツールは異なります。小規模プロジェクトではExcel・Googleスプレッドシートで十分です。中〜大規模でリソース管理や依存関係の自動計算が必要な場合は、Microsoft Project・Smartsheet・Asana・Notionなどが候補に挙がります。大切なのはツールの機能よりも「チームが継続的に更新・参照できるか」です。

Q3. アジャイル開発でもマスタースケジュールは必要ですか？

はい、必要です。アジャイル開発ではスプリント単位の詳細計画をチームが自律的に管理しますが、経営層やステークホルダーへの報告、予算計画、リリースロードマップの提示には全体感を示すマスタースケジュールが不可欠です。ただしアジャイルの場合は「ローリングウェーブ計画法」を採用し、直近のフェーズは詳細に、遠い将来のフェーズは粗い粒度で計画するアプローチが現実的です。

Q4. マスタースケジュールのテンプレートはどこで手に入りますか？

Microsoft OfficeテンプレートギャラリーやGoogleスプレッドシートのテンプレートギャラリーに無料のスケジュールテンプレートが多数用意されています。また、PMI（プロジェクトマネジメント協会）の公式サイトや各種PM関連書籍の付録としても提供されています。ただしテンプレートはあくまで出発点であり、自プロジェクトの特性に合わせてカスタマイズすることが重要です。

Q5. スケジュールが大幅に遅延した場合、マスタースケジュールはどう修正すべきですか？

まず遅延の根本原因を特定し、残りのフェーズへの波及影響を分析します。その後、①スコープ削減（機能・成果物の優先順位付け）、②リソース追加（クラッシング）、③並行作業の増加（ファストトラッキング）、④納期延伸の交渉、のいずれかまたは組み合わせでリカバリー計画を策定します。修正案はステークホルダーの正式承認を得たうえでベースラインを更新し、変更管理ログに記録してください。一方的にスケジュールを書き換えるだけでは信頼を失います。