マスタースケジュールの書き方と合意形成の極意｜システム開発を成功させる「鳥の目」の視点

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

PMやリーダーなら、一度はこのような冷や汗をかく経験をしたことがあるのではないでしょうか。システム開発を成功に導くためには、現場のタスクを管理する前に、ステークホルダー全員と「いつ、どこに到達すべきか」という大きな流れを合意しなければなりません。

そのために必要なのが、全体を俯瞰する「マスタースケジュール」です。

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

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

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

スケジュール管理で失敗する最大の原因は、「鳥の目」と「虫の目」を混同してしまうことです。

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

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

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

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

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

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

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

【代表的なマイルストーンの例】

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

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

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

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