多重下請け構造とは？元請け・一次請け・二次請けの仕組みと問題点

多重下請け構造の中で働きながら、「自分の会社は何次請けなのか」「なぜ顧客の顔すら見えないのか」と疑問を感じている人へ。多重下請け構造とは、発注された仕事が元請けから下請け、さらに孫請けへと段階的に再委託され、複数の企業が商流に入る仕組みです。

IT業界では元請け、一次請け、二次請け、三次請けと階層が深くなることがあります。私は、多重下請けを理解するときに最も重要なのは「何次請けか」という名称ではなく、契約・お金・情報・指示・実作業が誰から誰へ流れているのかを把握することだと考えています。

多重下請け構造とは？元請けから下請けまでどう仕事が流れる？

私は、多重下請け構造を理解するなら、まず「発注者と自分の間に何社いるか」を書き出すべきだと考えています。

多重下請け構造とは、発注者から仕事を直接受注した企業が別会社へ業務を委託し、その会社がさらに別会社へ再委託することで、複数の受発注階層が生まれている状態を指します。「重層下請構造」と呼ばれることもあります。

もっとも単純な形を図にすると、次のようになります。

• 発注企業（ユーザー企業）
• ↓ システム開発などを発注
• 元請け企業・一次請け企業
• ↓ 業務の一部を委託
• 一次下請け・二次請け企業
• ↓ さらに一部を委託
• 二次下請け・三次請け企業
• ↓ 人員や作業を提供
• 三次下請け以下の企業・現場エンジニア

ただし、呼び方は企業や案件によって異なります。

発注企業から直接仕事を受ける会社を「元請け」「直請け」「プライム」「一次請け」と呼ぶケースがあります。一方、その下を一次下請け、二次下請けと数える表現もあるため、「二次請け」という言葉だけでは階層を完全には判断できません。

重要なのは名称ではなく、発注者との間に何社入り、誰と誰が契約しているのかを見ることです。

たとえば企業Aがシステム開発を企業Bへ発注し、Bが企業Cへ開発の一部を委託し、Cが企業Dへプログラマーの確保を依頼したとします。

実際にコードを書くエンジニアが企業Dに所属していれば、発注企業Aとの間にはB社とC社が存在します。これが多重下請け構造の基本です。

元請けは何をする会社なのか

私は、元請けを「実際にプログラムを書く会社」とだけ捉えると、多重下請け構造を誤解すると考えています。

元請けとは、案件の発注者から直接仕事を受ける企業です。IT業界では、プログラムを書くことだけでなく、顧客との要件調整、プロジェクト全体の計画、予算管理、進捗管理、品質管理、協力会社への発注などを担当するケースがあります。

つまり、元請けの価値は「実作業をすべて自社で行うこと」とは限りません。

複数の企業や技術者をまとめ、大規模なプロジェクトを完了させるマネジメント機能にも価値があります。

この点を理解せず「元請けは仕事を流しているだけ」と一括りにすると、実際に担っているプロジェクト管理や品質保証の機能を見落とします。

下請けはどこまでを担当するのか

私は、「下請け」という言葉だけで仕事内容を判断するべきではないと思っています。会社の商流上の位置と、エンジニア本人が担当している工程は別だからです。

下請け企業は、元請けなど上位企業が受注した業務の一部または全部を契約に基づいて担当します。

案件によって、請負契約、準委任契約、派遣契約など異なる契約形態が使われます。

ここは混同しやすい部分です。

「客先で働いている＝下請け」「SES＝すべて請負」という意味ではありません。請負、準委任、労働者派遣では、仕事の完成責任や業務遂行方法、指揮命令関係などが異なります。

そのため、自分が多重下請け構造のどこにいるのか確認するときは、勤務場所だけで判断してはいけません。

• 自分の所属企業はどこか
• 所属企業は誰と契約しているか
• 顧客との間に何社入っているか
• どの企業が業務を管理しているか
• 自分はどの工程を担当しているか

この5点を分けて確認するほうが正確です。

---

多重下請け構造はなぜ生まれる？IT業界で階層化しやすい理由

私は、IT業界の多重下請け構造を「中間マージンを取る会社がいるから」という一言で説明するのは雑だと考えています。構造が生まれる根本には、案件ごとに必要な人数と専門性が大きく変わるという事情があります。

大規模案件に必要なエンジニアを、1社ですべて常時雇用しておくのは簡単ではありません。需要に応じて外部企業の人材や専門技術を利用すること自体には合理性があります。

問題になるのは、その分業が何層にも連なり、情報・予算・責任・育成機会まで分断される状態です。

必要なエンジニア数が案件ごとに変わる

私は、外注が発生すること自体より、外注先でも人員を確保できず再委託が連鎖することに注目すべきだと考えています。

システム開発では、案件によって必要な人数が大きく変わります。

大型プロジェクトを受注したときだけ100人必要だからといって、案件終了後も同じ人数の人件費を固定費として抱え続けられる企業ばかりではありません。

そこで不足する技術者を外部企業から確保します。

しかし一次下請け側でも必要人数を用意できなければ、さらに別会社へ依頼することになります。

• 大規模案件を受注する
• ↓
• 元請けだけでは人が足りない
• ↓
• 協力会社へ発注する
• ↓
• 協力会社でも人が足りない
• ↓
• さらに別会社へ発注する

という連鎖です。

ここだけを見ると、外注そのものには合理性があります。

しかし、階層が深くなっても担当企業がそれぞれ明確な役割を果たしているとは限りません。私は、「外注しているか」ではなく「その再委託によって何の機能が追加されているか」を見るべきだと考えています。

1980年代以降のIT需要拡大も背景にある

私は、多重下請け構造を現在の企業だけの問題として見るのではなく、日本のIT需要が拡大してきた歴史の延長として捉える必要があると思っています。

参考資料では、1980年代以降に企業のIT化が進み、元請け企業が多くのIT案件を受注する一方、自社だけで人員を育成・確保するのではなく、外部リソースを使って案件を遂行する仕組みが拡大したと説明されています。

多重下請け構造は、ある時点で誰かが一括して設計した制度ではありません。

IT需要の増加に対して、必要な技術者を企業間で融通する方法が積み重なった結果として形成された面があります。

似た構造はITだけでなく、建設、物流、広告、製造などにも見られます。

たとえば物流業界については、経済産業省・国土交通省・農林水産省による2023年4月27日の調査として、参考資料では約7割の事業者が下請けのトラック事業者を利用していると紹介されています。

つまり多重下請けは、IT業界だけに存在する特殊な現象ではありません。需要変動、専門分業、固定費負担を企業間取引で調整する産業では、階層化が起こりやすいと見るほうが実態に近いでしょう。

そして、ここまで商流を書き出して「自分が顧客から何社離れているのか分からない」と気づいたなら、転職するかどうかを今すぐ決める必要はありません。まず他社ではどのような商流・工程で働けるのか比較することが先です。

---

多重下請けの元請け・一次請け・二次請けでは何が違う？

私は、「上の商流ほど優秀、下の商流ほど劣る」と捉えるべきではないと考えています。見るべきなのは会社の序列ではなく、それぞれが案件の中で何を担当しているかです。

典型的な役割を整理すると、次のようになります。

立場	主な役割	発注企業との距離	担当しやすい業務
発注企業	システムやサービスを依頼	当事者	予算決定、要求整理
元請け・プライム	案件全体を受注	直接	要件調整、PM、設計、管理
一次下請け	元請けから業務を受注	1社挟む	設計、開発、チーム管理
二次・三次下請け	上位会社から再委託	複数社挟む	開発、テスト、運用など
現場エンジニア	実際の作業を担当	商流次第	設計、実装、試験、保守

もちろん、これは典型例であって、すべての案件に当てはまるわけではありません。

三次請けでも高度な専門技術を提供する会社はありますし、元請けでも自社エンジニアが大量の開発作業を担当している企業があります。

請負階層の深さと、そのエンジニアの技術レベルは同じものではありません。

私はここを強く分けて考えるべきだと思っています。

転職市場では「元請けか下請けか」という言葉が目立ちますが、本当に確認したいのは、案件の中でどの工程を経験できるか、顧客とどこまで関われるか、技術的な意思決定に参加できるかです。

一方で、階層が深くなるほど発注者から距離が生まれやすいという構造上の特徴はあります。

顧客がなぜそのシステムを必要としているのか、どの事業課題を解決したいのかといった情報が、末端のエンジニアまで十分に届かないケースもあります。

「指示された機能は作れる。しかし、なぜ作っているのかは分からない」という状態が長く続くなら、キャリア形成では注意したほうがいいと私は考えています。

---

多重下請け構造にはどんな問題がある？

私は、多重下請けの最大の問題を「中抜き」という言葉だけで説明するべきではないと考えています。より本質的なのは、階層が増えるほど情報・予算・権限と実作業者の距離が広がりやすいことです。

参考資料では、多重下請け構造の問題として、責任の所在、人材育成、労働環境、生産性・競争力などが挙げられています。

それぞれ別の問題に見えますが、商流が深くなることで仕事に必要な情報や意思決定権が分断されるという共通点があります。

責任の所在が分かりにくくなる

私は、中間企業の数よりも「問題が起きたとき誰が決められるのか」を確認するほうが重要だと考えています。

多重下請け構造では、1つのシステムに複数企業が参加します。

不具合が発生すれば、

• 要件の問題なのか
• 設計の問題なのか
• 実装の問題なのか
• テストの問題なのか

を切り分けなければなりません。

各工程を別企業が担当している場合、原因確認のための連絡も企業間をまたぎます。

元請け→一次下請け→二次下請け→担当者という順番で情報が伝われば、それだけ確認の往復が増えます。

私は、多重下請け構造の問題を「中間マージン」だけで語るより、この意思決定と責任確認の距離が伸びることのほうが重要だと考えています。

システム開発では、仕様変更や障害への対応速度が品質や納期に影響するからです。

エンジニアが全体像を理解しにくくなる

私は、下流工程を担当すること自体は問題ではないと考えています。問題なのは、本人が望んでも担当範囲を広げられない状態が何年も固定されることです。

参考資料では、案件が細分化され、一機能や部品単位の作業ばかり担当すると、システム全体を俯瞰する経験を得にくいことが問題として挙げられています。

たとえば同じJavaエンジニアでも、次のような一連の工程に触れられる人がいます。

• 顧客の業務課題を聞く
• 要件を整理する
• システム全体を設計する
• プログラムを実装する
• テストする
• リリース後の改善まで担当する

一方で、決められた仕様書をもとに特定機能だけを実装し続けるケースもあります。

数年間の経験年数が同じでも、経験した意思決定の範囲は変わります。

もちろん、実装やテストの経験には大きな価値があります。実装を理解しないまま上流工程だけ担当すれば、現実的な設計ができるとは限りません。

だから見るべきなのは「上流か下流か」のラベルではありません。

今の会社に居続けたとき、担当できる範囲が広がる仕組みがあるか。私はここを確認すべきだと思っています。

階層が増えるほど予算が現場へ届きにくくなる

私は、「中間マージンがあるから悪い」ではなく、「その対価としてどんな価値が提供されているか」で判断するべきだと考えています。

多重下請け構造では、各企業が契約上の役割を担い、それぞれ事業として利益を確保します。

そのため、下位企業へ渡る案件予算は発注時の金額そのものではありません。

単純化すると、次のような流れです。

• 発注企業
• ↓ 1,000万円で発注
• 元請け
• ↓ 一部を700万円で委託
• 一次下請け
• ↓ 一部を500万円で委託
• 二次下請け
• ↓ 実作業を担当

これは、実際の取引価格が必ずこのように減るという意味ではありません。

各社が営業、プロジェクト管理、品質保証、契約管理などを行いながら事業を維持する以上、それぞれに必要なコストと利益があります。

元請けや中間会社が顧客調整、設計、管理、品質保証など明確な価値を提供しているなら、その対価には合理性があります。

反対に、実質的な役割が乏しいまま再委託だけが繰り返されれば、商流を維持するためのコストだけが増える可能性があります。

したがって見るべきなのは、「中間会社が存在すること」ではありません。

その会社が商流に入ることで何の価値を生んでいるのか。ここが判断軸です。

労働環境や生産性にも影響する可能性がある

私は、「何次請けだから労働環境が悪い」と一律には断定できないと考えています。ただし、予算と裁量が限られた企業ほど、人材育成や設備投資に使える余力が小さくなる可能性は無視できません。

参考資料では、下位の受注企業ほど予算が限られ、仕事量とのバランスが崩れることで、長時間労働や休日出勤などにつながる可能性が指摘されています。

さらに人材が疲弊すれば、生産性や品質にも影響しかねません。

企業側から見れば、

• 低単価
• ↓
• 教育・設備投資の余力が減る
• ↓
• 技術者が育ちにくい
• ↓
• 生産性が上がらない
• ↓
• 高単価案件を取りにくい
• ↓
• 再び低単価案件へ依存する

という循環に入る可能性があります。

私は、多重下請け構造で最も注意すべきなのは「何次請けか」という肩書きそのものより、会社とエンジニアが次の段階へ進むための投資余力を持っているかだと考えています。

研修制度が書かれているかだけでは足りません。

実際に上位工程へ移る人がいるか、技術選定に関わる案件があるか、自社内に知見を共有する仕組みがあるかまで確認したほうが、将来性を判断しやすくなります。

---

多重下請け構造はすべて悪いのか？

私は、外注や下請けそのものを悪い仕組みと決めつけるべきではないと考えています。問題は企業間分業の存在ではなく、各社が明確な役割を担っているかです。

大規模システムを1社ですべて開発する必要はありません。

ネットワーク、クラウド、セキュリティ、データベースなど、特定分野に強い専門会社へ任せることで、品質や開発速度が上がるケースもあります。

一時的に必要な人数を外部から確保することも、企業の固定費を抑えながら需要変動へ対応する方法として機能します。

これは物流業界でも同じです。

参考資料では、繁忙期などの需要変動、ドライバー不足、突発的な運送依頼への対応として外部事業者を利用する実態が示されています。

つまり問題は「下請けがあるか・ないか」の二択ではありません。

必要な分業なのか、それとも付加価値の乏しい階層が増えているだけなのか。

私はここを分けて考えるべきだと思っています。

ITエンジニアのキャリアでも同じです。

二次請け企業や三次請け企業に所属しているからといって、それだけで転職すべきとは言えません。

確認したいのは次の点です。

• 顧客の課題を理解できるか
• 上流工程へ進めるか
• 設計や技術選定に関われるか
• 自社内に技術的なノウハウが残るか
• 評価と給与が担当業務に見合っているか
• 特定案件だけでなく市場で使える能力が身につくか

「客先常駐だから辞めたい」という段階では、まだ転職条件が粗いケースがあります。

「顧客の要求を直接聞ける仕事がしたい」「設計を担当したい」「事業側でシステム企画から関わりたい」と、今の構造で不足している経験まで言葉にできると、次の会社を選びやすくなります。

SESからの脱却は、気合や運ではなく、自分が商流のどこにいて、どの情報・権限・経験へアクセスできていないのかを理解することから始まります。

今の会社でその不足を埋められないなら、転職を即決する必要はありませんが、他社の求人で「商流・担当工程・顧客との距離」を比較する価値はあります。

---

多重下請け構造は今後どう変わる？重要なのは「階層」より介在価値

私は、「多重下請けを完全になくせばIT業界の問題が解決する」とは考えていません。今後重要になるのは階層の数だけではなく、各企業が商流へ入る理由を説明できるかです。

多重下請け構造を改善する方法として、参考資料では人材の確保や内製化、ビジネスモデルの転換などが挙げられています。

自社に技術者を確保し、企画から開発、運用まで担当できれば、外部へ再委託する必要は減ります。

コミュニケーション経路も短くなり、ノウハウを自社に蓄積しやすくなります。

一方、数百人規模のシステム開発を行うとき、すべての専門人材を1社で常時雇用するモデルが合理的とは限りません。

顧客折衝をする。

要件を整理する。

設計をする。

異なる専門企業を統括する。

品質を保証する。

技術支援をする。

こうした明確な役割を果たしている企業が商流に入ることには意味があります。

一方で、「案件情報を次の会社へ渡すだけ」「人を別会社から調達してさらに別会社へ出すだけ」という階層が増えるほど、その存在意義は説明しにくくなります。

ここで参考になるのが、物流業界で進んでいる商流の可視化です。

参考資料によれば、2025年4月から元請け事業者に実運送体制管理簿の作成が義務付けられ、実際に運送する事業者や請負階層を把握する仕組みが導入されました。

さらに2025年5月に成立した貨物自動車運送事業法の改正では、再委託回数を2回以内とする努力義務など、多重化を抑える方向性も示されています。

ITと物流では契約や規制が異なるため、物流の制度をそのままIT業界へ当てはめることはできません。

ただ、「誰が実作業をしているのか」「何社が介在しているのか」「各社がどの価値を担っているのか」を可視化する考え方は、IT業界でも重要です。

私は、エンジニア個人にも同じ視点が必要だと考えています。

まず紙やメモに、

発注者 → 元請け → 一次下請け → 二次下請け → 自社 → 自分

という商流を書き出してみてください。

分からない部分があれば、それ自体が確認ポイントになります。

次に、各社の横へ「何を担当している会社か」を書きます。

そして最後に、自分が将来どこへ進みたいかを照らし合わせます。

• 顧客に近い場所で要件を考えたい
• プロジェクト管理をしたい
• 技術スペシャリストになりたい
• 自社サービス開発へ移りたい
• 事業会社側で企画やベンダー管理をしたい

この順番で整理すると、「何次請けだから嫌だ」という感情を、次の職場選びに使える具体的な条件へ変えられます。

これが、多重下請け構造を理解する実務的な意味です。

---

多重下請け構造とは何かを改めて整理

私は、多重下請け構造を知ったあとに持ち帰るべきなのは、「下請けは悪い」という結論ではなく、自分の仕事がどんな商流と役割分担の上に成り立っているか確認する視点だと考えています。

多重下請け構造とは、発注企業から案件を受注した元請けが下請けへ仕事を委託し、その企業がさらに別会社へ再委託することで、契約関係が何層にも重なる仕組みです。

IT業界では、大規模案件への人員対応、専門技術の確保、人件費などの固定費抑制といった事情から、この仕組みが広がってきました。

一方で階層が深くなると、責任の所在が見えにくくなり、情報伝達が複雑化し、現場へ届く予算が限られたり、エンジニアが特定工程だけを担当し続けたりする問題も起こり得ます。

ただし、下請けや外注自体を問題視するだけでは本質を見誤ります。

重要なのは、元請け、一次請け、二次請けなどの各企業がどの役割を担い、商流へ入ることでどのような価値を生んでいるかです。

システムを発注するときに実際の開発主体や再委託構造を把握することは、品質・セキュリティ・責任分界を整理するうえで重要です。

反対にエンジニア側から見れば、商流を理解することは給与だけでなく、顧客との距離、経験できる工程、技術的な裁量、将来のキャリアまで読み解く材料になります。

最後に判断基準を1つに絞ります。

今の商流でも希望する工程へ進め、技術や顧客理解を積み上げられるなら、「多重下請け」という理由だけで転職する必要はありません。反対に、担当範囲が固定され、数年後も増やせる経験が見えないなら、他社の商流と担当工程を比較する段階に入っています。

「多重下請けだから悪い」と感情的に切り捨てるのではなく、自分がどの階層にいて、誰が何を担当し、どこに価値が生まれているのかを確認してください。

---

よくある質問

多重下請け構造とは簡単にいうと何ですか？

私は、「発注者と実作業者の間に複数の会社が入っている状態」と捉えると理解しやすいと考えています。

発注企業から仕事を受けた元請けが別会社へ委託し、その会社がさらに別会社へ再委託することで、元請け・一次下請け・二次下請け・三次下請けなど複数の階層が生まれる仕組みです。

IT、建設、物流、広告、製造など、複数企業による分業が行われやすい業界で見られます。

SESと多重下請け構造は同じ意味ですか？

私は、この2つを同じ意味として扱うべきではないと考えています。

SESは一般にITエンジニアによる技術支援を扱うビジネスを指す言葉として使われますが、多重下請け構造は発注・再委託が複数階層にわたっている「商流の状態」を示します。

そのため、SES企業でも商流が浅いケースはありますし、SES以外の請負開発でも複数階層の再委託が発生することがあります。

また、SES、請負、準委任、派遣は同じ概念ではありません。勤務場所だけを見て契約形態や商流を決めつけないことが重要です。

多重下請け企業で働いていたら転職したほうがいいですか？

私は、請負階層だけで転職を決めるべきではないと考えています。

顧客との距離、担当工程、設計や技術選定への参加、自社にノウハウが蓄積されるか、給与と仕事内容が釣り合っているか、今後担当範囲を広げられるかを確認してください。

今の会社でも希望する経験を増やせるなら残る選択肢があります。反対に、担当工程が固定され、会社に相談しても将来のキャリアパスが見えないなら、他社との比較を始める目安になります。

多重下請け構造を理解する目的は、焦って会社を辞めることではありません。自分の現在地と不足している経験を把握し、次の選択を構造的に判断できるようにすることです。

執筆：新海 智也