多重下請け構造とは｜発注側が損する4つの理由
こんにちは、合同会社SAi代表の佐藤です。2026年8月17日、読売新聞オンラインに元マイクロソフト開発者のインタビューが掲載されました。日本が「デジタル敗戦」の状態にある最大の原因は、ITゼネコンを頂点とする多重下請け構造にあるという内容です。
業界内では20年以上前から言われてきた話ですが、この記事では発注する側にとって何が問題なのかという角度で整理します。エンジニアの待遇の話としてではなく、システムを買う会社の損得の話として書きます。
先に立場を明かしておくと、当社は下請けを使わず、代表である私が直接ヒアリングして開発しています。構造の外にいる立場からの見方だという前提で読んでいただければと思います。
結論：発注側の損は「中抜き」と「伝言ゲーム」の2つに集約されます
| 何が起きるか | 発注側への影響 |
|---|---|
| 階層ごとに管理費が乗る | 払った額のうち、実際に作る工程に回る割合が下がる |
| 設計する人と作る人が別 | 要望が伝言ゲームになり、出来上がりがずれる |
| 判断が階層を往復する | 小さな変更にも時間がかかる |
| 実装したのが別会社 | 不具合が出たとき、誰が直すのか曖昧になる |
金額の話だけではありません。「言ったことが伝わらない」という不満の多くは、担当者の能力ではなく構造から生まれています。
何が報じられたのか
報道によれば、日本の典型的な開発体制はこうです。
IT大手が大規模なシステム開発を請け負い、その企業のエンジニアが設計図にあたる仕様書を書いて、プログラムは下請けに丸投げする。下請けや孫請けのエンジニアが低賃金で大量のプログラムを書き、ソフトをIT大手に納品する。
そして、IT大手のエンジニアは設計図を書くだけで、自らプログラムは書かない——この点について、記事ではこう表現されています。
日本は自分で料理をしない料理長が料理のレシピを書いているような状況だ。自らプログラムを書かない者がいいソフトを設計できるわけがない。
米国では設計もプログラムもエンジニア自身が手がけるのが当たり前で、優秀なエンジニアほどそうしている、とも述べられています。そしてこの問題は20年以上前から指摘されているのに直っていない——当事者であるIT大手に直す動機がないから、という指摘です。
発注側が損する4つの理由
1. 支払った額のうち、開発に回る割合が下がる
階層をまたぐたびに、その会社の管理費・営業費・利益が乗ります。元請けが受け取った金額が、そのまま開発に使われるわけではありません。
これは中間の会社が悪いという話ではなく、各社が自社の人件費を賄うために必要な費用です。ただし発注側から見れば、同じ金額でも実際に手を動かす時間が減るということになります。「高い見積もりなのに、出てきたものが薄い」と感じる場合、この構造が背景にあることがあります。
2. 設計する人と作る人が別なので、要望がずれる
これが金額以上に厄介です。ヒアリングした人、仕様書を書く人、実装する人が全員違うと、あなたの「こうしたい」は3回翻訳されてから実装されます。
現場の業務は、言葉にしきれない前提でできています。「この帳票は月末だけ形式が変わる」「この取引先だけ単価の計算が違う」——こうした細部は、直接聞いた人でないと拾えません。仕様書は完璧に書けないという前提に立つと、聞いた人が作るかどうかは品質そのものに直結します。
3. 判断と修正が遅い
「ボタンの位置を変えたい」という程度の話でも、発注側 → 元請けの営業 → 元請けのPM → 下請け → 実装者、と往復します。決定に人が挟まるほど、待ち時間が増えます。
システムは公開してからの調整が本番です。ここが遅い体制だと、使いにくいまま定着せず、現場がExcelに戻る——という結末になりがちです（中小企業のDXが失敗する理由でも触れました）。
4. 責任の所在が曖昧になる
不具合が出たとき、元請けは「下請けに確認します」、下請けは「仕様どおりです」となることがあります。発注側からは誰に言えば直るのかが見えません。
保守契約でも同じことが起きます。「保守費を払っているのに対応してもらえない」という相談の背景には、実装した会社と保守窓口が別、という事情があることが少なくありません（ホームページ保守費用の相場でも同じ構図を書きました）。
契約前に確認する5つの質問
構造は外から見えません。ただし、次の5つを聞けば輪郭は分かります。失礼な質問ではないので、普通に聞いて問題ありません。
- 実際に開発する方と直接話せますか？——最も効きます。会えないなら階層があります
- 担当エンジニアは御社の社員ですか、協力会社の方ですか？——比率を聞くのも有効です
- 仕様変更が出たとき、誰が判断しますか？——判断者が遠いほど遅くなります
- 公開後の修正は誰が対応しますか？——実装者と保守担当が別かどうか
- 見積もりの内訳を教えてください——管理費・調整費の比率が構造を示します
答えにくそうにする会社が悪いわけではありません。ただ、答えられる会社のほうが、あとで揉めにくいのは確かです。
ただし「多重下請け＝悪」ではありません
公平のために書いておきます。大規模な案件では、分業には合理性があります。
- 数十人規模の開発を同時に進めるなら、統括する層は必要です
- 24時間365日の運用、金融や公共のような可用性要件では、体制の厚みが安心につながります
- 発注側に専門知識がない場合、間に入って翻訳してくれる存在に価値があります
一方、少人数の会社に発注する場合によく聞かれるのが「担当者に何かあったらどうなるのか」という点です。もっともな懸念なので、当社がどう備えているかを書いておきます。
- 特殊な独自技術に依存しない——標準的な構成で作るので、他の開発者でも読める状態を保っています
- ソースコードとデータの所在を明確にする——お客様にお渡しできる形で管理します。当社に依存しない状態が前提です
- バックアップと復旧手順を文書化——本番環境は国内データセンターに置き、復旧手順を文書として残しています（情報セキュリティ方針に記載）
- 規模が合わない案件は正直にお断りする——数十人規模の同時開発や、24時間365日の有人監視が必要なシステムは、体制の厚い会社のほうが適しています
「引き継げない状態を作らない」ことが、少人数で受託する側の責任だと考えています。
つまり「規模と要件で選び分けるもの」であって、どちらかが常に正しいわけではありません。中小企業の業務システムのように、要件が現場に密着していて、小さく作って直し続ける類の開発では、直接やり取りできる体制のほうが向いている、というのが私の考えです。
当社が下請けを使わない理由
手前味噌になりますが、当社の立ち位置も書いておきます。
当社はお客様と開発者の間に誰も挟みません。ヒアリングした人間がそのまま作ります。だから「この帳票、月末だけ形が違うんです」という話が、翻訳されずにそのまま実装に反映されます。
そして価格についても同じ構造から説明できます。開発費を安くするために品質を削っているのではなく、開発以外にかかるコストを削っています。営業担当も中間業者もいないので、その分が価格に乗りません。初期費用0円・月額1万円〜（税別）でフルスクラッチ開発ができるのは、この構造の違いによるものです（内訳は料金ページに公開しています）。
報道された問題は、業界の外にいる人間が正すのは難しいものです。ただ発注する側が「実際に作る人と話せますか」と聞くようになるだけで、選ばれる会社は変わっていくと思っています。
DIRECT
開発する人間が、最初から最後まで対応します
相談・要件整理・開発・運用まで、代表である開発者が直接担当します。伝言ゲームがないので、現場の細かい事情がそのまま形になります。初期費用0円・月額1万円〜（税別）、稼働するまで課金なし、最短3日。100社以上の中小企業を支援してきました。
料金と体制を見る → 無料で相談する →その場で概算だけ知りたい方は、チャットで状況を話すだけで目安が出ます（登録不要・1分）。
よくある質問
Q. 多重下請け構造とは何ですか？
A. IT大手が大規模なシステム開発を請け負い、自社のエンジニアが仕様書を書いたうえで、プログラミングを下請け・孫請けに委託する日本のシステム開発の慣行です。読売新聞（2026年8月17日）が報じた元マイクロソフト開発者の指摘では、設計する人が自らプログラムを書かない点が問題とされ、20年以上前から指摘されながら改善されていないとされています。
Q. 発注側にとって何がデメリットですか？
A. 4つあります。①階層ごとに管理費が乗るため、支払った額のうち実際の開発に回る割合が下がる ②設計者と実装者が別なので要望がずれる ③判断が階層を往復するため修正が遅い ④不具合時に責任の所在が曖昧になる、です。金額よりも「言ったことが伝わらない」問題のほうが実害は大きくなりがちです。
Q. 発注先が下請けを使っているか、どう見分けますか？
A. 「実際に開発する方と直接話せますか」と聞くのが最も確実です。あわせて「担当エンジニアは御社の社員ですか」「仕様変更は誰が判断しますか」「公開後の修正は誰が対応しますか」を確認すると、体制の輪郭が分かります。答えられる会社のほうが、後で揉めにくい傾向があります。
Q. 多重下請けは常に悪いのですか？
A. いいえ。数十人規模で同時に開発する案件や、24時間365日の運用が必要なシステムでは、統括する層や体制の厚みに合理性があります。一方で、少人数の会社は担当者に依存するリスクがあります。規模と要件で選び分けるのが正しい考え方です。
Q. 少人数の開発会社に頼む場合、担当者に何かあったらどうなりますか？
A. 確認すべきは「引き継げる状態か」です。具体的には、①特殊な独自技術に依存せず標準的な構成で作られているか ②ソースコードとデータを自社で受け取れるか ③バックアップと復旧手順が文書化されているか、の3点を聞いてください。当社はいずれも満たしており、本番環境は国内のデータセンターに設置し、復旧手順を文書として残しています。なお、24時間365日の有人監視が必要なシステムは体制の厚い会社が適しているため、その場合は正直にお伝えしています。
Q. 中小企業の業務システムでは、どちらが向いていますか？
A. 要件が現場に密着していて、小さく作って直し続ける類の開発では、直接やり取りできる体制のほうが向いています。現場の細かい事情は仕様書に書き切れないため、聞いた人がそのまま作る形のほうが、結果として使われるシステムになりやすいからです。
まとめ：金額より「誰が作るか」を確認する
- 多重下請け構造とは、仕様書を書く会社と実装する会社が分かれる日本の慣行
- 発注側の損は①中抜き ②伝言ゲーム ③遅い判断 ④曖昧な責任の4つ
- 契約前に「実際に作る方と直接話せますか」と聞くだけで構造が見える
- 大規模案件では分業に合理性がある。規模と要件で選び分けるもの
- 現場に密着した中小企業の業務システムは、直接やり取りできる体制が向いている
「実際に作る人と話しながら進めたい」という方は、料金ページをご覧いただくか、お問い合わせからご相談ください。相談から開発まで、代表である開発者が直接対応します。
