SESの「多重下請け構造」とは何か？IT業界の仕組みを正直に話します

【この記事はこんな方に向けて書いています】
✅「多重下請け」って言葉を聞くけど、具体的にどういう仕組みなのか知りたい
✅ SESやIT業界の「闇」と言われる部分について、正直な話が聞きたい
✅ なぜ日本のITエンジニアの給料は上がりにくいのか、その構造を知りたい
✅ これからIT業界を目指す上で、失敗しないための知識を身につけたい

「日本のIT業界は、建設業界と似ている」こんな言葉を聞いたことはありませんか？

一見すると、最先端の技術を扱うIT業界と、土木や建築を行う建設業界は全く違うように見えます。しかし、そのビジネスの仕組み、特に「仕事の流れ」においては、驚くほどよく似た「多重下請け構造」という共通点があるのです。

そして、この構造こそが、多くのエンジニアを悩ませる「給料が上がらない」「スキルアップできない」といった問題の根源であり、「SESは闇が深い」と言われる原因にもなっています。

結論からお伝えします。多重下請け構造とは、発注元（クライアント）から出た一つの仕事が、複数の会社を経由するピラミッド型の構造のことです。そして、その過程で中間マージン（手数料）が何度も抜かれ、末端で働くエンジニアの取り分がどんどん減っていく仕組みを指します。

この記事では、なぜこのような構造が生まれてしまったのか、そして、この構造の中でエンジニアがどうなってしまうのか、その実態と対策を、包み隠さず正直にお話しします。

結論：これがIT業界の「多重下請け」の正体です

まず、言葉で説明するよりも、図で見ていただくのが一番わかりやすいでしょう。ここに、ある企業が「新しい顧客管理システムを1500万円で開発してほしい」と発注したケースを想定します。

🏢 【発注元】クライアント企業 「顧客管理システムを開発したい。予算は1500万円だ」 ↓ 【1次請け】大手SIer・コンサルファーム（元請け） 「受注したぞ。でもうちのエンジニアだけじゃ足りない。要件定義と設計はうちでやって、開発部分はA社に1000万円でお願いしよう」 ↓ 【2次請け】中堅ソフトウェア会社A社 「OK！でもプログラミングの一部は、付き合いのあるB社に700万円で手伝ってもらおう」 ↓ 【3次請け】小規模SES企業B社（あなたの会社） 「うちのエンジニアを3人、このプロジェクトにアサインしよう」 ↓ 【4次請け以降…】 時には、さらに個人のフリーランスエンジニアなどに仕事が流れることもあります。

お気づきでしょうか？発注元が支払った1500万円は、1次請けが500万円、2次請けが300万円と、それぞれの会社のマージン（利益や管理費）として抜いていき、3次請けの会社に仕事が来た時点では、予算は700万円にまで減ってしまっています。

実際に手を動かしてシステムを開発するエンジニアに支払われる給与は、この減ってしまった予算の中から支払われるのです。これが「多重下請け構造」と、そこで発生する「中抜き」のリアルな実態です。

なぜ「多重下請け構造」はなくならないのか？3つの理由

「そんな不合理な構造、なくせばいいのに！」そう思うのは当然です。しかし、この構造が日本のIT業界に深く根付いてしまっているのには、いくつかの歴史的・構造的な理由があるのです。

理由1：IT業界の成り立ちが「建設業モデル」だったから

日本のIT業界は、大手電機メーカーや通信会社が、官公庁や大企業の巨大なシステム開発を「一括で請け負う」ことから始まりました。これは、ゼネコン（総合建設業者）が大規模な建設プロジェクトを丸ごと請け負い、実際の工事は下請けの専門業者に任せるのと全く同じモデルです。元請けの大手SIer（システムインテグレータ）は、プロジェクト全体の管理や顧客との折衝に責任を持ち、実際の開発作業は下請け企業に再委託（外注）するという商習慣が、業界のスタンダードとして定着してしまったのです。

理由2：企業にとってのリスク分散と責任の所在

大規模なシステム開発は、数億円から数十億円の予算と、数百人月の工数を要する一大プロジェクトです。もしプロジェクトが失敗すれば、元請け企業は莫大な損害を被ります。そのため、開発作業を複数の下請け企業に分散させることで、リスクを分散させたいという思惑があります。また、「うちはプロジェクト管理に専念し、開発の実務は専門の会社に任せる」という形で、責任の所在を明確にするという意味合いも持っています。

理由3：深刻なIT人材不足という現実

これが最も大きな理由かもしれません。経済産業省の調査によれば、日本のIT人材は2030年には最大で約79万人も不足すると予測されています。

（出典：経済産業省「IT人材需給に関する調査」）

元請けとなる大手SIerも、当然ながら自社だけで全てのプロジェクトを回せるほどのエンジニアを抱えていません。そのため、二次請け、三次請けのSES企業が抱える多くのエンジニアの力を借りなければ、プロジェクトを完遂させることが物理的に不可能なのです。つまり、多重下請け構造は、IT業界の人材不足を補うための、ある種の「必要悪」として機能してしまっている側面があるのです。

エンジニアを苦しめる「多重下請け」の4つの弊害

では、このピラミッドの下層で働くエンジニアは、具体的にどのような不利益を被るのでしょうか。

弊害1：給与がとにかく上がらない

最も直接的で、深刻な問題です。先ほどの例で見たように、上位の企業にマージンを抜かれた後の、少ない予算から給与が支払われます。現場でどれだけ頑張ってクライアントから高い評価を得ても、その評価が上位の会社にまで届くことは少なく、自社の売上（単価）も上がらないため、給与に反映されにくいのです。昇給したとしても、その幅はごくわずか、というケースが後を絶ちません。

弊害2：スキルアップに繋がりにくい仕事が多い

一般的に、上流工程（要件定義、設計など）は1次請けや2次請けが担当し、下流工程（プログラミング、テスト、運用保守）が3次請け以下の企業に回ってくる傾向があります。そのため、ピラミッドの下層にいると、誰でもできるような単純なテスト作業や、古いシステムの保守といった、市場価値の上がりにくい業務ばかりを任されがちです。新しい技術に触れる機会も少なく、キャリアが停滞してしまうリスクが高まります。

弊害3：コミュニケーションが複雑で、情報が伝わらない

発注元であるクライアントの担当者と、実際に作業をする4次請けのエンジニアとの間に、3社も入っているとどうなるでしょうか。クライアントからの指示や要望が、各社を経由する伝言ゲームのようになり、末端のエンジニアに届く頃には、内容が変わっていたり、重要な情報が抜け落ちていたりすることが頻繁に起こります。質問を一つするにも、複数の会社を経由せねばならず、無駄な時間とストレスが発生します。

弊害4：モチベーションの維持が難しい

ピラミッドの下層では、自分が作っているシステムが「誰の」「どんな課題を解決するためのものなのか」という全体像が見えにくくなります。ただ言われた作業をこなすだけの日々が続くと、仕事へのやりがいや当事者意識が失われ、「自分はこのプロジェクトの歯車でしかない」という無力感に苛まれてしまうエンジニアも少なくありません。