「大手だから安心と思って頼んだのに、実際に作っていたのは名前も知らない下請け会社だった」。システム開発の発注では、こうした多重下請けは珍しくありません。頼んだ相手が自社で作らず、下請け・孫請けへ再委託していると、品質や責任の所在があいまいになり、トラブル時に誰に言えばよいのか分からなくなります。発注前に「この会社は本当に自分たちで作るのか」を見抜けると安心です。
結論から言うと、受託開発の多重下請けそのものは違法でも異常でもありませんが、発注者が構造を知らないまま丸投げすると、品質・責任・情報管理の面でリスクが高まります。大事なのは、発注前に体制や再委託の可否を確認し、契約で管理しておくことです。この記事では、受託開発の多重下請け（一次受け・二次請け・再委託）とは何か、発注者にどんなリスクがあるか、そして発注前に丸投げを見抜くための確認点までを、発注者目線で整理します。
この記事のポイント
- 多重下請けとは、受注した会社が下請け・孫請けへ再委託して開発する構造のこと
- 発注者のリスクは品質のばらつき・責任のあいまい化・伝言ゲーム・情報漏れ・中間マージン
- 体制図・工数内訳・実際の作業者を発注前に確認すると、丸投げを見抜きやすい
- 再委託の可否と責任範囲は契約で明確にしておく
目次
受託開発の多重下請けとは何か
受託開発の多重下請けを見抜くには、まず「そもそもどういう構造なのか」と「なぜ発注者に不利になりうるのか」を押さえる必要があります。ここでは仕組み・リスク・発生する理由の順に整理します。
一次受け・二次請けと再委託の仕組み
多重下請けとは、発注者から仕事を受けた会社（元請け＝一次受け）が、その仕事の全部または一部を別の会社（下請け＝二次請け）へ再委託し、さらにその下請けが孫請けへ渡す、というように委託が何層にも重なる構造です。「一次受け」「一次請け」は発注者から直接受ける会社、「二次請け」「三次請け」はその下の階層を指します。
発注者から見て厄介なのは、契約している相手（元請け）と、実際に手を動かす人（下請け・孫請け）が別だという点です。元請けが仕事をまるごと下請けに流すと、実質的な「丸投げ（一括再委託）」になります。発注者は元請けの名前と提案書を見て安心していても、現場では顔も知らない会社がコードを書いている、ということが起こります。
もちろん、専門分野を一部だけ外部に頼む再委託は一般的で、それ自体が悪いわけではありません。問題になりやすいのは、元請けがほとんど手を動かさずに中抜き（マージンだけ取って流す）している場合や、階層が深くて誰が何をしているか発注者から見えない場合です。まずは「どこまでが再委託で、どこからが丸投げか」を意識することが出発点になります。
具体例で考えてみます。ある会社にシステム開発を発注し、窓口の営業や提案は元請けの社員が対応してくれたとします。ところが実際の設計・実装は二次請けの会社が担い、さらにテストの一部は三次請けに流れていた、というケースです。この場合、発注者が打ち合わせで話す相手と、成果物を作る人が二層も三層も離れています。要望が正確に伝わりにくく、不具合が出たときも「うちは受けて渡しただけ」と各社が言い出すと、原因の切り分けだけで何日もかかります。多重下請けの怖さは、こうした「距離」がトラブル対応のたびに効いてくる点にあります。
多重下請けで発注者に起きるリスク
多重下請けが深くなるほど、発注者が受けるリスクは積み上がります。代表的なものを整理すると、次のようになります。
| リスク | 発注者に起きること |
|---|---|
| 品質のばらつき | 実際に作る会社の技術力が不明で、成果物の品質が読めない |
| 責任のあいまい化 | 不具合時に「どこの工程の問題か」で押し付け合いになり、対応が遅れる |
| 伝言ゲーム | 要望が元請け→下請けと伝わる途中でズレ、意図と違うものができる |
| 情報漏れリスク | 自社の機密情報や個人情報が、把握していない孫請けまで渡る |
| 中間マージン | 各階層が利益を乗せるぶん、実開発費に対して割高になりやすい |
特に見落とされがちなのが、責任のあいまい化と情報漏れリスクです。トラブルが起きたとき、契約相手は元請けなので、発注者は元請けに責任を問うのが基本です。ですが実作業が孫請けだと、原因調査も改修も伝言ゲームになり、時間がかかります。情報管理も同様で、機密データがどの会社まで渡っているかを発注者が把握できていないと、漏えい時に被害範囲すら分かりません。こうした構造は、途中でどこかの会社が倒産したときの連鎖リスクにもつながります。開発途中の倒産への備えは受託開発の外注先が倒産したときのリスクと備えを解説した記事もあわせて確認してください。
なぜ受託開発で多重下請けが起きるのか
多重下請けは、特定の会社が悪いというより、業界の構造と発注側の事情の両方から生まれます。仕組みを知っておくと、見抜くときの目線が変わります。
業界側の事情としては、IT人材の不足が大きく、1社ですべてをまかなえないため、専門性や人手を下請けから調達する慣行が根づいています。発注側の事情としては、「社内にIT担当がいないので要件定義から運用まで丸ごとお願いしたい」というニーズや、「大手なら安心」という理由で再委託前提の大手に発注が集中しやすいことがあります。加えて、提案された体制図や工数内訳の妥当性を発注者が判断できず、見積もりをそのまま受け入れてしまうことも、多重下請けを見えなくします。
裏を返せば、発注者が「体制の中身を見る目」を少し持つだけで、丸投げされる構造をかなり避けられるということです。大手・中小どちらに頼むにせよ、会社の規模やブランドだけで選ばず、実際の体制まで見て選ぶ姿勢が効きます。会社選びの判断軸そのものは受託開発会社の選び方を解説した記事で整理しているので、あわせて参考にしてください。
受託開発の多重下請けを見抜く発注前の確認点
多重下請けは、発注前と契約時の確認でかなりコントロールできます。ここでは「発注前に何を確認するか」と「契約でどう管理するか」に分けて、発注者ができることを整理します。
発注前に自社開発か再委託かを確認する
まず発注前に、その会社が自社で開発するのか、下請けに再委託するのかを直接確認します。聞きにくいと感じるかもしれませんが、まっとうな会社なら体制はきちんと説明してくれます。むしろ、体制の質問に歯切れが悪い会社は要注意です。
具体的に確認したいのは、第一に体制図です。プロジェクトに誰が入るのか、自社の社員なのか外部要員なのかを図で示してもらいます。第二に工数内訳で、どの工程に何人月かかり、その内訳が妥当かを見ます。第三に実際の作業者で、要件定義や設計を誰が担当し、実装は自社か下請けかを聞きます。第四に再委託の有無と範囲で、一部を外部に出すなら、どこを・どの会社に出すのかを明らかにしてもらいます。
これらを候補各社に同じ質問で聞くと、比較しやすく、丸投げ体質の会社も浮かび上がります。発注前に会社情報・実績・体制・再委託などを同じ質問でそろえて聞きたいときは、RFI（情報提供依頼書）テンプレートを使うと、各社へ同じ様式で質問でき、回答を横並びで比較しやすくなります。口頭でその場任せに聞くより、書面で残しておくほうが、後の契約や検収でも根拠になります。
回答の読み方にもコツがあります。良い兆候は、体制図に実名や役割が具体的に書かれていて、「この工程は自社、この部分は長年組んでいる協力会社」と再委託の範囲まで正直に説明してくれることです。反対に注意したい兆候は、「詳細は契約後にご説明します」「体制はお任せください」と中身をぼかす、質問するたびに担当者が代わる、再委託先を一切明かさない、といった対応です。すべての再委託が悪いわけではないので、隠すかどうか・説明できるかどうかを見るのがポイントです。正直に体制を開示できる会社は、それだけで信頼の材料になります。
契約で再委託を管理する
発注前の確認に加えて、契約で再委託を管理しておくと、丸投げや無断の孫請けを防げます。ここは発注者が主導権を持って条件を決められる部分です。
契約で押さえたいのは、まず再委託の可否と手続きです。「再委託は原則禁止」または「発注者の事前承諾を得た場合のみ可」とし、勝手に下請けへ流せないようにします。次に責任範囲で、再委託した場合も元請けが全体の責任を負うことを明記します。これで、孫請けの不手際を理由に元請けが責任を逃れることを防げます。加えて、機密情報や個人情報の管理義務を再委託先にも同じ水準で課すこと、再委託先を発注者に開示することも定めておくと安心です。
ここで現実的なさじ加減も知っておくと役立ちます。再委託を全面禁止にすると、専門的な部分まで元請けが抱え込んで割高・低速になったり、そもそも受けてもらえなかったりすることがあります。多くの現場では「原則は事前承諾制にして、どこを誰に出すかを把握できる状態を保つ」のが落としどころです。禁止することが目的ではなく、発注者が構造を見えている状態を作ることが目的だと考えると、条件を決めやすくなります。無断の丸投げだけは避け、健全な再委託は認める、という線引きが実務的です。
こうした再委託の条項は、著作権やソースコードの扱い、不具合の責任範囲といった契約全体の確認点の一部です。契約で発注者が確認すべき点は受託開発の契約で発注者が確認すべきことをまとめた記事で整理しているので、再委託まわりとあわせて確認してください。再委託を含めて品質・納期・コストから体制まで発注側で管理する全体像は、この後の契約・進行の設計にそのまま効いてきます。
発注前に確認したい多重下請けのサイン
- 体制図や工数内訳の質問に、歯切れの悪い説明しか返ってこない
- 要件定義から実装まで「全部おまかせください」で中身を説明しない
- 実際の作業者や再委託先を教えてくれない
- 相場よりかなり安いのに、自社開発だと言い張る
- 契約書に再委託の可否や責任範囲の記載がない
よくある質問
- Q. 受託開発で下請けに再委託されること自体はいけないことですか？
- A. いいえ。専門分野や一部工程の再委託は一般的で、それ自体は問題ありません。問題になりやすいのは、元請けがほとんど手を動かさない丸投げや、発注者が把握できないほど階層が深い場合です。可否と範囲を契約で管理するのが現実的です。
- Q. 大手に頼めば多重下請けは避けられますか？
- A. 必ずしも避けられません。むしろ大手は再委託前提で受注し、実作業を下請けが担うことも多いです。規模やブランドだけで判断せず、体制図や実際の作業者を発注前に確認することが大切です。
- Q. 多重下請けかどうかは発注前に見抜けますか？
- A. 完全には見抜けませんが、体制図・工数内訳・実作業者・再委託の有無を同じ質問で各社に確認すれば、丸投げ体質の会社はかなり浮かび上がります。質問への説明が曖昧な会社は避けるのが無難です。
- Q. 再委託を禁止すると費用は上がりますか？
- A. 上がる場合もありますが、無断の再委託による品質低下や責任のあいまい化を防げるメリットがあります。全面禁止が難しければ「事前承諾制」にし、どこを誰に出すかを把握できる状態にするのが現実的です。
