多重下請けがなぜ生まれるのか疑問に感じる人へ。答えは、発注側と受注側の利害が人員調整と責任分担で一致するからです。
「何社も間に入る意味が分からない」「自分の単価だけ削られているのでは」と感じているなら、まず構造そのものを分解して見る必要があります。
単純に「中間企業が利益を抜くため」だけでは説明できません。IT業界では、需要変動、人材不足、責任分担、専門分業、発注企業のIT人材不足といった複数の事情が重なり、多重下請けが合理的な仕組みとして残り続けています。
多重下請け構造とは何が何重になっているのか？
私は、多重下請けを理解するときに最初から「良い・悪い」で見るべきではないと思っています。まず確認すべきなのは、仕事の受発注関係が何層になり、それぞれの企業が何を担当しているのかです。
多重下請け構造とは、発注企業から仕事を受けた元請け企業が業務を別企業へ委託し、その企業がさらに別企業へ委託することで、受発注関係が何層にも重なった状態を指します。
たとえばシステム開発では、発注企業から直接案件を受ける「元請け」「一次請け」「プライム」と呼ばれる企業が存在します。
元請け企業はプロジェクト全体を管理しながら、自社だけでは対応できない設計、開発、テスト、インフラ構築などを別の企業へ発注します。
一次下請けが自社だけで対応できなければ、さらに二次下請けへ発注します。二次下請けが三次下請けへ委託すれば、その分だけ階層が深くなります。
IT業界では、こうした取引で請負契約、準委任契約、派遣契約など複数の契約形態が使われます。
請負契約では一般に成果物の完成が重要となり、派遣契約では派遣先が労働者に指揮命令を行います。準委任では業務の遂行を委託しますが、発注側が受注側の労働者へ直接指揮命令する契約ではありません。
つまり「同じ現場にいる人たち」が、必ずしも同じ会社や同じ契約関係に属しているわけではありません。
ここは客先常駐やSESを考えるうえでも重要です。勤務場所が客先であることと、誰が業務上の指揮命令をする契約なのかは別の問題だからです。
そして、多重下請け自体をすべて不合理な仕組みと考えるのも正確ではありません。専門分業や繁忙期の人員調整という意味では、外注そのものには経済合理性があります。
問題になるのは、必要な分業を超えて階層が深くなり、誰が何を管理しているのか分からなくなった場合です。
多重下請けはなぜ生まれる？発注側にはどんなメリットがある？
私は、多重下請けが生まれる最大の出発点は、発注企業が必要な技術者をすべて自社で固定的に抱える必要をなくせることだと考えています。
大規模なシステム開発を例に考えてみます。
ある企業が数百人規模の開発プロジェクトを実施するとしても、その規模の案件が毎年同じように発生するとは限りません。
プロジェクトのピークに合わせて数百人の技術者を直接雇用すれば、プロジェクト終了後も給与や社会保険、教育、管理などの固定費が残ります。
そこで、大規模案件を受注できる企業へプロジェクト全体を任せ、必要な期間だけ外部の開発リソースを利用する方式が選ばれます。
2024年4月19日のアイエスエフネット編集部の記事でも、日本では雇用流動性が低く、一時的に人員需要が増えても柔軟に雇用を調整しにくいことが、多重下請けを生む背景として挙げられています。
1980年代以降に企業のIT化が進むと、元請けとなるIT企業には多くの開発案件が集まりました。
しかし、案件の最大規模に合わせて常時大量のエンジニアを抱えるのではなく、必要な人材を外部から確保する方式が広がりました。
この考え方を突き詰めると、多重下請けは単なる「中抜き」ではなく、企業が開発人員の需給変動を吸収する仕組みでもあることが分かります。
発注企業は「技術」だけでなく「責任」も買っている
私は、発注企業が外部の大手IT企業へ支払っている対価を「エンジニアの作業費」だけで考えると、多重下請けの理由を見誤ると思っています。
大規模システムでは、予算だけでなく事業への影響も大きくなります。障害や納期遅延が発生した場合、発注企業には原因究明や復旧、社内説明などが必要になります。
そのため発注企業からすれば、多数の小規模な開発会社と個別に契約するより、プロジェクト全体を管理できる大手企業と契約するほうが管理しやすい場合があります。
元ネタとして提示されたIT業界関係者の見解でも、大規模案件では「問題が発生した際の責任を引き受けられる規模の企業へ発注する」という考え方が紹介されています。
もちろん、これは個人の見解であり、すべての案件が同じ理由で大手企業へ発注されるわけではありません。
ただし、発注企業がPMや設計能力まで外部へ委ねる場合、「実際にプログラムを書く会社」だけではなく、「プロジェクト全体を取りまとめる会社」の価値が生まれます。
発注者が購入しているのはエンジニアの作業時間だけではありません。大規模案件を統括する能力、契約管理、品質管理、トラブル対応を含めた管理機能も購入しています。
だからこそ、間に企業が存在することと、何の価値も生まない企業が介在することは分けて考えなければなりません。
なぜ元請けは下請けへ仕事を出すのか？
私は、元請け企業が再委託すること自体を問題視しても、多重下請けの構造は理解できないと思っています。元請けにも、案件の波と専門人材の不足を吸収する必要があるからです。
大手の元請け企業が案件を受注したあと、自社ですべて開発すれば多重下請けは解消できるのでしょうか。
理論上は可能でも、現実には簡単ではありません。
理由は、開発需要が常に一定ではないからです。
大型案件を基準に大量のエンジニアを雇えば、案件が少ない時期には人員が余ります。反対に通常時の仕事量に合わせて人員を抱えれば、大型案件を受注したときに人手が不足します。
2024年1月29日更新のHiPro Techの記事でも、プロジェクトごとの人員配置のロスを減らすことが、多重下請け構造が根付いた背景の一つとして説明されています。
必要なタイミングで外部企業へ発注できれば、元請けは固定費を抑えながら大きな案件を受注できます。
受注能力を自社従業員数だけに制限されなくなるわけです。
さらにシステム開発には、アプリケーション、ネットワーク、クラウド、セキュリティ、データベース、テストなど多くの専門領域があります。
すべての分野で大量の専門人材を社内にそろえることは容易ではありません。
専門企業へ仕事を分けること自体には合理性があります。
製造業で部品を専門メーカーから調達したり、建設業で電気工事や水道工事を専門業者へ依頼したりするのと同じく、分業によって専門性を利用できるからです。
したがって、本質的な問題は「下請けが存在すること」ではありません。
管理機能や専門性を提供しない企業まで階層に入り、委託だけを繰り返す状態になることです。
多重下請けはなぜ受注側でも繰り返されるのか？
私は、多重下請けが長く残る理由として「人員不足」だけでなく、企業間の営業経路が固定化されることも大きいと考えています。
多重下請けを考えるとき、元請け側の事情だけを見ると構造を正しく理解できません。
一次請けや二次請けといった受注側にも、さらに仕事を外注する理由があります。
たとえば一次請け企業が30人必要な案件を受けても、自社で空いている技術者が20人しかいなければ、残り10人分を外部企業へ委託する選択肢が出てきます。
その委託先も必要人数を確保できなければ、さらに別会社へ仕事が流れます。
結果として、次のような階層が形成されます。
- 発注企業
- 元請け企業
- 一次下請け
- 二次下請け
- 三次下請け
- 実際に作業する企業や技術者
元ネタにある中小IT企業経営者の説明では、巨大な国家プロジェクトを例として、大企業が案件全体を受け、中堅企業へ機能単位で分割し、さらに小規模な開発会社へ細分化していく構造が紹介されています。
この例で重要なのは、小規模企業に巨大プロジェクト全体をそのまま渡しても処理できないという点です。
100億円規模の仕事を数十人規模の会社が単独で受注しても、契約、資金、人員、管理能力の面から対応できるとは限りません。
案件を適切な単位へ分割すること自体には意味があります。
一方で、受注企業には営業面の事情もあります。
実績が少ない企業が、いきなり大企業から大型案件を直接受注するのは容易ではありません。過去の取引実績や信用力がある元請け企業に案件が集まり、新規参入企業はその下の階層から実績を積むことになります。
その結果、一度できた商流が次の案件でも利用されます。
技術者個人の能力が高くても、企業間取引では契約、信用、営業、管理の実績が求められます。
つまり、技術力だけで商流の階層が決まるわけではありません。
もし今の環境で商流も担当工程も変わる見込みがないなら、「辞めるか」を決める前に、外ではどんな選択肢があるのか比較しておく価値があります。
今の市場価値を確認するなら：
客先常駐エンジニアにおすすめの転職エージェント5選
なぜ多重下請け構造はなくならない？発注側と受注側の利害が一致するから
私は、多重下請けが問題視されながら残り続ける理由を「古い慣習だから」の一言で済ませるべきではないと思っています。関係企業それぞれに、構造を維持する経済的な理由があります。
発注企業は、多数の開発会社を自社で直接管理せずに済みます。
元請け企業は、自社で大量のエンジニアを常時雇用せず、大型案件を受注できます。
下請け企業は、自社だけでは獲得できない大規模案件へ参加できます。
さらに案件の繁閑に合わせて企業間で人員を融通できるため、業界全体として固定人員を減らす効果もあります。
元ネタの一つでは、システム開発の人的リソースを製造業の「在庫」にたとえる説明もされています。
開発案件がない期間でも正社員には給与が発生するため、企業から見ればエンジニアの非稼働期間はコストになります。
多数の企業が一つの受注経路に参加し、人材需要をまとめれば、余剰人員を減らしやすくなるという考え方です。
この視点に立つと、多重下請けは単に昔の慣習だから残っているわけではありません。
案件量の変動を企業間ネットワークで吸収する機能を持っているため、現在まで存続していると見るほうが実態に近いと私は考えます。
同様の構造はITだけではありません。
アイエスエフネットの記事では、IT業界のほか建設業界と運送業界も多重下請けが見られやすい業界として挙げています。
建設では工事ごとに必要な専門職や人員が変わり、運送では荷物量の変動に合わせて車両やドライバーを確保する必要があります。
国土交通省などが2023年4月27日に公表したトラック輸送の多重下請構造に関する実態把握調査では、7割の事業者が下請けのトラック事業者を利用していると回答したと紹介されています。
さらに物流では、季節や曜日によって荷物量が大きく変わります。
ピークに合わせてトラックとドライバーを常時抱えると固定費が増えるため、自社で処理できない荷物を同業他社へ委託する仕組みが発達しました。
ITと物流は仕事の内容こそ異なりますが、「需要の変動に対して固定人員・固定設備を持ちすぎない」という点では共通しています。
多重下請け構造は何が問題なのか？
私は、多重下請けの問題を「企業が何社入っているか」だけで判断するのは危険だと考えています。見るべきなのは、階層が増えた結果、管理・情報・報酬・キャリアにどんな影響が出ているかです。
多重下請けが生まれること自体には合理的な理由があります。
それでも問題視されるのは、階層が深くなることで、その合理性を上回る弊害が発生する場合があるためです。
とくに指摘されるのが、責任の所在、情報伝達、人材育成、報酬の四つです。
責任の所在が見えにくくなる
私は、複数企業が関わることよりも「責任範囲が設計されていないこと」のほうが問題だと思っています。
複数の会社が一つのシステムに関与すると、不具合が起きた工程を特定するまでに時間がかかる可能性があります。
要件を決めた企業、設計した企業、開発した企業、テストした企業が異なれば、「どの段階で認識がずれたのか」を調査する必要があるからです。
階層が深いほど、発注企業と実際の開発担当者との距離も遠くなります。
途中の企業が十分に管理していなければ、伝言ゲームのような状態になりかねません。
下流工程に固定されると人材育成が難しくなる
私は、エンジニア個人にとってはこちらのほうが重要な問題だと考えています。商流の深さそのものより、担当できる工程が固定されることのほうがキャリアには直接影響するからです。
元ネタでは、多重下請けによって一つの案件が細分化され、下位企業が一機能や一部品だけを担当し続ける問題も指摘されています。
一部分の実装やテストだけを長期間担当していると、要件定義、設計、プロジェクト管理などシステム全体を見る経験を得にくくなる場合があります。
もちろん、下請け企業にいるだけでスキルが伸びないと断定することはできません。
高度な専門技術を持つ企業が専門領域だけを受託するケースもあるからです。
重要なのは「何次請けか」という数字だけではなく、自分の会社がどの役割を担当し、どこまで意思決定に参加できているかです。
階層が増えるほど現場予算が減る可能性がある
私は、「中間企業がいる＝中抜き」と短絡する必要はない一方、各階層の役割と対価が釣り合っているかは確認すべきだと思っています。
元請け企業は、受注金額から管理費や利益を確保したうえで下請けへ発注します。
次の企業も同じように利益や管理コストを確保して再委託すれば、末端で実作業を担当する企業が受け取る金額は当初の契約金額より小さくなります。
もちろん、中間企業がプロジェクト管理、品質保証、顧客折衝、設計、セキュリティ管理など明確な役割を果たしているなら、その対価には合理性があります。
問題なのは、付加価値の薄い企業が複数介在するケースです。
元ネタでは、極端なケースとして受注案件をほぼ丸ごと再委託し、途中企業が利益だけを差し引くような状態も問題として挙げられています。
こうなると、下位企業に低い予算と大きな作業量が集中し、長時間労働や休日出勤など労働環境の悪化につながる懸念があります。
生産性まで低下すれば発注側にも跳ね返る
私は、多重下請けの弊害をエンジニア側だけの問題として扱うべきではないと思っています。現場の情報伝達や技術蓄積が弱くなれば、最終的な損失は発注企業にも戻るからです。
現場の予算不足やコミュニケーションの複雑化によって品質や生産性が低下すれば、最終的には発注企業にも影響します。
HiPro Techの記事では、経済産業省が2008年に公表した「IT産業における下請の現状・課題について」を根拠として、元請企業と下請企業の生産性には約1.7倍の差があったと紹介しています。
古いデータであるため、現在のIT業界へそのまま当てはめるべきではありません。
ただ、多重下請けが「人件費を安くする問題」だけではなく、産業全体の生産性や技術蓄積にも関わるという論点は現在でも重要です。
ここまでの問題が自分の現場にも重なり、担当工程を広げる見込みも薄いなら、今の会社の外にどんな選択肢があるかを調べる段階に入っています。
今の市場価値を確認するなら：
客先常駐エンジニアにおすすめの転職エージェント5選
多重下請けをなくせばすべて解決するのか？
多重下請けをゼロにすること自体を目標にしても、IT業界の問題は解決しません。
大規模プロジェクトでは専門分業が必要ですし、案件量の増減もなくなりません。
発注企業があらゆる専門家を正社員として抱える方式にも、人件費や採用難という別の問題があります。
また、小規模な専門企業が大規模案件へ参加できるのも、元請け企業が仕事を分割しているからです。
したがって、必要なのは「外注を禁止すること」ではありません。
どこまでが必要な分業で、どこからが付加価値の乏しい多層化なのかを区別することです。
私なら、多重下請けを見る際には「何次請けか」だけではなく、次の観点を確認します。
- 各企業が具体的にどの管理・技術機能を担っているか
- 発注企業と実際の開発担当者が必要な情報を共有できているか
- 再委託によって品質管理や責任分担が曖昧になっていないか
- 現場企業に技術やノウハウが蓄積する仕事になっているか
- 階層が増えることで価格だけが削られていないか
中間企業が存在していても、PM、アーキテクト、品質管理、セキュリティ管理など明確な価値を提供しているのであれば、その企業を単純に「不要」とは言えません。
一方、顧客との契約を別会社へ流すだけで実質的な役割がほとんどない場合は、階層を減らす余地があります。
この切り分けをしないまま「多重下請けだから悪い」「大手だから中抜きしている」と決めつけると、構造の本質を見誤ります。
とくにエンジニア側では、「三次請けだから悪い」と会社の位置だけで判断するより、顧客課題、設計判断、技術選定、レビュー、改善提案のどこまでに関われているかを見るほうが実務的です。
発注企業の内製化で多重下請けは減るのか？
私は、内製化は多重下請けを浅くする有力な方法の一つだと思います。ただし、内製化を進めれば自動的に安くなり、外注が不要になるわけではありません。
発注企業自身がIT人材を抱え、要件定義やプロジェクト管理を行えるようになれば、すべてを大型SIerへ一括発注する必要は小さくなります。
専門企業やエンジニアと直接契約する選択肢も増えます。
また、開発と運用を社内で継続すれば、システムに関する知識を自社へ蓄積できます。
元ネタでも、多重下請けから脱却する利点として、開発スピードや品質の向上、ノウハウの蓄積が挙げられています。
ただし、内製化にもコストがあります。
IT人材を採用し、技術力を維持し、プロジェクトの繁閑にかかわらず雇用を続ける必要があるからです。
つまり「外注から内製へ変えれば自動的に安くなる」という話ではありません。
発注企業自身がプロジェクトを管理できる能力を持ち、長期的にIT人材を活用できる仕事量がある場合に、内製化の効果が出やすくなります。
逆に数年に一度しか大型開発を行わない企業なら、外部企業を活用する合理性は残ります。
多重下請けが生まれる理由を理解すると、内製化が万能ではない理由も見えてきます。
また、今後は「内製か外注か」の二択ではなく、コア領域は社内で握り、専門領域のみ外部企業を使う形も重要になります。
発注側が要件、設計方針、アーキテクチャ、優先順位を自ら判断できれば、外注先が複数存在しても、従来型の丸投げに近い多重構造とは性質が変わります。
多重下請け構造をエンジニアはどう見ればいい？
私は、客先常駐エンジニアが多重下請けを理由に今すぐ辞める必要はないと思っています。判断材料にすべきなのは、商流の深さよりも現在の仕事から次のキャリアにつながる経験を取れているかです。
たとえば三次請けでも、高度な専門技術を評価されて参画している企業なら、技術者として経験を積める可能性があります。
反対に一次請けでも、案件管理だけで技術経験がほとんど得られない職場もあり得ます。
ただし、長期間にわたり案件の一部分だけを担当し、顧客との接点も設計経験もなく、自社にもノウハウが蓄積していない場合には注意が必要です。
キャリア市場で評価されるのは「何年間働いたか」だけではなく、何を設計し、何を改善し、どこまで責任を持ったかだからです。
最初から転職だけを答えにする必要はありません。
まず現在の案件について、発注企業、元請け、自社、再委託先の関係を整理し、自分がどの工程を経験できているのかを見るほうが先です。
具体的には、「自分は誰から仕事を受け、誰に成果を返し、何を自分で判断できているのか」を書き出してみると構造が見えやすくなります。
そこで上流工程や設計へ広がる余地がないと分かった場合に、一次請け、受託開発、社内SE、自社サービス企業など別の選択肢を比較すればよいでしょう。
動く決心がついてから情報を集めるのではなく、情報を集めてから動くかどうかを決めればいいのです。
構造を知らずに「客先常駐は全部だめ」と判断するより、自分がどこにいて、どの価値を提供しているのかを把握するほうが合理的です。
多重下請けはなぜ生まれるのかを発注側・受注側から考える
私は、多重下請けが長く残ってきた理由は、誰か一社の都合ではなく、発注側・元請け・下請けの合理性が連鎖しているからだと考えています。
多重下請けが生まれる理由を一言でまとめるなら、企業が仕事量の変動、専門性、管理責任を自社だけで抱えないためです。
発注企業は、多数の専門企業を直接管理する負担や大型プロジェクトのリスクを減らしたい。
元請け企業は、案件のピークに合わせて大量の技術者を常時雇用するリスクを避けたい。
下請け企業は、自社だけでは獲得できない大型案件へ参加したい。
この三者の事情がかみ合うため、多重下請け構造は形成されます。
そして一度できた商流には、取引実績、信用、営業関係、管理ノウハウが蓄積します。
新しい案件でも同じ取引先へ発注するほうが企業にとって安全であるため、構造はさらに固定化されます。
ここまで考えると、多重下請けが何十年も残っている理由は、「誰も問題に気づいていないから」ではないことが分かります。
一定の機能を持ち、関係企業にとって経済合理性があるから残ってきました。
一方で、階層が深くなりすぎれば、情報伝達の遅れ、責任の曖昧化、現場予算の減少、人材育成の停滞といった副作用が大きくなります。
今後重要になるのは、多重下請けそのものを一律に否定することではなく、「中間にいる企業は何を提供しているのか」を可視化することだと私は考えます。
技術、管理、品質保証、調整といった明確な価値があれば、外注には意味があります。
反対に、実質的な付加価値がないまま契約だけを何段階も流す構造は、発注企業にとってもエンジニアにとっても持続しにくいでしょう。
IT人材の内製化やクラウドサービス、SaaS、標準パッケージの活用が進めば、従来のように巨大なスクラッチ開発を細かな工程へ分割して発注する案件は、一部では減る可能性があります。
それでも専門人材を外部から調達する需要までなくなるとは考えにくいため、多重下請けは「消滅する」というより、必要な階層だけを残す方向へ変化していくと見るほうが現実的です。
ここで注目したいのは、企業の階層数だけではなく、誰が要件を決め、誰が設計を判断し、誰に知識が残るのかです。
同じ三次請けでも専門技術を持って意思決定に参加できる案件と、指示された作業だけを繰り返す案件では、エンジニアにとっての意味は大きく異なります。
まとめ
私は、多重下請けについて「何次請けなら危険」と一律に決めるより、各企業が何を担い、自分に何が残るのかを見るべきだと考えています。
多重下請け構造がなぜ生まれるのかを考えると、単純な中間搾取だけでは説明できません。
発注側には、大規模プロジェクトの管理や責任をまとめて任せたい事情があります。元請けや受注側には、案件量に合わせて人員を調整し、固定費を抑えながら大型案件へ対応したい事情があります。
さらに専門分業、IT人材不足、既存取引先への信用、営業経路の固定化などが重なり、多重下請け構造は長期間続いてきました。
一方で、階層が深くなりすぎると、責任の所在が分かりにくくなり、情報伝達が遅れ、現場予算や人材育成にも悪影響が出る可能性があります。
そのため重要なのは、「下請けを全部なくすこと」ではありません。
各企業が技術や管理という実質的な価値を提供しているかを確認し、不要な階層を減らしていくことです。
エンジニア側の判断は具体的です。設計・改善・顧客折衝・技術選定など担当範囲が広がっているなら、商流が深いだけで転職を急ぐ必要はありません。反対に、長期間同じ限定作業に固定され、今後も担当範囲が広がる見込みがないなら、別の環境を比較し始める目安になります。
「何次請けか」ではなく、「この仕事を続けた先で何を説明できるエンジニアになるか」。ここを基準にすると、多重下請けの中にいる自分の立ち位置を冷静に判断できます。
よくある質問
多重下請け構造はなぜなくならないのですか？
私は、発注側と受注側の双方に経済合理性があることが最大の理由だと考えています。
発注企業にはプロジェクト管理や人員調整を外部へ任せたい事情があり、受注企業にも固定人員を増やさず大型案件へ対応したい事情があります。
専門分業や取引実績による信用もあるため、一定の機能を持つ仕組みとして残っています。
多重下請け構造はすべて悪いのでしょうか？
すべてが問題とは限りません。
専門企業への分業や繁忙期の人員確保には合理性があります。問題になりやすいのは、階層が過度に深くなり、途中企業の役割が不明確になったり、情報や報酬が現場まで十分に届かなくなったりするケースです。
「何社入っているか」だけではなく、「それぞれの会社に明確な役割があるか」を確認するのがポイントです。
IT業界で多重下請けが多いのはなぜですか？
大規模開発では必要なエンジニア数が案件ごとに大きく変動し、専門分野も多岐にわたるためです。
発注企業や元請けがピーク時の人数を常時雇用するより、必要な期間だけ外部企業の人材や専門性を活用するほうが経営上合理的な場合があり、その結果として複数階層の委託構造が形成されてきました。
また、一度構築された取引実績や商流が次の案件でも利用されやすいことも、構造が固定化する理由の一つです。
本記事にはプロモーションを含む場合があります。
執筆：新海 智也
SESや客先常駐から抜け出したい人に向けて、退職・転職の仕組みと、各サービスの中身を調べてまとめています。