マイルストーンの決め方｜日付だけでなく通過条件と証跡をそろえる
「設計完了」と予定表に書いてあっても、ファイルができた日なのか、レビューを終えた日なのか、承認された日なのかが違うと、次の工程は安心して始められません。マイルストーンには日付だけでなく、通過条件と判断に使う証跡を置きます。
ここでは、工程をまたぐ節目の決め方を解説します。実在の案件を再現したものではなく、説明用の表です。本番リリースの安全確認や個別の品質基準は、対象システムに合わせて別途定める必要があります。
節目と、その前に行う作業を分ける
マイルストーンは「この状態へ到達した」と判断する節目です。「レビューを実施する」は作業、「合意した要件を承認する」は節目として整理できます。レビュー会議が終わっても重大な未決が残れば、要件を確定したことにはなりません。
節目を細かく増やしすぎると、通常のタスクと区別できなくなります。後続工程の開始、外部への約束、費用・体制の判断など、次の動き方が変わる箇所を優先します。
条件・証跡・判断者を一組にする
| 節目 | 通過条件の例 | 証跡 | 判断する役割 |
|---|---|---|---|
| 要件の確定 | 対象範囲と例外条件を合意、重大な未決を解消 | 要件一覧の対象版、合意記録 | 業務責任者 |
| 設計の確定 | 必須のレビュー指摘を処置、実装可能性を確認 | 指摘管理表、対象設計版 | 技術責任者 |
| 受入確認の完了 | 合意した受入条件を満たし、残事項の扱いを判断 | 確認結果、残事項と承認 | 受入権限者 |
| 運用移管 | 保管先、権限、連絡経路を後任が確認 | 引き継ぎ確認表 | 運用責任者 |
通過条件は、担当者が自分の気分で「大丈夫」と言うためのものではありません。判断者が同じ材料で確認できる状態を目指します。「品質が良い」「ほぼ完成」といった言葉は、具体的な確認項目へ置き換えます。
すべての証跡を一つのファイルへ詰める必要はありません。条件ごとに保管先と対象版をリンクし、判定会議で迷わず参照できるようにします。古い版の承認を、最新版の承認として使わないことも点検します。
未達のときの扱いを、予定日前に決めておく
予定日が来たからという理由で、条件を満たしていない節目を「完了」にしないようにします。未達なら、延期、条件付き通過、範囲見直しなど、権限者が選べる対応案を準備します。
条件付き通過を認める場合は、残る条件、責任者、期限、後続工程へ与える影響を記録します。たとえば案内文の表現修正と、権限の不具合では影響が違います。何でも同じ「残課題」として進めないでください。
条件を緩めること自体が計画や品質の変更になる場合もあります。会議内で口頭了解を得るだけで足りるかは、組織の承認ルールを確認します。PMOが判定資料を作っても、判断権限を持つとは限りません。
進捗は「通過済みか」だけでは測れない
節目が五つあり、二つ通過したから40％という計算では、残りの作業量が分かりません。節目は到達状態の確認に使い、残作業と終了見込みは別に説明します。
また、当初予定・現在見込み・実績を分けて残します。当初予定を毎週上書きすると、どの節目でどれだけずれたか追えなくなります。変更が承認された場合は、新しい計画版と、その承認理由を残します。
判定前の確認を小さく習慣化する
- 通過条件は、関係者が同じ意味で理解しているか。
- 条件に対応する証跡は、最新の対象版か。
- 未達項目について、影響・対応案・判断期限があるか。
- 判定者は参加できるか。不在時の権限者は合意されているか。
- 通過後に誰が何を始めるか決まっているか。
説明用の判定記録は「要件確定：保留。拠点別の承認ルートが未確認。業務責任者へ確認し、確定まで通知設定は仮置きとする」のように書けます。節目のラベルより、次の作業へ何を渡せるかが大切です。
最初に見直すなら、直近の節目一つについて、日付の隣へ「通過条件・証跡・判断者」を追加してみてください。計画全体を複雑にせず、完了の認識差を減らせます。
次に確認したい実務ガイド
PMO実務テンプレート・確認表の一覧から、目的に合う記事を探せます。
参考情報とこの記事の位置づけ
マイルストーンが主要な節目を表すという概念の確認に使用しました。通過条件の表は独自提案です。 Atlassian：Project Milestones（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。
課題管理表の作り方も必要な作業に合わせて参照してください。
アイキャッチ写真：2H Media / Unsplash。職場の実写ではなくイメージ写真です。
