【PM必見】プロジェクトの「見えない遅延」を可視化する|PDM(プレシデンスダイアグラム法)実践ガイド
「WBSは作ったけれど、どの作業が遅れるとマズいのかが見えない」
「並行して進められる作業を整理して、なんとか工期を短縮できないか?」
プロジェクトの全容を把握し、論理的な裏付けを持ってスケジュールを管理するために欠かせないのが「プレシデンスダイアグラム法(PDM)」です。
タスクのリスト(WBS)を作るだけでは、作業同士の「縛り」や「余裕」は見えてきません。今回は、PMやリーダーが現場ですぐに使えるよう、PDMの基本からスケジュールを最適化する活用ポイントを解説します。
プレシデンスダイアグラム法(PDM)とは
PDMとは、アクティビティ(作業)の順序や依存関係を可視化したネットワーク図の一種です。各作業を「ノード(箱)」で表し、それらを「線(矢印)」で結ぶことで、「どの作業が終わらないと次へ進めないのか」を一目で把握できるようにします。
現在のPMツール(Microsoft Project、Backlog、Asana等)の多くもこの方式(AON形式)を採用しており、現場で最も馴染みのある形式です。
ネットワーク図の種類(AOAとAONの違い)
作業のつながりを表すネットワーク図には、大きく分けて2つの記述方式があります。現場で混同しないよう、それぞれの特徴とサンプルの違いを押さえておきましょう。
AOA:アクティビティ・オン・アロー(矢印上に作業)
矢印(アロー)の上に作業内容を記述する伝統的な方式で、「アローダイアグラム」とも呼ばれます。
- 特徴: 結合点(ノード)は「イベント(マイルストーン)」を表します。
- 現場での注意点: 論理的な接続だけを示す「ダミー作業(点線の矢印)」が必要になることがあり、図が複雑になりやすい側面があります。

AON:アクティビティ・オン・ノード(箱の中に作業)
箱(ノード)の中に作業内容を記述し、矢印は単純に前後関係のみを表す方式です。プレシデンスダイアグラム法(PDM)はこの「AON」に該当します。
- 特徴: ノードの中に作業名、期間、担当者などの属性を書き込みやすく、直感的です。
- メリット: 複雑なダミー作業を置く必要がなく、論理的な矛盾が起きにくいため、現代のプロジェクト管理ツールの標準となっています。

プレシデンスダイアグラム法の記号と表現方法
PDMは、以下の要素を組み合わせて構成されます。
| アイテム説明 | 表し方(図の例) |
|---|---|
| アクティビティ・ノード 作業そのものを表す箱です。作業名、作業番号、所要期間(工数ではなく期間)を記述します。 | ![]() |
| マイルストーン 重要な節目を表します。実作業ではないため、所要期間はゼロです(例:要件定義承認、本番環境リリースなど)。 | ![]() |
| 並行関係 同時に実施できる作業は、上下に並べて表記します。 | ![]() |
| 前後関係 作業を順に進める場合は、先行から後続へ矢印を引きます。 | ![]() |
| 並行・前後関係 「AとDの両方が終わってからFが始まる」といった、複雑な合流や分岐も表現可能です。 | ![]() |
ネットワーク図の階層化と親子関係
大規模なプロジェクトでは、すべての作業を一つの図に描こうとすると非常に煩雑になり、全体像が見えなくなります。そのため、ネットワーク図を「階層化」して管理するのが一般的です。
- 上位レベル: プロジェクト全体のマイルストーン(主要な節目)を中心に配置します。
- 下位レベル: 上位のマイルストーンをブレイクダウンし、詳細なアクティビティに分解したネットワーク図を作成します。
整合性を保つための「親子関係」
下位の図にあるすべてのアクティビティが完了して初めて、上位レベルの親マイルストーンが完了するという親子関係を維持することが、スケジュール管理の整合性を保つコツです。
現場の「無理・無駄」を暴く4つの依存関係
PDMの最大の利点は、単なる「終わったら次」という関係以外に、4つのパターンを表現できる点にあります。これを知るだけで、スケジュールの「詰め所」が変わります。
| 依存関係(略称) | 説明・現場での 活用シーン | パターン事例 |
|---|---|---|
| 終了一開始(FS) | 最も一般的 「作業Aが終わったら、作業Bを開始できる」 例:要件定義が終わらないと、設計には着手できない。 | ![]() |
| 開始一開始(SS) | 並行作業を促進 「作業Aが始まったら、作業Bも開始できる」 例:画面設計が始まれば、関連するDB定義も並行して着手できる。 | ![]() |
| 終了一終了(FF) | 品質とゴールの同期 「作業Aが終わるまで、作業Bを終わらせることができない」例:全機能のテストが終わらないと、総合品質報告書の作成は完了できない。 | ![]() |
| 開始一終了(SF) | 特殊な切り替え 「作業Aが開始されるまで、作業Bを終了できない」 例:新システムの稼働が始まるまで、旧システムの保守運用は終了できない。 | ![]() |
| 依存関係 | 略称 | 説明・現場での 活用シーン | パターン事例 |
|---|---|---|---|
| 終了一開始 | FS | 最も一般的 「作業Aが終わったら、作業Bを開始できる」 例:要件定義が終わらないと、設計には着手できない。 | ![]() |
| 開始一開始 | SS | 並行作業を促進 「作業Aが始まったら、作業Bも開始できる」 例:画面設計が始まれば、関連するDB定義も並行して着手できる。 | ![]() |
| 終了一終了 | FF | 品質とゴールの同期 「作業Aが終わるまで、作業Bを終わらせることができない」例:全機能のテストが終わらないと、総合品質報告書の作成は完了できない。 | ![]() |
| 開始一終了 | SF | 特殊な切り替え 「作業Aが開始されるまで、作業Bを終了できない」 例:新システムの稼働が始まるまで、旧システムの保守運用は終了できない。 | ![]() |
「リード」と「ラグ」で現実に即した調整を行う
論理的な接続だけでは説明できない「待ち時間」や「前倒し」を考慮することで、より精度の高いスケジュールになります。
- ラグ(待ち時間): 作業の間にあえて設ける空き時間。
- 例: サーバを発注してから、納品されるまでにかかる「10日間の待ち時間」など。
- リード(前倒し): 先行作業が終わる前に、後続作業をオーバーラップさせること。
- 例: プロトタイプの作成中、8割方見えた段階で後続のレビュー準備を開始する。

PMがPDMを活用する最大の目的:クリティカルパスの特定
PDMを作成するゴールは、単に図を描くことではなく、「クリティカルパス」を特定することにあります。
- クリティカルパスとは: プロジェクト開始から終了までを結ぶ経路のうち、「所要期間が最も長くなる経路」のことです。
- PMの注目ポイント: このパス上にある作業が1日でも遅れると、プロジェクト全体の終了日も1日遅れます。
現場では、このパス上の作業に最も優秀なリソースを配置したり、進捗を毎日確認したりする「集中管理」が必要になります。
実務で役立つアドバイス:失敗を防ぐチェックポイント
始まりと終わりを「1つ」にする
図が複雑になると、どこにも繋がっていない「浮いたタスク」が発生しがちです。必ず一つの開始ノードで始まり、一つの終了ノードで終わる「一本道」を意識してください。
WBSとの連動を常にチェックする
WBSにある作業が漏れなくネットワーク図に反映されているか、粒度は合っているかを常にチェックしましょう。下位のタスクがすべて完了すると、上位のマイルストーンが完了するという親子関係を維持するのが整合性を保つコツです。
必要な矢印だけに絞る
直接的な依存関係がないものまで繋ぐと、図がスパゲッティ状態になり、クリティカルパスが見えなくなります。「この作業を始めるために、本当にこの作業の完了が必要か?」を常に問い直してください。
まとめ:依存関係の可視化がプロジェクトを救う
プレシデンスダイアグラム法(PDM)は、プロジェクトの「どこにリスクがあるか」を白日の下にさらし、チーム全員が納得感を持って進むための強力な武器になります。
「WBSを作って終わり」にせず、PDMを使って作業のつながりを整理することで、不測の事態にも慌てず、最短ルートでゴールを目指すことができるはずです。
次に読むべきおすすめ記事
スケジュールの「つながり」が見えたら、次は「期間の見積もり」と「具体的なデッドラインの計算」に進みましょう。
- [PERT/CPMによるクリティカルパス特定と見積もり術] PDMで描いた図をもとに、プロジェクトの運命を握る最短ルートを数値で算出します。
- [システムコンテキスト図の書き方|情報の境界線を確定させる] そもそも、そのタスクは「範囲内」ですか?境界線を再確認しましょう。
- [ユースケース図の書き方|現場で迷わないアクター定義のコツ] 機能の価値を再定義し、無駄なタスクを削ぎ落とすヒントが見つかります。









