マスタスケジュールの作成手順と管理方法 – マスタスケジュールを作成する理由の解説

はじめに

マスタスケジュールは、プロジェクトを計画するうえで不可欠なドキュメントです。
経営側へのプロジェクト説明から現場のスケジュール作成まで幅広く活用されます。
このマスタスケジュールが適切に運用されていないと、プロジェクトを間違った方向にミスリードする可能性があります。

しかし、マスタスケジュールが形骸化しているプロジェクトも少なからず存在します。
そのようなプロジェクトでは進捗遅延が出ていないか判断できず、感覚でプロジェクト運営している状況も珍しくありません。

そうならないためにも、マスタスケジュールを正しく運用するためのポイントについて解説します。
マスタスケジュールの作成については、別記事「スケジュール・ベースライン」を参考にしてください。

なぜマスタスケジュールを利用するのか

マスタスケジュールはプロジェクトの予定と実績を把握するために使用しますが、その理由をさらに分解すると、次の理由が考えられます。

全体像の把握

スケジュール管理する場合、主にマスタスケジュールと詳細スケジュールの２つを利用します。
詳細スケジュールはWBSのタスクごと予定と実績を設定することで作業進捗を管理します。
開発メンバが具体的な作業計画を立てるためには必要ですが、管理粒度が細かすぎるためプロジェクトの全体像が見えません。

マスタスケジュールでは詳細スケジュールよりも粒度が荒く、開発メンバの作業を管理するには向いていませんが、プロジェクト全体の計画を俯瞰することができます。
詳細スケジュールとしても、その計画がプロジェクト全体の計画に収まっているか確認するためにも必要です。

次工程を進めるための準備、要員調達を始める時期など、プロジェクトの行動計画にもマスタスケジュールを活用します。

アクティビティ依存関係の明確化

工程単位での作業間の依存関係を確認します。
作業工程には順序があり、工程開始条件や終了条件などの制約があります。
例えば、基本設計が終わっていないのに詳細設計を完了することができないケースが該当します。

特に入り組んだ工程のプロジェクトであったり、複数の会社やチームが連携しながら推進するプロジェクトであれば、より工程ごとのアクティビティ依存関係を明確にする必要があります。
他プロジェクトで構築している機能との連携（例えば外部インターフェイスなど）を確認する場合、マスタスケジュールを見て、連携時期やタイミングについて確認するのにも利用します。

マイルストーンの明確化

マイルストーンはプロジェクトに影響を与える、日程を遅らせることができないイベントのことです。
プロジェクトは、マイルストーンと整合がとれるようにマスタスケジュール調整します。

このマイルストーンはクライアントや外部ベンダなどのステークホルダーに影響を与えることが多いです。
そしてマイルストーンを変更することは、費用的損失につながることが多いため、マイルストーンを変更する場合の調整は難航します。
ステアリングコミッティのように経営層と調整することもあります。

クリティカルパスの明確化

プロジェクトの各工程を進めていく中で、遅延するとプロジェクト全体のスケジュールに影響が出る作業経路をクリティカルパスと言います。

例えば、アプリ開発の基本設計→詳細設計→製造→・・・のような流れは、他タスクの完了待ちが発生することなく進んでいきます。
この工程のどこかで遅延が発生したらプロジェクトのスケジュール遅延となります。

それとは別にサーバ構築作業があったとして、アプリ開発の詳細設計工程あたりで作業予定とします。
ただアプリ開発の単体テスト完了までにサーバ構築が間に合っていれば、それまでにスケジュール的余裕があることになります。
これはクリティカルパスにはなりません。

クリティカルパスを把握することで、作業工程の優先順位を決めるための判断材料になります。
プロジェクト遅延が発生した場合、クリティカルパスの作業を重点的に要員追加したり調整することで、プロジェクトのスケジュールへの影響を最小限します。
そのためにもマスタスケジュールは必要になります。

詳細スケジュールのインプット情報

マスタスケジュールと詳細スケジュールは連動します。
詳細スケジュールを作成する場合、マスタスケジュールの期間内に収まるように要員を配置したりタスク割り当てを行います。
そのため、マスタスケジュールを変更するような事態になると、詳細スケジュールの計画を全体的に見直すことになります。

逆に詳細スケジュールの進捗状況によってはマスタスケジュールを変更する場合もあります。
しかし、それはプロジェクト全体のスケジュール見直しであり、プロジェクト遅延につながる行為です。
そのため、詳細スケジュールの実績状況を理由にマスタスケジュールを変更するのは容易に行ってはいけません。

マスタスケジュールの作成手順

マスタスケジュール作成の手順について解説します。
ここでは新規でマスタスケジュールを作成する場合の流れについて解説します。
もし、過去に類似プロジェクトの実績がある場合、その時のマスタスケジュールをベースにしてカスタマイズすると良いでしょう。

マスタスケジュールを作成するときの注意点として、できるだけシンプルに作ることを心がけます。
スケジュール表は用紙１枚に収まる程度となるように情報量を抑えます。
あれもこれもと情報を入れていくとスケジュールが複雑になり、頭を使わないと理解できない資料となります。
複雑なスケジュールは見る人によって捉え方が変わるので誤解のもとになります。

管理対象の工程を設定する

まずスケジュール管理の軸である工程を設定します。
縦軸に設計や製造などの工程を記載するのが基本ですが、スケジュールとして意識すべき作業があれば、各工程間との比較で使用できるので設定してもよいです。
ただしWBSのように設定が細かすぎると全体像が分かりにくくなるので、作成者が人へ説明しやすいレベルでの粒度にします。

From-Toのように期間があるわけでなく、イベントなど特定日に発生する予定はマイルストーンになるので、赤枠の縦軸には含めません。

マイルストーンを設定する

次に設定するのはマイルストーンです。
マイルストーンとはプロジェクト進行における重要目標地点です。
わかりやすく言うとプロジェクトで発生するイベントや節目を指します。
プロジェクト開始のキックオフや本番リリース、運用開始もマイルストーンと言えます。

マイルストーンにはスケジュール作成の中で調整できるものと、基本的に変更できないものがあります。
変更できないのは、プロジェクトの前提事項であったり、他会社との調整や契約といった対外制約などの理由が挙げられます。
この変更できないマイルストーンに合うようスケジュールを検討することになります。

スケジュール線を設定する

マイルストーンを設定したらスケジュール線を設定します。
とはいえ、ただ線を引けばよいわけでなく、プロジェクト遂行できる現実的なスケジュールを設定する必要があります。
その流れは次の通りです。

クリティカルパスを見極める

クリティカルパスとはスケジュールの軸となる工程の流れであり、工程遅延の発生がプロジェクト遅延に直結する作業を指します。
図の例でいうと要件定義から設計、製造、テストの流れがクリティカルパスに該当します。
クリティカルパスの工程が見えたら、ざっくりでよいのでスケジュール線を引きます。
この線はたたき台として使用するためであり、後から精緻化します。

リスク対策を先行する

リスク対策の作業を先行することで不足の事態に備えます。
プロジェクト計画時にリスク計画を策定しますが、その中で想定されるリスクのうち予防策として実施すべき作業をスケジュールに含めます。
そして、そのリスク対策の作業は速いタイミングで設定します。
図の例では、開発環境が不明瞭なプロジェクトのためプロトタイプを作成しています。
これにより製造時に設計したプログラムが想定どおり動かない、というリスクを回避しています。
その結果、どうしても線が合わない場合は要員数が足りなかったり、マイルストーンの設定に無理がある場合があります。

要員山積みとマイルストーンを調整する

大まかなスケジュールを設定したら、要員山積みを作成しながら線を精緻化します。
要員山積みは縦軸に要員、横軸に月単位の日付を設定し、月ごと作業工数を算出します。
この作業工数と各工程の所要工数を比較することで、スケジュール線の期間が決まります。
その線とマイルストーンを比較しながら予定を組みなおします。
その場合は要員調整したり、マイルストーンの見直しをクライアントと相談するなどの対策をします。

ステークホルダーとの調整

マスタスケジュールでスケジュール線まで作成できたら、その内容で問題ないかステークホルダーに確認します。
ステークホルダーの合意を取って初めてマスタスケジュールとして有効となるので、確認漏れがないように注意します。
プロジェクト推進中にマスタスケジュールを変更する場合、プロジェクト計画変更となるので上位層やクライアントの承認を得る必要があります。

マスタスケジュールの管理方法

ここではマスタスケジュールを管理するためのポイントについて解説します。

スケジュールの最新化

マスタスケジュールはプロジェクトの道標でありバイブル的存在なので、常に最新化されていることが大切です。
そのためにもマスタスケジュールを最新化する運用ルールを定義する必要があります。

本解説の前段で記載しているように、マスタスケジュールの変更はプロジェクト進行に大きく影響を与えます。
そのため変更を行う場合はプロジェクト責任者など全体統括している人の承認が必要になります。
たとえWBSで遅延発生したとしても、リーダが勝手に変更してはいけません。

そのためマスタスケジュールを変更するための運用フローが必要になります。
誰が起案し、承認するのか明確にするなどマスタスケジュールを更新する手順を整理します。

スケジュール変更時の調整

マスタスケジュールを変更する場合、以下の点に注意して整合性を確認します。

• マイルストーンへの影響
• クリティカルパスへの影響
• コスト、スコープへの影響
• WBSへの影響
• 要員が確保されているか
• リスク対策の確認

特にマイルストーンについては、クライアントや他チームに影響を与えるため慎重に調整します。

マスタスケジュール変更が発生する事態が発生した場合、プロジェクトオーナーや上位の関係者に報告します。
状況によってはステアリングコミッティを開催します。
経営判断の結果、スケジュール変更ではなく要員増加や、要件の削減といった対策になるかもしれません。

スケジュール管理の注意点

マスタスケジュールの取り扱いにおける注意点です。
よく、クライアント向きと内部向けでスケジュールの２種類が存在しているプロジェクトがあります。
理由としては、クライアントなど相手への報告内容と実態が乖離しているケースが多いようです。

プロジェクト都合でやむを得ない場合もあると思います。
とはいえ「原則、スケジュールの２重管理は危険でありNG」です。
２重管理すると、正常なプロジェクト運営が困難になります。

最初はそれなりに上手く進めているように感じますが、プロジェクト後半で進捗状況に不整合や辻褄が合わない状態になる可能性があります。
何か一つトラブルが発生すると収拾がつかなくなり、手の打ちようがない事態になります。
その結果、嘘に嘘を重ねる結果となるでしょう。
そして帳尻を合わせるためにメンバに無理な作業を強いてスケジュールを死守させるようになります。

スケジュールの２重管理が必要になるのは、多くが報告先の相手と正直ベースで会話できるほど関係構築が進んでいない可能性があります。
その場合、まずは相手と正しくコミュニケーションが取れるような関係作りが最優先となるでしょう。
もし相手側の性格や考え方に起因して上手くコミュニケーションが取れなければ、上司や上層部と相談するなど改善に向けた対策を検討するべきです。

もし、どうしてもスケジュールを２重管理するのであれば、それぞれのスケジュールの整合を確認することも含めてスケジュール管理する要員を割り当てる必要があります。
それくらい、２重管理の運用は難しいことを理解しましょう。