これは何か
依存関係一覧は、「Aが終わらないとBが始められない」という関係を、作業・判断・他のチームの成果物・環境について1件ずつ並べ、待っている側と渡す側、渡す予定の時期、今の状態を管理する成果物です。
たとえば、テストのチームが「来週から総合テストを始める」と計画していても、別のチームが準備するテスト用の環境ができていなければ始められません。それぞれの計画には自分の作業が書かれていますが、「どちらがどちらを待っているか」は見えにくいものです。これを1か所に集めるのが依存関係一覧です。
なぜ作るか
- 自分のチームの中だけ見ると予定どおりでも、他のチームの遅れで止まることに早く気づく（00-03）
- 渡す側のチームが、「誰が自分の成果物を待っているか」を知る
- 遅れが出たとき、その先で止まる作業をたどれる
- 判断が出ないことで止まっている作業を、判断を求める材料として示せる
誰が使うか・いつ作るか
- 管理する人：一般的には PMO など、チームをまたいで計画を見る担当
- 使う人：各チームのリーダー、プロジェクトの責任者、ベンダーの PM
- 一般的には、プロジェクト計画書（PRG-002）で管理の方法を決め、全体スケジュール（PRG-005）を作るときに洗い出し、定例の会議で状態を更新します
- アステリア案件で、依存関係をどの一覧で、誰が管理したかは、正本に記載がありません。未確定
関係する成果物との違い
- 全体スケジュール（PRG-005）：工程を時間の流れに並べる。依存は線で示すが、1件ずつの状態までは追わない
- 依存関係一覧：待っている側と渡す側の組を1件ずつ持ち、「約束の時期に届くか」を追いかける
- 課題・リスク管理表（PRG-006）：依存が守られそうにないと分かったとき、その問題を課題・リスクとして登録して対応する
- システム連携一覧（ARC-004）：動いているシステムの間のデータの流れ。依存関係一覧は、プロジェクトの作業の間の関係を扱う
CASE FACTFROZEN正本に記載されたアステリア案件の事実
依存が生まれやすい構造
- 約120人規模、マルチベンダー
- Vendor A / ネクサスシステムズ — 新基幹アプリケーション
- Vendor B / クラウドブリッジ — クラウド基盤、ネットワーク、IAM、連携、CI/CD、監視
- Vendor C / ファイナンスシステムサービス — FIN-CORE、会計連携
- Vendor D / タイムリンク — 勤怠・工数管理SaaS
- P-004 田辺 彩 — PMOリーダー
担当の違う会社が4社あるため、会社をまたぐ依存が生まれやすい構造です。ただし、アステリア案件の具体的な依存関係、渡す時期、PMOリーダーがこの一覧を管理するかは、正本に記載がありません。未確定
主な項目
- 番号
- 待っている側：どのチームの、どの作業か
- 待っているもの：作業の成果物・判断・環境のどれか。中身
- 渡す側：どのチームの誰が渡すか
- 必要な時期と、渡す予定の時期：両方を書き、ずれを見る
- 状態：予定どおり・遅れのおそれ・遅れ・渡し済み
- 届かなかったときの影響：どの作業が止まるか
- 対応：課題・リスク管理表の番号など
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 依存関係の4つの種類
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。チーム名も架空です。
| 番号 | 種類 | 待っている側 | 待っているもの | 渡す側 | 必要な時期／渡す予定 | 状態 |
|---|---|---|---|---|---|---|
| DEP-EX-01 | 他チームの成果物 | 移行チーム：移行の練習 | 新しいデータの形の定義 | 開発チーム | 第3週／第3週 | 予定どおり |
| DEP-EX-02 | 環境 | テストチーム：総合テストの開始 | テスト用の環境 | 基盤チーム | 第5週／第7週 | 遅れのおそれ（課題 ISS-EX-04） |
| DEP-EX-03 | 判断 | 業務チーム：操作手順の作成 | 承認の流れを1段にするか2段にするかの決定 | 業務の責任者 | 第4週／未定 | 遅れ |
| DEP-EX-04 | 作業 | 教育チーム：利用者の研修 | 研修用の画面の完成 | 開発チーム | 第9週／第8週 | 渡し済み |
「必要な時期」と「渡す予定」を並べると、DEP-EX-02 は2週間のずれがあることが一目で分かります。DEP-EX-03 は渡す予定が「未定」で、判断を求める先がはっきりしています。
読み方
- 状態が「遅れ」「遅れのおそれ」の行から見る
- 「必要な時期」と「渡す予定」のずれを見る
- 渡す予定が「未定」の行は、誰に何を求めればよいかを確かめる
- 1件の遅れが、別の依存の「待っている側」にさらにつながっていないかをたどる
書き方
- 各チームの計画から、「他のチームから受け取るもの」を書き出してもらう
- 渡す側のチームに、その依存を認識しているか、渡す予定の時期を確かめる
- 作業・判断・成果物・環境の区別を付けて一覧にする
- 定例の会議で状態を更新し、ずれが出たら課題・リスク管理表に登録する
何を書いてはいけないか
- 待っている側だけで決めた「渡す予定」（渡す側が合意していない）
- 「関係チームと調整中」のように、渡す側がはっきりしない書き方
- 同じチームの中で完結する作業の順番（全体スケジュールやチームの計画で扱う）
どこを見るか
- 待っている側と渡す側が、両方とも書かれているか
- 必要な時期と渡す予定の時期がそろっているか
- 判断待ち・環境待ちも、作業と同じように載っているか
- 渡す予定が未定のものに、確かめる担当が付いているか
- 遅れの行が、課題・リスク管理表につながっているか
赤信号
- 渡す側のチームが、この一覧に載っている依存を知らない
- 状態が長く更新されていない
- 判断待ちの行だけが、いつまでも「未定」のまま
- 会社をまたぐ依存が、一覧にほとんど載っていない
よくある失敗
- 最初に洗い出したきりで、計画が変わっても更新しない
- 判断が出ないことを依存として扱わず、作業の遅れとしてだけ報告する
関係するUnit・成果物・危機演習
- Unit：00-03 プロジェクトとプログラムの違い、07-06 36本を一覧で管理する、03-05 プロジェクトの問題をどう管理するか
- 成果物：PRG-002 プロジェクト計画書、PRG-005 全体スケジュール、PRG-006 課題・リスク管理表、PRG-003 プロジェクト体制図
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、各チームの計画から依存の候補を探す下書きに役立ちます。
「次の各チームの計画を読み、ある作業が他のチームの成果物・判断・環境を前提にしている箇所を、候補として挙げてください。候補ごとに、待っている側・待っているもの・渡す側と思われるチームを書いてください。渡す予定の時期は推測せず、空欄にしてください。」
REVIEW
- AIが挙げた候補を、待っている側・渡す側の両方のチームに確かめたか
- AIが時期や担当を、推測で埋めていないか
- 計画に書かれていない依存（口頭の約束など）が漏れていないか
人間が判断すること
- 渡す予定の時期を、渡す側と待つ側のどちらの都合に合わせるか
- 依存の遅れに対して、作業の順番を入れ替えるか、計画を見直すか
- 判断待ちの依存を、誰にいつまでに判断してもらうか
いつ使うか
この教材では STAGE 03｜120人をどう動かすのか の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この一覧を見た人は、「自分のチームの次の作業が、どのチームの何を待っていて、それがいつ届く予定か」を答えられますか？