タスクの依存関係とクリティカルパス｜待ち時間を含めて予定を組む

2026年10月12日

ある作業が遅れたとき、全体納期も同じだけ遅れるとは限りません。後続作業が待っているのか、別の経路がまだ長いのか、担当者の空きはあるのかを確認する必要があります。タスクの依存関係を整理すると、急いで解消すべき待ちが見えます。

この記事では、すべて開始条件が明確な小さな計画を使って、クリティカルパスの考え方を説明します。日数は説明用です。複雑な案件では、実際のカレンダー・資源・並行作業の制約を加味してください。

Contents

依存関係は「前の作業名」ではなく受け渡す条件

「設計の次に開発」とだけ書くと、設計全体の完成を待つのか、特定部分の合意で着手できるのか分かりません。「通知先一覧の承認後に、通知設定を確定する」のように、後続が必要とする条件を書きます。

先行作業の未完了が必ずしも全面停止を意味するわけではありません。未決の部分を分離し、安全に着手できる部分があるかを担当同士で確認します。ただし、仮置きで始めるなら、前提が変わった場合の手戻りも予定に入れます。

説明を簡単にするため、各作業は先行作業の完了後に始まり、日数は同じ営業日単位、担当者の競合はないと仮定します。Aの後にBとCを並行し、DはBを、EはDとCの両方を待つ計画です。

作業	日数	開始条件	最早の終了時点
A：要件確認	2日	開始時点	2日目の終わり
B：画面作成	3日	Aが完了	5日目の終わり
C：運用案内作成	2日	Aが完了	4日目の終わり
D：動作確認	2日	Bが完了	7日目の終わり
E：公開準備	1日	CとDが完了	8日目の終わり

小さい画面では表を横にスクロールできます。

A→B→D→Eは2＋3＋2＋1＝8日、A→C→Eは2＋2＋1＝5日です。長い方の8日経路が、この条件で全体の終了を決めます。これがクリティカルパスです。

Cは4日目に終わっても、EはDが終わる7日目まで始められません。この例ではCの終了が3日遅れても、他の条件が同じなら全体終了は変わりません。ただし、Cに4日以上の遅れが出ると、C側が全体を決める経路へ変わります。

重要度は事業・品質・安全などの観点です。クリティカルパスは、現在の計画で全体期間を決める経路という日程の概念です。期間に余裕がある仕事でも、法令対応やセキュリティ確認を省略してよいわけではありません。

複数の経路が同じ最長期間になる場合もあります。また、予定を更新すれば、これまで余裕があった経路がクリティカルになることもあります。初期計画で赤くした行だけを監視し続けないようにします。

先ほどの表でBとCを同じ人が担当し、並行できなければ、8日という計算をそのまま使えません。レビュー者が週に一度しか確認できない場合や、同じテスト環境を別チームが使う場合も、待ちが生まれます。

依存関係の横に、必要な担当・環境・判断者・受け渡し日時を置きます。単純な「完了してから開始」だけで表現できない関係は、担当と一緒に条件を説明し、使用する計画ツールの機能で表せるかを確認します。

待ち時間を作業工数に混ぜると、どこを短縮すればよいかが分からなくなります。承認待ちを減らす相談と、作成時間を減らす相談は、相手も対応方法も違います。

「Bが1日遅れます」で止めず、「Dの開始とEの公開準備が1日後ろへ動く見込み」と伝えます。そのうえで、Bの対象を分割できるか、確認を一部先行できるか、公開時期を調整するかを相談します。

短縮案は、品質条件や作業順序を無視して成立するものではありません。確認を削る案には残るリスクと承認が必要です。人数を増やす案も、仕事を分けられるか、説明やレビューが増えないかを見ます。

先行ID	後続ID	受け渡す条件	予定日	担当窓口	遅れた場合の影響	代替案	未決事項

依存表の役割は、誰を急かすかを決めることではなく、全体を止めている条件を見つけることです。全体日程の予測は、最新の残作業と制約を入れて更新してください。

依存作業の最長経路という概念を確認しました。所要日数は説明用で実績ではありません。 Atlassian：Critical Path Method（確認日：2026年10月11日）。記入例・確認表は当サイトが説明用に作成したもので、実在の案件・実績ではありません。

週次報告書の書き方も必要な作業に合わせて参照してください。

アイキャッチ写真：2H Media / Unsplash。職場の実写ではなくイメージ写真です。

よかったらシェアしてね！