多重下請け構造とは
多重下請け構造とは、発注者から開発業務を受けた元請け企業が、その業務の一部または全部を二次請け企業に再委託し、さらに二次請けが三次請けへ…と、何層にもわたって業務が受け渡されていく構造のことです。
図にすると、発注者を頂点に、元請け、二次請け、三次請けと下に広がるピラミッドの形になることから「ピラミッド構造」とも呼ばれます。建設業界でも見られる構造ですが、日本のIT業界、特に大規模なシステム開発やSESの取引で広く見られることが指摘されてきました。
仕組み・生まれる理由と影響
多重下請け構造が生まれる背景には、次のような事情があります。
- 人材の需給の波：大規模案件では一時的に多くの人手が必要になり、一社では確保しきれない。
- 元請けへの発注の集中：発注者が実績や信用のある大手企業に一括で発注し、元請けは管理を担って開発を外部に出す。
- 専門分野の分担：特定の技術や工程に強い会社に任せる。
- 営業力の差：開発力があっても直接受注の窓口を持たない会社が、上位の会社を通じて仕事を得る。
一方で、層が深くなるほど次のような影響が出やすくなります。
| 影響 | 内容 |
|---|---|
| 費用 | 各層で管理費や利益が上乗せされ、発注額に対して実際の作業者に届く対価が小さくなる |
| 情報伝達 | 要件や変更が何層も経由して伝わり、意図がずれたり遅れたりする |
| 品質と責任 | 実際に作業する人が発注者の目的を知らず、問題の責任の所在があいまいになる |
| 意思決定の速さ | 質問や確認が上位の層を経由するため、回答に時間がかかる |
| 人材の定着 | 下位の層ほど条件が厳しく、経験やノウハウが蓄積されにくい |
なお、業務の再委託そのものが違法というわけではありません。ただし、実態が労働者派遣にあたるのに契約が請負や準委任になっている場合など、法令上の問題につながるケースもあるため、判断に迷う場合は公的機関や専門家に確認してください。
実務での使い方・具体例
架空の例として、ある会社が元請けの開発会社に業務システムを発注したケースを考えます。定例会には元請けの担当者が出席し、「確認します」と持ち帰ることが多く、仕様の質問に答えが返ってくるまでに数日かかっていました。後で分かったのは、実際の開発が三次請けの会社で行われ、元請けの担当者自身は技術的な詳細を把握していなかったということでした。
このような状況を避けるため、発注側が契約前に確認できることがあります。
- 実際に開発を担当するチームはどの会社に所属しているか。
- 再委託をする場合、その範囲と委託先を事前に知らせてもらえるか（契約で再委託の承諾条件を定める）。
- 定例会や仕様の打ち合わせに、実際の開発担当者が参加できるか。
- 品質や情報管理の責任を、元請けがどう担保するか。
- 個人情報や機密情報を扱う場合、再委託先にも同じ管理基準が適用されるか。
また、規模の小さい開発であれば、そもそも何層もの構造を必要としない体制を選ぶことも一つの方法です。実際に手を動かすチームと直接やり取りできれば、情報のずれや待ち時間が減り、発注額が作業そのものに使われる割合も高くなります。
発注側の体制づくりで意識したいこと
- 仕様の判断ができる人を発注側に置き、質問に迅速に答える
- 決定事項は文書に残し、各層で同じ情報を参照できるようにする
- 定期的に成果物を自分の目で確認する
提案を比較する段階では、各社に「実際の開発体制図」を出してもらうと有効です。誰がどの会社に所属し、どの役割を担うのかが一枚で分かれば、層の深さや、窓口と実作業者の距離を判断できます。
よくある誤解と注意点
- 「下請け＝悪い」ではない：専門性の高い会社と組むための再委託は合理的です。問題は、層が深くなり情報と責任が見えなくなることです。
- 大手なら安心とは限らない：元請けの規模と、実際の開発体制は別の話です。実際の担当者を確認します。
- 発注側の進め方も影響する：仕様が曖昧なまま一括発注すると、各層での解釈のずれが大きくなります。
- 安さだけを求めると構造が深くなりやすい：無理な費用や納期は、さらに下の層へのしわ寄せにつながります。
関連用語
- SES（システムエンジニアリングサービス）：エンジニアの稼働に対価を払う契約形態。
- 内製化：外部に頼らず自社で開発すること。
- PMO（プロジェクトマネジメントオフィス）：プロジェクト管理を支援する組織や役割。
- ラボ型開発：専属チームを確保して開発する形態。
- 実践記事：システム開発会社の選び方、フリーランスと開発会社のどちらに頼むべきか
Otsumuに相談できること
開発会社の体制が明確で、実際の担当者とも直接やり取りできているなら、特に心配する必要はありません。誰が実際に作っているのか分からない、質問への回答が遅く仕様のずれが続いている、次の発注では体制を見直したい、といった場合は、目的と必要な機能を整理したうえで体制を選び直すのが有効です。Otsumuではシステム開発を、構想から開発・運用まで自社の少人数チームで一貫して担い、発注側と直接やり取りしながら進めます。30分の無料相談でお気軽にご相談ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01