ガントチャートのマイルストーンの置き方｜守る日と動かせる日を分ける
ガントチャートにマイルストーンを置いたのに、遅れが出たとたんに全部の菱形が意味を失った。そんな話は、進行をとりまとめている人からよく聞きます。原因は、置いた数でも、置いた位置でもありません。動かしてはいけない日と、動かしてよい日が、同じ見た目で並んでいることです。
この記事では、工程表の節目を「守る日」と「動かせる日」に分けて置く方法を扱います。節目を何で書くか、いくつ置くか、社外との約束と社内の目標をどう二本立てにするか、そして遅れたときにどこまで動かしてよいのかまでを、順に決められる形で示します。読み終えたときに、いま引いている工程表のどこに菱形を打ち直せばよいかが分かる状態を目指します。
節目を置く目的は、日付を守らせることではない
マイルストーンは、工程表の上に菱形や旗で示される「日付だけを持つ点」です。作業のように長さを持たず、期間の線も引かれません。ある日をもって何かが確定したことを示す印です。設計の確定日、外部への提出日、検収日、公開日といったものが典型です。
ここで多くの現場が最初につまずきます。節目を「守らせるための締切」として置いてしまうことです。締切として置かれた節目は、守れなかった瞬間に価値を失います。遅れた菱形が赤くなり、それを見た人が気まずくなり、次の週から誰もその表を開かなくなる。節目が増えるほど、この気まずさは増えます。
節目の本当の役割は、その日に「次へ進んでよいかどうかを判断する」ことです。判断のための集合点であって、罰のための締切ではありません。この違いは運用の結果に直結します。締切として置けば、遅れの報告は先送りされます。判断点として置けば、遅れは判断材料として早く上がってきます。進行をとりまとめる立場で本当に困るのは、遅れそのものではなく、遅れを知るのが遅いことです。
節目ごとに次の段階へ進んでよいかを確認するという考え方は、公的機関が公開している開発プロセスの資料でも一貫して示されています。
節目ごとに、必要な成果物がそろっているか、次の段階へ進んでよいかを関係者で確認する。 出典: ipa.go.jp
判断点として置くと決めた時点で、置くべき節目の数は自然に減ります。判断が必要な場面は、そう何度もないからです。3か月の案件に菱形が20個並んでいるなら、そのほとんどは判断点ではなく、ただの作業の終わりです。作業の終わりは線の右端が示してくれます。菱形を重ねる必要はありません。
守る日と動かせる日を分ける
節目を整理する軸は1つで足ります。その日は動かせるのか、動かせないのか。この2種類に分けて、見た目も置き方も変えます。
守る日は、外から決まった日
守る日は、こちら側の都合では動かせない日です。契約書に書かれた納品日、相手の社内会議に間に合わせる提出日、法令や制度の期限、イベントの開催日、外部サービスの停止日などが該当します。共通しているのは、動かすときに社外の誰かの合意が要ることです。
守る日の特徴は、動かすコストが高いことです。納品日を1週間ずらすには、相手の担当者が社内で説明を通す必要があり、場合によっては契約の変更が要ります。だから守る日は、工程表の上で最初に打ちます。他のすべての予定は、この日から逆算して置かれます。
守る日には、必ず「誰との約束か」を添えます。菱形の名前を「納品」ではなく「先方への初稿提出」と書くだけで、動かすときに誰へ連絡が要るかが表から読み取れます。とりまとめる人が交代しても、この情報があれば引き継げます。
動かせる日は、中で決めた日
動かせる日は、チームの中だけで完結する日です。社内レビューの日、仕様を固める日、テストを始める日、素材を集め終える日といったものです。これらは、外の誰にも連絡せずに前後させられます。
動かせる日は、守る日を守るために置かれます。目的は、遅れを早く見つけることです。2か月先の納品日しか節目が無ければ、遅れが発覚するのは締切の直前です。途中に動かせる日を置いておけば、そこで判断ができます。つまり動かせる日は、守る日の警報装置です。
警報装置なので、鳴ることに意味があります。動かせる日が予定通り来なかったとき、それは失敗ではなく、装置が正しく働いた合図です。ここを責める運用にしてしまうと、担当者は「間に合っています」と言い続けるようになり、装置が壊れます。動かせる日の遅れは記録するが評価には使わない、と最初に宣言しておくと運用が続きます。
分けないまま並べるとどうなるか
守る日と動かせる日が同じ見た目で並んでいると、遅れたときに全部が同じ重みに見えます。すると起きるのは、次の2つのどちらかです。
1つは、全部を守ろうとして無理な調整が始まることです。社内レビューが2日遅れただけなのに、後続の全作業を詰め直して残業で吸収しようとする。守る日までまだ3週間あるのに、余裕を使わずに人を削って回すことになります。
もう1つは逆で、全部が動かせるものとして扱われることです。1つ遅れて誰も困らなかった経験が積み重なると、菱形は全部「目安」に格下げされます。そして本当に動かせない日が来たときに、同じ調子で遅れます。
工程表を見た人が3秒で「これは動かせない」と分かる状態を作ること。それが分ける目的です。色を変える、名前の頭に印を付ける、行を分けて上下に置くなど、方法は道具に合わせて選べば十分です。大事なのは、区別が表の上に見えていることです。
節目をどう書くか
置く場所を決める前に、書き方を決めます。書き方が曖昧なままだと、当日になっても達成したかどうかが判断できず、節目が機能しません。
作業ではなく状態で書く
節目の名前は、動詞の作業名ではなく、その日に成立している状態で書きます。「デザイン作業」ではなく「デザイン確定」。「テスト」ではなく「受入テスト合格」。「先方確認」ではなく「先方承認取得」。
状態で書くと、その日にできているかどうかを他人が判定できます。作業名で書くと、担当者の主観にしか判定できません。「デザイン作業はだいたい終わっています」という報告は、進行を預かる立場からすると何も分かりません。「確定したか、していないか」なら答えは1つに定まります。
もう1つの効果として、状態で書くと必要な成果物が見えてきます。「デザイン確定」であれば、確定した証拠として何が残るのか。ファイルなのか、承認のメールなのか、会議の議事録なのか。この置き場所まで決めておくと、後から遡って確認するときに探し回らずに済みます。
数を絞る
節目の数は、案件の長さで決めます。目安として、1か月の案件で守る日と動かせる日を合わせて3個から5個、3か月の案件で6個から10個に収まれば、表として読めます。これを超えると、菱形が背景になって誰も個別に見なくなります。
数を絞る基準は簡単です。その日を過ぎたときに、やり直すコストが跳ね上がるかどうか。跳ね上がるなら節目です。跳ね上がらないなら、ただの作業の区切りなので線の右端で足ります。
たとえば、設計を確定したあとに設計を変えると、後続の実装をやり直すことになります。ここはコストが跳ね上がるので節目です。一方、資料のフォーマットを整えるといった作業は、いつやってもコストがほぼ変わりません。ここに菱形は要りません。
判定する人を先に決める
節目には、判定する人の名前を付けます。「誰がその日にこれを見て、進んでよいと言うのか」を決めておくということです。ここが空白のまま当日を迎えると、全員が誰かの判断を待って、判断されないまま次の週に流れます。
判定する人は、その節目の後の作業で一番困る人にするとうまく回ります。設計確定なら実装する人、素材確定なら制作する人です。困る人が見れば、足りないものにすぐ気づきます。とりまとめる人が全部の節目を判定する形にすると、その人が休んだ週にすべてが止まります。
案件の型ごとに、置き場所はだいたい決まっている
どこに節目を置けばよいか迷う場合は、案件の型から入ると早く決まります。型が同じなら、判断が要る場面もほぼ同じだからです。
受託の制作案件であれば、要件の確定、初稿の提出、先方の修正指示の受領、最終稿の提出、検収の5つが基本形になります。このうち先方の修正指示の受領は、こちらの努力では動かせないのに、後続の全作業がぶら下がる点です。ここを節目として明示していない工程表は多く、そして相手の返事が遅れた分がそのまま自分たちの残業になります。
社内のシステム導入であれば、要件の確定、設計の確定、テスト環境での確認、本番切り替え、切り替え後の様子見期間の終了が並びます。本番切り替えは戻すコストが極端に高いので、必ず守る日として扱い、その手前に持ち寄る日を置きます。
イベントや公開日を持つ案件では、公開日から逆算した「これ以降は内容を変えない日」を1つ立てます。この日が無いと、公開直前まで修正が入り続け、確認する時間が消えます。名前は「内容確定」とし、判定する人を必ず1人決めておきます。
節目の手前に持ち寄る日を置く
節目当日に集まって、そこで初めて足りないものが発覚する。これが最もよくある失敗です。避けるには、節目の2日から3日前に、材料を持ち寄る日を置きます。
持ち寄る日は動かせる日として置き、判定はしません。そろっているかを見るだけです。ここで足りないものが分かれば、節目当日までに埋められます。この1手間を入れるだけで、節目の空振りは大きく減ります。工程表の上では小さな菱形で示し、名前は「材料そろえ」のように、判断ではないと分かる書き方にしておきます。
社外との約束と、社内の目標を分ける
守る日と動かせる日を分けたら、次は日付そのものを二本持ちます。相手に伝えた日と、中で目指している日です。
日付を二本持つ
社外に伝える納品日と、社内で目標にする完成日を同じにすると、余裕がゼロになります。何かが1つ遅れた瞬間に約束が破れる状態です。だから社内の目標日を先に置きます。差は案件の長さと不確実さで決めますが、1か月の案件で3日から5日、3か月の案件で1週間から2週間あたりが実務でよく使われる幅です。
重要なのは、この差を隠さないことです。チームの中では「社内目標は15日、先方への提出は20日」と両方見えている状態にします。隠すと、担当者は社内目標を本当の締切だと思い込み、間に合わないと分かった時点で強い焦りが生まれます。見えていれば、遅れたときに「まだ緩衝が5日ある」と冷静に判断できます。
外部に委託している作業がある場合は、相手からの納品日にも同じ考え方を適用します。相手に伝える期限と、こちらが本当に必要な日を分けておくということです。ただし、余裕を見込んで実際より早い期限を一方的に押し付ける形にすると、取引上の問題になる場合があります。委託の条件や納期の設定については、中小企業庁などが公開している取引に関する資料を確認し、判断に迷う場合は所管の窓口や専門家に確認してください。
余裕をどこに置くか
余裕の置き方には2通りあります。個々の作業に少しずつ足す方法と、まとめて後ろに置く方法です。
個々の作業に足す方法は、一見安全に見えて機能しません。余裕が作業ごとに埋め込まれると、担当者はその余裕まで使い切ります。3日の作業に1日足して4日にすると、4日かかります。そして早く終わった分は次に回りません。結果として、足した余裕は消えたまま、遅れだけが後ろへ積み上がります。
まとめて後ろに置く方法では、余裕は個別の作業に付けず、節目の直前にひとまとまりの期間として置きます。工程表の上では「調整期間」といった名前の帯として見えるようにします。この形なら、余裕が誰のものでもない共有の資源になり、実際に遅れた作業のために使えます。そして、どれだけ食い潰したかが表の上で一目で分かります。残りの緩衝が半分を切ったら注意、ゼロになったら守る日の見直しを相手と相談する、という運用の基準も置けます。
相手にも節目を持ってもらう
工程表の節目は、自分たちがやることだけで埋まりがちです。しかし実際に案件を止めるのは、相手側の作業であることが少なくありません。素材の支給、確認の返答、社内承認の取得といったものです。
だから、相手にお願いすることも節目として置きます。「先方から素材受領」「先方の確認完了」のように、主語を相手にして書きます。そして、その日を過ぎるとこちらの何が止まるのかを1行添えます。「この日を過ぎると、公開日が同じ日数だけ後ろへ動きます」と書いておくのが最も伝わる形です。
この書き方には、遅れたときの会話を楽にする効果があります。相手の返事が5日遅れたとき、非難する言葉を使わずに「この節目が5日動いたので、公開日も同じだけ動きます」と事実だけを示せます。工程表の上に最初から書いてあれば、後出しの言い訳には見えません。逆に、相手の作業を節目に書かずに進めると、遅れの原因がどこにあったのかが後から誰にも分からなくなります。
相手に見せる表と、中で使う表を分ける
社外に共有する工程表と、社内で使う工程表を同じものにするかどうかは、案件によって変わります。同じにする利点は手間が減ることです。分ける利点は、中の細かい遅れをいちいち説明せずに済むことです。
外部に見せる表には、守る日と、相手にお願いすることの期限だけを載せます。相手が知りたいのは「自分がいつ何をすればよいか」と「約束の日が守られそうか」の2つだけです。社内の動かせる日まで見せると、細かい遅れのたびに説明が要り、双方の時間が削られます。
中で使う表には全部を載せます。動かせる日、持ち寄る日、緩衝の帯、担当者、依存関係まで含めます。ここで大事なのは、2つの表が別々に管理されて、片方が古くなる状態を作らないことです。同じデータから見せ方を切り替えられる形にするのが理想で、それが難しければ、社外向けの表を更新するタイミングを節目の直後に固定しておくと、ずれが最小限に収まります。
遅れたときに、どこまで動かすか
節目の設計で最も価値があるのは、遅れる前に「遅れたらどうするか」を決めておくことです。遅れてから相談を始めると、感情と焦りが混ざって判断が鈍ります。
動かす順番を先に決める
遅れが出たときに調整できるものは、大きく3つしかありません。日程を後ろへずらす、投入する人を増やす、やることを削る。この3つのうち、どれをどの順で使うかを、案件の開始時に決めておきます。
多くの受託の現場では、優先順位は「削る、ずらす、増やす」の順になります。人を増やすのが最後になるのは、途中から人を足しても、説明と引き継ぎのコストで短期的にはむしろ遅くなることが多いからです。社内の案件で品質が最優先の場合は「ずらす、増やす、削る」になることもあります。正解は1つではありませんが、決めておくことに意味があります。
この順番を、工程表の脇か、案件の説明ページの冒頭に1行で書いておきます。遅れが出たときに、この1行があるだけで議論が短くなります。
1日ずらすと何日ずれるかを見る
節目を動かす判断には、その節目の後ろに何がぶら下がっているかの把握が要ります。ある作業が1日遅れたときに、最終の守る日が1日ずれるのか、それとも吸収できるのかは、依存関係で決まります。
判断のために見るのは2つです。1つは、その作業が終わらないと始められない作業がいくつあるか。もう1つは、その作業と守る日の間に緩衝がどれだけ残っているか。前者が多く、後者が少ないほど、その遅れは重大です。逆に、後続が無く緩衝が十分にある作業なら、1週間遅れても守る日には影響しません。
ここで工程表の道具が効いてきます。依存関係が線でつながっていれば、1つの作業を後ろへずらしたときに、後続がどこまで動くかがその場で見えます。つながっていない表では、担当者が頭の中で計算することになり、規模が大きくなるほど間違えます。
動かせないときは中身を削る
守る日が動かせず、人も増やせない場合、残るのは削ることだけです。ここで大事なのは、削る候補を遅れてから探さないことです。
案件の開始時に、成果物を「これが無いと成立しないもの」と「あった方がよいもの」に分けておきます。分けるのは、進行をとりまとめる人ではなく、成果物の中身に責任を持つ人と、可能なら発注側です。この線引きを最初にやっておけば、遅れたときの相談が「何を削るか」ではなく「予定通り、あった方がよいものから外します」という確認だけで済みます。
削る判断を先送りすると、全部を中途半端な品質で出すことになります。これが最も損な結末です。守る日に間に合っていて、削った部分が事前に合意されていれば、案件としては成立します。
日程の変更を相手に伝える順番
守る日を動かすと決めたら、伝え方で結果が変わります。順番は決まっていて、状況、原因、影響、案、必要な返事の5つをこの順で書きます。
最初に、いまどこまで進んでいて何が遅れているかという状況を書きます。次に原因を1行で書きます。ここを長くすると言い訳に読まれるので、事実だけにします。そのうえで影響を示します。守る日が何日動くのか、動かさない場合は何が削られるのかを、数字で書きます。
続けて案を出します。案は2つに絞るのが実務的です。日程を動かす案と、日程を守って中身を削る案の2つです。3つ以上並べると、相手が選べずに保留になります。最後に、いつまでにどちらかの返事が要るかを書きます。この期限が無いと、返事待ちの間にさらに日数を失います。
やってはいけないのは、遅れそうだという段階で黙って挽回を試み、挽回できないと確定してから伝えることです。相手側にも調整の時間が要ります。伝えるのが遅いほど、相手が使える手は減ります。
動かした記録を残す
節目を動かしたら、動かした日、動かした理由、新しい日付の3つを残します。工程表の上で日付を書き換えるだけだと、履歴が消えます。
記録が残っていると、次の案件の見積もりが良くなります。同じ種類の遅れが繰り返し起きていることに気づけるからです。よくあるのは、外部からの素材の到着待ち、社内の承認待ち、仕様の確定が動くことの3つで、どれが自分たちのボトルネックかは記録しないと分かりません。
記録の場所は、節目そのものにぶら下げるのが最も探しやすい形です。カードのコメントでも、専用の欄でも構いません。別のファイルに分けると、案件が終わった時点で誰も開かなくなります。
節目が形骸化する原因と、道具の側で見ておくこと
ここまでの設計をしても、運用が2か月続かないことがあります。原因はだいたい決まっています。
1つ目は、節目の更新が特定の1人の作業になっていることです。工程表を1人が引き直している間、他の人はその表を見られません。この構造だと、更新は必ず後回しになり、表と現実がずれます。
2つ目は、作業の場所と工程表が別々になっていることです。担当者が毎日開くのが課題の一覧やチャットで、工程表は月に1度しか開かれない資料になっていると、節目の遅れは工程表に反映されません。入力する人が増えないと、進捗の表はすぐ嘘になります。
3つ目は、節目が多すぎることです。前述の通り、数が増えると個別に見られなくなります。判断が要る点だけに絞るのは、運用を続けるための条件でもあります。
定例会議と節目をつなげる
節目を生かすうえで効果が大きいのに、やられていないことがあります。定例会議の議題を、節目から作ることです。
多くのチームで、週の定例は「各自の進捗報告」で埋まります。順番に話して、聞いた側は自分に関係のない部分を聞き流し、60分が消えます。ここを変えるには、議題を「次の節目までに足りていないもの」に固定します。話すのは、節目の判定に必要な材料のうち、まだそろっていないものだけです。
この形にすると、報告が要らない人は話さずに済み、会議が短くなります。そして節目が近づくほど議題が具体的になるので、当日の空振りが減ります。工程表の上で次の節目がどれかが全員に見えていれば、議題を作る手間もほぼゼロになります。
逆に、定例で節目に一度も触れない運用が続いているなら、その菱形はもう機能していません。誰も見ていない印を表に残しておくと、工程表そのものの信頼が下がります。使っていない節目は消す方が、表は読まれるようになります。
道具を選び直すときに見るところ
この3つのうち、1つ目と2つ目は道具の構造に関わります。判断の材料になるのは、次の点です。
作業の板と工程表が同じデータになっているか。カードの日付を変えたら線が動き、線を動かしたらカードの日付が変わる形なら、二重入力が消えます。転記が要る形だと、更新は誰かの追加業務のままです。
複数人が同時に触れるか。1人が編集している間、他の人が待つ構造だと、更新の頻度は必ず落ちます。
守る日と動かせる日を見た目で分けられるか。色や種別を分けられない道具では、区別を運用の約束だけで維持することになり、人が入れ替わると崩れます。
料金の増え方も、続けられるかどうかに直結します。使いたい機能ごとに上位のプランへ移る形だと、必要になったときに判断が要ります。板にまとめる考え方の道具では、機能で絞らず、区切るのは人数とボードの数だけという形をとっています。金額と上限は変わるので、料金で当日の内容を確認してください。
いま使っている道具のままがよい場合
先に、乗り換える理由が無い場合を書きます。工程表を引くのが月に1度で、担当者は課題の一覧だけを見ていて、それで案件が回っているなら、道具を替える価値は小さいです。既に開発の課題管理と工程表が同じ場所で完結していて、更新が複数人から入っているなら、それも替える理由になりません。
替える価値が出るのは、板でカードを動かしているのに工程表が別のファイルにあり、そこを1人が転記している状態のときです。この状態が続くと、節目の設計をどれだけ丁寧にやっても、表が現実から離れます。
他の道具との違いを1つずつ確認したい場合は、板の使い勝手を軸にしたTrelloとの比較、作業の割り当てと期日の扱いを整理したAsanaとの比較、文書と一覧を1つにまとめる考え方との違いを扱ったNotionとの比較、多機能な運用との違いを見るmonday.comとの比較があります。国内の開発現場でよく使われている道具との違いはBacklogとの比較、国産の板型の道具との違いはJootoとの比較にまとめています。全部をまとめて見たい場合は比較の一覧から入れます。いずれも料金や上限は各社の公式ページで当日の内容を確認してください。
板にまとめる道具の側にも、できないことがある
正直に書いておきます。板と工程表をひとつにまとめる考え方の道具にも、できないことがあります。
ソースコードを置く場所としての機能は持ちません。開発の課題と実装を同じ場所で完結させたいなら、そこは別の道具が要ります。自動化や外部サービスとの連携でも勝負していません。多数の外部サービスと自動でやり取りする運用が中心なら、その領域が強い道具を選ぶ方が結果は良くなります。画面は日本語のみで、海外のメンバーが日常的に触るチームでは実務上の障壁になります。既存の板から自動で取り込めるのも、限られた1つの道具からだけです。移行の手順はTrelloからの移行にまとめています。
できることの範囲を先に確認したい場合はできることを、データの扱いと保管の考え方は安全性の考え方を見てください。導入前に出やすい疑問はよくある質問に集めています。
打ち直すときの手順
最後に、いまの工程表を見直す順番を示します。まず、並んでいる菱形を守る日と動かせる日に振り分けます。次に、守る日それぞれに「誰との約束か」を書き足します。ここまでで、動かせない日がいくつあるかが確定します。
続いて、動かせる日を判断点だけに絞ります。判断が要らないものは菱形をやめて、作業の線の右端に任せます。残った節目に、状態で書いた名前と判定する人を付けます。
そのうえで、守る日の手前に緩衝の帯を置き、社内の目標日を別に立てます。最後に、遅れたときに使う手段の順番を1行で書いておきます。ここまでやると、菱形の数はたいてい半分以下になり、残ったものは全員が意味を説明できる状態になります。工程表が読まれるかどうかは、線の本数ではなく、この「説明できる菱形だけが残っているか」で決まります。
Q1. マイルストーンはいくつ置くのが適切ですか？
判断が必要な点だけに絞るのが基準です。目安として1か月の案件で3個から5個、3か月の案件で6個から10個に収まれば表として読めます。その日を過ぎるとやり直すコストが跳ね上がる箇所だけを節目にして、単なる作業の区切りは線の右端に任せると、この範囲に自然に収まります。
Q2. 守る日と動かせる日は、表の上でどう区別すればいいですか？
見た人が3秒で判断できる形なら方法は問いません。色を分ける、名前の頭に印を付ける、行を上下に分けるなどが実務でよく使われます。大事なのは運用の約束だけで区別を維持しないことです。表の上に見えていないと、担当者が入れ替わった時点で崩れます。
Q3. 社内の目標日と社外に伝える納品日は、どれくらい離すべきですか？
案件の長さと不確実さで決めます。1か月の案件で3日から5日、3か月の案件で1週間から2週間あたりがよく使われる幅です。この差はチームの中では隠さず両方見える状態にしてください。隠すと担当者が社内目標を本当の締切と誤解し、遅れた時点で不要な焦りが生まれます。
Q4. 節目が遅れたとき、どこまで動かしてよいですか？
先に決めておくことが重要です。調整できるのは日程をずらす、人を増やす、やることを削るの3つで、どれをどの順で使うかを案件の開始時に決めて工程表の脇に1行で書いておきます。動かした場合は、動かした日と理由と新しい日付の3つを節目にぶら下げて残すと、次の見積もりに使えます。