案件が3件を超えたあたりから、「どれが遅れそうか」を頭の中だけで把握するのは難しくなります。この記事では、納期から逆算して工程を並べ、遅れの兆候を期日の前に見つけるための6つの手順を、工程の分解粒度や着手予定日の置き方といった具体的な判断基準とともに整理します。
- 案件と納期を並べる 確定納期と仮納期を分けて書き出す
- 工程に分解する 1〜3日で終わる単位まで割る
- 逆算で着手予定日を置く 最終工程から前倒しで日付を埋める
- ガント形式で重ねる 担当者ごとの山と谷を見る
- 週次で着手状況を確認する 着手・残作業・完了見込みを確認する
- 遅延時の見直し基準を決める 誰が何を判断するかを先に決める
なぜ「頭の中の進捗」は破綻するのか
担当者が案件の状況を把握していないわけではありません。問題は、把握している内容が本人の記憶の中にあり、他の人から見えないことです。この状態では次の三つが起こりやすくなります。
- 遅れに気づくのが、納期直前か、先方からの催促を受けたとき
- 誰がどれだけ抱えているか分からず、新規案件の受注可否を判断できない
- 担当者が不在になった瞬間、引き継ぎに数時間かかる
とくに厄介なのは一つ目です。完了日だけを確認していると、遅れに気づくのが遅くなることがあります。着手予定日と実績、残作業、完了見込み、後続工程への影響を合わせて確認します。
進捗の見える化では、着手・完了の実績と残作業を記録し、計画との差を早く見つけます。
手順1〜2：案件を並べ、工程に分解する
納期を2種類に分けて書き出す
まず、進行中の案件をすべて1枚に並べます。このとき納期を「確定納期」と「仮納期」に分けてください。先方と合意済みの日付と、社内で想定しているだけの日付を混ぜると、どこを死守すべきか分からなくなります。
工程の分解粒度
工程は細かすぎても粗すぎても機能しません。目安は次のとおりです。
| 粒度 | 例 | 向き不向き |
|---|---|---|
| 粗い（案件単位） | 「A社案件」 | 遅れが見えない。進捗確認に使えない |
| 適切（1〜3日） | 「初稿作成」「社内レビュー」「修正反映」 | 日次・週次の確認に合う |
| 細かい（数時間） | 「見出し案を作る」 | 更新の手間が管理の負担を上回りやすい |
1〜3日で終わる単位に割ると、週次の確認で「今週やるはずの工程が始まっていない」という判定ができます。また、1工程につき担当者は1人に決めてください。2人以上を割り当てた工程は、どちらも着手していない状態が起きやすくなります。
待ち時間を工程に入れていない計画は、ほぼ確実に遅れます。先方の確認に何営業日かかるかは過去の案件から推定し、日数として置いておきます。
手順3〜4：逆算で着手予定日を置き、重ねて見る
着手予定日の置き方
納期から最終工程を引き、その前の工程を引き、と前倒しで日付を埋めていきます。このとき、すべての工程をぴったり連続させないでください。どこか1か所でも遅れると全体が倒れます。
実務的な置き方の目安は次のとおりです。
- 先方確認を挟む工程の後に、1〜2営業日の余裕を置く
- 最終工程（納品・提出）の前に、まとまった予備日を1枠置く
- 各工程の間に細かく余裕を分散させるより、要所にまとめて置く
余裕を細かく散らすと、各工程で少しずつ使い切ってしまい、最後に残りません。
並べて初めて分かること
案件ごとの工程をガント形式で縦に並べると、横軸の同じ週に同じ担当者の工程が3つ重なっている、といった状況が見えます。これは個別の案件表を見ているだけでは気づけません。
着手予定日は納期から逆算して置き、余裕は細かく散らさず要所にまとめます。
手順5〜6：遅れの兆候を見つけ、見直す基準を決める
週次の確認では、着手と完了の実績に加え、残作業量・完了見込み・阻害要因を確認します。着手予定日を過ぎても着手されていない工程は、その時点で遅延の兆候です。
遅延時の見直し基準
遅れが出たときに毎回ゼロから相談していると、判断が遅れます。あらかじめ基準を決めておきます。
担当者の判断で進める
- 遅れが2営業日以内
- 後続工程に余裕日が残っている
- 確定納期に影響しない
上長・先方に相談する
- 遅れが3営業日以上
- 予備日を使い切っている
- 確定納期そのものを動かす必要がある
日数の線引きは業種や案件の長さで変わります。重要なのは数字そのものより、「誰が判断するか」が事前に決まっていることです。
LINEのやりとりから進捗を拾い上げる
中小企業の現場では、依頼や期日の変更がLINEのトークで流れていくことが少なくありません。そこで決まった内容が管理表に転記されないまま、進捗表と実態がずれていきます。
Lバディは、LINEの会話から依頼と期日を抽出してタスク化し、期日の前にトークへ催促を送ります。登録したタスクは表・カンバン・ガントの形式で管理できるため、この記事で説明した「案件ごとの工程を並べて重なりを見る」という使い方にそのまま当てはめられます。
具体的には、次のような流れになります。
- トークで出た依頼と期日をタスクとして取り込む
- 工程に分解し、それぞれに担当者と着手予定日を持たせる
- ガント表示で案件を縦に並べ、同じ週に集中している工程を探す
- 期日前の催促を、着手漏れの検知に使う
転記の手間が減ると、表の更新が止まりにくくなります。進捗の見える化が続かない原因の多くは、仕組みの良し悪しより更新の手間にあります。
よくある質問
Q: 工程をどこまで細かく分けるべきか迷います。判断の目安はありますか。
A: 1〜3日で終わる単位が目安です。判断に迷う場合は、「週次の確認で、その工程が遅れているかどうかを一言で答えられるか」を基準にしてください。答えられないほど大きい工程は分けます。逆に、更新のたびに何件も触らなければならないほど細かい場合は、まとめたほうが続きます。
Q: 計画どおりに進むことがほとんどありません。ガントで管理する意味はありますか。
A: 計画どおりに進めることが目的ではなく、ずれを早く見つけることが目的です。着手予定日と実績、残作業や完了見込みを定期的に確認すると、遅れの兆候を早めに捉えやすくなります。当初予定を残して見通しを更新し、納期・後続工程・必要な人員への影響と対応を判断してください。
Q: 担当者が更新してくれず、表が古くなってしまいます。
A: 更新の手間と、更新する場所が日常の連絡と離れていることが原因になりやすいです。やりとりが行われている場所からタスクを拾える仕組みにする、工程の粒度を粗めに戻す、確認を週1回の固定時間にまとめる、といった形で負担を下げる方向から見直してください。
まとめ
進捗の見える化では、納期から逆算した着手予定日に加え、着手・完了の実績と残作業、完了見込みを確認することが大切です。工程を1〜3日の粒度に割り、担当者を1人に決め、待ち時間も工程として置く。そのうえでガント形式に並べれば、同じ週に作業が集中している箇所や、着手されていない工程が目に見えます。
あわせて、遅れたときに誰が判断するかという基準を先に決めておくと、相談の往復が減ります。そして何より、更新が止まらない仕組みを選ぶことです。LINEのやりとりからタスクを拾い、ガントで並べて見るという形は、日々の連絡と管理表を切り離さないための一つの選択肢になります。
