依存関係マッピング：チーム間の受け渡しを整理する方法

各チームのタスク一覧では順調に見えても、全体としてはリリースできないことがあります。開発は承認済みの原稿を待ち、マーケティングは動くデモを待ち、サポートはデモでどの動作を案内するのか分からない。それぞれの作業は見えていても、チーム間の受け渡しが見えていない状態です。

依存関係マッピングのワークショップでは、この受け渡しを一枚のボードにまとめます。目指すのは、あるチームが別のチームから何を、いつまでに受け取る必要があり、間に合わない場合はどうするのかを合意することです。

依存関係マップで明らかにすること

依存関係とは、他の担当者や組織からの情報、判断、機能、資源がなければ、予定どおりに作業を進められない関係です。デザイナーが製品説明の承認を必要としているなら、それは依存関係です。一方、二人のデザイナーが同じ会議に参加すること自体は、必ずしも依存関係ではありません。

Atlassianの依存関係マッピングの手法では、影響を受けるシステム、リスク、担当者、継続的な調整を扱います。複数チームが関わるリリースでは、この広い視点を具体的な受け渡しの合意に落とし込みましょう。自分たちが上流から受け取るものと、自分たちの成果物を必要とする下流の作業の両方を含めます。

タイムラインは「いつ実施するか」を示します。RACIマトリクスは、参加者の役割と意思決定の責任を明確にします。依存関係マップが答えるのは、この作業を先に進めるには、何がそろっている必要があるかという別の問いです。三つとも必要な場合はありますが、同じ内容を重複させる必要はありません。

一つの成果を中心に準備する

「会社全体を整理する」ではなく、「新しい顧客向けオンボーディングをリリースする」のように範囲を絞ります。ボードの上部には予定日と、今回は扱わない事項を明記します。日付が仮なら、その旨も書いてください。そうしないと、誰も確約していない日程に合わせて参加者が調整を始めてしまいます。

受け渡しの条件を確認できる人を招きます。提供側と受領側の各チームの代表に加え、範囲や日程の対立を解決できる人が必要です。レビュー待ち、休暇の予定、環境へのアクセス、外部業者の所要期間など、実際の制約を持ち寄ってもらいます。進行管理の担当者だけでは、未確認の約束をきれいに並べただけのマップになりかねません。

事前にチームごとの横長のレーンを作り、最終成果を右側に置きます。未解決の質問を置く領域も分けて用意します。一つの日付をめぐる議論で、全体の作業を止めないためです。

成果から逆向きにたどる

まず受領側のチームに「これを完了するには、何が手元に必要ですか」と尋ねます。その条件を上流へたどり、次の条件が当該チーム内で解決できるもの、または今回の範囲外になるところまで進めます。記憶を頼りに全タスクを挙げるより、成果から逆算するほうが抜けた前提条件を見つけやすくなります。

成果物のカードには「オンボーディングの説明を承認する」「テスト用エンドポイントを公開する」「エスカレーション経路を確認する」のように、動詞と具体的な名詞を使います。提供側のカードから受領側のカードへ線を引き、矢印には「承認済み原稿」「テスト用認証情報」「合意済みルール」など短いラベルを付けます。矢印の方向を凡例で定義し、全体で統一します。

すべての矢印が同じ条件を表すわけではありません。必須の前提条件と、暫定的な情報でも着手できる作業を区別します。執筆者は仮のスクリーンショットでガイドを書き始められても、公開前には確定版が必要です。この違いを示せば、依存関係を消したことにせず、進め方の選択肢を増やせます。

例：セルフサービス型トライアルの開始

利用者が自分で登録できるトライアルを準備する、架空のソフトウェアチームを考えます。プロダクト担当が提供条件を決め、開発がアクセスを実装し、マーケティングが登録ページを公開し、サポートが問い合わせ対応を準備します。最初のマップでは話が循環しています。マーケティングは完成したトライアルの画像を求め、開発はトライアルのルールを仕上げるために、ページの最終原稿を求めているのです。

そこで、提供条件の決定と画像の準備を分けます。プロダクト担当が先にルールを承認すれば、マーケティングは仮素材でページを作れます。開発も本番公開前にテスト環境を提供できます。マップには、確認可能な小さな受け渡しが並ぶようになります。

受け渡しの日程は、実際に作業する人と受け取る人が決める必要があります。ボードに早い締め切りを書いても、処理能力が増えるわけではありません。

重要な矢印を具体的な合意にする

最終成果に影響する受け渡しには、提供側と受領側の責任者、必要になる日、提供予定日、受け入れ条件を記録します。二つの日付は分けてください。「期限」を一つだけ書くと見えなくなる食い違いが、その差から分かります。

受領側の責任者に、何がそろえば使えるのかを自分の言葉で説明してもらいます。「APIが準備できた」は、ある人には仕様書の公開、別の人には本番環境への安定したアクセスを意味します。例えば「テスト用エンドポイントが合意したサンプルデータを返し、連携担当チームが認証できる」と書けば、確認しやすくなります。

日程が合わないときは、単に催促を強める前に、提供範囲の縮小、モックの利用、順序の変更、作業範囲の見直しを検討します。重要なトレードオフは意思決定ログに残します。依存関係ボードにはその判断へのリンクを置けばよく、二つ目の議事録にする必要はありません。

注意が必要な依存関係を見つける

一つの提供元に多数のチームが依存している箇所、余裕のない長い連鎖、誰も受け取りを引き受けていない成果物、日程が推測のままの外部依存を探します。循環も確認しましょう。反復的な共同作業を表す場合もあれば、どちらが先に動くべきか分かっていない場合もあります。

すべてを「重大」と分類するのではなく、危険な矢印の横に影響を書きます。「研修を開始できない」「セキュリティレビューをやり直す必要がある」「このレポートがなくても公開できる」といった説明は、赤いカードで埋め尽くすより役立ちます。マップだけでプロジェクトのクリティカルパスを計算することはできません。計算には作業期間とスケジュール上の条件が必要です。

会議後も更新できるマップにする

Boardmixでは、このトライアルの例をプロダクト、開発、マーケティング、サポートの四つのレーンに配置します。成果物を図形で、受け渡しをラベル付きの線で表します。承認済みルールからテスト環境と登録ページ原稿へ線を引き、テスト環境から画像撮影とサポートのリハーサルへつなぎます。重要な矢印の横には、双方の責任者と受け入れ条件を添えます。Boardmixを開いてマップを作り、チームがすでに管理しているタスクへのリンクを付けてください。

定例の進捗会議だけでなく、必要な情報が変わったとき、提供日が動いたとき、受領側が成果物を受け入れられなかったときにも見直します。影響を受けるチームに、何が変わるのかを確認してください。順序や範囲が変わるなら、プロジェクト計画も更新します。受け渡しの完了は、提供側が送信したことではなく、受領側が必要なものを得たことを意味するべきです。