監修：山根一城（株式会社ポテンシャライト代表取締役CEO ／ 業界20年）
マイルストーン スケジュールとは、プロジェクトの進行を日々のタスクではなく、意思決定や成果物の確定といった重要な節目（マイルストーン）で区切って表した全体計画のことです。作業の一つひとつを細かく並べる詳細工程表とは別に、関係者が「どの時点で何が決まっていればよいか」を共有するために使われます。要件確定、設計完了、テスト開始、本番移行などが代表的な節目にあたります。
マイルストーン スケジュールの目的は、プロジェクトに関わる人たちが細部に埋もれずに全体の流れをつかめるようにすることです。詳細なタスクを数百行並べたガントチャートは、作業者には必要でも、経営層や顧客側の責任者には読みにくいことが少なくありません。節目だけを抜き出して並べることで、誰が見ても進捗の大枠と今後の山場が把握できます。
節目は、おおむね二つの性格に分かれます。一つは成果物が確定するタイミングで、要件定義書の承認、基本設計書のレビュー完了などがこれにあたります。もう一つは意思決定のタイミングで、次工程へ進む判断（いわゆるゲート）や、ステアリングコミッティでの投資継続の判断などが含まれます。
作成の主役はPM（プロジェクトマネージャー）です。まず、プロジェクト憲章や計画書で合意した全体のゴールと納期を起点に置きます。そのうえで、ゴールから逆算して「ここが遅れたら間に合わない」という節目を抜き出していきます。前から順に積み上げるより、終わりの日付から引いて配置するほうが、無理のある計画に気づきやすくなります。
次に、各節目に判定条件を添えます。「設計完了」とだけ書くのではなく、「基本設計書が顧客レビューを通過した状態」のように、達成したと言える条件を具体的に決めておきます。条件があいまいな節目は、後で「終わった／終わっていない」の水掛け論になりがちです。
節目どうしのつながりも確認します。要件が固まらないと設計に入れない、といった前後関係を押さえ、クリティカルパス上の節目を特に目立たせておくと、遅れが全体に響く箇所が一目で分かります。最後に、この一枚をキックオフやステアリングコミッティで共有し、関係者の合意を取ってから運用に入ります。
よくあるつまずきは、節目を置きすぎて詳細工程表と変わらなくなることです。十数行で全体が読めるのが利点なのに、細かい作業まで節目にしてしまうと、かえって要点が埋もれます。節目は「そこがずれたら計画全体を見直す」レベルの事柄に絞るのが扱いやすい目安です。
達成条件を決めずに日付だけ置くのも、ありがちな失敗です。条件がないと、形だけ資料を出して「完了」と宣言され、実際には中身が固まっていないという事態が起きます。節目の判定は、できれば作成者とは別の人、たとえば顧客側の承認者やレビュー担当が行う形にしておくと、甘い自己申告を防ぎやすくなります。
マイルストーン スケジュールは、似た言葉と混ざりやすいので、役割の違いで整理しておくと迷いにくくなります。軸は「粒度」と「用途」です。
詳細スケジュール（ガントチャートやWBSから展開した工程表）は、作業の着手日・完了日・担当・依存関係まで細かく並べたもので、実作業を回すための道具です。マイルストーン スケジュールは、そこから節目だけを抜き出した要約版にあたり、報告や合意形成に向いています。両者は対立するものではなく、詳細側の節目と要約側の節目が同じ日付を指すように、整合を保って併用します。
クリティカルパスは、遅れが全体の納期に直結する作業の連なりを指す考え方で、どの節目を特に守るべきかを判断する材料になります。計画書やプロジェクト憲章は、プロジェクト全体の目的・体制・前提を定める文書で、マイルストーン スケジュールはその中の時間軸の部分を一枚で表したもの、と位置づけると関係がつかみやすくなります。
マイルストーン スケジュールを組める力は、PM（プロジェクトマネージャー）としての守備範囲の広さを示しやすい部分です。細かいタスク管理は進捗管理者やリーダーに任せられても、全体の節目を設計し、経営層や顧客に筋道立てて説明する役割は、立場が上がるほど求められます。逆算で節目を置き、達成条件を定め、遅れが全体へ及ぶ因果を一枚で語れると、報告や意思決定の場での信頼につながります。
転職を検討する段階では、単に工程表を引けることより、どの節目をどんな条件で守り、遅延をどう食い止めたかを具体的に語れるかが見られます。担当したプロジェクトで、節目の置き方や判定の工夫をふり返っておくと、面接で自分の関与の深さを示す材料になります。
マイルストーン スケジュールと詳細工程表は、どちらを先に作りますか。
多くの場合、全体の節目を先に置いてから詳細を埋めていきます。ゴールと納期から逆算して重要な節目を決め、その骨格に沿って各作業の着手日や依存関係を展開すると、無理のある計画に早く気づけます。両者は役割が違うので、片方だけで済ませず併用するのが扱いやすい形です。
節目はどのくらいの数が適切ですか。
決まった数はありませんが、全体が一目で読める程度に絞るのが目安です。要件確定、設計完了、テスト開始、本番移行のように、そこがずれたら計画全体を見直すレベルの事柄に限ると、要点が埋もれにくくなります。細かい作業まで節目にすると、詳細工程表と変わらなくなります。
節目が達成されたかどうかは、どう判断しますか。
日付の到来ではなく、あらかじめ決めた達成条件を満たしたかで判断します。たとえば「設計完了」なら、基本設計書が顧客レビューを通過した状態、のように条件を具体化しておきます。判定は作成者以外、たとえば承認者やレビュー担当が行う形にすると、甘い自己申告を避けやすくなります。