ベンダーの多重下請け構造、発注側はどこまで把握すべきか

はじめに

「プライムベンダーに発注しているから安心」——そう思っていたら、実際にシステムを開発していたのはプライムベンダーが再委託した先の、さらに下請けの会社だった。こうした話は、IT業界では珍しくありません。

多重下請け構造そのものは違法ではなく、SES・準委任・請負の違い｜発注側が理解しておくべき契約形態で触れたように、業界の分業体制として一般的に存在します。問題は、発注側がその構造を把握せずに「見えない相手」に重要な工程を委ねてしまうことです。

今回は、発注側がベンダーの下請け構造をどこまで把握し、どう管理すべきかを整理します。

発注側が多重下請け構造を把握すべき理由は、大きく3つあります。

1点目は、品質・進捗の責任の所在が曖昧になりやすいことです。プライムベンダーの担当者に「大丈夫です」と言われても、実際の開発を担っているのが別会社であれば、その言葉の裏付けを取りにくくなります。

2点目は、情報セキュリティのリスクです。自社の機密情報や顧客データが、契約書上は想定していない会社の社員にまで渡っている可能性があります。オフショア開発を使う際、発注側が気をつけるべきことでも触れましたが、再委託先が海外企業である場合はさらに注意が必要です。

3点目は、キーマン離任のリスクです。ベンダーのキーマンが離任・退職したときに発注側がすべきことで解説した通り、実際にプロジェクトを支えているキーマンが下請け会社に所属している場合、発注側はその存在すら認識できていないことがあります。

多くのIT契約書には、再委託（下請けへの発注）に関する条項があります。典型的なパターンは以下の2つです。

発注側として望ましいのは事前承諾型です。ただし、現実には「再委託は原則自由、ただし主要な工程は除く」といった曖昧な条項になっているケースも多く、契約締結前にこの条項の実効性を確認しておく必要があります。

すべての再委託先を細部まで把握しようとすると、管理コストが膨らみすぎます。実務上は、以下のようにリスクの高さで深さを変えるのが現実的です。

キックオフの段階で、プライムベンダーに「体制図（会社名・役割・主要メンバー）を提出してもらう」ことを契約条件に含めておくと、後から揉めずに済みます。

「下請けを使うな」という要求は非現実的ですし、ベンダーとの関係を損ねます。大切なのは「発注側として管理すべき立場にあるから、体制の透明性を確保したい」という伝え方です。

実務では、キックオフ会議で以下のように伝えるのが効果的です。

これらをプロジェクト計画書や契約書の付帯条件に明記しておくことで、「後出しの要求」にならずに済みます。

ベンダーの多重下請け構造は、業界の分業体制として自然に存在するものであり、それ自体が問題ではありません。発注側が注意すべきは、その構造を把握せずに重要な工程をブラックボックスのまま進めてしまうことです。

契約段階で再委託条項を確認し、キックオフ時に体制図の提出を求め、リスクの高い工程ほど深く把握する——この3点を押さえておくことで、「誰が実際にシステムを作っているのか分からない」という不安な状態を避けられます。

執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。