プロジェクト間依存関係マップ・管理表のテンプレート

プログラムで起きる遅れの多くは、個々のプロジェクトの力不足ではありません。他のプロジェクトの成果物を待っているあいだ、手が止まっていることが原因です。しかもこの待ちは、プロジェクト単体の計画書には出てきません。

この記事では、プロジェクト間の依存関係マップと管理表のテンプレートを紹介します。ポイントは、依存の本数を数えるのではなく「余裕の小さい依存」を数えることです。記入例は、ハルタ工機（架空）の「基幹システム再構築プログラム」（3年・承認枠9億2,000万円・構成4本）です。

■ 1. 背景・よくある課題

よくある状態	何が起きるか
依存関係が各PMの頭の中にある	担当が変わると、前提ごと失われる
「〜と連携」としか書かれていない	いつまでに何が必要なのかが分からない
受け取る側の期限しか書いていない	渡す側が、その期限を知らない
依存の一覧が50件を超えている	どれが危ないのか分からず、全部が同じ扱いになる
遅れの影響が連鎖で見えていない	1本の遅れが、3本先まで波及することに気づけない
依存に責任者がいない	渡す側も受け取る側も、相手が気にしていると思っている

■ 2. テンプレート作成の目的

目的	具体的にどうなることか
依存を文書にする	誰が、誰に、何を、いつまでに渡すかを1行で書く
余裕（バッファ）を数字で持つ	必要期限と提供予定日の差を、月数で持つ
危ない依存だけに集中する	余裕1か月未満の依存を、毎週の確認対象にする
波及を見えるようにする	1本の遅れが、どこまで響くかをたどれるようにする
両側に責任者を置く	渡す側と受け取る側の、両方に名前を書く

■ 3. 依存関係の4つの種類

種類	内容	例	見つけ方
成果物の依存	Aの成果物が無いと、Bが進まない	マスタ統合基盤のAPIが、受注システムの結合テストに必要	各PJのインプット一覧を突き合わせる
順序の依存	Aが終わらないと、Bを始められない	旧システムを止めてからでないと、新拠点へ切り替えられない	移行・切替の計画を並べる
資源の依存	同じ人・設備を、複数のPJが同時に必要とする	インフラ担当3名が、C1の移行とC2のテストで重なる	要員配分計画の山を重ねる
意思決定の依存	Aの判断が決まらないと、Bの設計が進まない	会計方針が決まらないと、原価計算の設計ができない	各PJの前提条件を読む

4つめの意思決定の依存が、いちばん見落とされます。成果物ではないので、線表に現れないからです。各プロジェクトの前提条件一覧を読み、「他のプロジェクトや会議体の判断を待っているもの」を拾い出してください。

■ 4. 依存関係マップ

図プロジェクト間の依存関係

マップでは、矢印の色を「余裕の大きさ」で変えます。本数ではなく、色で危険度が伝わるようにするためです。

色	余裕	確認の頻度	扱い
赤	1か月未満	毎週	推進会議の固定議題。提供側の進捗を直接確認する
橙	1〜3か月	隔週	推進会議で状態だけ確認する
青	3か月以上	月次	台帳の更新のみ

ハルタ工機の例では、赤はD-01の1本だけです。C4（マスタ統合基盤）の品目マスタAPIが、C1の結合テスト開始日である2025年3月にそのまま必要で、余裕が0か月でした。C4が1か月遅れれば、C1の稼働（2025年12月）がそのまま1か月ずれます。

これに対して打った手は、C4の品目マスタだけを先行リリースし、2025年1月に暫定版をC1へ渡すというものでした。C4全体の完成を待たず、必要な部分だけを切り出す。依存を見つけたときの対処は、たいていこの形になります。

■ 5. 依存関係管理表の列

列	記入する内容	書き方のコツ
ID	D-01、D-02…	会議で「D-01の件」と呼べるようにする
種類	成果物／順序／資源／意思決定	種類によって対処法が変わる
提供側（誰が渡すか）	プロジェクトIDと、担当者の個人名	提供側にも責任者を置く
受取側（誰が待つか）	プロジェクトIDと、担当者の個人名	―
何を	具体的な成果物名、または判断の内容	「連携」ではなく「品目マスタ参照API v1.0」
必要期限	受取側が、いつまでに必要か	受取側の作業開始日から逆算する
提供予定日	提供側が、いつ渡せるか	提供側のスケジュールから取る
余裕	提供予定日と必要期限の差（月）	自動計算。マイナスなら即座に赤
状態	未着手／進行中／提供済／遅延	提供済になった時点で、確認対象から外す
遅れたときの影響	何が、どれだけずれるか	「C1の稼働が1か月ずれる」まで書く
回避策	依存を弱める手段	暫定版の先行提供、仕様の凍結、代替手段など

回避策の列が、この表の価値を決めます。依存は見つけて終わりではなく、弱められないかを考えるのが本番です。よく使う手は次の3つです。

手	内容	向いている場面
切り出して先行提供	必要な部分だけを、本体より前にリリースする	成果物の依存。相手が必要としているのが一部分のとき
仕様だけ先に凍結	実装より先にインターフェース仕様を確定させる	受取側が、仕様さえ決まれば作り始められるとき
暫定・代替でつなぐ	手作業やダミーデータで、一時的に代替する	テストなど、本番品質を要しない期間があるとき

■ 6. 記入例（架空企業：ハルタ工機）

ID	種類	提供→受取	何を	必要期限	提供予定	余裕	回避策
D-01	成果物	C4→C1	品目マスタ参照API v1.0	2025/3	2025/3	0か月	品目のみ先行リリース（2025/1に暫定版）
D-02	成果物	C4→C2	取引先マスタ参照API	2025/9	2025/6	3か月	―
D-03	成果物	C4→C3	勘定科目マスタ	2026/3	2025/6	9か月	―
D-04	成果物	C1→C3	受注実績の会計連携仕様	2026/6	2026/4	2か月	仕様のみ2025/12に凍結
D-05	成果物	C2→C3	原価実績データ	2026/9	2026/6	3か月	―
D-06	意思決定	C1→C2	在庫引当ロジックの方針決定	2026/3	2026/1	2か月	推進会議で1月に決定と明記
D-07	資源	C1↔C2	インフラ担当3名（移行とテストで重複）	2025/10〜12	―	―	C2のテストを2026/1に後ろ倒し

D-07は資源の依存です。成果物のやりとりではないので、マップには線として描きにくいのですが、影響は成果物の依存と同じくらい大きいです。要員配分計画で山が重なっている箇所を、必ず依存として登録してください。

■ 7. 運用ルール

ルール	内容	理由
両側に責任者を置く	提供側と受取側の、両方に個人名を書く	片側だけだと、もう一方が気にしていると思ってしまう
余裕で分けて、頻度を変える	赤は毎週、橙は隔週、青は月次	全部を同じ頻度で見ると、危ないものが埋もれる
赤が3本を超えたら順序を見直す	個別の対処ではなく、計画そのものを変える	余裕ゼロの依存が3本あると、必ずどれかで詰まる
提供予定日は提供側が書く	受取側が希望を書くのではない	希望日と予定日を混ぜると、余裕の計算が意味を失う
提供済になったら確認対象から外す	台帳には残すが、会議では扱わない	一覧を短く保つ
四半期に1回、全件を洗い直す	新しい依存が生まれていないかを確認する	設計が進むと、依存は必ず増える

■ 8. 活用シーン

場面	使い方
プログラムの計画時	各PJの前提条件とインプット一覧を突き合わせて、初版を作る
推進会議（隔週）	赤と橙の依存だけを確認する。青は台帳の更新のみ
1本のプロジェクトが遅れたとき	そのPJが提供側になっている依存をたどり、波及範囲を出す
ステージゲートの判定	提供予定日が守れるかを、ゲートの判定項目に入れる
プロジェクトの追加時	新しいPJが生む依存を洗い出してから、追加を承認する
要員配分の検討	資源の依存（D-07のような重複）を、山積み表と突き合わせる

■ 9. よくある失敗と直し方

失敗	起きること	直し方
「〜と連携」としか書いていない	いつ何が必要か分からず、直前に慌てる	成果物名・必要期限・提供予定日の3つを必ず書く
余裕を計算していない	どれが危ないか分からない	必要期限−提供予定日を自動計算し、色で分ける
一覧が50件を超えている	全部が同じ扱いになり、危ないものが埋もれる	余裕3か月以上は月次の台帳更新だけにする
資源の依存を登録していない	要員の取り合いが、直前に表面化する	要員配分計画の山の重なりを、依存として登録する
回避策の欄が空欄	見つけただけで終わり、何も変わらない	赤と橙には、必ず回避策を1つ書く
提供側が期限を知らない	受取側だけが焦っている	両側に責任者を置き、推進会議で両方が出席する

■ 10. 導入効果

観点	台帳が無いとき	依存関係マップを作ったとき
依存の把握	各PMの頭の中	7件の台帳と、1枚のマップ
危険度の判断	すべて同じ扱い	赤1本・橙2本に絞って毎週確認
遅れたときの影響	後から分かる	「C1の稼働が1か月ずれる」と事前に言える
打てる手	相手を急かす	先行リリース・仕様凍結・暫定代替の3つから選ぶ
会議での扱い	各PJの報告の中に埋もれる	推進会議の固定議題になる

■ まとめ

依存関係の管理でいちばん大事なのは、全部を追いかけないことです。余裕を計算して色をつけ、赤い依存だけに時間を使ってください。

そして依存を見つけたら、必ず「弱められないか」を考えます。先行リリース、仕様の凍結、暫定での代替。依存は減らせなくても、余裕は作れます。