PDM（プレシデンスダイアグラム法）の書き方｜見えない遅延を防ぐ実践ガイド
「WBSは作ったけれど、どの作業が遅れるとマズいのかが見えない」
「並行して進められる作業を整理して、なんとか工期を短縮できないか？」
プロジェクトの全容を把握し、論理的な裏付けを持ってスケジュールを管理するために欠かせないのが「プレシデンスダイアグラム法（PDM）」です。
タスクのリスト（WBS）を作るだけでは、作業同士の「縛り」や「余裕」は見えてきません。今回は、PMやリーダーが現場ですぐに使えるよう、PDMの基本からスケジュールを最適化する活用ポイントを解説します。
この記事でわかること
- PDMとは何か、WBSとの役割の違い
- AOA（従来型）とAON（現代の主流）の違い【比較表】
- 現場の「無理・無駄」を暴く4つの依存関係と、リード・ラグの活用例
- スケジュールの命綱「クリティカルパス」の特定と集中管理のコツ
プレシデンスダイアグラム法（PDM）とは
PDMとは、アクティビティ（作業）の順序や依存関係を可視化したネットワーク図の一種です。
各作業を「ノード（箱）」で表し、それらを「線（矢印）」で結ぶことで、「どの作業が終わらないと次へ進めないのか」を一目で把握できるようにします。 現在のプロジェクト管理ツール（Microsoft Project、Backlog、Asana、Jiraなど）が採用しているガントチャートの裏側も、このPDMの論理で動いています。
ネットワーク図の種類（AOAとAONの違い）
作業のつながりを表すネットワーク図には、大きく分けて2つの記述方式があります。現場で混同しないよう、それぞれの特徴を押さえておきましょう。プレシデンスダイアグラム法（PDM）は、後者の「AON」に該当します。
| 項目 | AOA（アクティビティ・オン・アロー） | AON（アクティビティ・オン・ノード）※PDM |
|---|---|---|
| 作業の記述場所 | 矢印（アロー）の上 | 箱（ノード）の中 |
| 結合点（ノード）の意味 | イベント（節目・マイルストーン） | 作業（アクティビティ）そのもの |
| メリット・特徴 | 昔からある伝統的な手法（アローダイアグラムとも呼ばれる）。 | ノードの中に作業名、所要期間、担当者などの属性を書き込みやすく直感的。 |
| 現場での注意点 | 論理的な接続だけを示す「ダミー作業（点線の矢印）」が必要になることがあり、図が複雑になりやすい。 | 現代のPMツールの標準。ダミー作業が不要で、論理矛盾が起きにくい。 |
【AOA（アクティビティ・オン・アロー）のネットワーク図サンプル】
【AON（アクティビティ・オン・ノード）のネットワーク図サンプル】
PDMを構成する記号と表現方法
PDMは、以下の要素を組み合わせて構成されます。
| アイテム | 説明 | 図解イメージ |
|---|---|---|
| アクティビティ・ノード | 作業そのものを表す箱です。作業名、作業番号、所要期間（工数ではなく「期間」）を記述します。 |  |
| マイルストーン | 重要な節目を表します。実作業ではないため、所要期間はゼロです（例：要件定義承認、本番環境リリースなど）。 |  |
| 並行関係 | 同時に実施できる作業は、上下に並べて表記し、並行して進むことを示します。 |  |
| 前後関係（矢印） | 作業を順に進める場合は、先行タスクから後続タスクへ矢印を引きます。 |  |
| 並行・前後関係 | 「AとDの両方が終わってからFが始まる」といった、複雑な合流や分岐も表現可能です。 |  |
ネットワーク図の階層化と親子関係
大規模なプロジェクトでは、すべての作業を一つの図に描こうとすると非常に煩雑になり、全体像が見えなくなります。そのため、ネットワーク図を「階層化」して管理するのが一般的です。
- 上位レベル: プロジェクト全体のマイルストーン（主要な節目）を中心に配置します。
- 下位レベル: 上位のマイルストーンをブレイクダウンし、詳細なアクティビティに分解した図を作成します。
【整合性を保つコツ】 下位の図にあるすべてのアクティビティが完了して初めて、上位レベルの親マイルストーンが完了するという「親子関係」を維持することが、スケジュール破綻を防ぐポイントです。
現場の「無理・無駄」を暴く4つの依存関係
PDMの最大の利点は、単なる「終わったら次」という関係以外に、4つの依存関係パターンを表現できる点にあります。これを知るだけで、スケジュールの「詰め所（短縮できるポイント）」が変わります。
| 依存関係 | 略称 | 説明・現場での活用シーン | パターン事例 |
|---|---|---|---|
| 終了－開始 | FS | 最も一般的。「作業Aが終わったら、作業Bを開始できる」 例：要件定義が終わらないと、基本設計には着手できない。 |  |
| 開始－開始 | SS | 並行作業を促進。「作業Aが始まったら、作業Bも開始できる」 例：画面設計が始まれば、関連するDB定義（テーブル設計）も並行して着手できる。 |  |
| 終了－終了 | FF | 品質とゴールの同期。「作業Aが終わるまで、作業Bを終わらせることができない」 例：全機能のテストが終わらないと、総合品質報告書の作成は完了できない。 |  |
| 開始－終了 | SF | 特殊な切り替え。「作業Aが開始されるまで、作業Bを終了できない」 例：新システムの稼働が始まるまで、旧システムの保守運用は終了できない。 |  |
「リード」と「ラグ」で現実に即した調整を行う
論理的な接続だけでは説明できない「待ち時間」や「前倒し」を考慮することで、より精度の高い、現実に即したスケジュールになります。
- ラグ（待ち時間） 先行作業と後続作業の間に、あえて設ける空き時間のことです。
現場事例： サーバー機器を発注してから、実際に納品されるまでにかかる「10日間の待ち時間」など。 - リード（前倒し） 先行作業が完全に終わる前に、後続作業をオーバーラップ（前倒し）させて開始することです。
現場事例： API仕様書の完成を待たずに、ドラフトができた段階でフロントエンドのモックアップ開発を先行スタートさせる、など。
【リードとラグのイメージ図（ガントチャート）】
PMがPDMを活用する最大の目的：クリティカルパスの特定
PDMを作成するゴールは、単に綺麗な図を描くことではなく、「クリティカルパス」を特定することにあります。
- クリティカルパスとは: プロジェクト開始から終了までを結ぶ経路のうち、「所要期間が最も長くなる経路（余裕時間ゼロの経路）」のことです。
- PMの注目ポイント: このパス上にある作業が1日でも遅れると、プロジェクト全体の終了日も確実に1日遅れます。
【現場での集中管理アクション】 クリティカルパスが特定できたら、PMは以下のような「集中管理」を行います。
- そのパス上の作業には、最も確実なアウトプットを出せるエース級のエンジニアをアサインする。
- 他のタスクは週次報告でも、クリティカルパス上のタスクはデイリーで進捗と課題を確認する。
- 万が一に備え、このパスの周辺に意図的にバッファ（予備日）を確保しておく。
実務で役立つアドバイス：失敗を防ぐチェックポイント
PDMを作成する際、図のスパゲッティ化や形骸化を防ぐためのチェックポイントです。
- 始まりと終わりを「1つ」にする 図が複雑になると、どこにも繋がっていない「浮いたタスク」が発生しがちです。必ず一つの「開始ノード」で始まり、一つの「終了ノード」で終わる一本道を意識してください。
- WBSとの連動を常にチェックする WBSにある作業が漏れなくネットワーク図に反映されているか、粒度は合っているかを常にチェックしましょう。片方だけ更新されている状態は炎上の元です。
- 必要な矢印だけに絞る 直接的な依存関係がないものまで全て線で結んでしまうと、図がスパゲッティ状態になり、肝心のクリティカルパスが見えなくなります。「この作業を始めるために、本当にその先行作業の完了が必須か？」を常に問い直してください。
まとめ：依存関係の可視化がプロジェクトを救う
プレシデンスダイアグラム法（PDM）は、プロジェクトの「どこにリスクがあるか」を白日の下にさらし、チーム全員が納得感を持って進むための強力な武器になります。
「WBSを作って終わり」にせず、PDMを使って作業のつながりを整理することで、不測の事態にも慌てず、最短ルートでゴールを目指すことができるはずです。
次に読むべきおすすめ記事
スケジュールの「つながり」が見えたら、次は「期間の見積もり」と「具体的なデッドラインの計算」に進みましょう。
- [PERT/CPMによるクリティカルパス特定と見積もり術] PDMで描いた図をもとに、プロジェクトの運命を握る最短ルートを数値で正確に算出します。
- [システムコンテキスト図の書き方｜情報の境界線を確定させる] そもそも、そのタスクは「範囲内」ですか？スケジュールの前に境界線を再確認しましょう。
- [ユースケース図の書き方｜現場で迷わないアクター定義のコツ] 機能の価値を再定義し、無駄なタスクを削ぎ落とすヒントが見つかります。
