マイルストーンとは、プロジェクトや仕事の進行上、重要な到達点を確認するための節目です。実務では、節目の名前と予定日だけでなく、「どの状態になれば到達か」「何を見て確認するか」をセットで決めると使いやすくなります。
「10月15日:レビュー」と予定表に書いても、会議を開けばよいのか、指摘への対応まで終えるのかは分かりません。日付が決まっていても、達成の判断がそろっていなければ、進み具合を確認しにくいのです。
この記事では、社内向け業務マニュアルを作成して公開する小規模プロジェクトを使い、日付だけの予定をマイルストーンへ直します。業務名・日付・人数・条件はすべて架空の設定です。自分の予定表に置き換えられる簡易表も用意しています。
マイルストーンとは
ビジネスでは、重要な承認、成果物の完成、次の工程へ進む判断などをマイルストーンにします。プロジェクト管理では、作業にかかる期間そのものではなく、進行上の重要な時点を表します。中間の節目だけでなく、最終成果の完成も設定できます。
たとえば「マニュアルの初稿を書く」は作業ですが、「対象3業務の初稿がそろい、内容レビューを始められる」は到達状態です。その状態を確認する節目が「初稿レビュー開始」です。
Asanaのマイルストーン解説でも、時間をかけて行うタスクと、重要な到達点を示すマイルストーンを区別しています。この記事では、この区別を予定日・到達状態・確認方法の4項目に整理します。
マイルストーンとタスク・期限の違い
| 項目 | 示すこと | 架空例 |
|---|---|---|
| タスク | 実行する作業 | 申請受付の手順を書き、画面画像を挿入する |
| 期限・締切 | 作業や提出などを終えるべき日・時刻 | 初稿の提出締切は10月5日 |
| マイルストーン | 重要な到達状態を確認する節目 | 10月5日に対象3業務の初稿がそろい、内容レビューを始められる |
| スケジュール | 作業の順序・期間・節目を含む日程全体 | 初稿作成、レビュー、修正、承認、公開の日程 |
期限は「いつまでに」、マイルストーンは「どの重要状態まで進んだか」を確認するものです。同じ日付になることはありますが、すべての締切が重要な節目になるわけではありません。逆に、マイルストーンには、それを目指す予定日を付けられます。
日程全体がスケジュール、その中で重点的に確認する点がマイルストーンです。タスクの一覧をマイルストーン表に置き換える必要はありません。
マイルストーンを設定する意味
重要な節目を共有すると、大きな仕事の途中で「ここまで進んだか」を確認できます。マニュアル制作なら、最終日に初めて内容を確認するのではなく、初稿がそろった時点と内容レビューを終えた時点で問題を見つけられます。
- 確認者が、いつ何を見る必要があるか分かる。
- 次の工程に必要な文書・判断がそろっているか確かめられる。
- 未解決の指摘を、公開直前まで持ち越しにくくなる。
ただし、設定だけで遅延を防げるわけではありません。節目と節目の間のタスク管理や、問題への対応も必要です。また、節目を通過したことだけで、成果物の品質やプロジェクト全体の成功を保証することはできません。
マイルストーンの決め方
- 最終成果と仕事の流れを確認する。この例の最終成果は、承認済みの3業務のマニュアルが社内に公開され、対象社員が閲覧できることです。初稿作成→内容レビュー→修正・承認→公開準備→公開、という流れを置きます。
- 途中で確認が必要な重要状態を洗い出す。「レビュー対象がそろった」「指摘の扱いが決まった」「公開できる状態になった」など、後の作業を左右する状態を挙げます。
- 単なる作業ではなく節目を選ぶ。画像の挿入やファイル名の変更はタスクとして管理し、レビューや公開へ進める状態をマイルストーンにします。
- 予定日を決める。必要な作業時間、確認者が対応できる日、前の工程を待つ関係を確認します。最終日から逆算するだけでなく、担当者が実行できるかも確かめます。
- 到達状態を具体化する。対象文書、必要な確認、残件の扱いを書きます。「初稿完了」だけでなく、「3業務の初稿がそろい、手順の必須欄に未記入がない」とします。
- 確認方法を決める。ファイル一覧、レビュー記録、承認記録、実際の閲覧画面など、到達したと判断する根拠を指定します。
- 関係者と共有する。確認する人と、次工程へ進むか判断する人を決め、予定日と条件を合意します。
確認者と承認者の違いが曖昧なら、RACIによる役割分担も参考になります。表を増やすことより、「誰がこの状態を確認するか」が共有されていることが大切です。
架空例:日付だけの予定をマイルストーンへ直す
対象は、申請受付・内容確認・結果通知の3業務です。作成担当者が初稿を作り、各業務の確認者が内容を確認し、部署責任者が公開を承認する設定にします。仕事の対象はすでに決まっているものとし、ここでは進行途中の節目を整理します。
修正前:日付と作業名だけでは、進んだか判断できない
| 日付 | 予定 |
|---|---|
| 10月5日 | 原稿作成 |
| 10月15日 | レビュー |
| 10月25日 | 完成 |
この表では、10月5日は作り始める日なのか、初稿をそろえる日なのか分かりません。「レビュー」も、確認者へ依頼を送っただけか、指摘の扱いまで決まった状態かが不明です。「完成」は文書の承認か、公開準備か、社員が閲覧できる状態かで必要な作業が違います。
さらに、未解決の指摘が残っている場合に到達とするかも判断できません。そこで、作業名を重要な到達状態へ変え、確認する根拠を添えます。
修正後:到達状態と確認方法をそろえる
| マイルストーン | 予定日 | 到達状態 | 確認方法 |
|---|---|---|---|
| 初稿レビュー開始 | 10月5日 | 3業務の初稿がそろい、手順・使用画面・注意点の必須欄に未記入がない。確認者に対象版を共有済み | 作成担当者がファイル一覧と必須欄を確認し、共有記録で対象版を照合する |
| 内容レビュー完了 | 10月15日 | 各業務の確認者が内容を確認済み。全指摘の対応方針が決まり、修正が必要な指摘には担当者と期限がある | 作成担当者と確認者がレビュー記録の確認欄・指摘一覧・対応方針を照合する |
| 公開準備完了 | 10月25日 | 公開前に必須とした修正が反映され、対象版を部署責任者が承認済み。公開先と閲覧権限の設定が確定 | 作成担当者が修正版と承認記録を照合し、公開先・権限設定を確認する |
| 社内公開完了 | 10月28日 | 承認済みの3業務の文書が公開され、対象社員が閲覧できる。案内を送付済み | 対象社員用アカウントで公開URLと文書の版を確認し、案内の送付記録を確認する |
10月15日の「内容レビュー完了」は、修正がすべて終わった意味ではありません。この例では、確認と指摘の対応方針決定までを節目にしています。修正作業は10月25日の公開準備完了までに行います。どこまでをその節目に含めるかを明記すれば、名前だけで判断する誤解を防げます。
手順の誤りなど、公開前に直す必要がある指摘を残したまま「公開準備完了」とはしません。公開後でもよい軽微な表現修正は、その扱いを責任者と合意し、担当者・期限を記録します。残件を認めるかどうかは、仕事の品質条件に応じて決めます。
元の「10月25日:完成」は、この例では公開準備と公開完了に分けました。10月28日は説明用に追加した日付です。実際に公開期限が10月25日なら、その期限を勝手に延ばさず、公開操作と閲覧確認まで含めて前の工程の日程を組み直します。
良いマイルストーンの条件
次の条件で、予定表の各行を確認してください。
- 重要な節目である:到達しないと後の作業や判断に影響する。
- 到達したか確認できる:対象物と判断条件があり、確認する記録や画面が決まっている。
- 単なる作業名ではない:「資料作成」より、作った結果の状態が分かる。
- 関係者が同じ意味で読める:「レビュー」に承認や修正を含むかが明確である。
- 次の工程との関係が分かる:到達後に何を始められるかが説明できる。
- 必要以上に多くない:日々の作業一覧と区別され、重要な確認点が埋もれない。
「資料作成」「10月15日」「レビュー」だけでは、作業名・日付・活動名のどれかしか分かりません。「その日に何がそろえば、次へ進めるか」と問い直すと、足りない条件を見つけられます。
「設計完了」「レビュー完了」を具体化する
「完了」という言葉だけで、達成条件は決まりません。対象物+必要な確認+残件の扱いへ分けると、観測できる状態に直せます。
| 名前だけの状態 | 具体化した到達状態 | 確認するもの |
|---|---|---|
| 構成設計完了 | 3業務の章立てと必須記載項目がそろい、各業務の確認者が了承している。未決事項の扱いが決まっている | 構成案、確認記録、未決事項一覧 |
| レビュー完了 | 指定確認者の確認が終わり、すべての指摘の対応方針が決まっている | 確認済みの記録と、指摘ごとの対応欄 |
「ファイルがある」は存在の確認、「内容が正しい」は品質の確認です。初稿の節目で前者を確認しても、公開前の後者まで確認したことにはなりません。確認方法も、品質を判断したいのにファイル一覧だけを見る、といった食い違いを避けます。
構成設計完了は表現を直すための候補例であり、先ほどの表へ必ず追加する節目ではありません。独立した承認が必要かどうかで採否を決めます。
マイルストーンを多くしすぎない
すべてのタスクをマイルストーンにすると、確認や更新に手間がかかり、重要な遅れが埋もれます。「画面画像を1枚入れる」「見出しを直す」などはタスクとして管理し、マイルストーンは重要な承認、成果物の完成、次工程へ進む判断、外部との重要な合意、大きな段階の区切りに絞ります。
この例なら、画像の挿入ごとに節目を増やすより、必要な画像を含む初稿がそろったかを10月5日に確認します。ただし、その画像がないと内容レビュー自体ができない場合は、初稿レビュー開始の条件に含めます。
適切な数は、期間や仕事の複雑さによって変わります。「この節目で誰が何を判断するのか」を答えられない行は、タスクに戻すか、近い節目にまとめることを検討してください。
マイルストーンが未達になったときの確認
10月15日になっても、結果通知の業務について確認者の回答が届かず、指摘の対応方針も決まっていないとします。「レビューが遅れています」で終えず、次の順に確認します。
- 満たしていない到達条件を特定する。この例では「指定確認者の確認」と「全指摘の対応方針決定」が未達です。他の2業務の確認が済んでいても、節目全体は未達と記録します。
- 原因となるタスクを確認する。確認者に正しい版を送ったか、依頼が届いているか、内容確認と方針決定のどこで止まっているかを調べます。
- 前提・依存関係を確認する。回答に必要な運用ルールが未決なら、確認者に催促するだけでは進みません。ルールを決める人と判断日を確認します。
- 次の節目への影響を見る。未確定の指摘が修正・承認・公開準備を止めるか、他の業務の修正は先に進められるかを分けます。
- 対応と日程を合意する。判断を依頼する、確認を分担する、予定日を変更するなどの対応を決めます。作業範囲の変更が必要なら、依頼者と影響を確認します。
確認待ちが全体の流れを止めているなら、ボトルネックの見つけ方が役立ちます。対象業務を減らす案など、約束した仕事の範囲を変える場合は、スコープ変更の考え方も確認してください。
予定日を直すときは、元の予定、変更理由、新しい予定、次の確認日を短く残します。日付だけ後ろへずらしたり、未達の条件を黙って緩めたりせず、関係者が影響を判断できるようにします。条件を満たしていない工程へ進む必要がある場合も、残件・影響・判断者を明確にして合意します。
マイルストーン設定でよくある失敗
| 失敗 | 直すポイント |
|---|---|
| 日付だけを設定する | その日に確認する到達状態と、確認方法を添える |
| タスクをそのまま並べる | 作業を積み上げた結果の、重要な到達点を選ぶ |
| 到達条件が曖昧 | 対象文書・必要な確認・残件の扱いを明記する |
| 数を増やしすぎる | 承認や次工程の判断に使う節目を残す |
| 最終日しかない | 修正する時間を残せる途中の確認点を置く |
| 未達でもそのまま進む | 不足条件と後工程への影響を確認し、進める範囲を合意する |
| 状況が変わっても見直さない | 前提が変わったときに条件・日程・後工程への影響を確認する |
| 「完了」という名前だけで判断する | 合意した到達条件を記録や成果物で確かめる |
コピー用の簡易マイルストーン表
次の表をコピーし、自分の仕事の節目を記入してください。まずは1行で構いません。確認方法には、見るファイルや記録と、確認する人を書きます。
| マイルストーン | 予定日 | 到達状態 | 確認方法 |
|---|---|---|---|
マニュアル制作なら「初稿レビュー開始/10月5日/3業務の初稿がそろい、必須欄に未記入がなく、確認者に対象版を共有済み/作成担当者がファイル一覧・必須欄・共有記録を照合」と記入できます。予定日や条件が分からないときは、仮の日付や曖昧な「完了」で埋めず、誰に何を確認する必要があるかをメモしてから確定します。
まとめ
今持っている予定表から、次の工程を左右する節目を一つ選んでください。「何が確認できれば到達か」を一文にし、その根拠となるファイル・記録・画面を隣に書きます。
その1行を確認する人と共有し、同じ状態を「到達」と判断できれば、日付だけの予定を進捗確認に使えるマイルストーンへ変えられます。
