マイルストーン一覧のテンプレート
マイルストーンは、たいてい工程の名前で置かれます。「基本設計完了」「開発完了」。これでも形にはなりますが、確認点の間が3〜4か月空くことになり、遅れに気づくのが遅れます。
このページでは、マイルストーン一覧のテンプレートと、置き方の考え方、記入例をまとめます。記入例は、事例集の「まなびカレッジ（架空）の受講管理システム刷新」に当てはめたものです。
■ この帳票が要る場面（背景・よくある課題）
よくある症状 | 本当の原因 |
|---|---|
開発完了の日になって、初めて遅れが分かる | その前の確認点が4か月前にしかなかった |
「基本設計完了」と報告されたが、実は決まっていないことが残っていた | 完了の判定基準を決めていなかった |
他部署が、自分たちの作業をいつ始めればよいか分からない | マイルストーンが内部工程の名前で、他部署に関係がない |
進捗報告が「順調です」だけになる | 次に何が終わるべきかが共有されていない |
■ このテンプレートの目的
遅れが表に出るまでの時間を短くする：間隔を4〜6週間に保てば、遅れは必ず1か月半以内に見えます
完了の判定を、人によってぶれない形にする：判定基準を数字か○×で書きます
関係者が、自分の出番をカレンダーに入れられるようにする：特に他部署の作業が発生する時期を明示します
■ テンプレートの全体像
マイルストーンの置き方には、2つの原則があります。
原則 | 内容 | なぜ |
|---|---|---|
① 間隔は4〜6週間 | 2か月以上空けない | 空けた期間ぶん、遅れの発見が遅れるため |
② 「何が確定しているか」で書く | 工程名ではなく、確定した状態を書く | 工程名は「終わった／終わっていない」の判断があいまいになるため |
①の間隔を守ろうとすると、自然と工程の途中に確認点を置くことになります。その確認点をどう定義するかが②です。たとえば開発期間が3か月あるなら、真ん中に「画面とバッチの半数が単体テストまで完了」を置きます。工数の50%ではなく、本数で定義するのがコツです。工数の50%は自己申告になりますが、本数は数えられます。
■ 各項目の説明
列 | 何を書くか | 書き方のコツ |
|---|---|---|
No | M1、M2… | 途中で追加しても番号は振り直さない（M3.5のように枝番にする） |
マイルストーン名 | 確定した状態 | 「基本設計」ではなく「基本設計完了（画面46本・バッチ22本の設計書が承認済み）」 |
判定基準 | 何をもって達成とするか | 数えられる形で。「レビュー指摘の未クローズ0件」「計算例72件すべて一致」 |
判定する人 | 誰が達成を認めるか | PMではなく、その成果物を受け取る人にするとぶれません |
計画日 | 当初の予定日 | 動かさない。動かすと、どれだけ遅れたか分からなくなります |
見通し日 | 現時点での着地見込み | 毎週更新する列。ここが動くことで遅れが見えます |
実績日 | 実際に達成した日 | 達成後に記入 |
遅れ | 実績日 − 計画日（営業日） | 累計ではなく、そのマイルストーン単体の遅れ |
関係者の作業 | このマイルストーンの前後で、他部署に発生する作業 | 他部署が自分の出番を把握できるようにする欄 |
備考 | 遅れた理由、対応 | 遅れた場合は必ず記入する |
計画日と見通し日を分けるのが、この表の要点です。1つの列しかないと、遅れそうになったときに日付を書き換えてしまい、遅れの記録が残りません。
■ 記入例：まなびカレッジ 受講管理システム刷新
11か月・108人月のプロジェクトです。途中でクリティカルパスの組み替えを行い、M2（連携I/F仕様確定）を追加しています。
No | マイルストーン名 | 判定基準 | 判定する人 | 計画日 | 実績日 | 遅れ |
|---|---|---|---|---|---|---|
M1 | 要件定義 完了 | 業務シナリオ124本すべてに、業務部門の承認署名がある／項目定義の「未定」が0件 | 業務部長 | 2025/5/16 | 2025/5/16 | 0 |
M2 | 連携I/F仕様 確定 | 受け渡すデータ項目38件と方式が確定し、学習基盤側の合意書がある | 技術リーダー | ― | 2025/6/27 | ― |
M3 | 受講管理 基本設計 完了 | 画面34本・バッチ18本の設計書が承認済み／レビュー指摘の未クローズ0件 | 業務リーダー | 2025/7/11 | 2025/7/22 | ＋6日 |
M4 | 詳細設計 完了 | 全52本の詳細設計書が承認済み／単体テストケース1,040本が作成済み | ベンダーPL | 2025/9/5 | 2025/9/5 | 0 |
M5 | 開発 50% | 画面17本・バッチ9本が単体テストまで完了（未解決0件） | ベンダーPL | 2025/10/17 | 2025/10/17 | 0 |
M6 | 開発 完了 | 全52本が単体テスト完了／単体テストケース密度20ケース/KStep以上 | ベンダーPL | 2025/11/28 | 2025/11/28 | 0 |
M7 | 結合テスト 完了 | 未解決0件／直近2週の発生件数がピーク週の20%以下 | テスト責任者 | 2026/1/23 | 2026/1/23 | 0 |
M8 | 受入テスト 完了 | 不具合密度0.25件/KStep以下／業務部門の受入確認書に署名 | 業務部長 | 2026/2/20 | 2026/2/20 | 0 |
M9 | 本番稼働 | 移行データの照合不一致0件／稼働判定会議で承認 | 情報システム部長 | 2026/3/2 | 2026/3/2 | 0 |
判定基準の列を見てください。すべて数えられる形になっています。「設計書が完成していること」では、完成の定義が人によって変わります。「画面34本・バッチ18本の設計書が承認済み、指摘の未クローズ0件」なら、誰が見ても同じ判断になります。
M2は当初の計画になく、6月に追加したマイルストーンです。このように途中で追加できるのがマイルストーン一覧の使い方で、追加したものには計画日を入れず「―」としておきます。当初計画との比較が崩れないようにするためです。
関係者の作業（抜粋）
No | 他部署に発生する作業 | 誰が | いつ |
|---|---|---|---|
M1の前 | 業務シナリオ124本のレビューと承認署名 | 講座運営部 6名 | 2025/4/21〜5/16（延べ12日） |
M3の前 | 画面イメージの確認（34本） | 講座運営部 3名 | 2025/7/1〜7/11（延べ4日） |
M8の前後 | 受入テストの実施 | 講座運営部・事務局 12名 | 2026/1/26〜2/20（延べ36日） |
M9の前 | 講座マスタ180件の登録 | 事務局 4名 | 2025/12/1〜2026/2/13 |
この表があると、他部署が自分の出番を半年前からカレンダーに入れられます。「受入テストに12名を36日分」は、直前に言われても出せません。
■ 運用ルール
間隔は4〜6週間。2か月以上空くところがあれば、その中間に確認点を置きます
判定基準は、数えられる形で書く。「完成していること」は基準になりません
判定する人は、成果物を受け取る人にする。作った人が判定すると通ってしまいます
計画日は動かさない。見通し日を別の列で毎週更新します
見通し日が動いたら、その週の会議で理由を報告する。動いたこと自体は問題ではなく、黙って動くことが問題です
マイルストーンを追加したときは、計画日を空欄にする。当初計画との比較が崩れないようにします
達成したら、その日に実績日を入れる。まとめて入れると、記憶で書くことになります
■ 活用シーン
場面 | 使い方 |
|---|---|
キックオフ | スケジュールのページで、この一覧をそのまま見せる |
週次の進捗報告 | 「次のマイルストーンはM5、10/17。見通しは変わらず」の1行で足りる |
他部署への協力依頼 | 「関係者の作業」の列を見せ、半年前から日程を押さえてもらう |
経営層への報告 | 計画日と見通し日の差を並べる。9個のうち何個が計画どおりかで全体が伝わる |
フェーズの切り替え判定 | 判定基準を1つずつ確認する。ゲートとして使う |
遅れの説明 | 「M3で6営業日遅れ、M4までに吸収」と、どこで遅れてどこで戻したかを示せる |
■ よくある失敗と直し方
失敗 | 何が起きるか | 直し方 |
|---|---|---|
工程名をそのままマイルストーンにする | 確認点の間隔が3〜4か月空き、遅れの発見が遅れる | 工程の途中にも確認点を置き、間隔を4〜6週間に保つ |
判定基準が「完了していること」 | その場の空気で通ってしまう | 数えられる基準にする（本数・件数・署名の有無） |
「開発50%」を工数で定義する | 自己申告になり、確かめられない | 本数で定義する（画面17本・バッチ9本が単体テスト完了） |
計画日を見通しで上書きする | 遅れの記録が残らず、振り返りができない | 計画日・見通し日・実績日の3列に分ける |
他部署の作業を書かない | 受入テストの直前に人が集まらない | 「関係者の作業」の列を作り、半年前に共有する |
マイルストーンが20個を超える | どれが重要か分からなくなる | 1年の案件なら8〜12個が目安。細かいものはWBSで持つ |
■ 導入効果
項目 | 工程名だけの場合 | このテンプレートの場合 |
|---|---|---|
確認点の間隔 | 最長4か月半 | 4〜6週間 |
遅れが表に出るまで | 最大4か月 | 最大6週間 |
完了判定 | 報告者の感覚 | 数えられる基準で、受け取る側が判定 |
他部署の準備 | 直前に依頼され、調整がつかない | 半年前から日程を確保できる |
進捗報告の手間 | 毎回、状況を文章で説明する | 「次はM5、見通し変わらず」の1行 |
まなびカレッジの案件では、M3で6営業日の遅れが出ましたが、M4以降はすべて計画どおりに達成しています。M3の遅れが7月の時点で見えたから、M4までの間で吸収する手が打てました。もし次の確認点が11月の「開発完了」だったら、6日の遅れは他の遅れと混ざって見えなくなっていたはずです。
最後に1つ。マイルストーンは、報告のために置くのではありません。自分たちが「ここまでに何を確定させるか」を決めるために置きます。だから、達成できたかどうかより、判定基準を決める作業そのものに価値があります。「何をもって基本設計完了とするか」を関係者と決めるとき、たいてい認識の違いが見つかります。