IT元請けとは？下請けとの違いや多重下請け構造について解説

IT業界で良く耳にする、元請けというワード。「元請けって何？」や「多重下請け構造って何が問題になっているの？」といった疑問を持つ企業の新人担当者は多いと思います。そこで今回は、IT元請けについてわかりやすく解説いたします。元請けと下請けの違いや、元請けで請け負う時の注意点など、詳しくご紹介するのでぜひチェックしてみてください。

 

目次

 

 

 

元請けと下請けはどう違う？

元請けとは、クライアントから直接依頼を受けた企業のことを意味します。また、元請けから仕事の依頼をされた企業のことを下請けといいます。IT業界では、下請けに仕事を依頼し、実際の作業を行ってもらうという構造が主流です。ここで、IT元請けについて、下請けとの違いなどを解説いたします。

 

●元請けとは？

「元請け」とは、発注者から直接仕事を請け負う業者のことを意味します。とりわけIT業界では、発注者からシステム開発などの仕事を直接請け負うシステム開発会社をいいます。

一次請けやプライム、直請けなどと表現することもあります。また、元請けする会社や人を指して「元請業者」や「元請負人」と呼ぶこともあります。IT元請けの多くは、主にクライアントと直接やりとりする仕事が多くなります。クライアントと打ち合わせをして、システムの提案、予算、スケジュールなどの詳細を決めます。そのあと、予算や開発内容に合う下請け業者に仕事を依頼し、納期までを管理するのが主な仕事です。つまり、IT元請けの多くは、下請け業者を選定し、開発を依頼する前段階の調整が主な仕事となります。

 

●下請けとは？元請けとの違いは？

下請けとは、元請けが顧客から依頼されて請け負った仕事のすべて、または一部を請け負う企業のことを意味します。二次請けと表現されることもあります。また、下請けする会社や人のことを「下請業者」や「下請負人」と呼ぶこともあります。下請けは、元請けが発注者とヒアリングや相談を進めて作成した要件定義書や仕様書、設計書などに沿ってコーディングを行います。開発したプログラムの動作テストや仕様書の作成、運用マニュアルの作成なども請け負います。元請けとは、打ち合わせや進捗報告を行っているため、下請けは発注者から直接仕事の指示を受けることはないのが一般的です。

 

多重下請け構造とは？

多重下請け構造とは、発注者から委託された業務を元請け企業が、二次請け企業、さらにその下層の企業に流れていく構造のことです。

多重下請け構造は、建設業界の仕事の流れでも良く使われるワードです。大手ゼネコンが大型の仕事を受注し、受注した仕事を分割して、いくつかの中堅企業に発注をします。仕事を引き受けた中堅企業は、その仕事を分割して中小企業へ発注、そこからさらに零細企業へというような流れです。いわば、大手ゼネコンを頂点としたピラミッド型構造なのです。

この構造を多重請負構造といい、これに似たような流れがIT業界にも存在しているのです。仕様書や設計書類を作り、プログラミングやテストを行うのが下請けの主な仕事ですが、自社だけでは工数や技術的に難しい作業は、三次請け企業に依頼することもあります。

実はIT業界も、建設業界と同じく階層構造になっているのが一般的です。一次請け企業から発注を受ける二次請け企業、さらにその下で仕事を請け負う三次請けというように、ピラミッド型構造により成り立っています。この階層構造が建設業界に似ていることから、ピラミッドの頂点に位置する大手IT企業を「ITゼネコン」とも呼ぶことがあります。

 

下請けには「請負契約」と「準委任契約」がある

IT業界における下請けは、以下の2種類があります。

• 請負契約

• 準委任契約

 

●請負契約

システムを含む納品成果物の完成を約束する契約です。期日までに成果物を納めることで、報酬が支払われます。開発システム一式を成果物とする場合がほとんどです。指定の成果物を納品すれば、どのような手順で、誰が作業したのか、などは問われません。

また、請負契約は成果物が納品されれば問題ないので、前出のような下請け、二次請け、三次請けへの依頼が可能です。請負契約は、成果物の納品前出あれば、発注者からの解約が可能です。しかし、これは受注側への損害の賠償や補填が条件になります。

 

●準委任契約

これは発注者に依頼された業務を行うことに関しての契約です。システム開発工程における要件定義や、運用テストなどの支援として技術力を提供する場合が多いです。準委託契約には、成果物の品質や成功失敗を問わず、提供した労働時間やスキル、工数に対して報酬を支払う「履行割合型」と、発注者が依頼した業務が完了した時に報酬を支払う「成果完成型」があります。

準委託契約は、基本的には下請けへの依頼ができません。これは委託先に対して「あなたの会社のこのスキルを使って仕事をして欲しい」などの意向がある場合が多いためです。しかし、禁止されているわけではないので、「受注側（元請けなど）の責任で再委託も可能」という条件がある場合はこの限りではありません。業務中の解約に関しては、発注、受注どちら側からも申し出が可能ですが、相手に不利益になるタイミングでの解約は損害の賠償や補填をしなければなりません。

順委任契約について、詳しく知りたい方は「準委任契約とはどんな契約？契約形態ごとの違いは？」の記事をご一読ください。

 

●請負契約と準委任契約の「成果完成型」、どう違う？

一見すると、請負契約と準委任契約の成果完成型は同じ契約のように見えますよね。大きな違いは契約不適合責任が発生するかどうかです。契約不適合責任とは、成果物に瑕疵があった場合、受注側がその責任を負うというものです。以前は瑕疵担保責任と呼ばれていました。成果完成型であっても、準委任契約はあくまで依頼された業務に対してそれを行うための労働時間や工数を提供するという契約になります。

 

多重下請け構造の問題点

IT業界では、たびたび多重下請け構造問題が話題になっています。ここで、IT業界が抱える多重下請け構造の問題点について解説いたします。

 

●実際に作業するエンジニアの給与が少なくなる

多重下請け構造の問題点として、途中階層の企業が自社取り分を差し引いて下請けに案件を丸投げするため、末端のエンジニアの報酬が少なくなることが挙げられます。

例えば、ユーザー企業から委託された開発業務が、四次請け企業にて行われるケースでは、一次〜三次請けの企業が自社取り分を差し引いています。そして、多重下請けが発生している場合、実際に作業をするエンジニアの報酬は、どうしても少なくなってしまいます。多重下請け構造の場合、中間に入っているそれぞれの会社は、利益を引いて受注した金額よりも安い値段で下請けの会社へ発注するためです。

 

●問題が発生した場合に追加要員が準備できないことも

多重下請け構造は、下請けになればなるほど予算がギリギリの状況で作業しているため、問題が発生した場合に要員追加ができず、既存要員の長時間労働につながる可能性があるということも問題点として挙げられます。多重下請け構造は、労働環境の悪化に加えて、雇用条件や待遇の悪化を引き起こし、さらには業界のイメージダウンによって引き起こるエンジニア不足の原因となっている部分があるのです。

 

●違法性の有無が問題視されている

実は、多重請負は違法か否かが議論になっています。結論としては、多重請負自体は違法というわけではありません。しかし、IT業界での多重請負は、違法性が認められる場合が多いようです。なぜIT業界で多重下請けが違法になってしまうケースが多いのかというと、「業務委託契約でありながら、実質的には労働者派遣契約のようになっているから」です。これを偽装請負といいます。派遣先で指揮命令が行われるので、本当は派遣契約をしなければなりません。しかし、形式上は請負契約であるかのように偽装されているのです。結果的に多重派遣になっていて、多重派遣は違法です。偽装請負は単体で違法ですが、多重請負自体は単体では違法ではありません。

 

元請けと下請けにありがちなトラブル

元請けや下請けといった仕組みは、IT業界で日常的に使われています。仕事を効率的にこなすためには便利な方法ですが、元請けと下請けの間では、しばしばトラブルが発生することがあります。ここでは、元請けと下請けにありがちなトラブルについてご紹介します。

 

●下請け代金が払われない

元請けと下請けのトラブルの中でも多いのは金銭問題です。元請け、下請け、孫請けと、ひとつの仕事にかかわる業者が増えることで、当たり前ですが各業者の利益は減っていきます。あらかじめしっかりと契約をしておかなければ、ピラミッドの下のほうへ行くほど、正当な報酬を得られない可能性が出てきてしまいます。仕事を完遂したにもかかわらず、下請け業者が赤字を抱えてしまい、裁判に至ったケースもあります。

 

●下請けのミスも元請けが責任を負わなければならない

元請けのデメリットは、自社で行う業務だけでなく、下請けの企業の分まで責任を負わなければいけない可能性があることです。

下請け業者に業務を依頼する場合、下請けのミスで仕事に支障が出て、発注者に損害が出てしまうこともあります。その場合、元請けも責任を負うことになるのが一般的です。少し納期が遅れただけで、発注側から遅延損害を請求されることもあります。納期の遅延の原因が下請けにあったとしても発注側から責任を追求されるのは元請けです。このような事態を招かないためには、信頼のおける下請け業者を選定すること、そしてきちんと管理することが重要です。

 

●発注もしていない仕様に対して追加請求が発生する

IT業界においては、システム開発作業を進めていくにつれて、仕様変更が必要なことは多いです。仕様変更をするにおいて、問題となるのは費用面です。システム開発では、発注者の意向を確認することなく、独断で仕様変更を行って追加費用を請求するケースが多々あります。発注していない仕様を下請け会社が勝手に追加して、追加請求をされたら困惑してしまいますよね。とくに、大規模なシステム開発になればなるほど、仕様変更は増加していきます。仕様変更に伴い発生する追加費用については、あらかじめ当事者間で契約しておきましょう。

 

 

■受託案件の獲得に成功した企業インタビュー

株式会社エイブリッジ 商談数増加で若手営業の経験・スキルが向上。AR・VR・MRなど先端技術領域の挑戦も可能に	スクエアワン株式会社 導入1年半で7200万円受注！オフショアならではのメリットを生かした営業プロセスとは？	アプテック株式会社 コロナ禍でも2000万円受注！発注ナビを5年以上使い続ける理由とは
Tech Fun株式会社 SESから受託獲得で利益率UP！商談を通じてエンジニアに起きた変化とは？	株式会社クロステックラボ 代理店頼りから脱却！エンドユーザーへの提案機会を獲得できた理由	株式会社MU 「受注ゼロ」から一転、2000万円規模の案件獲得。売上増により営業部門の新設も実現
株式会社アイ・エス・ビー 東証一部上場・売上244億円の大手開発会社が発注ナビで手に入れた新たな強みとは	株式会社relation 半年間で4件受注。技術力を活かした案件獲得で、エンジニアのモチベーションも向上！	株式会社ベンジャミン 人脈営業の限界を発注ナビが解消！年間8件もの受注に至った秘訣とは？