進捗の遅れに気づくのが遅いチームへ。締め切り前に出る3つのサイン

進捗管理表もツールも用意してあるのに、遅れが表面化するのは締め切りの直前です。毎週の報告では「順調です」と聞いていたのに、最後の1週間で「間に合いません」が出てくる。多くのチームが同じところで詰まっています。

原因は、報告のサボりでも担当者の甘さでもなく、見ている指標が遅れを映さないことにあります。この記事では、締め切りより前に出る3つのサインと、それを週に5分で確認する手順をまとめます。

完了率が上がっていても、遅れは見えない

進捗の指標としてよく使われるのが完了率です。終わったタスクの数を全タスクの数で割ったもので、多くのツールが自動で出してくれます。

ただ、完了率の分子が増えるのはタスクが終わったときだけです。着手して途中で止まっているタスクも、まだ手をつけていないタスクも、完了率の上では同じ「0」として扱われます。つまり完了率は、詰まっているタスクの存在を教えてくれません。

そのため完了率は、締め切りの直前まできれいな線を描き、最後にまとめて崩れます。週次の報告で「70%まで来ました」と聞いていたのに、残りの30%に3週間分の作業が詰まっていた、というのはこの形です。

計画どおりに終わらないこと自体は、めずらしくありません。一般社団法人日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2025」（2024年度調査）は、東証上場企業とそれに準じる企業981社の回答をもとに、システム開発の工期を規模別に集計しています。100人月未満（1人が1か月で終わる作業量を1人月と数えます）の規模では「予定どおり完了」が31.0%、「ある程度は予定どおり完了」が52.4%、「予定より遅延」が16.6%でした（回答694件）。規模が上がると「予定どおり完了」はさらに下がり、100〜500人月未満で16.0%、500人月以上で11.0%です。

100人月未満で見ると、大半は「予定どおり完了」か「ある程度は予定どおり完了」に収まっているものの、当初の計画のまま最後まで進むほうは3割ほど、という形です。同調査は、2015年度から2024年度までの10年間の推移で、すべてのプロジェクト規模において「予定どおり完了」の割合が低下傾向にあると報告しています。

この数字はシステム開発を対象にしたもので、回答企業も上場企業が中心です。それでも、計画どおりぴったりに終わるほうが少ない、という形自体は他の業務でも見覚えがあるのではないでしょうか。だとすれば、見るべきなのは「遅れたかどうか」ではなく、遅れの兆候が出ているかどうかです。

サイン1: 着手予定日を過ぎても、まだ始まっていない

1つめのサインは、始まる予定だったのに始まっていないタスクです。

タスクに期限だけを入れていると、そのタスクは期限日の当日まで「まだ大丈夫」に見えます。3日で終わる想定の作業なら、残り3日を切る前に始まっていないと間に合いません。ところが期限しか入れていないと、その日を過ぎたことは誰にも見えず、気づくのは期限の前日です。

ここで効くのが開始日（着手予定日）です。期限とセットで開始日を入れておくと、遅れは期限より何日も前に姿を現します。条件はこれ1つ、「開始日が今日より前なのに、状態が未着手のままのタスク」です。多くのツールでは、この作業の状態を「ステータス」と呼び、未着手をTODO、着手中をDOING、完了をDONEのように表します。

このサインが役に立つのは、担当者に聞かなくても分かることです。報告を待つ必要がなく、誰かが「遅れています」と言い出す勇気を出すのを待つ必要もありません。

開始日を決めるときは、作業日数を見積もってから期限日から逆算します。3日かかる作業で期限が金曜なら、開始日は水曜です。ここを空欄にしたままだと、サイン1は使えません。

着手が遅れる理由は、たいてい見積もりが甘かったか、別の割り込みが入ったかのどちらかです。サイン1が出たら、その2つを先に確かめます。

サイン2: 期限を2回以上動かしている

2つめのサインは、期限を動かした回数です。着手したまま止まっているタスクは、たいてい先に期限のほうが動きます。ステータスはDOINGのままなので未着手の数には出てきませんが、期限を動かした回数を数えていれば、そちらで拾えます。

期限が1回動くのは、ふつうに起こります。見積もりが少し外れた、別の急ぎが入った、という理由なら、動かして先に進むほうが合理的です。

問題は2回目です。同じタスクの期限が2度動いているとき、詰まっているのはたいてい作業そのものではなく、その手前にある前提のほうです。仕様が決まっていない、確認の返事が来ていない、担当者に空きがない。作業時間を足しても解決しないので、3回目も動きやすくなります。

期限を2回動かしたら、作業ではなく前提を疑う。そう決めておくと、その場の判断が要らなくなります。動かした回数は自動では残らないことが多いので、タスクに数値の管理項目を1つ足して、期限を動かした人がその場で1を足す運用にしておくと数えられます。

サイン3: 未完了が1人に偏っている

3つめは、人の側を見ます。担当者ごとに未完了のタスクがいくつ残っているかを並べて、数を比べるだけです。

これは個人の速さの話ではありません。割り振った結果として、1人に5件、他のメンバーに1件ずつ、という状態ができていることがあります。この状態だと、5件持っている人の1件が詰まっただけで、後ろに並んだ4件がまとめて遅れます。

タスクを付箋のように並べて列で分ける表示を、カンバンボードといいます。この列を担当者ごとにすると、持ち分の偏りが列の高さの違いとして一目で分かります。

偏りが見つかったら、動かすのはタスクのほうです。持ちすぎている人から、まだ着手していないタスクを1件か2件、他のメンバーに移します。着手済みのタスクを移すと引き継ぎのコストが乗るので、動かすなら未着手のものからです。

3つのサインを、週に5分で見る

3つのサインは、それぞれ絞り込みの条件が決まっています。まとめると次のようになります。

サイン	見る条件	出たときに疑うこと
1. 着手が止まっている	開始日が今日より前で、ステータスが未着手	見積もりの甘さ、または割り込み
2. 期限を動かしている	期限の変更回数が2回以上	作業ではなく、その手前の前提
3. 持ち分が偏っている	担当者ごとの未完了タスク数	割り振りのバランス

この3つを見るのに必要なのは5分ほどです。大事なのは頻度と、見たあとの決めごとのほうです。

曜日と時刻を先に決めます。「毎週月曜の朝いちばん」のように固定すると、忙しい週に飛ばされにくくなります。プロジェクトの期間が1か月を切っているなら、週2回に増やす形もあります。

いくつ出たらどうするかも、先に決めておきます。たとえば「着手が止まっているタスクが3件を超えたら、その週の予定を組み直す」「期限を2回動かしたタスクが出たら、担当者ではなく前提を確認する場を作る」といった形です。基準を先に決めておくと、報告を受けた側が「これは報告すべきか」と迷わずに済みます。

見つけたサインへの対応でひとつ気をつけたいのは、サインが出た担当者を責める場にしないことです。サインは仕組みが拾うものなので、拾えたこと自体は成功です。ここで詰問すると、次からステータスの更新が止まり、サインそのものが出なくなります。

タスクマンで3つのサインを見るための設定

タスクマンでこの運用をする場合、用意するものは3つです。

1つめは、開始日と期限を両方入れること。タスクには期限と開始日の両方を設定できます。開始日を空欄にしないことが、サイン1の前提になります。

2つめは、ステータスと期限の変更回数。プロジェクトを作ると、ステータス（TODO / DOING / DONE）と優先度（高 / 中 / 低）のカスタムフィールドが自動で作られます。カスタムフィールドは、プロジェクトごとに自由に足せる管理項目のことです。ここに数値型のフィールドを1つ追加して「期限変更回数」とすれば、サイン2で使えます。数値は範囲でフィルタできるので、2以上のタスクだけを絞り込めます。

3つめは、担当者別のカンバン。カンバンボードは担当者別・ステータス別などで列を分けられます。担当者別に切り替えれば、サイン3の偏りが列の高さとして見えます。

リスト表示ではカラムをカスタマイズできるので、開始日・期限・ステータス・期限変更回数の4つにカラムを絞っておくと、週次の5分がさらに短くなります。

なお、進捗管理表そのものの列をこれから決める段階であれば、進捗管理表のテンプレートを探す前に。決めておく5つの項目もあわせてご覧ください。

まとめ

遅れに気づくのが遅くなるのは、完了率が「終わったもの」しか映さないからです。締め切りより前に出るサインは3つあります。

• 開始日を過ぎても着手されていないタスク
• 期限を2回以上動かしているタスク
• 未完了が1人に偏っている状態

どれも、担当者の報告を待たずにタスクの一覧から拾えます。曜日と時刻、そして「いくつ出たらどうするか」を先に決めておけば、週5分の確認で、締め切りの直前に慌てる回数を減らせます。

まずは今のプロジェクトを開いて、開始日が空欄のタスクがいくつあるかを数えるところからはじめてみてください。