「発注額の半分以上が中抜きされとるんやないか」――中堅企業の情報システム責任者から頻繁に聞く違和感だ。 元請け SIer に月額 280 万円で発注した PM が、実は 6 次請けまで階層が伸び、現場で実装する開発者の手取り単価は 80 万円台。差額 200 万円が中間マージンとして消える構造が、日本の IT 業界で長年続いてきた。
多重下請けの問題は、コストだけではない。品質劣化・情報齟齬・責任分散・スケジュール遅延といった連鎖的な弊害が、システム品質を確実に蝕む。本記事では、中堅企業が多重下請けから脱却し、直発注で品質と単価を取り戻すための実務手順を、6 ステップで整理する。
注意： 本記事の単価レンジ・階層別マージン率は、IPA「IT 人材白書」「DX 白書」、JEITA「ソフトウェア取引実態調査」、JISA 統計、公正取引委員会「下請取引実態調査」など公開資料の傾向値をもとに整理した参考値である。実際の発注では、自社の調達ポリシー・法務レビュー・顧問弁護士の確認を前提に活用すること。
目次
- IT 多重下請け構造の実態
- 多重下請けで起きる 4 つの弊害
- 直発注 6 ステップ
- 直発注リスクと対策
- 中堅企業の発注パターン 3 ケース
- PMO 体制構築
- 内製比率の段階上げ
- よくある質問（FAQ）
- 関連記事
- 参考資料
IT 多重下請け構造の実態
6 次請けまで存在する現場
日本の IT 業界では、元請け SIer から数次にわたる再委託が常態化している。IPA「IT 人材白書」「DX 白書」など公開資料の傾向では、1 案件あたり平均 2-3 次、大規模案件では 5-6 次までの再委託が観測されることが報告されている。
階層が深くなる典型的な要因は 3 つだ。
- 元請けのリソース不足：受注は取れたが社内に空き要員がいない
- 専門領域の補完：基盤・フロント・QA を別会社に分担させる必要がある
- コスト調整：元請けが粗利を確保するため、より単価の安い下層に流す
層別単価分布の傾向
公開統計の傾向をもとに整理した、案件単価（人月）の階層別分布の目安は以下の通り。
| 階層 | 役割の典型 | 単価レンジ（人月）の目安 | 元請け請求額に対する比率 |
|---|---|---|---|
| 元請け（顧客請求） | 営業・PM | 200-300 万円 | 100% |
| 1 次請け | PMO・設計 | 130-180 万円 | 55-65% |
| 2 次請け | リーダー・設計 | 100-140 万円 | 40-50% |
| 3 次請け | 実装・PG | 80-110 万円 | 30-40% |
| 4 次以下 | 実装・テスト | 60-90 万円 | 20-30% |
数字の前提： 上表は IPA「IT 人材白書」「DX 白書」、JEITA・JISA の取引実態調査、公正取引委員会「下請取引実態調査」など複数の公開資料の傾向値をもとに整理した参考レンジである。地域・業種・エンジニア経験年数・常駐有無によって変動する。
つまり、顧客が 280 万円で発注しても、実際に手を動かす開発者の単価は 80-110 万円帯で、差額 170-200 万円が各階層のマージンとして消えている計算になる。
2 次請け・3 次請けの違い
混同されがちだが、契約構造としては次の通り区別される。
- 2 次請け：元請けと直接契約せず、1 次請けとの間で再委託契約を結ぶ事業者
- 3 次請け：2 次請けからさらに再委託を受ける事業者
- 4 次以下：実態としては「個人事業主」「フリーランス」「常駐 SES」が混在するレイヤー
問題は、顧客側からは 2 次以下の構造が見えないことが多い点だ。発注先と請求書上の取引相手は元請けのみで、実際にコードを書いているエンジニアの所属会社・契約形態・指揮命令系統は不透明になる。
多重下請けで起きる 4 つの弊害
弊害 1：品質劣化
発生メカニズム： 階層が深くなるほど、要件の意図・前提・制約が伝言ゲーム化する。元請け PM が顧客から聞いた背景は、1 次請けに「設計書」として渡る時点で抽象化され、3 次請けの開発者には「機能仕様」しか届かない。
見抜き方：
- 開発者からの「なぜこの仕様なのか」という確認質問が PM 経由で 3 日以上戻ってこない
- レビュー指摘に対して「指示通り作りました」という回答が頻発する
- テスト工程で初めて「業務上ありえない仕様」が露見する
弊害 2：単価押下
発生メカニズム： 各階層が 15-25% のマージンを取るため、現場に届く頃には人月単価が初期発注額の 30-40% にまで減る。開発者個人の手取りは更に低く、優秀層が流出して残るのは経験浅めのリソース、というスパイラルに陥る。
見抜き方：
- 同じ会社のエンジニアが半年単位で入れ替わる（離職率の高さ）
- 設計者と実装者の経験ギャップが大きい
- ベテランは打ち合わせのみ参加し、実装は別の若手が担当する分業
弊害 3：情報齟齬
発生メカニズム： 階層間で連絡ハブが PM のみになり、技術的判断の共有が遅れる。Slack / Teams が部署単位で分断され、顧客側 → 元請け → 1 次 → 2 次 → 3 次の片方向フローが生じる。
見抜き方：
- 質問への回答が「持ち帰り → 翌日以降」になることが多い
- 開発者と直接会話できる場が定例会以外にない
- 顧客側の意思決定が下層に届くまで 5 営業日以上かかる
弊害 4：責任分散
発生メカニズム： 障害発生時に「元請けの設計が悪い」「1 次請けの実装漏れだ」「3 次請けの動作確認不足だ」と責任の押し付け合いが起き、原因究明が遅れる。契約上の責任は元請けにあるが、実態として元請け PM が技術詳細を把握していないことが多い。
見抜き方：
- 障害対応の事後レポートで「人的ミス」「確認不足」という抽象的な原因に集約される
- 同種の障害が再発する
- 改善策が「チェックリスト追加」のみで根本対応がない
直発注 6 ステップ
Step 1：ベンダーリサーチ（2-4 週間）
直発注の出発点は、元請け SIer ではなく、実際にコードを書く事業者を直接探すこと。リサーチ対象の例は次の通り。
- 中規模開発会社（30-200 名規模、自社開発比率 50% 以上）
- 業種特化のドメイン特化型ベンダー（金融・医療・製造など）
- 専門領域のスペシャリスト集団（AI / データ基盤 / クラウド移行）
- 国内ニアショア（地方都市の開発拠点を持つ会社）
情報源： IPA 認定ベンダーリスト、業界団体（JISA・CSAJ）、各種テックコミュニティの登壇者、GitHub での技術発信実績、自治体の DX 認定企業リストなど。
Step 2：RFP 発行（2-3 週間）
RFP（提案依頼書）には次を明記する。
- 業務背景と目的：なぜこのシステムを作るのか
- 機能要件・非機能要件：何が必要で、どこまで求めるか
- 技術制約：既存システムとの連携、利用クラウド、セキュリティ基準
- 予算レンジ：上限を明示すると見積もり精度が上がる
- スケジュール：稼働希望日、フェーズ分割の可否
- 再委託の方針：「再委託する場合は事前承認」「2 次請けまで」など制約
- 評価軸：価格 / 技術力 / 体制 / 実績の重み
重要： 再委託の制限を RFP 段階で明記することで、多重下請け前提の提案を初期段階で除外できる。
Step 3：提案評価（2 週間）
評価軸を事前に重み付けし、定量比較する。中堅企業向けの推奨配分は次の通り。
| 評価軸 | 重み | 評価ポイント |
|---|---|---|
| 価格 | 25% | 単価妥当性 / 隠れコストの有無 |
| 技術力 | 25% | 提案された技術選択の根拠 |
| 体制 | 25% | 再委託有無 / アサイン人数と経験 |
| 実績 | 15% | 同業種・同規模の事例 |
| カルチャー | 10% | コミュニケーション頻度 / 透明性 |
Step 4：契約交渉（2-3 週間）
契約書で押さえるべき条項。
- 再委託の事前承認義務：書面承認なしの再委託禁止
- アサインメンバーの固定：主要メンバーの交代時は事前承認
- 成果物・ソースコードの知財帰属：原則として顧客側に帰属
- 検収基準と SLA：障害発生時の対応時間・補償条件
- 撤退条件：プロジェクト中断時の費用清算ルール
- 下請法・フリーランス保護法の遵守：書面交付・支払期日・禁止行為への準拠
下請法の詳細は「下請法改正 2026 対応ガイド」で解説しているため、契約レビュー前に確認しておきたい。
Step 5：PMO 体制（プロジェクト開始-3 ヶ月）
直発注では、顧客側に最低 1 名の PMO 担当者を配置する。元請け SIer がいない分、進捗管理・課題管理・ベンダー間調整の責任は顧客に集約される。
- 専任 PM（社内）：1 名（経営企画・情報システム部門のリーダー級）
- アシスタント：0.5 名（議事録・資料作成）
- 必要に応じて外部 PMO：0.5-1 名（経験不足を補う）
詳細は本記事後半の「PMO 体制構築」で解説する。
Step 6：運用フェーズ（稼働後-継続）
リリース後の運用も、元請け SIer に丸投げせず、複数の運用ベンダーと直接契約するのが直発注の流儀。
- 24/365 監視：監視特化のベンダーと SLA 契約
- 障害対応：開発ベンダーと別途運用契約
- 機能改修：開発ベンダーまたは別の機能改修専門ベンダー
- セキュリティ：脆弱性診断・WAF 運用は別ベンダー
これにより、特定ベンダーへのロックインを防ぎつつ、領域ごとに最適なパートナーを選べる。
直発注リスクと対策
リスク 1：規模ミスマッチ
症状： 中規模開発会社に大規模案件を依頼してリソース枯渇。
対策： 案件を 3-6 ヶ月単位のフェーズに分割し、各フェーズで体制をリ評価。3-5 名規模で進められる単位に切り出す。
リスク 2：リソース不足
症状： 直発注先が他案件で手一杯になり、稼働が確保できない。
対策： 契約時に「最低稼働率 80%」「主要メンバー専任」を明記。複数ベンダーへの分散発注で単一障害点を回避する。
リスク 3：教育コスト
症状： 自社の業務知識・既存システム仕様の引継ぎに時間がかかる。
対策： 業務マニュアル・現行システムの設計書を整備しておく。インプット工数を 2-3 週間と明示し、契約に含める。
リスク 4：撤退条件の曖昧さ
症状： プロジェクトが頓挫した際、成果物の権利・支払い義務が不明確。
対策： 検収マイルストーンごとの中間納品を設定し、各マイルストーン時点での支払い済み成果物に対する知財帰属を契約書に明記する。
中堅企業の発注パターン 3 ケース
業種別の典型的な直発注パターンを 3 ケース整理する。いずれも特定企業を示唆するものではなく、業界の一般的傾向として記載する。
ケース A：製造業 / 受発注システム刷新
- 規模：300-500 名 / 年商 100-300 億円
- 元請け体制：大手 SIer 1 社 → 1 次請け 2 社 → 2 次請け 5 社
- 直発注後：中規模ドメイン特化ベンダー 1 社 + ニアショア 1 社の 2 社体制
- 効果の方向性：中間マージン削減と意思決定スピード向上が見込める
ケース B：流通業 / EC プラットフォーム
- 規模：500-1000 名 / 年商 300-500 億円
- 元請け体制：大手 SIer 1 社 → 1 次請け 3 社 → 2-3 次請け 8 社
- 直発注後：EC 特化ベンダー + データ基盤専門 + UX 専門の 3 社並走
- 効果の方向性：領域特化により施策スピードと品質を両立しやすい
ケース C：金融業 / 基幹システムモダナイゼーション
- 規模：200-400 名 / 連結子会社含む
- 元請け体制：メインフレームベンダー 1 社 → 子会社 SIer 2 社 → 派遣・SES 多数
- 直発注後：クラウド移行特化 1 社 + 既存ベンダー（一部継続）+ セキュリティ専門の 3 社
- 効果の方向性：金融業の規制要件は段階的移行と既存ベンダー併走が前提
直発注 PoC 診断は無料で実施できます
中堅企業の直発注検討は、現状ヒアリング → 階層別マージン推定 → 直発注時の試算 → リスク評価の 4 ステップで判断できます。GXO では、貴社の現行発注構造を診断し、直発注に切り替えた場合の試算と推奨ベンダー要件を整理する無料 直発注準備度診断を提供しています。
PMO 体制構築
社内側 1-2 名で回すための役割設計
直発注では、PMO の責任範囲を「進捗 / 課題 / コスト / 品質 / リスク」の 5 軸で明確化する。社内側 1-2 名でも回せる体制設計は次の通り。
| 役割 | 専任 / 兼任 | 必要スキル | 月稼働の目安 |
|---|---|---|---|
| プロジェクトオーナー | 兼任（部長級） | 意思決定 | 20-40h |
| PMO リーダー | 専任 | PM 経験 / 業務知識 | 120-160h |
| PMO アシスタント | 兼任 | 議事録 / 資料作成 | 40-60h |
| 業務 SME | 兼任（現場リーダー） | 業務詳細 | 20-40h |
外部 PM 委託の選定軸
社内に PM 経験者がいない場合、外部 PMO 委託を検討する。選定軸は次の通り。
- 業界経験：自社業種での PM 実績が 3 年以上
- 規模感：自社案件と同等規模（人月 100-500 万円）の経験
- 中立性：開発ベンダーと資本関係・業務提携がない
- 契約形態：成果報酬ではなく時間制契約（独立性確保のため）
- 稼働形態：週 2-3 日のリモート稼働を許容するか
外部 PMO の費用は週 2 日稼働で月額 80-120 万円が目安レンジだ。元請け SIer の PM 費用（月額 200-300 万円）と比較すると、直発注 + 外部 PMO の組み合わせで合計コストは 30-40% 削減できる試算が一般的に成立する（前提条件によって変動）。
内製比率の段階上げ
直発注の次の段階は、内製比率の段階的引き上げだ。3 段階での移行モデルを整理する。
段階 1：直発注（外注 100%）
- 期間：1-2 年目
- 体制：社内 PMO 1-2 名 + 外注ベンダー 2-3 社
- 目的：発注プロセスの掌握、ベンダー比較眼の獲得
- KPI：中間マージン削減率、品質指標（バグ密度・障害件数）
段階 2：一部内製（外注 70% / 内製 30%）
- 期間：2-3 年目
- 体制：社内エンジニア 2-5 名 + 外注ベンダー 2-3 社
- 目的：コア領域（業務ロジック・データ基盤）の内製化
- KPI：内製コミット比率、社内エンジニア定着率
段階 3：主導内製（外注 30% / 内製 70%）
- 期間：3-5 年目
- 体制：社内エンジニア 5-15 名 + 外注ベンダー 1-2 社（補助的）
- 目的：技術選択・アーキテクチャ決定の社内化
- KPI：機能リリース頻度、新規開発スピード
移行の注意点： 段階を飛ばさないこと。直発注を経ずに内製化に踏み切ると、ベンダー選定眼が育たず、内製チームの品質判断軸が曖昧になる。
よくある質問（FAQ）
Q. 直発注で大手 SI と契約できるか？ A. 大手 SIer は通常、再委託前提のビジネスモデルのため、中堅企業の直発注先としてはミスマッチが多い。中規模専門ベンダー（30-200 名）または専門領域特化型ベンダーを優先する方が直発注の効果が出やすい。
Q. 中堅企業が直接発注した実績はあるか？ A. 製造業・流通業・金融業を中心に、ここ 5 年で増加傾向。IPA「DX 白書」など公開資料の傾向では、中堅企業の直発注比率は緩やかに上昇していると報告されている。具体的な事例は守秘義務上掲載できないが、業界団体の事例集（JEITA / JUAS など）で公開事例を確認できる。
Q. PMO 体制構築の現実的な道のりは？ A. 最短ルートは「外部 PMO 1 年間委託 + 社内 PMO 育成」の並走型。1 年で社内 1 名を PM 経験者に育てた上で、2 年目以降は内製化する。育成投資としては年間 1,000-1,500 万円規模が一般的レンジ。
Q. 相見積もりは何社まで取るべきか？ A. 3-5 社が標準。10 社以上だと比較工数が膨大になり、提案の質も下がる。事前リサーチで 10-15 社を絞り込み、RFP 発行は 3-5 社、本契約交渉は 1-2 社が現実的な進行。
Q. 直発注で品質保証はどう担保するか？ A. 契約書での SLA 明記（応答時間・障害復旧時間・バグ密度上限）と、第三者機関による品質監査の組み合わせが標準。中堅企業の場合は IPA の「ソフトウェア品質指標」をベースに自社版 SLA を作成する事例が多い。
Q. 既存元請けにバレずに直発注検討を進められるか？ A. 検討段階では NDA を厳格に運用すれば可能。ただし契約満了タイミングで通知することが商道徳上は望ましい。下請法・取引適正化の観点でも、不当な切替は親事業者側にリスクとなる。
Q. 直発注で総コストは下がるが工数は増えないか？ A. 増える。元請け SIer に集約していた管理工数を社内 PMO が引き受けるため、社内工数は 1.5-2 倍に増加することが多い。総コストとしては中間マージン削減で 20-30% 圧縮、社内人件費増加分を差し引いても 10-15% の純削減が標準レンジ。
Q. 直発注に失敗した場合の出口戦略は？ A. 元請け SIer に戻すのではなく、別の中規模ベンダーへの切替が現実解。一度直発注の発注プロセスを掌握すれば、ベンダー切替コストは元請け SIer 体制よりも下がる。詳細は「ベンダー切替 失敗パターン」を参照。
関連記事
- ベンダーロックイン防止戦略｜特定ベンダーに依存しないシステム設計の方法
- 下請法改正 2026 対応ガイド｜中堅企業の取引実務と契約見直しチェックリスト
- ベンダー切替 失敗パターン分析と移行リスク管理 2026
- IT ベンダー選定基準と RFP ガイド
- オフショア vs 国内開発比較
- AI ベンダーマネジメント中堅 200 人フレームワーク
参考資料
- IPA「IT 人材白書」「DX 白書」
- JEITA「ソフトウェア取引実態調査」
- JISA（情報サービス産業協会）統計資料
- 公正取引委員会「下請取引実態調査」「下請取引適正化推進講習会テキスト」
- 中小企業庁「下請かけこみ寺」「価格交渉ハンドブック」
- 経済産業省「DX レポート 2.1」「情報サービス・ソフトウェア産業における下請取引適正化推進のためのガイドライン」
中堅企業の多重下請け脱却・直発注体制構築・PMO 設計の支援は GXO のシステム開発支援サービスで対応可能です。現状の発注構造ヒアリングから直発注ロードマップ策定まで、無料相談から開始できます。