依存関係管理

状況: フロントエンド・バックエンド・インフラの3チーム（計18名）で進める全面リニューアル。

依存関係の洗い出し:

• バックエンドAPIが完成しないとフロントエンドの結合テストができない（FS）
• インフラの環境構築が終わらないとバックエンドのデプロイができない（FS）
• フロントエンドとバックエンドのAPI仕様は同時に合意する必要がある（SS）
• 外部決済サービスとの連携はベンダーの対応待ち（外部依存）

軽減策の実施:

1. API仕様をプロジェクト開始2週間で確定し、モックAPIを先に作成 → フロントエンドがバックエンド完成を待たずに開発可能に
2. インフラ環境は最小構成を第2週で準備 → バックエンドが早期にデプロイ・テスト可能に
3. 決済ベンダーとの連携は最も早い段階でPoCを実施 → 外部依存のリスクを早期に検証
4. 毎週月曜に3チーム合同で依存関係レビューを15分実施

モックAPIと最小インフラを先行準備することで待ち時間を87%削減し、予定通り6ヶ月でリリースを完了できた。

状況: 従業員350名の精密機器メーカー。製造・購買・在庫・経理・営業の5部門が絡むERP導入プロジェクト（12ヶ月）。各部門のマスタデータ移行が相互に依存しており、順序を間違えるとデータ不整合が発生する。

依存関係マップ:

• 品目マスタ（製造部門）→ 購買マスタに品目コードが必要（FS）
• 購買マスタ（購買部門）→ 在庫管理の初期データに必要（FS）
• 得意先マスタ（営業部門）→ 経理の売掛管理に必要（FS）
• 5部門の並行テストは全マスタ完了後に開始（FF）

軽減策:

• 品目マスタを最優先で2ヶ月前倒しで着手（クリティカルパス上のため）
• 各マスタの「暫定版」を先に共有し、後続部門が並行作業できるようにする
• 週次のクロス部門レビューで依存関係の状況を全員で確認

この取り組みが示すように、5部門のマスタデータ依存を事前にマッピングし、品目マスタを前倒しすることで手戻りを89%削減。12ヶ月の計画に対し2週間の遅延で完了した。

状況: 従業員12名のフィンテックスタートアップ。新規決済アプリの開発で、銀行API（2行）・認証サービス・審査機関の3つの外部依存を抱えていた。ローンチ期限は投資家との約束で固定。

外部依存のリスク評価:

軽減策:

• 銀行APIは両行とも3ヶ月前からPoC開始。サンドボックス環境で先行テスト
• 認証サービスは抽象化レイヤーを実装し、仕様変更への耐性を確保
• 審査機関には予備日を1ヶ月確保。申請書類を早期に準備して先行提出

結果: 銀行A APIが実際に3週間遅延したが、PoC段階で問題を早期発見し、回避策を実装済みだったため影響ゼロ。予定通りローンチを達成。

外部依存は「コントロールできない」が「準備はできる」。PoCと抽象化レイヤーで外部リスクの影響をゼロに抑え、固定期限のローンチを達成した。