プロジェクト・ネットワーク図

英語名 Project Network Diagram
読み方 プロジェクト ネットワーク ダイアグラム
難易度
所要時間 初回作成2〜4時間
提唱者 CPM(Critical Path Method)・PERTネットワーク
目次

ひとことで言うと
#

プロジェクトのタスクをノード(箱)と矢印(依存関係)で結んだ図。どのタスクが完了しないと次に進めないかを可視化し、最も時間がかかる経路(クリティカルパス)を特定することで、遅延リスクの管理とスケジュール最適化を実現する。

押さえておきたい用語
#

押さえておきたい用語
ノード(Node)
ネットワーク図上で1つのタスクを表す箱。タスク名・所要時間・最早開始日・最遅完了日などを記載する。
依存関係(Dependency)
あるタスクが別のタスクの完了を前提とする関係。FS(完了→開始)が最も一般的。
クリティカルパス(Critical Path)
全タスクの中で最も長い経路。この経路上のタスクにはスラック(余裕)がゼロであり、1日の遅延がPJ全体を1日遅らせる。
スラック(Float / Slack)
タスクが遅延しても全体スケジュールに影響しない余裕時間を指す。スラック=最遅開始日−最早開始日。

プロジェクト・ネットワーク図の全体像
#

ネットワーク図の構成と読み方
Webサイト制作のネットワーク図(例)A: 要件定義5日スラック: 0B: デザイン8日スラック: 0C: 原稿作成4日スラック: 4日D: コーディング10日スラック: 0E: テスト5日スラック: 0クリティカルパス: A → B → D → E = 28日C(原稿作成)は4日のスラックがあり、遅延してもPJ全体に影響しないクリティカルパス(スラック=0)非クリティカル(スラックあり)ノードの読み方タスク名 / 所要日数 / スラック(0ならクリティカルパス上)
ネットワーク図の作成フロー
1
タスク洗い出し
WBSを元に全タスクと所要時間を一覧化
2
依存関係の定義
各タスクの先行・後続タスクを矢印でつなぐ
3
前進パス・後退パス計算
最早開始日と最遅完了日を算出しスラックを求める
クリティカルパス特定
スラック=0のタスクを結んだ最長経路を明示

こんな悩みに効く
#

  • タスクの順番が不明確で、手待ちや手戻りが発生する
  • どのタスクが遅れると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)
  • バッファはクリティカルパスの最後に集約(各タスクに分散させない)
  • 並行化できるタスクがないか再検討し、クリティカルパスを短縮する

具体例
#

例1:Web制作会社がネットワーク図で並行作業を最適化する

状況: ECサイトのリニューアル案件(当初見積もり 45日)。タスクを全て直列に並べてガントチャートを作ったが、クライアントから「35日で完了できないか」と依頼。

ネットワーク図で並行化を検討

  • クリティカルパス: 要件定義(5日)→デザイン(8日)→コーディング(10日)→テスト(5日) = 28日
  • 非クリティカル: 原稿作成(4日)、写真撮影(3日)はデザインと並行可能
  • 直列にしていた「CMS設定」をコーディングと並行化
計画全体期間クリティカルパス
変更前(全直列)45日45日
変更後(並行化)30日28日

並行化により 15日短縮。35日の期限に2日のバッファ付きで収まり、受注を獲得。

例2:製造業の工場移転でクリティカルパスの遅延を事前防止する

状況: 工場移転PJ(期間6か月)。100以上のタスクがあり、どれが遅れるとPJ全体に影響するか不明。前回の工場移転では「搬入の順番を間違えて3週間のやり直し」が発生。

ネットワーク図の作成結果

  • 全122タスクの依存関係を図示
  • クリティカルパス: 設計→発注→搬入→設置→動作確認→試運転 = 152日
  • 「搬入」と「設置」の間に「床面補修」が必要だが、見落とされていた

クリティカルパス上の「床面補修」(10日)を事前に発見し、搬入前に着手する計画に修正。結果、移転は予定通り 148日 で完了。前回のような「順番間違い」はゼロ。

例3:個人のフリーランスが3案件の依存関係を整理する

状況: フリーランスのデザイナー。ロゴ制作・LP制作・パンフレット制作の3案件を同時進行。「LP制作はロゴが決まらないと着手できない」「パンフレットはLPのデザインを流用する」という依存関係があるが、頭の中だけで管理していて混乱。

手書きのネットワーク図で整理

  • ロゴ(5日) → LP(8日) → パンフレット(4日) = クリティカルパス 17日
  • ロゴの初稿をクライアントに出した後、LP制作にすぐ着手(ロゴの最終版を待たない)
  • パンフレットの「テキスト部分」はLP制作と並行して進める

全3案件を 15稼働日 で納品。ネットワーク図は紙1枚に手書きしたものだが、「依存関係が見えるだけで、何から手をつけるか迷わなくなった」と実感。

やりがちな失敗パターン
#

  1. 全てのタスクを直列に並べる — 並行化できるタスクまで直列にすると、期間が無駄に長くなる。先行タスクが本当に完了しないと着手できないか確認する
  2. 依存関係を過剰に設定する — 「念のため」でFS依存を増やすと、クリティカルパスが長くなり柔軟性が失われる。本当に必要な依存だけを設定する
  3. クリティカルパス以外のタスクを放置する — スラックがあるタスクも遅延が重なるとクリティカルパスが入れ替わる。「スラックの残日数」を定期的に確認する
  4. 一度作ったら更新しない — 実績が出るたびにネットワーク図を更新し、クリティカルパスの変化を追跡する

まとめ
#

プロジェクト・ネットワーク図は、タスクの依存関係とクリティカルパスを「見える化」するツールだ。並行化できるタスクを発見して期間を短縮し、クリティカルパス上のタスクにリソースとモニタリングを集中させることで、限られた時間を最大限に活用できる。ツールはMS ProjectやSmartsheetが便利だが、紙に手書きでも十分に機能する。