マイルストーンの設定方法｜完了条件つきテンプレートと記入例
マイルストーンは、重要な判断や引渡しの到達点を共有するための節目です。日付を決めるだけでなく、誰が、どの版を、何の条件で確認するかまで決めると、通過した意味が明確になります。架空のWeb改修を使い、コピーできる表と、変更時に当初計画を残す方法を紹介します。
マイルストーンと前工程タスクを分ける
マイルストーンは、一般的な工程表では期間を持たない点として表します。一方、その判断に必要な資料作成、試験、レビューには時間がかかります。「要件承認」という節目だけ置き、承認準備や回答期間を入れないと、前工程が抜けた計画になります。使うツールによって表示方法が異なる場合もあります。
Microsoftのマイルストーン項目の説明も、Projectで節目を扱う参考になります。ただし、特定ツールの項目定義を、全組織の唯一の決め方とする必要はありません。重要なのは、前工程の作業と、通過を判定する時点を区別して共有することです。
タスクの完了と節目の通過も同じではありません。資料を送っただけなら、提出作業は完了していても承認は待ちかもしれません。受領、合格、承認、条件付き承認など、どの結果が必要かを合意します。判断者が不在のときの代替や、未解決事項の扱いも決めておくと、判断が止まった理由が見えます。
節目を置く5つの基準
節目の候補は、工程の長さより意思決定の意味から選びます。次の5つの基準を使い、重要なところへ置いてください。これはこの記事の確認方法であり、すべての案件を同じ数や間隔へそろえる基準ではありません。
基準 | 節目の例 | 確認する理由 |
|---|---|---|
承認が必要 | 要件版の承認 | 合意した範囲を確定する |
戻しにくい判断 | 発注・公開の可否 | 費用や外部影響が変わる |
担当間の引渡し | 制作から運用へ移管 | 受け手が開始できる条件を確認 |
複数工程の合流 | 制作・法務確認の完了判断 | 必要な枝がそろうか確認 |
外部との約束 | イベント開始・納品 | 相手が判断や準備に使う |
小規模案件なら数個で足りることも、大きな案件なら多数必要なこともあります。5〜10個や2週間ごとの設置を普遍的な規則にしないようにします。定例会議があるという理由だけで節目を増やすと、何が決まったかが曖昧になります。単なる状況共有なら通常のレビューとして扱えます。
数が多く見づらいときは、重要な判断だけを全体表示し、部門内の節目を詳細表示へ分ける方法があります。省略してよいかは後続の判断に必要な情報で決めます。名称も「レビュー」だけでなく「要件v1承認」のように対象と結果を含めると、同じ言葉でも違う範囲を指す問題を減らせます。
コピー用テンプレート：日付・判定者・条件・証跡
コピー用の表では、当初計画と現在見込を別にします。責任者は判定の準備を進め、判定者は権限に従って結果を決める人です。同一人物でも構いませんが、どちらの役割かを明確にします。証跡には、対象版と判断を確認できる記録の場所を記載します。
項目 | 書く内容 | 記入時の注意 |
|---|---|---|
ID・節目 | M01 要件v1承認 | 前工程タスクとは別ID |
当初計画・現在見込 | 第2日・第3日見込 | 元の合意日を消さない |
責任者・判定者 | PM・事業責任者 | 資料準備と判断権限を区別 |
版・完了条件 | v1の範囲、除外、制約を承認 | 曖昧な「問題なし」だけにしない |
証跡 | v1文書と承認記録 | 対象版と日時が分かるようにする |
状態・変更 | 判定待ち、回答日変更 | 理由と承認、未解決事項を記録 |
条件が複数あるなら、別のチェック表へまとめ、その版を参照しても構いません。すべてを1セルや1行へ縮める必要はありません。判断の根拠になる条件を置き、節目一覧から参照できるようにします。候補の段階と、関係者が承認した計画を混同せず、いつ誰が合意した条件かを残してください。
記入例：要件承認と受入判定
次の架空例は、要件承認を第2作業日、公開判定を第12作業日に置くWeb改修です。判定基準は事前に当事者が合意した例で、すべての公開案件へ適用する最低基準ではありません。実務では契約、品質、安全性など必要な条件を別途確認します。
ID・節目 | 計画日 | 責任者・判定者 | 条件と証跡 | 状態 |
|---|---|---|---|---|
M01 要件v1承認 | 第2日 | PM・事業責任者 | v1の範囲・除外・制約を承認。未決事項に担当と期限。文書と承認記録を参照 | 承認済み |
M02 公開可否判定 | 第12日 | QA担当・公開責任者 | 対象120件実施、118合格。軽微2件のリスク・期限・例外承認と他の公開条件を確認 | 判定待ち |
120件の対象試験を120件実施したら、実施率は120÷120＝100%です。しかし合格は118件で、合格率は118÷120＝約98.3%です。実施したことと、全件合格したことを分けてください。重大不具合が0でも、残る2件の扱いと他の公開条件が未確認なら、自動的に公開可にはなりません。
この例では、軽微2件について残存リスク、修正期限、責任者を記録し、権限を持つ判定者が例外を受け入れた証跡を確認します。それ以前のM02は判定待ちです。例外承認が得られない、または必須条件を満たさない場合は、修正して再判定するか、公開予定を見直します。例外が許されない条件もあるため、あらかじめ境界を決めます。
計画日・現在見込・変更履歴を維持する
変更が起きたら、当初の計画日、現在の見込、変更理由と判断を残します。日付の上書きだけでは、遅れの発生も対策の効果も見えません。計画の正式な改訂が必要な場合も、旧版と新しい合意を参照できるようにします。暫定見込を正式承認の日付と見せないことが大切です。
対象 | 当初計画 | 現在見込 | 理由・判断 |
|---|---|---|---|
M01要件承認 | 第2日 | 第3日 | 必要条件の回答待ち。事業責任者へ判断期限確認 |
後続デザイン | 第3日開始 | 第4日開始 | M01承認が開始条件 |
M02公開判定 | 第12日 | 再計算中 | 後続容量と余裕を確認して決定 |
この変更例は、前の表とは別の遅延シナリオです。「承認済み」の結果を都合よく書き換えるのではなく、計画時に回答が遅れた場合の記録方法を示しています。実際の記録では状態の日時と対象版を併記し、現状と仮定の試算を分けてください。
遅れたときの余裕・依存先・承認事項を確認
遅れた節目が最終納期に影響するかは、後続の依存関係と余裕で確認します。Microsoftのクリティカルパスの解説も参考に、どの連鎖が終了日を決めるかを確認します。外部の引渡しが遅れたら必ず全工程が同じ日数遅れる、とは限りません。
対応では、先に渡せる部分、範囲の分割、代替確認者、担当容量の調整、約束日の再合意を検討します。品質や権限を無視して判定を省略しないようにします。余裕を使った場合は残りを更新し、次の遅れを吸収できるという前提を置き続けないでください。
見直しの最後に、誰が何を判断し、次にいつ確認するかを記録します。同じ理由で日付が動くなら、必要資料、回答条件、判定の権限、前工程の期間見積を変える必要があります。移動回数だけで失敗と断定せず、判定条件と後続の約束を守るための情報が揃ったかを確かめましょう。
判定の準備では、資料が存在するだけでなく、判定者が閲覧できるか、対象版が一致しているか、残る例外が一覧になっているかを確認します。前の版への承認を、新しい変更分への承認と読み替えないようにしてください。担当が交代するなら、節目の状態だけでなく、条件付き承認の残件と次の確認日も引き継ぎます。
通過後に条件が変わる場合もあります。たとえば承認済みの要件へ追加依頼が来たら、元の承認を無効にしたと決めつけるより、変更範囲と影響を評価し、必要な再承認を定義します。小さな修正かどうかも権限と基準に従って判断します。節目の表を、日付を並べる表から、何が合意され何が残っているかを確かめる記録へ変えていきましょう。
次に使える関連記事
タスクの進行を施策単位で扱い、月次計画と承認済み予算も確認したい場合は、Xtrategyのプロジェクト機能をご覧ください。Xtrategyでは施策のタスク進行をプロジェクト内で管理し、月次計画と承認済み予算を並べて確認できます。関連する予算・CRM・承認情報へ遷移できます。