IT元請けとは?下請けとの違いや多重下請け構造について解説
2022.01.27
IT業界で良く耳にする、元請けというワード。「元請けって何?」や「多重下請け構造って何が問題になっているの?」といった疑問を持つ企業の新人担当者は多いと思います。そこで今回は、IT元請けについてわかりやすく解説いたします。元請けと下請けの違いや、元請けで請け負う時の注意点など、詳しくご紹介するのでぜひチェックしてみてください。
目次
新規案件開拓の課題は「発注ナビ」で解決!システム開発に特化したビジネスマッチング
元請けと下請けはどう違う?
元請けとは、クライアントから直接依頼を受けた企業のことを意味します。また、元請けから仕事の依頼をされた企業のことを下請けといいます。IT業界では、下請けに仕事を任せるピラミッド構造が主流になっています。ここで、IT元請けについて、下請けとの違いなどを解説いたします。
●元請けとは?
元請けとは、発注者から直接仕事を請け負うことを意味します。とりわけIT業界では、発注者から直接システム開発などの仕事を請け負うシステム開発会社をいいます。
一次請けやプライム、直請けなどと表現することもあります。また、元請けする会社や人のことを「元請業者」や「元請負人」とも呼ぶことがあります。IT元請けの多くは、主にクライアントと直接やりとりする仕事が多くなります。クライアントと打ち合わせをして、システムの提案や予算、スケジュールを決めていきます。そのあと、予算と開発に合った下請けに仕事を依頼し、納期まで管理するのが主な仕事です。つまり、IT元請けの多くは、下請けに開発を任せる前段階の仕事が主となります。
●下請けとは?元請けとの違いは?
下請けとは、元請けが顧客から請け負った仕事のすべて、または一部を請け負う企業のことを意味します。二次請けと表現されることもあります。また、下請けする会社や人のことを「下請業者」や「下請負人」と呼ぶこともあります。下請けは、元請けが発注者とヒアリングや相談を進めて作成した要件定義書や仕様書、設計書などに沿ってコーディングを行います。開発したプログラムの動作テストや仕様書の作成、運用マニュアルの作成なども請け負います。元請けとは、打ち合わせや進捗報告を行っているため、下請けは発注者から直接仕事の指示を受けることはないのが一般的です。
多重下請け構造とは?
多重下請け構造とは、発注者から委託された業務を元請け企業が、二次請け企業、さらにその下層の企業に流れていく構造のことです。
多重下請け構造は、建設業界の仕事の流れでも良く使われるワードです。大手ゼネコンが大型の仕事を受注し、受注した仕事を分割して、いくつかの中堅企業にその仕事を振り分けます。仕事を引き受けた中堅企業は、さらに仕事を分割して中小企業へ、そこからさらに零細企業へというような流れです。いわば、大手ゼネコンを頂点とするピラミッド型構造です。
この構造を多重請負構造といい、これに似たような流れがIT業界にも存在しているのです。仕様書や設計書類を作り、プログラミングやテストを行うのが下請けの主な仕事ですが、自社でさばききれないテストやプログラミングは、三次請け企業に依頼することもあります。
実はIT業界も、建設業界と同じく階層構造になっているのが一般的です。一次請け企業、一次請け企業からの発注される二次請け企業、さらにその下に三次請けと呼ばれる企業で成り立つピラミッド型で成り立っています。この階層構造や階層構造の一番上にいる大手IT企業のことを、同じような構造を持つ建設業界になぞらえて「ITゼネコン」とも呼ぶこともあります。
下請けには「請負契約」と「準委任契約」がある
IT業界における下請けは、以下の2種類があります。
-
請負契約
-
準委任契約
●請負契約
成果物(システム含む)の完成を約束する契約です。期日までに成果物を納めることで、報酬が支払われます。開発システムの一式が成果物となることが多いです。指定の成果物を納品すれば、どのような手順で、誰が作業したのか、などは問われません。
また、請負契約は成果物が納品されれば問題ないので、前出のような下請け、二次請け、三次請けへの依頼が可能です。請負契約は、成果物の納品前出あれば、発注者からの解約が可能です。しかし、これは受注側への損害の賠償や補填が条件になります。
●準委任契約
これは発注者に依頼された業務を行うことに関しての契約です。システム開発工程におけるユーザーが主体となる要件定義や、運用テストなどの支援として技術力を提供する場合が多いです。準委託契約には、成果物の品質や成功失敗を問わず、提供した労働時間やスキル、工数に対して報酬を支払う「履行割合型」と、発注者が依頼した業務が完了した時に報酬を支払う「成果完成型」があります。
準委託契約は、基本的には下請けへの依頼ができません。これは委託先に対して「あなたの会社のこのスキルを使って仕事をして欲しい」などの意向がある場合が多いためです。しかし、禁止されているわけではないので、「受注側(元請けなど)の責任で再委託も可能」という条件がある場合はこの限りではありません。業務中の解約に関しては、発注、受注どちら側からも申し出が可能ですが、相手に不利益になるタイミングでの解約は損害の賠償や補填をしなければなりません。
順委任契約について、詳しく知りたい方は「準委任契約とはどんな契約?契約形態ごとの違いは?」の記事をご一読ください。
●請負契約と準委任契約の「成果完成型」、どう違う?
一見すると、請負契約と準委任契約の成果完成型は同じ契約のように見えますよね。大きな違いは契約不適合責任が発生するかどうかです。契約不適合責任とは、成果物に瑕疵があった場合、受注側がその責任を負うというものです。以前は瑕疵担保責任と呼ばれていました。成果完成型であっても、準委任契約はあくまで依頼された業務に対してそれを行うための労働時間や工数を提供するという契約になります。
多重下請け構造の問題点
IT業界では、たびたび多重下請け構造問題が話題になっています。ここで、IT業界が抱える多重下請け構造の問題点について解説いたします。
●実際に作業するエンジニアの給与が少なくなる
多重下請け構造の問題点として、途中階層の企業が自社取り分を差し引いて下請けに案件を丸投げするため、末端のエンジニアの報酬が少なくなることが挙げられます。
例えば、ユーザー企業から委託された開発業務が、四次請け企業にて行われるケースでは、一次〜三次請けの企業が自社取り分を差し引いています。そして、多重下請けが発生している場合、実際に作業をするエンジニアの報酬は、どうしても少なくなってしまいます。多重下請け構造の場合、中間に入っているそれぞれの会社は、利益を引いて受注した金額よりも安い値段で下請けの会社へ発注するためです。
●問題が発生した場合に追加要員が準備できないことも
多重下請け構造は、下請けになればなるほど予算がギリギリの状況で作業しているため、問題が発生した場合に要員追加ができず、既存要員の長時間労働につながる可能性があるということも問題点として挙げられます。多重下請け構造は、労働環境、雇用条件、待遇の悪化、さらに業界の魅力低下によるエンジニア不足といった社会問題の原因となっている部分があるのです。
●違法性の有無が問題視されている
実は、多重請負は違法か否かが議論になっています。結論としては、多重請負自体は違法というわけではありません。しかし、IT業界での多重請負は、違法性が認められる場合が多いようです。なぜIT業界で多重下請けが違法になってしまうケースが多いのかというと、「業務委託契約でありながら、実質的には労働者派遣契約のようになっているから」です。これを偽装請負といいます。派遣先で指揮命令が行われるので、本当は派遣契約をしなければなりません。しかし、形式上は請負契約であるかのように偽装されているのです。結果的に多重派遣になっていて、多重派遣は違法です。偽装請負は単体で違法ですが、多重請負自体は単体では違法ではありません。
元請けと下請けにありがちなトラブル
元請けや下請けといった仕組みは、IT業界で日常的に使われています。仕事を効率的にこなすためには便利な方法ですが、元請けと下請けの間では、しばしばトラブルが発生することがあります。ここでは、元請けと下請けにありがちなトラブルについてご紹介します。
●下請け代金が払われない
元請けと下請けのトラブルの中でも多いのは金銭問題です。元請け、下請け、孫請けと、ひとつの仕事にかかわる業者が増えれば増えるほど、それぞれの業者が得る利益は減っていきます。あらかじめしっかりと契約をしておかなければ、下請けや孫請けの企業は、正当な報酬を得られない可能性が出てきてしまいます。仕事を完遂したにもかかわらず、下請けのもとには赤字だけが残ってしまうケースもあります。裁判に至ったケースもあります。
●下請けのミスも元請けが責任を負わなければならない
元請けのデメリットは、自社で行う業務だけでなく、下請けの企業の分まで責任を負わなければいけない可能性があることです。
下請けに委託する場合、下請けのミスで仕事に支障が出て、発注者に損害が出てしまうこともあります。その場合、元請けも責任を負うことになるのが一般的です。少し納期が遅れただけで、発注側から遅延損害を請求されることもあります。納期の遅延の原因が下請けにあったとしても発注側から責任を追求されるのは元請けです。このような事態を引き起こさないために、信頼のおける下請け企業を選ぶこと、そしてきちんと管理することが重要です。
●発注もしていない仕様に対して追加請求が発生する
システム開発などの現場では、作業を進めていくにつれて、仕様変更が必要なことは多いです。仕様変更をするにおいて、問題となるのは費用面です。システム開発では、発注者の意向を確認することなく、独断で仕様変更をして追加費用を請求するケースが良くあります。発注していない仕様を下請け会社が勝手に追加して、追加請求をされたら困惑してしまいますよね。とくに、大規模なシステム開発になればなるほど、仕様変更は増加していきます。仕様変更に伴い発生する追加費用については、あらかじめ当事者間で契約しておきましょう。
新規案件開拓の課題は「発注ナビ」で解決!システム開発に特化したビジネスマッチング
■受託案件の獲得に成功した企業インタビュー
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |