現役エンジニアがIT業界の多重請負を解説『下請けから脱出したい』

大手SIerで10年以上働いていたHRです。

本記事の内容はこちら。

SIer業界では、大手SIerが受注した大型案件の開発が中堅・中小IT企業へ流れてきます。

多重構造が使われている理由は、企業側にとってエンジニアを柔軟に確保できる・人件費を抑えるなどメリットが大きいため。

一方で働いているエンジニアには、労働環境が良くならないデメリットがあります。

本記事では、そのあたりまでお話しします。

IT業界の多重請負構造とは

普通の取引は、お客さん⇔企業の間で商品やサービスのやりとりがありますよね。

SIer業界では、お客さん⇔IT企業の階層が何重にも重なって1つの案件を開発していく仕組みがあります。

ピラミッド構造で仕事が下りてくる

頂点のIT企業がお客さんから受注した開発案件が、1次請けIT企業、2次請けIT企業・・と流れていきます。

日本を代表する大手SIが頂点で、お客さんと直接やり取りするIT企業はプライムベンダーと呼ばれます。

そしてこの多重請負の構造はピラミッド構造と呼ばれています。

建設業界のモデルを取り入れた

SIer業界がピラミッド構造になっている理由は建設業界をまねたからです。

コンピュータが起業に普及してIT企業が産まれてきたころ、まだIT業界のモデルがありませんでした。

とあるIT企業がそのころ労働者を効率的に集めていた建設業界を参考にしたことで、IT業界にもピラミッド構造が定着したと言われています。

多重請負構造のメリット

こちらの4つです。

IT企業が多重請負を使っているのは当然メリットがあるからです。

ただし多重構造のメリットは主に企業にとってのもの。

これらを詳しく説明していきます。

労働力を柔軟に確保できる

大手SIerでも大きなシステム開発案件をいつも受注できるものではありません。

多重請負の仕組みなら、いざ大きな案件を受注したときに一時的にエンジニアを大量に集められます。

たとえば、大手SIerがエンジニア1000人規模の開発案件を受注したとします。

・大手SIerは200人分は自社エンジニアをつかい、残りの800人分のエンジニアを2次請けのIT企業4社にそれぞれ200人ずつ依頼。

・2次請けIT企業は50人分の自社エンジニアを確保して、残りの150人を3次請けのIT企業3社にそれぞれ50人ずつ依頼。

・3次請けIT企業は20人分の自社エンジニアを確保して、残りの30人を4次請けのIT企業数社に数名ずつ依頼。

分かりやすくするためかなり単純化した例なので、もちろん本当の案件ではもっと複雑です。

エンジニアを雇わなくていい

多重請負の仕組みなら、案件の開発が終われば集めていたエンジニアもリリースできます。

もしエンジニアを社員で雇用すると手間とお金がかかるので、企業にとっては人件費が抑えられます。

案件があるときだけ下請けエンジニアに発注すれば、一時的な開発費用だけで済み固定費はかかりません。

仕事を取りやすい

多重請負なら、2次請け以降のIT企業はエンドユーザから案件を直接取らなくていいので仕事を確保しやすいんです。

IT業界のお客さんになるのはエンドユーザーとよばれるユーザ企業が多いです。

エンドユーザの仕事も無限ではないので、限られた開発案件を受注するのは簡単ではありません。

中小のIT企業にとって一番難しいのは、エンジニアの仕事を確保しつづけること。

多重請負の仕組みは、安定して会社の売上を上げるため役立っています。

大きな案件に関われる

大手SIerが受注した大きな案件の一部を受注できれば、中小企業でも大規模案件を経験できます。

中小IT企業のエンジニアは大きな案件をなかなか経験できません。

大規模案件は、会社とエンジニアどちらにとってもメリットになります。

多重請負構造のデメリット

こちらの4つです。

多重請負のデメリットは主にエンジニア側。

エンジニアにとっては労働環境が良くならないリスクがあります。

多重化が進むほど納期が厳しくなる

多重請負だと、2次請け、3次請け・・と下の階層に行くほど納期は短くなります。

プライムベンダーからユーザ企業への納期は決まっているので、いくら案件が下にいっても納期は変わりません。

下の階層ほど納期が短くなるのは、それぞれの階層で受け入れ期間が必要だからです。

たとえばプライムベンダーからお客さんへの納期が１年だとします。

プライムベンダーは2次請け企業から納品されたシステムをチェックするため、2カ月ほど余裕を見た10か月に納期を設定する。

2次請け企業は3次請け企業からの納品物をチェックするため、さらに2カ月ほど余裕をみた6ヶ月に設定する。

こうやって下にいくほど納期がきびしくなっていきます。

多重化が進むほど金額も安くなる

納期と同じ理由で、下の階層にいくほど受注金額も安くなります。

理由はそれぞれの階層で企業が管理費を取るからです。

納期もきびしくなる上に受注金額も安くなるので、エンジニア・会社どちらにとっても良いことではありません。

常駐エンジニアになりやすい

2次請け、3次請け以降のIT企業では、下請け企業のエンジニアを自社に集めることが少なくありません。

集められたエンジニアは”常駐エンジニア”と呼ばれ、発注元IT企業のオフィス・勤務ルールで働きます。

エンジニアを集める理由はケースバイケースなものの、機密情報を扱う案件ではデータや開発環境を外に出せないことが多くあります。

なお常駐エンジニアは働き方がコントロールできず、スキルも固定化されやすいのでおススメしません。

こちらの記事で詳しく解説していますのであわせてご覧ください。

• エンジニア×働き方

  常駐エンジニアはおすすめしない『10年以上勤務した経験を語る』

会社にスキルが蓄積されない

多重請負で開発をしても、プライムベンダーや1次請けといった上の階層企業には開発スキルが蓄積されません。

なぜなら、実際に現場でプログラミング・テストをするのは自社社員ではないからです。

2次請け、3次請けより後の下請けエンジニアの開発スキルに頼っていて、自分たちはスケジュール管理・進捗管理しかできない状態です。

IT業界は多重請負だけなのか

IT業界をかなりざっくり分けると、大きく次の3つです。

こちらの記事でも書いているように、それぞれ仕事内容やビジネスモデルが全然ちがいます。

• 社内SE×転職

  社内SEと社内開発エンジニアは違います『転職の求人には注意』

① SIer業界

本記事で紹介したピラミッド構造をビジネスモデルとする業界です。

大手SIer業界を頂点としたビジネス構造が出来上がっています。

② 自社開発

SIer業界のピラミッド構造とは別に、おもに自社でお客さんへ直接サービスを提供している業界です。

パッケージソフトやWebサービス、ホームページなど幅広いシステムを開発しています。

③ 社内SE

ユーザのIT部門・情報システム部門で働くエンジニアです。

メーカーや金融などいろんな企業のシステムを担当し、SIerや自社開発企業へ開発案件を発注する立場です。

ちなみにぼくは残業を減らしたくてSIer業界から社内SEへ転職しました。

こちらの記事で詳しく解説していますので、よろしければご覧ください。

• 社内SE×転職

  ぼくが転職を考えたきっかけは？『社内SEへのキャリアチェンジ』

働き方は環境で決まる

上の3つの業界例から分かるように、業界によってビジネスモデルは決まっています。

労働環境が厳しくなりやすい多重請負から脱出するには、環境を変えるしかありません。

環境を変えるには、転職先企業のビジネスモデル・労働環境を見極める必要があります。

ただしホームページや求人情報はあくまで目安です。

実態はIT業界に強い転職アドバイザーに確認しましょう。詳しくは以下をご覧ください。

自社内開発を希望するなら、はじめから社内開発に特化したITエージェントを使えば効率的です。

まとめ：環境はコントロールできない

昔から続いている会社や組織・業界のルールは、ある程度固まっています。

個人で変えるのは簡単ではありません。

自分で変えられないことにエネルギーを注ぐのではなく、自分でコントロールできることに目を向けてみましょう。

まずは環境を変えることからスタートしてみませんか。

それでは。