マスタースケジュールの書き方｜炎上を防ぐ「顧客との合意形成」3ステップ（システム開発）

「プロジェクトの全体像が見えないまま、なんとなくWBSを書き始めてしまった･･････」
「納期間際になって、顧客から『そんなの聞いていない』と調整を拒否された･･････」

PMやリーダーなら、一度はこのような冷や汗をかく経験をしたことがあるのではないでしょうか。

システム開発を成功に導くためには、現場の細かなタスク管理を始める前に、ステークホルダー全員と「いつ、どこに到達すべきか」という大きな流れを合意しなければなりません。そのために必要なのが、全体を俯瞰するマスタースケジュールです。

本記事では、システム開発の現場で培われた「マスタースケジュールの書き方」と、プロジェクトを迷わせないための「合意形成のポイント」を実践的に解説します。

※本記事は、シリーズ「現場で迷わない！システム開発スケジュール作成の極意」の【第1回：マスタースケジュール編】です。

マスタースケジュールは「旅程表」、WBSは「持ち物リスト」

スケジュール管理で失敗する最大の原因は、「鳥の目」と「虫の目」を混同してしまうことです。まずはそれぞれの役割の違いを明確にしましょう。

マスタースケジュールは、いわば「いつ、どこへ行くか」を決める旅程表です。これがないままWBSという持ち物リストを作り始めても、何が必要で何が不要かは判断できません。まずは、プロジェクトの動かせない外枠を固めることから始めましょう。

【想定プロジェクト】販売管理システム（注文・出荷管理機能）の新規構築。要件定義フェーズが完了し、具体的な機能を実装していく段階を想定します。

いきなり線表を引くのは禁物です。まずは、スケジュールを縛る前提条件と制約条件を洗い出します。ここを曖昧にすると、後からスケジュールが破綻します。

計画を立てる上での仮定です。これが崩れると計画全体を見直す必要があります。

自分たちの努力では変えられない制限です。

外枠が固まったら、具体的なスケジュールに落とし込みます。ここでは細かすぎないことが成功の秘訣です。

「要件定義」「設計」「開発」「テスト」「移行」といった大きな工程を月単位・週単位の横軸に並べます。そして、各工程の終わりにマイルストーン（主要な節目）を置きます。

プロジェクトが遅れる最大の要因は顧客側のボールが止まることです。以下のタスクを線表に組み込み、顧客の責任範囲を可視化します。

「この承認が降りないと、次の工程の開発に着手できない」といった依存関係を矢印などで繋ぎます。これにより、どのマイルストーンが1日でも遅れると納期に直結するのか（クリティカルパス）を全員が認識でき、リスクへの警戒感が高まります。

マスタースケジュールを単なる予定表にしないためのコツがあります。

全体を1枚（1画面）にまとめる
詳細にこだわりすぎず、パッと見て現在地とゴールが直感的に伝わることが重要です。経営層との合意形成にはこの一覧性が欠かせません。
ベースラインを固定する
最初に合意した計画をベースラインとして残しておきましょう。遅延が発生した際に、当初の予定からの乖離を客観的に比較し、対策を練るためです。
変更を前提にする
計画はあくまで仮説です。想定外の事態が起きた際、その影響範囲を即座に特定し、ステークホルダーと再合意するためのベースとして活用しましょう。