ひとことで言うと#
プロジェクトのタスクをノード(箱)と矢印(依存関係)で結んだ図。どのタスクが完了しないと次に進めないかを可視化し、最も時間がかかる経路(クリティカルパス)を特定することで、遅延リスクの管理とスケジュール最適化を実現する。
押さえておきたい用語#
- ノード(Node)
- ネットワーク図上で1つのタスクを表す箱。タスク名・所要時間・最早開始日・最遅完了日などを記載する。
- 依存関係(Dependency)
- あるタスクが別のタスクの完了を前提とする関係。FS(完了→開始)が最も一般的。
- クリティカルパス(Critical Path)
- 全タスクの中で最も長い経路。この経路上のタスクにはスラック(余裕)がゼロであり、1日の遅延がPJ全体を1日遅らせる。
- スラック(Float / Slack)
- タスクが遅延しても全体スケジュールに影響しない余裕時間を指す。スラック=最遅開始日−最早開始日。
プロジェクト・ネットワーク図の全体像#
こんな悩みに効く#
- タスクの順番が不明確で、手待ちや手戻りが発生する
- どのタスクが遅れるとPJ全体が遅れるのかわからない
- 並行して進められるタスクを直列にしてしまい、期間が無駄に長い
基本の使い方#
WBSで分解したタスクを一覧にし、各タスクの先行タスクを定義する。
| タスク | 所要時間 | 先行タスク |
|---|---|---|
| A: 要件定義 | 5日 | なし |
| B: デザイン | 8日 | A |
| C: 原稿作成 | 4日 | A |
| D: コーディング | 10日 | B |
| E: テスト | 5日 | C, D |
依存関係のタイプは主に4つ:FS(完了→開始)、FF(完了→完了)、SS(開始→開始)、SF(開始→完了)。最も一般的なFSをまず使い、必要に応じて他のタイプを使う。
ネットワーク図上で2つの計算を行う。
- 前進パス(Forward Pass): 開始から終了に向かって、各タスクの「最早開始日(ES)」と「最早完了日(EF)」を算出
- 後退パス(Backward Pass): 終了から開始に向かって、各タスクの「最遅完了日(LF)」と「最遅開始日(LS)」を算出
- スラック = LS − ES(または LF − EF)
スラックが0のタスクを結んだ経路がクリティカルパス。
クリティカルパス上のタスクに対して以下の対策を講じる。
- リソースを優先配置(最もスキルの高いメンバーをアサイン)
- 進捗を日次で確認(クリティカルパス外は週次でOK)
- バッファはクリティカルパスの最後に集約(各タスクに分散させない)
- 並行化できるタスクがないか再検討し、クリティカルパスを短縮する
具体例#
状況: ECサイトのリニューアル案件(当初見積もり 45日)。タスクを全て直列に並べてガントチャートを作ったが、クライアントから「35日で完了できないか」と依頼。
ネットワーク図で並行化を検討
- クリティカルパス: 要件定義(5日)→デザイン(8日)→コーディング(10日)→テスト(5日) = 28日
- 非クリティカル: 原稿作成(4日)、写真撮影(3日)はデザインと並行可能
- 直列にしていた「CMS設定」をコーディングと並行化
| 計画 | 全体期間 | クリティカルパス |
|---|---|---|
| 変更前(全直列) | 45日 | 45日 |
| 変更後(並行化) | 30日 | 28日 |
並行化により 15日短縮。35日の期限に2日のバッファ付きで収まり、受注を獲得。
状況: 工場移転PJ(期間6か月)。100以上のタスクがあり、どれが遅れるとPJ全体に影響するか不明。前回の工場移転では「搬入の順番を間違えて3週間のやり直し」が発生。
ネットワーク図の作成結果
- 全122タスクの依存関係を図示
- クリティカルパス: 設計→発注→搬入→設置→動作確認→試運転 = 152日
- 「搬入」と「設置」の間に「床面補修」が必要だが、見落とされていた
クリティカルパス上の「床面補修」(10日)を事前に発見し、搬入前に着手する計画に修正。結果、移転は予定通り 148日 で完了。前回のような「順番間違い」はゼロ。
状況: フリーランスのデザイナー。ロゴ制作・LP制作・パンフレット制作の3案件を同時進行。「LP制作はロゴが決まらないと着手できない」「パンフレットはLPのデザインを流用する」という依存関係があるが、頭の中だけで管理していて混乱。
手書きのネットワーク図で整理
- ロゴ(5日) → LP(8日) → パンフレット(4日) = クリティカルパス 17日
- ロゴの初稿をクライアントに出した後、LP制作にすぐ着手(ロゴの最終版を待たない)
- パンフレットの「テキスト部分」はLP制作と並行して進める
全3案件を 15稼働日 で納品。ネットワーク図は紙1枚に手書きしたものだが、「依存関係が見えるだけで、何から手をつけるか迷わなくなった」と実感。
やりがちな失敗パターン#
- 全てのタスクを直列に並べる — 並行化できるタスクまで直列にすると、期間が無駄に長くなる。先行タスクが本当に完了しないと着手できないか確認する
- 依存関係を過剰に設定する — 「念のため」でFS依存を増やすと、クリティカルパスが長くなり柔軟性が失われる。本当に必要な依存だけを設定する
- クリティカルパス以外のタスクを放置する — スラックがあるタスクも遅延が重なるとクリティカルパスが入れ替わる。「スラックの残日数」を定期的に確認する
- 一度作ったら更新しない — 実績が出るたびにネットワーク図を更新し、クリティカルパスの変化を追跡する
まとめ#
プロジェクト・ネットワーク図は、タスクの依存関係とクリティカルパスを「見える化」するツールだ。並行化できるタスクを発見して期間を短縮し、クリティカルパス上のタスクにリソースとモニタリングを集中させることで、限られた時間を最大限に活用できる。ツールはMS ProjectやSmartsheetが便利だが、紙に手書きでも十分に機能する。