フレームワーク活用ガイドひとことで言うと#
複数チーム・複数タスク間の依存関係を1枚のボード上に可視化し、どこが詰まると全体が遅れるかを一目で把握できるようにする手法。依存の「見えない糸」を見える化することで、遅延の連鎖を未然に断ち切る。
押さえておきたい用語#
- 依存関係（Dependency）
- あるタスクの開始・完了が別のタスクの成果物や判断に左右される関係のこと。FS（終了→開始）が最も一般的だが、SS・FF・SFのパターンもある。
- クリティカルパス（Critical Path）
- プロジェクト全体の所要期間を決定する最長経路。この経路上のタスクが遅れると、プロジェクト全体が遅延する。
- バッファ（Buffer）
- 依存関係のある接続点に設ける余裕時間。想定外の遅延を吸収するためのクッション。
- ブロッカー（Blocker）
- 他のタスクの進行を完全に止めてしまう依存関係。ボード上で最優先で解消すべき項目。
依存関係ボードの全体像#
こんな悩みに効く#
- 複数チームが関わるプロジェクトで、「あのチームの作業待ち」が頻発する
- タスクは個別に進んでいるのに、結合すると動かない
- 1つのチームの遅延がドミノ式に全体へ波及してしまう
- スプリントプランニングでチーム間の調整が毎回炎上する
基本の使い方#
ボードの縦軸にチーム、横軸にタイムライン（スプリントや週）を取り、各チームのタスクを配置する。
- 1チームあたり3〜5個の主要タスクに絞る（細かすぎると読めなくなる）
- タスクにはIDを振り（F-1, B-2など）、口頭での参照を簡単にする
- 物理ボードなら付箋、デジタルならMiroやJiraのボードビューを使う
あるタスクの成果物が別チームのタスクのインプットになる関係を矢印で結ぶ。
- 「このタスクが完了しないと、あのタスクが始められない」関係を全て洗い出す
- 矢印の向きは成果物の流れる方向（提供元→受領先）
- 依存関係はチーム間だけでなく、チーム内のタスク間も忘れずに記載する
すべての依存関係のうち、遅延が即座に全体に波及するものを赤線で強調する。
- 並行作業で吸収できる依存は通常扱い、代替手段がないものがクリティカル
- 各クリティカル依存にバッファ日数を設定し、遅延耐性を可視化する
- ブロッカー（現時点で解消していない依存）は即座にエスカレーションする
依存関係ボードは生き物。作って終わりではなく、定期的に更新する。
- 週次のスクラム・オブ・スクラムズや全体同期会議でボードをレビューする
- 完了したタスクの依存線を消し、新たに発見した依存を追加する
- 遅延が発生したら、影響を受ける下流タスクのオーナーに即通知する
具体例#
フィンテック企業が新しいモバイル決済アプリをリリースする4か月のプロジェクト。モバイルチーム（4名）、APIチーム（3名）、インフラチーム（2名）の3チーム体制だった。
初期状態の問題: 各チームがそれぞれのバックログを独立に管理しており、Sprint 2の終わりに「APIがまだ完成していないのでモバイル側のテストが丸々1スプリント止まった」という事態が発生。2週間のロスが発生した。
依存関係ボードの導入: 3チーム合同でボードを作成し、14本の依存線が可視化された。そのうちクリティカル依存は5本。
| 依存元 | 依存先 | 種類 | バッファ |
|---|---|---|---|
| API認証モジュール | モバイル・ログイン画面 | クリティカル | 3日 |
| API決済エンドポイント | モバイル・決済フロー | クリティカル | 5日 |
| インフラ・ステージング環境 | API結合テスト | クリティカル | 2日 |
| APIドキュメント | モバイル・モック実装 | 通常 | — |
| インフラ・監視設定 | 本番リリース判定 | クリティカル | 3日 |
対策:
- クリティカル依存の上流タスクを各スプリントの前半に配置し、後半に下流タスクを開始できるようにした
- APIドキュメントはOpenAPI定義を設計段階で先行公開し、モバイルチームがモック実装を並行できるようにした
- 隔週の3チーム合同レビューでボードを更新
結果: 残りの2か月間でチーム間の待機時間が合計32時間 → 6時間に削減。予定通り4か月でリリースを完了した。
年商200億円のECサイトのフルリプレイスプロジェクト。フロントエンド、商品管理、受注管理、在庫管理、決済、物流連携、検索、インフラの8チーム（合計45名）が参加。
課題: 8チームのスプリントプランニングを個別にやっていたが、Sprint 3で23件の依存衝突が同時に発覚。「Aチームが待っている成果物をBチームは次のスプリントに予定していた」というズレが多発した。
依存関係ボードの構築:
- 物理ボード（壁一面のホワイトボード）とMiroの両方を使い、8チーム × 6スプリントのマトリクスを作成
- 全依存線を引いた結果、67本の依存関係が可視化された
- クリティカル依存は18本、うち即座に対処が必要なブロッカーが4本
重点対策:
- 4本のブロッカーに対して「依存解消スプリント」を1回設け、上流チームがブロッカー解消に集中
- 週1回の「依存関係レビュー会」（30分）を全チームリード参加で実施
- 各クリティカル依存にオーナー（依存元チームのリード）を任命し、遅延時の第一連絡先を明確化
6か月後の成果: 依存衝突によるスプリント内の手戻りが月平均12件 → 2件に減少。全体スケジュールの遅延は最終的に**1スプリント（2週間）**に収まり、当初想定の「3か月遅延リスク」を大幅に圧縮した。
消費財メーカーが大型キャンペーンを実施するにあたり、マーケティング・営業・制作・法務・ITの5部門が関わることになった。過去のキャンペーンでは「法務チェックが終わらないと広告入稿できない」「IT側のLP公開が営業研修より遅れる」といった依存問題で毎回1〜2週間の遅延が発生していた。
依存関係ボードで可視化した結果:
キャンペーン開始日から逆算して、5部門のタスクと22本の依存線を可視化。特に問題だったのが以下の3つのクリティカル依存だった。
- 制作→法務: クリエイティブ完成後に法務チェック（通常5営業日）。制作が1日遅れると法務の着手も1日遅れる
- 法務→制作→IT: 法務承認後にクリエイティブ修正→IT側のLP反映。3部門の直列依存
- IT（LP公開）→営業（研修資料作成）: LPのURLが確定しないと営業資料を完成できない
対策:
- 法務チェックの事前レビュー制度を導入。ラフ段階で法務に方向性を確認し、完成版チェックを3営業日に短縮
- LP のURLを先行確定（仮ページで発行）し、営業チームがURL確定を待たずに研修資料を作れるようにした
- 各クリティカル依存に2日のバッファを設定
結果: キャンペーン準備期間が従来の8週間 → 6週間に短縮。遅延ゼロでローンチでき、初週のCV数は前回キャンペーン比**135%**を達成した。
やりがちな失敗パターン#
- タスクを細かく分けすぎる — 全タスクを載せると線が交錯して読めなくなる。チーム間のインターフェースとなる主要タスクに絞る
- 作ったきりで更新しない — 依存関係は変化する。週次で更新しないと、実態とズレたボードが信頼を失い使われなくなる
- 依存元チームに当事者意識がない — 「自分のタスクが終われば関係ない」という態度では依存は解消しない。下流チームへの影響をボードで可視化し、オーナーシップを持たせる
- バッファを設けない — 依存接続点にバッファがないと、わずかな遅延が即座に連鎖する。クリティカル依存には最低2〜3日のバッファを設ける
まとめ#
依存関係ボードは、チーム間・タスク間の「見えない糸」を1枚のボードに可視化し、遅延連鎖を未然に防ぐ手法である。縦軸にチーム、横軸にタイムラインを取り、成果物の流れを矢印で結ぶだけで「どこが詰まると全体が止まるか」が一目でわかる。大事なのは作って終わりにしないこと。週次で更新し、クリティカル依存にはバッファとオーナーを設定し、遅延が発生したら即座に下流チームへ通知する。依存を管理するのではなく、依存を減らす設計（APIの先行公開、仮データでの並行作業など）を意識することで、チーム間の待ち時間は大幅に圧縮できる。