複数ベンダーが参加するプロジェクトの運用
大きなプロジェクトでは、アプリ開発、基盤構築、データ移行などを別々の会社が担当することがよくあります。会社ごとに別々の管理表を使っていると、「他社の遅れが自分たちにどう影響するのか」が見えません。本システムで全社が同じ仕組みの上で記録すると、チーム間のつながりが見えるようになります。
役割と記録の流れ
設定のポイント
設定 | やり方 | 効果 |
|---|---|---|
グループ | 会社名ではなく役割（アプリチーム、基盤チーム）で作る | 体制図で責任範囲がわかる |
主管チーム | 課題やTODOには必ず主管チームを設定 | どの会社が対応するかが明確になる |
先行・後続 | チームをまたぐ作業の順番を設定 | 他社の遅れの影響が日程にすぐ反映される |
公開範囲 | 契約・費用などはカテゴリの公開範囲を限定 | 共有すべき情報と、そうでない情報を分けられる |
メンバー一覧 | 各社の方針に応じて非公開にする | 参加者情報の扱いに配慮できる |
チームをまたぐ課題の扱い方
状況 | やり方 |
|---|---|
原因がどの会社か分からない | 主管チームをPMOにし、各社に調査のTODOを起票して関連付ける |
A社の対応待ちでB社が止まっている | B社の作業にA社の作業を「先行」として設定し、待ちの関係を見えるようにする |
責任の範囲で意見が分かれる | コメントで事実を整理し、PMOが判断した結果と理由を記録する |
契約の範囲を超える対応が必要 | 変更要求を起票し、変更管理のプロセスで判断する |
運用のコツ
全社合同の定例会を開く：チームをまたぐ課題と、他社に影響する遅れを中心に確認します。
ルールは全社共通に：ステータスや記録のルールを会社ごとに変えないことが、横断して見られる前提です。
「他社の課題」ではなく「プロジェクトの課題」：記録を共有することで、責任の押し付け合いではなく、一緒に解決する雰囲気が生まれます。
まとめ
複数ベンダーのプロジェクトで難しいのは、会社と会社の「すき間」です。本システムで全員が同じ記録を使い、主管チームと先行・後続でつながりを見えるようにすれば、すき間に落ちる問題を減らすことができます。