はじめに
発注側が最低限知っておくべきプロジェクト管理の「型」では、進捗確認の定例化をベンダーコントロールの基本として紹介しました。この定例化を機能させるために欠かせない道具が、マスタスケジュールです。
SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応してきた経験から、マスタスケジュールを発注側自身が持つべき理由と、運用のポイントを解説します。
ベンダー提示のスケジュールをそのまま使わない
プロジェクトが始まると、ベンダーからマスタスケジュール（案）が提示されることがほとんどです。ここで多くの発注側担当者がやってしまうのが、提示されたスケジュールをそのまま正としてしまうことです。
ベンダーが引くスケジュールは、当然ベンダー側の都合（要員のアサイン状況、他案件とのリソース競合など）を踏まえて組まれています。これ自体は悪いことではありませんが、発注側には発注側の都合があります。経営会議への報告タイミング、予算執行のサイクル、他システムとの連携タイミングなど、ベンダーからは見えない制約です。
提示されたスケジュールを鵜呑みにせず、自社側の制約と突き合わせた上で、自社としてのマスタスケジュールを別途持っておくことをおすすめします。両者にズレがあれば、プロジェクトの早い段階で調整すべき論点として扱えます。
月次粒度で「全体感」を管理する
発注側がスケジュールを管理するとき、やりがちな失敗が細かく管理しすぎることです。ベンダーが作る週次・日次のタスク一覧（WBS）まで発注側が逐一追いかけようとすると、情報量が多すぎて、かえって「今プロジェクト全体がどういう状況か」が見えなくなります。
発注側が持つべきマスタスケジュールは、フェーズ・主要マイルストーン単位の月次粒度で十分です。詳細なタスク管理はベンダー・現場のPMに任せ、発注側は「今どのフェーズにいて、次のマイルストーンまでの進捗はどうか」という全体感の把握に専念する方が、結果的に的確な意思決定ができます。
進捗率は「申告」ではなく「残作業」で確認する
進捗報告の受け方については別の記事でも触れましたが、マスタスケジュール上でも同じ注意が必要です。ベンダーから「進捗80%です」と報告されても、それが残りの20%にどれだけの作業量が残っているかを表しているとは限りません。経験的に、進捗報告の数字は終盤になるほど動かなくなる傾向があります。
マスタスケジュール上では、経過期間に対して進捗率が見合っているかをガントチャート上で視覚的に確認することをおすすめします。期間の経過に対して進捗率の伸びが鈍い項目は、定例会で深掘りして確認すべき対象です。
「見える化」されていなければ、適切な意思決定はできない
ここまでの話をまとめると、結局のところ一つの原則に行き着きます。意思決定は、状況が見えていることが前提になるという原則です。
タスクを1件ずつ眺めているだけでは、「プロジェクト全体として、今どれくらい危険な状態なのか」を判断できません。期限を過ぎているタスクが何件あるのか、着手すべき時期を過ぎても手つかずのタスクがどれだけ積み上がっているのか——こうした情報が数字として可視化されて初めて、「今すぐ経営層にエスカレーションすべきか」「もう少し現場の対応を見守るべきか」という意思決定ができます。
逆に言えば、個別のタスクの遅れをいくら細かく把握していても、それが全体としてどの程度の危険度を意味するのかが一覧で見えなければ、対応の優先順位をつけられません。発注側がマスタスケジュールを持つ目的は、単にタスクを並べることではなく、プロジェクト全体の危険度を一目で判断できる状態を作ることにあります。
まとめ
マスタスケジュールは、ベンダーに作ってもらうものではなく、発注側自身が持つべき管理の道具です。ベンダー提示のスケジュールを鵜呑みにせず、月次粒度の全体感で管理し、進捗率は申告ではなく経過期間とのギャップで確認する。そして何より、個別のタスクではなく全体の状況を可視化し、意思決定に使える状態を保つ。この4点を押さえるだけで、スケジュール遅延の兆候にかなり早く気づけるようになります。
実際に使っているマスタスケジュールのテンプレートは、noteで配布しています。
執筆者プロフィール：SIerで4年半、ITコンサルファームで4年半、要件定義からベンダーマネジメントまで一貫して対応。基幹システム刷新・DX推進プロジェクトに多数従事。
コメント