多重下請け構造がコストに与える影響とは

「発注した会社に実際に開発をしているエンジニアが何人いるのか、よく分からない」——見積もりを取って契約まで進んだはずなのに、いざプロジェクトが始まってみると、窓口の担当者と実際に手を動かす人が別会社だった、という経験はないでしょうか。名刺交換をした相手と、打ち合わせに同席する技術者が違う会社の人間だったと後から気づき、戸惑った現場責任者も少なくないはずです。

実はこの違和感は、思い込みや勘違いではなく、システム開発業界に根強く存在する「多重下請け構造」という商流の仕組みそのものに由来しています。この構造を知らないまま発注すると、見積もり金額だけを見て「高い」「安い」と判断してしまい、実際には何にお金を払っているのか分からないまま契約することになりがちです。

この記事では、多重下請け構造がなぜ生まれるのか、それがコストにどう影響するのかを整理したうえで、発注前にどんな視点を持っておくと判断材料になるかを解説します。

多重下請け構造とは何か

多重下請け構造とは、発注者から仕事を受けた元請け企業が、その業務の一部またはすべてを別の会社（下請け）に再委託し、さらにその下請けがまた別の会社に委託する、という連鎖が複数段に重なった状態を指します。建設業界などでもよく知られた商習慣ですが、システム開発業界でも同様の構造が長く続いてきました。

この構造が生まれる背景には、大規模な案件を受注できる体制（営業力・実績・資本力）を持つ企業と、実際に手を動かせる技術者を抱える企業が、必ずしも一致していないという事情があります。発注者からすると、元請けの会社としか契約していないつもりでも、実際の開発作業は二次請け、三次請けの会社やフリーランスが担っている、という状態が珍しくありません。

なぜ階層が増えるとコストが積み上がるのか

多重下請け構造がコストに影響を与える最大の理由は、各階層ごとに中間マージン（手数料）が発生する点にあります。元請けが受注した金額の中から、自社の利益や管理コストを差し引いた残りを下請けに発注し、その下請けもまた同じように差し引いた金額をさらに下の階層へ発注する、という仕組みが連鎖します。

この結果、発注者が支払った金額のうち、実際に開発作業そのものに充てられる割合（実作業への配分）は、階層が増えるほど小さくなっていきます。逆に言えば、同じ開発作業量であっても、間に入る会社の数が多いほど、発注者側の総支払額は大きくなりやすい構造になっているということです。ここは、見積もりの金額だけを見て判断する前に、頭の片隅に置いておきたい視点です。

ただし、階層が多いこと自体が一方的に悪いわけではありません。元請け企業が品質管理やプロジェクト全体の進行管理、トラブル対応の窓口機能を担っている場合、その分のコストには相応の意味があります。問題になりやすいのは、階層が増えているにもかかわらず、管理機能や品質保証の実態が伴っていない場合です。

階層が増えることで起きる、コスト以外の影響

多重下請け構造の影響は、金額の多寡だけにとどまりません。階層が増えるほど、発注者の要望が実際の開発現場まで届くのに時間がかかるようになり、逆に現場からの疑問や懸念が発注者に届くまでにも時間がかかるようになります。伝言ゲームのような状態が生まれやすく、これが仕様の認識違いや手戻りの原因になることもあります。

また、トラブルが発生した際の責任の所在が曖昧になりやすいという点も見落とせません。「どの階層の作業に問題があったのか」を特定するのに時間がかかり、対応が後手に回るケースも見受けられます。契約書上は元請けが責任を負う形になっていても、実務上の原因究明には複数の会社をまたいだ確認が必要になるため、ここは発注する側が意識しておきたいところです。

さらに、担当者の変更や離脱といった事態が起きたとき、下の階層にいる技術者ほど、発注者からは見えにくい存在になりがちです。この点については、担当エンジニアが辞めたらプロジェクトは止まるかでも扱っていますが、多重下請け構造のもとでは、そもそも「誰が実際に担当しているのか」を発注者が把握しきれていないケースもあり、離脱リスクへの備えがより難しくなる面があります。

発注先を比較するときに確認しておきたいこと

多重下請け構造の影響を踏まえると、見積もりを比較する際には金額そのものよりも、まず「誰が実際に開発するのか」を確認する姿勢が実務上の出発点になります。

• 体制図の提示を求める：見積もりと合わせて、実際に作業する会社・担当者の構成（体制図）を示してもらえるかどうかを確認する。提示を渋る、または曖昧にしか答えられない場合は、階層の実態が見えにくい可能性がある
• 再委託の可否と範囲を契約書で確認する：契約書に再委託に関する条項があるか、ある場合はどこまでの再委託が許容されているかを確認する
• 窓口担当者と実作業者の関係を聞く：打ち合わせに同席する人物が、実際にコードを書く担当者なのか、それとも管理のみを担う立場なのかを早い段階で確認する
• トラブル時の連絡フローを確認する：不具合が発生した際、どの階層まで情報が届き、誰が最終的に対応責任を負うのかを事前にすり合わせておく

これらは、SIer・フリーランス・自社、見積書の構造を読むでも触れている、発注先ごとの事業構造の違いと重なる部分があります。価格構造の比較検討を進める際には、多重下請け構造の有無もあわせて確認しておくと、見積書だけでは見えない判断材料が増えます。

なお、下請事業者との取引に関しては、下請代金支払遅延等防止法（下請法）という法律があり、公正取引委員会と中小企業庁が共同で運用・監視にあたっています。公正取引委員会は同法に基づく違反事例や指導内容を取りまとめて公表しており、取引条件を書面で明確にすることや、下請代金を不当に減額しないことなどが規制の柱となっています。発注者の立場であっても、取引の透明性に関するこうした考え方を知っておくと、契約交渉の際の参考になる場面があります。

誰が実際に手を動かしているかを把握できているかどうかは、金額の妥当性以上に、プロジェクトの進行やトラブル対応の速度を左右する要素だと言えます。

まとめ

• 多重下請け構造とは、元請けから下請け、孫請けへと業務が再委託される商流の重なりであり、システム開発業界に根強く存在する慣習である
• 階層が増えるほど各段階で中間マージンが発生し、発注者の支払額のうち実作業に充てられる割合が小さくなりやすい。ただし階層そのものが一律に悪いわけではなく、管理機能が伴っているかが判断の分かれ目になる
• 発注前には体制図の提示や再委託条項の確認、トラブル時の連絡フローのすり合わせを行うことで、見積書だけでは見えないリスクを把握しやすくなる