「この案件、マイルストーンを置いておいて」。会議でそう言われて頷いたものの、席に戻って手が止まる――具体的に何を、どこに、どう置けばいいのか。タスクリストとは何が違うのか。調べ始めるとガントチャートやWBSといった言葉も出てきて、かえって分からなくなる。そんな経験はないでしょうか。
結論から言えば、マイルストーンとは「プロジェクトの節目となる中間目標」のことです。ポイントは、「デザインを作る」のような作業ではなく、「デザインが承認された」のような成果物・状態で表すこと。納期から逆算して2〜4週間隔で節目を置き、それぞれを「何がどうなっていれば通過か」で定義し、節目までのタスクに分解する――この3ステップを押さえれば、迷わず置けるようになります。
私はAIタスク管理アプリ「するたす」を開発・運営しています。本記事では、言葉の意味、タスク・WBS・ガントチャートとの関係、置き方の手順、ありがちな失敗と対策までを、順を追って解説します。
プロジェクト全体の進め方から押さえたい方は「プロジェクトの進め方」を、スケジュール全体を1枚にする方法は「ガントチャートの作り方」を併せてご覧ください。
マイルストーンとは：プロジェクトの節目となる中間目標
まず言葉の意味に正面からお答えします。マイルストーン（milestone）は、もともと道路に1マイルごとに置かれた「里程標」のこと。旅人が「いまどこまで来たか」を確かめるための目印です。プロジェクト管理では、この意味が転じて、ゴールまでの途中に置く「節目となる中間目標」を指します。「◯月◯日までに、◯◯が完了している」という、日付と到達状態のセットが基本形です。
「作業」ではなく「成果物・状態」で表すのがポイント
節目を書くときの最大のコツは、動作ではなく状態で表現することです。「デザインを作成する」は作業（タスク）ですが、「デザイン案が承認された」は状態、つまり節目です。作業は”やっている最中”が存在しますが、節目は通過したか・していないかの二択しかありません。この「二択で判定できるか」が、タスクと節目を見分ける一番簡単なテストです。
状態で書くと、進捗の会話も変わります。「デザイン、どのくらい進んでる？」「8割くらいです」というやり取りは、実際には何も判定していません。一方「デザイン承認、通過した？」なら、答えはイエスかノーのどちらかです。曖昧な”進捗率”の応酬を、明確な”通過判定”に置き換えられる――これが状態で書くことの実利です。
タスク・WBS・ガントチャートとの関係
調べると必ず一緒に出てくる3つの言葉と、役割を整理しておきます。
| 概念 | 役割 | 例 |
|---|---|---|
| マイルストーン | 節目となる中間目標（点）。到達状態で表す | 「6/30 デザイン案が承認された」 |
| タスク | 節目に到達するための個々の作業（線） | 「ワイヤーフレームを作る」「レビュー会を設定する」 |
| WBS | やるべき作業全体をもれなく分解した一覧表 | 成果物→工程→作業の階層リスト |
| ガントチャート | タスクと節目を時間軸に並べた見取り図 | 横棒でタスク、◆マークで節目を表示 |
関係を一言でいえば、節目が「点」、タスクが「線」、WBSが「線の一覧」、ガントチャートが「点と線を時間に並べた地図」です。作業の洗い出し方は「WBSの作り方」、時間軸への並べ方は「ガントチャートの作り方」で詳しく扱っています。本記事は、その手前にある「点をどこに打つか」に集中します。
「置いたのに機能しない」が起きるとき、何が共通しているか
言葉の意味が分かっても、実際に置いてみると「作ったはいいが誰も見ていない」という状態に陥りがちです。心当たりのある場面を挙げてみます。キックオフで日付だけ並べた表を作ったが、2週間後には誰の頭にも残っていない。「中間報告」「進捗確認」という名前の節目が並んでいるが、その日に何がどうなっていればいいのか誰も説明できない。期日が近づいて初めて「これ、間に合わなくない？」と気づく。
こうした場面を振り返ると、たいてい2つの共通点が見つかります。1つは、節目が「状態」で定義されておらず、通過したかどうかを判定できないこと。もう1つは、節目とその日までにやるタスクがつながっておらず、日々の作業と切り離された”ただの日付”になっていることです。
だとすれば、打ち手は明確です。置き方の手順の中に、「通過条件を状態で書く」「節目までのタスクに分解する」という工程を最初から組み込んでしまえばいい。次の3ステップは、この2つを埋め込んだ手順になっています。
マイルストーンの置き方：3ステップ
ここからが実践です。白紙の状態から節目を置いて、日々のタスクにつなげるまでを3ステップで進めます。
ステップ1：納期から逆算して、2〜4週間隔で節目を置く
起点は今日ではなく納期です。最終ゴールの日付を固定し、そこから手前に向かって「この状態になっていないと次に進めない」という関門を探していきます。多くの仕事には、要件が固まる→形になる→検証が終わる→世に出る、というような工程の切れ目が自然に存在します。その切れ目に節目を置くのが基本です。
間隔の目安は2〜4週間に1つ。これより間隔が空くと、遅れに気づくのが遅くなりすぎます。逆に毎週のように置くと、それはもう節目ではなく週次のタスクリストです。3ヶ月のプロジェクトなら3〜5個、半年なら5〜8個あたりに収まることが多いはずです。
ステップ2：各節目を「何がどうなっていれば通過か」で定義する
日付を打っただけでは、まだ半分です。それぞれの節目に、「何が・どういう状態になっていれば通過とみなすか」という通過条件を書き添えます。「中間報告」ではなく「レビュー会で構成案の承認が出ている」。「開発完了」ではなく「主要機能が動き、テストを開始できる状態になっている」。誰が読んでもイエス／ノーで判定できる文になっているかを確認してください。
この一手間には、もう1つ効用があります。通過条件を書こうとすると、「そもそも承認って誰が出すんだっけ」「テスト開始の条件って何だっけ」という未確定事項がその場であぶり出されます。期日直前ではなく計画段階で曖昧さに気づける――これが、通過条件を先に書く一番の理由です。
ステップ3：節目までのタスクに分解する
最後に、直近の節目といまの状態の間を埋めるタスクを書き出します。「6/30にデザイン案が承認されている」なら、そこに至るには「参考事例を集める→ラフ案を作る→レビュー会の日程を押さえる→修正して提出する」といった作業が必要なはずです。節目から手前に向かって「その前に何が終わっている必要があるか」と問いを繰り返すと、抜けが出にくくなります。
ここで大事なのは、すべての節目を最初から細かく分解しようとしないことです。細かく割るのは直近の節目までで十分。先の節目は状況が変わるので、近づいてから分解するほうが結果的に手戻りが少なくなります。書き出したタスクを日々のスケジュールに落とす手順は「タスク分解からスケジュールへの落とし込み方」で詳しく解説しています。
🎯 節目までの「タスク分解」を軽くするのが「するたす」です
- ✅ 入力はタスク名だけ → AIが今日できる最初の一歩に自動分解
- ✅ 節目と日々の作業がつながる → “ただの日付”で終わらない
- ✅ 一歩が小さく具体的 → 計画倒れせずに動き出せる
※登録不要で体験フォームが使えます
📱 PCの方はスマホで読み取り
ありがちな失敗3つと対策
置き方が分かっても、運用でつまずくパターンは決まっています。よくある3つと、その場でできる対策を整理します。
失敗1：数が多すぎて、ただのタスクリストになる
丁寧に計画しようとするほど、節目の数は増えがちです。けれど毎週のように節目が並んだ表を思い出してみると、結局どれが本当の関門なのか分からなくなっていたはずです。数が増えるほど1つあたりの重みは薄まり、通過しても誰も気に留めなくなります。対策はシンプルで、「ここを外すと納期に響く」という関門だけに絞ること。細かい作業の管理はタスクリストやWBSの仕事であって、節目の仕事ではありません。
失敗2：「頑張る」系の曖昧な節目を置いてしまう
「開発を頑張る」「営業活動を強化する」のような節目は、期日が来ても通過したかどうか誰にも判定できません。判定できない節目は、遅れの検知という本来の役割を果たせず、置いていないのとほぼ同じです。見分け方は前述のテストと同じで、イエス／ノーで答えられる文になっているか。なっていなければ、「何がどうなっていれば通過か」を書き足して状態の文に直します。
失敗3：置いただけで、日々の仕事の中で見ない
一番多いのがこれです。計画時に立派な表を作ったのに、日々の仕事はメールとチャットに追われ、次に表を開くのは期日が過ぎた後――振り返ると、そんな経験に心当たりのある方は多いはずです。対策は、見る”場所”と”タイミング”をあらかじめ決めておくこと。週次の定例の最初の5分で直近の節目との差分を確認する、と運用に埋め込んでしまうのが確実です。確認することは「予定どおりか」ではなく「直近の節目に、いまのペースで届くか」。届かないと分かった時点で、タスクの組み替えや関係者への相談を前倒しできます。
ケースで見る：3ヶ月プロジェクトの節目の設計例
手順を具体例に落とします。7月頭に始まり、9月末公開の「社内向けサイトのリニューアル」を想定した設計例です。
| 節目 | 期日 | 通過条件（何がどうなっていれば通過か） |
|---|---|---|
| M1 要件確定 | 7/18 | 掲載コンテンツと必須機能の一覧に関係部署の合意が取れている |
| M2 デザイン承認 | 8/8 | 主要ページのデザイン案に決裁者の承認が出ている |
| M3 実装完了 | 9/5 | 全ページが検証環境で表示され、動作チェックを開始できる |
| M4 公開判定 | 9/24 | 修正が完了し、公開の可否判断に必要な確認項目がすべて埋まっている |
ポイントは3つ。①納期（9月末）から逆算して約3週間隔で置いていること、②すべてイエス／ノーで判定できる状態の文になっていること、③「M1 要件確定」までのタスク（現状ページの棚卸し→関係部署へのヒアリング→一覧表の作成→合意の場の設定）だけを先に分解し、M2以降は近づいてから割る前提になっていることです。この表をガントチャートに載せれば時間軸の見取り図が完成します。プロジェクト全体の回し方は「プロジェクトの進め方」を参考にしてください。
マイルストーンに関するよくある質問（FAQ）
Q1. マイルストーンとタスクの違いは何ですか？
タスクは「やる作業」、マイルストーンは「到達している状態」です。タスクには”やっている最中”がありますが、節目は通過したか・していないかの二択しかありません。「〜する」で書かれていればタスク、「〜が終わっている・承認されている」のように状態で書かれていれば節目、と見分けると簡単です。
Q2. いくつ置けばいい？間隔の目安は？
2〜4週間に1つが目安です。3ヶ月のプロジェクトなら3〜5個程度に収まることが多いはずです。毎週のように置くと節目ではなくタスクリストになり、逆に間隔が空きすぎると遅れの検知が遅れます。「ここを外すと納期に響く関門か」で絞り込んでください。
Q3. 納期（デッドライン）との違いは？
納期は最終的な締切、マイルストーンはそこに至る途中の節目です。納期しか置いていないと、遅れに気づくのは納期直前になります。途中に節目を置いておけば、「直近の節目に届かない」という形で遅れを数週間早く検知でき、タスクの組み替えや相談を前倒しできます。
Q4. 個人の仕事や資格勉強にも使えますか？
使えます。考え方はチームの場合と同じで、締切から逆算して「◯日までに過去問1周が終わっている」のような状態の節目を置き、直近の節目までを日々のタスクに分解します。個人の場合は特に「置いただけで見ない」が起きやすいので、週1回など見返すタイミングをあらかじめ決めておくのがおすすめです。
Q5. 節目に間に合わないと分かったらどうすればいい？
まず、早く気づけたこと自体が節目を置いた成果です。そのうえで、①残タスクを見直して削れるものを削る、②他の人に頼める作業を切り出す、③それでも無理なら早めに関係者へ相談して期日か範囲を調整する、の順で手を打ちます。振り返ると、問題がこじれるのはたいてい相談が期日直前になったときのはずです。検知が早いほど、打てる手は多く残っています。
まとめ：節目は「状態で定義し、タスクへ分解」までがセット
- マイルストーンとは、プロジェクトの節目となる中間目標。作業ではなく成果物・状態で表す
- 節目が「点」、タスクが「線」、WBSが「線の一覧」、ガントチャートが「点と線を時間に並べた地図」
- 置き方は 納期から逆算して2〜4週間隔で置く → 「何がどうなっていれば通過か」で定義する → 節目までのタスクに分解する の3ステップ
- ありがちな失敗は「多すぎ」「頑張る系の曖昧な節目」「置いただけで見ない」。関門に絞り、状態の文に直し、見るタイミングを運用に埋め込む
- 細かく分解するのは直近の節目までで十分。先の節目は近づいてから割るほうが手戻りが少ない
節目が決まったら、次は作業の洗い出しと時間軸への配置です。「WBSの作り方」と「タスク分解からスケジュールへの落とし込み方」を続けて読むと、計画から日々の実行までが一本につながります。
🚀 「するたす」を無料で試す
節目を置いても、日々のタスクにつながらなければ”ただの日付”のまま。タスク名を入れるだけで、AIが今日できる最初の一歩に自動分解します。
📱 PCの方はスマホで
この記事をシェア：
著者：藤岡 拓也（Takuya Fujioka）
AIタスク管理アプリ「するたす」開発者・運営者
タスク分解の”摩擦”をゼロにすることをテーマに、プロダクトを日々磨いています。
