プログラムでは、複数の会社が同時に動くことがよくあります。基幹系はA社、周辺システムはB社、インフラはC社。それぞれに契約があり、それぞれの都合があります。

ここで決めておくべきことは1つです。つなぎ目の責任を、誰が持つのか。

■ 3つの型から選ぶ

図の3つが基本形です。どれが正しいということはなく、状況で選びます。

①自社が直接束ねる。自社にプログラムの経験者がいる場合に取れます。費用は安く、判断も速い。ただし、自社の担当者に負荷が集中します。その人が抜けると止まります。

②統括ベンダーを置く。大規模で、自社に経験者がいない場合の選択です。つなぎ目の責任が契約上はっきりします。ただし費用が上がり、統括が他社を下請けにすると、実態が見えにくくなります。

③役割分担型。技術領域がはっきり分かれている場合に有効です。領域ごとに主幹を決めます。問題は境目で、「どちらの担当か」で揉めやすくなります。

■ どの型でも必要な3つ

型を選んだあと、必ず用意するものがあります。

1行目の責任分担表は、作業の粒度が粗いと役に立ちません。「テストを実施する」ではなく、「結合テストのテストデータを準備する」「結合テストの環境を用意する」くらいまで分けます。揉めるのはいつも細かい作業です。

■ ベンダー同士を直接話させる

発注者がすべての連絡を仲介すると、必ず遅くなります。技術的な確認まで発注者を経由させると、1往復に数日かかります。

だから、担当者同士が直接やり取りできる関係を作ります。ただし、次の2つは守ってもらいます。

• 決定事項は、発注者を含めた場で確認する（勝手に決めない）

• 費用や期日が動く話は、必ず発注者に上げる

この線引きを最初に伝えておけば、多くの会社は適切に動いてくれます。

■ 会社間の壁が出る場面

複数ベンダーの体制で、必ず問題になる場面があります。

1行目が最も頻繁に起きます。「うちの範囲は正常です」と両社が言い、誰も動かない時間が生まれます。原因が分かるまでは、決めた1社が窓口として動くと決めておくだけで、この停滞が消えます。

■ 情報の置き場所を1つにする

各社がそれぞれの管理表を持っていると、必ず食い違います。課題一覧、リスク一覧、依存一覧は、プログラムで1つにします。

置き場所も1か所です。各社の社内システムではなく、全員が見られる場所に置く。セキュリティ上の制約がある場合でも、少なくとも課題一覧だけは共通化する価値があります。

■ まとめ

複数ベンダーのプログラムでは、つなぎ目の責任を誰が持つかを最初に決める。そのうえで、責任分担表・共通スケジュール・合同の場の3つを用意する。担当者同士は直接話してもらい、決定と費用の話だけ発注者を通す。

いまの体制で、結合テストの不具合が出たとき誰が最初に動くか、決まっているか確かめてみてください。決まっていなければ、次の打ち合わせで決める価値があります。