
プロジェクトの納期遅延は、多くの現場で繰り返される課題です。タスクや依存関係が増えるほど、どの遅れが納期に直結するかを、即座に判断するのは難しくなります。日付だけの工程表では、重要な経路までは見えてきません。本記事では、納期を左右するクリティカルパスの基本から、工程表への正しい落とし込み方までを実務目線で解説します。
WBSによる作業分解、依存関係の整理、クリティカルパス算出のための前進計算・後退計算・フロート算出の手順に加え、工程表への具体的な書き方と実務で機能させるための運用ポイントまで整理しました。
クリティカルパスの基本と、なぜ工程表に必要なのか

工程表にタスクを並べただけでは、どこが本当に重要なのかは見えてきません。クリティカルパスを理解すると、「遅らせてはいけない作業」が明確になります。
クリティカルパス=納期を決定づける経路
クリティカルパスとは、プロジェクトの開始から完了までを結ぶ作業経路のうち、最も所要時間が長い経路を指します。この経路上のタスクは余裕(フロート)がなく、1日でも遅れれば、そのまま完了日が後ろ倒しになります。例えば、設計→実装→テストが直列依存で最長経路となる場合、それがクリティカルパスです。
ここに遅延が発生すると、他の作業をどれだけ前倒ししても納期は縮まりません。つまり、クリティカルパスは、納期を維持するために優先的に管理すべき作業経路を示すものです。
日付だけの工程表では管理できない理由
日付を並べただけの工程表では、すべてのタスクが同じ重要度で表示されます。しかし実際のプロジェクトでは、「遅れても影響が小さい作業」と「1日遅れるだけで納期に直結する作業」が混在しています。その違いを可視化できないことが、日付中心の工程表の限界です。
比較すると、管理の視点が大きく異なります。
| 比較項目 | 日付だけの工程表 | クリティカルパスを考慮した工程表 |
|---|---|---|
| 管理の焦点 | 各タスクの完了日 | 納期に直結するタスク |
| 遅延リスクの把握 | 遅延が発生して初めて気づく | 事前に影響範囲を特定できる |
| リソース配分 | 重要度が見えず感覚的 | 重要経路へ優先配分できる |
| スケジュール調整 | どこを動かせるか不明 | フロートを踏まえて調整可能 |
| 問題対応 | 場当たり的な対応になりやすい | 影響経路を踏まえ計画的 |
日付中心の工程表は進捗の有無を確認するための道具に留まりますが、クリティカルパスを反映した工程表は納期に影響する経路を特定し、どこを守るべきかを判断するための道具になります。工程管理を受け身の確認で終わらせないためには、この視点が不可欠です。
クリティカルパスの詳細は、以下の記事をご覧ください。
工程表を作る前の準備|書き方で成否が決まる

作業分解・依存関係・所要日数の精度が不十分なままでは、正しい経路は導き出せません。本章では、クリティカルパスを工程表に正しく落とし込むための書き方として、作成前に押さえるべき3つの準備を整理します。
WBSレベルまでタスクを分解する(書き方の土台)
まず行うべきは、成果物を起点にタスクを漏れなく分解することです。WBS(Work Breakdown Structure:作業分解構造図)により、抽象的な工程を具体的な作業単位へ落とし込みます。
| 大項目(フェーズ) | 中項目(成果物) | 小項目(WBSレベルのタスク) |
|---|---|---|
| Webサイト制作 | デザイン | ワイヤーフレーム作成 デザインカンプ作成(PC版) デザインカンプ作成(スマートフォン版) |
| 実装 | HTML/CSSコーディング JavaScript実装 問い合わせフォーム設置 |
「デザイン」「実装」といった抽象的な単位のままでは、遅延の原因を具体的に特定できません。WBSレベルまで作業を分解することで、担当者を明確にし、作業量を適切に見積もり、どの工程で遅れが発生しているのかを正確に把握できる状態が整います。
下記の記事では、WBSの詳細や作成方法について解説しています。
依存関係(FS中心)を整理する(順序の書き方)
次に、タスク同士の前後関係を定義します。依存関係を定めなければ、正しいクリティカルパスは算出できません。
| 依存関係の種類 | 説明 | 具体例 |
|---|---|---|
| 終了-開始 (FS) | 先行タスク完了後に後続開始 | カンプ完了後にコーディング開始 |
| 開始-開始 (SS) | 先行開始後に後続開始 | 設計開始と同時に部品調達開始 |
| 終了-終了 (FF) | 先行完了後に後続完了 | テスト完了と同時にマニュアル完成 |
| 開始-終了 (SF) | 先行開始後に後続完了 | 新システム稼働開始で旧監視終了 |
実務では、まずFS関係を整理するだけでも精度は大きく向上します。依存関係が曖昧な工程表では、遅延の影響範囲を正確に把握できません。
所要日数を現実的に見積もる(簡易PERTの考え方)
最後に、各タスクの所要日数を見積もります。単一の予想日数ではなく、3点見積もりで期待値を算出する方法が有効です。
- 楽観値: 最もスムーズに進んだ場合の日数
- 最頻値: 最も可能性が高いと思われる通常の日数
- 悲観値: 最悪の事態(問題発生など)を想定した日数
| タスク名 | 楽観値 (a) | 最頻値 (m) | 悲観値 (b) | 期待値 (a+4m+b)/6 |
|---|---|---|---|---|
| ワイヤーフレーム作成 | 2日 | 3日 | 5日 | 3.2日→4日 |
| デザインカンプ作成 | 5日 | 7日 | 12日 | 7.5日→8日 |
| コーディング | 8日 | 10日 | 18日 | 11.0日→11日 |
期待値を採用することで、希望的観測に偏った見積もりを排除し、過度なバッファを削減しながら、より客観性の高い計画を立てることが可能になります。
クリティカルパスを意識した工程表の書き方【6ステップ】

準備が整ったら、実際にクリティカルパスを工程表へ落とし込む書き方に沿って特定します。重要なのは、感覚ではなく前進計算・後退計算に基づいて、納期を決定づける経路を導き出すことです。
Step1:タスクを一覧化する
まず、WBSで分解したタスクを整理し、所要日数と依存関係を明確にします。
| プロジェクト例:小規模イベント開催 | |||
|---|---|---|---|
| タスクID | タスク名 | 所要日数 | 先行タスク |
| A | 企画立案 | 3日 | – |
| B | 会場予約 | 2日 | A |
| C | 登壇者交渉 | 5日 | A |
| D | Webサイト制作 | 4日 | B |
| E | 集客・広報 | 7日 | C, D |
| F | 当日運営準備 | 2日 | E |
ここで重要なのは、「何が終わらないと次に進めないか」を明確にすることです。
Step2:依存関係を図式化する
タスク同士をネットワーク図(PERT図)で接続します。視覚化することで、並列作業と直列作業の区別が明確になります。
Step3:所要日数を反映する
各タスクに見積もった日数を記入します。これにより、計算の前提が確定します。
Step4:前進計算(最早開始日 ES / 最早終了日 EF)の書き方
開始日から順方向に計算し、「最短で完了する場合のスケジュール」を求めます。
【計算ルール例】
- 開始タスクのES=0
- EF=ES+所要日数
- 後続タスクのES=先行タスクのEFの最大値
| タスクID | 所要日数 | 先行タスク | 最早開始日 (ES) | 最早終了日 (EF) |
|---|---|---|---|---|
| A | 3 | – | 0 | 3 (0+3) |
| B | 2 | A | 3 (AのEF) | 5 (3+2) |
| C | 5 | A | 3 (AのEF) | 8 (3+5) |
| D | 4 | B | 5 (BのEF) | 9 (5+4) |
| E | 7 | C, D | 9 (CとDのEFの最大値) | 16 (9+7) |
| F | 2 | E | 16 (EのEF) | 18 (16+2) |
この計算により、プロジェクト全体の最短完了日数が18日であることがわかります。
Step5:後退計算(最遅開始日 LS / 最遅終了日 LF)の書き方
完了日から逆算し、「どこまで遅らせられるか」を算出します。
【計算ルール例】
- 最終タスクのLF=プロジェクト完了日(18日)
- LS=LF-所要日数
- 先行タスクのLF=後続タスクのLSの最小値
| タスクID | 所要日数 | 後続タスク | 最遅終了日 (LF) | 最遅開始日 (LS) |
|---|---|---|---|---|
| F | 2 | – | 18 | 16 (18-2) |
| E | 7 | F | 16 (FのLS) | 9 (16-7) |
| D | 4 | E | 9 (EのLS) | 5 (9-4) |
| C | 5 | E | 9 (EのLS) | 4 (9-5) |
| B | 2 | D | 5 (DのLS) | 3 (5-2) |
| A | 3 | B, C | 3 (BとCのLSの最小値) | 0 (3-3) |
Aは最遅開始日(LS)が0のため、開始を1日でも遅らせるとプロジェクト全体の完了日(18日)に影響します。
Step6:フロートを算出し、クリティカルパスを特定する
フロート=LS-ES、フロートが0のタスクが「遅延不可」の作業です。
| タスクID | ES | LS | フロート (LS – ES) | クリティカルパス |
|---|---|---|---|---|
| A | 0 | 0 | 0 | ● |
| B | 3 | 3 | 0 | ● |
| C | 3 | 4 | 1 | |
| D | 5 | 5 | 0 | ● |
| E | 9 | 9 | 0 | ● |
| F | 16 | 16 | 0 | ● |
計算の結果、クリティカルパスはA→B→D→E→Fで、全体期間は18日と確定しました。タスクCには1日のフロートがあり、1日以内であれば納期に影響しません。
このように算出には複数の計算工程が必要であり、依存関係やタスク数が増える実務では手作業での管理は非現実的なため、多くの現場ではツールによる自動計算を前提に運用しています。
Excelで作るクリティカルパス工程表の書き方

専用ツールがなくても、Excelなどの表計算ソフトでクリティカルパスを工程表に落とし込むことは可能です。ただし前提となるのは、依存関係と前進・後退計算のロジックを正しく設計する書き方を理解していることです。本章では、実務で使える最小構成と数式設計の考え方を整理します。
必要な列構成(そのまま使えるテンプレ)
まずは以下の列構成でシートを作成します。クリティカルパス算出に必要な情報はすべてここに集約します。
| No | タスク名 | 担当者 | 所要日数 | 先行タスクNo | 最早開始日 | 最早終了日 | 最遅開始日 | 最遅終了日 | フロート |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 企画立案 | A | 3 | ||||||
| 2 | 会場予約 | B | 2 | 1 | |||||
| 3 | 登壇者交渉 | A | 5 | 1 | |||||
| 4 | Web制作 | C | 4 | 2 | |||||
| 5 | 集客・広報 | B | 7 | 3, 4 | |||||
| 6 | 当日運営準備 | 全員 | 2 | 5 |
重要なのは、「先行タスクNo」を必ず記載することです。ここが曖昧だと計算できません。
前進計算・後退計算のロジック
計算列に数式を組み込むことで、手計算の負担を軽減できます。ただし、Excelの関数だけでは複雑な依存関係(先行タスクが複数ある場合など)を完全に自動化することは難しく、一部は手動での調整が必要になる場合があります。
| 計算列 | 数式の考え方の例(No.5 集客・広報の場合) |
|---|---|
| 最早開始日 (F5) | 先行タスク(No.3とNo.4)の最早終了日の最大値/=MAX(G3,G4) |
| 最早終了日 (G5) | =F5+D5 |
| 最遅終了日 (I5) | 後続タスク(No.6)の最遅開始日。=H6 |
| 最遅開始日 (H5) | =I5-D5 |
| フロート (J5) | =H5-F5 |
実際の数式は、VLOOKUP関数などを組み合わせることで、より汎用的に作成できます。
条件付き書式でクリティカルパスを色分けする方法
前進計算・後退計算によってフロートが算出できたら、次はクリティカルパス(フロート=0のタスク)を視覚的に強調します。Excelの条件付き書式を使えば、自動で色分けできます。
- 色を付けたい範囲(例:A列からJ列まで)を選択する
- リボンのホームタブから条件付き書式→新しいルールを選択する
- ルールの種類で「数式を使用して、書式設定するセルを決定」を選択する
- 数式入力欄に=$J2=0と入力する(J列がフロートの列、2が行の開始番号)
- 書式ボタンを押し、好きな塗りつぶしの色(赤や黄色など)を設定する
- OKをクリックして完了
これにより、フロートが0のタスク(クリティカルパス上のタスク)が自動で強調表示され、納期に直結する重要工程を一目で判別できます。
Excel管理の限界|書き方だけでは解決できない理由

Excelは、クリティカルパスの書き方や計算ロジックを理解する教材としては有効です。しかし、実務で工程表として継続運用するには限界があります。特に計画変更や遅延発生時の更新負荷が大きく、修正作業に追われて管理そのものが目的化しやすい点が課題です。
遅延が発生したときに起きる手動修正の連鎖
タスクが遅延すると、後続工程の開始日・終了日を順に修正する必要があります。依存関係が多いほど影響範囲は広がり、修正漏れや参照ミスが発生しやすくなります。更新作業そのものが新たなリスクとなり、管理負荷を高めるのです。
依存関係が形骸化し、工程表が使われなくなる理由
仕様変更や優先度の見直しが重なると、手動修正が追いつかず、工程表と実態が乖離します。依存関係が正しく反映されない状態では納期判断に使えません。結果として現場から信頼を失い、工程表は形だけの資料になります。
進捗更新だけで日程が再計算される重要性
実務で機能する工程表は、進捗更新と同時に後続工程が自動再計算される仕組みを備えています。遅延の波及を即座に可視化できれば、クリティカルパスも常に最新状態に保たれます。自動連動こそが管理の前提です。
Lychee Redmineなら、クリティカルパスを自動算出・自動更新できる工程表へ
Excelでは、WBS・依存関係・工数が分断されやすく、更新のたびに整合性が崩れるリスクがあります。Lychee Redmineは、これらを一体化することで、計画と実績の乖離を防ぎます。
WBS・ガントチャート・依存関係・工数を一元化し「更新負荷」を解消
Lychee Redmineでは、タスク分解(WBS)・スケジュール(ガントチャート)・依存関係・工数実績が同一データ上で連動します。
| 課題 | 解決内容 |
|---|---|
| WBS(作業分解)と日程が別管理 | WBSとガントチャートが自動連動 |
| 依存関係が形骸化 | 線で設定し即時反映 |
| 実績が判断に使えない | 工数と計画を同時表示 |
| 修正の手間が大きい | 変更が全体に自動反映 |
一箇所の変更が全体に反映されるため、手動修正の連鎖が発生しません。
遅延の影響範囲とボトルネックを即時把握
Excelでは、あるタスクの遅延がどこまで波及するかを都度確認する必要があります。Lychee Redmineでは、期間変更と同時に後続タスクが自動スライドし、最新のクリティカルパスが再計算されます。
その結果、
- 納期に直結する経路が即座に把握できる
- 新たなボトルネックが可視化される
- 調整判断を即時に行える
という状態が維持されます。
クリティカルパス工程表の書き方|よくある質問と回答(FAQ)

最後に、クリティカルパスに関してよく寄せられる質問と回答をまとめました。
クリティカルパスはどうやって見つければ良いですか?
重要なのは「計算」よりも「前提の精度」です。WBSレベルまで作業を分解し、依存関係を整理し、現実的な所要日数を設定した上で前進計算・後退計算を行います。その結果、フロートが0になる経路がクリティカルパスです。ただし実務では、タスク数が増えるほど手計算は現実的ではありません。多くの現場では、依存関係を設定するだけで自動算出されるツールを前提に運用しています。
PERTとクリティカルパスはどう違いますか?
PERTは「見積もり精度を高める手法」です。楽観値・最頻値・悲観値から期待値を算出し、現実的な所要時間を導きます。一方、クリティカルパスは「納期に影響する経路を特定する手法」です。PERTで精度を高めた所要時間を用いることで、より実態に近いクリティカルパスを算出できます。両者は対立概念ではなく、見積もりと管理をつなぐ関係にあります。
Excelでも本当に管理できますか?
理論上は可能です。しかし、実務では次の課題が生じます。
- 依存関係が複雑になると数式管理が破綻しやすい
- 変更のたびに再計算・修正が必要
- 工数や進捗との連動が弱い
小規模・短期案件であれば対応可能ですが、案件が増えたり変更が頻発したりすると、更新が追いつかず工程表が形骸化します。クリティカルパスを「考え方」として学ぶにはExcelは有効です。しかし、運用で機能させ続けるには自動連動できる環境が前提になります。
クリティカルパス工程表はExcelで理解し、運用段階でツールへ移行する

クリティカルパスを反映した工程表は、納期を左右する経路を明確にする有効な手法です。しかし実務では仕様変更や遅延が日常的に発生するため、手動更新を前提としたExcel管理には限界があります。修正のたびに再計算が必要となり、整合性が崩れやすくなるのが実情です。
まずはExcelで前進計算・後退計算を用いたクリティカルパス工程表の書き方を理解することが重要です。その上で、依存関係や進捗に応じて日程が自動更新されるツールへ移行することが、実務における現実的な選択と言えます。
30日無料トライアルをはじめる
- 多機能ガントチャート/カンバン/バックログ/リソース管理/CCPM/レポートなど
- ・ クレジットカード登録不要
- ・ 期間終了後も自動課金なし
- ・ 法人の方のみを対象
このサイトはreCAPTCHAによって保護されており、Googleのプライバシーポリシーと利用規約が適用されます。




