システム開発を外部の会社に委託するとき、契約書の表題が「請負」や「業務委託」であっても、現場での働き方の実態によっては、別の評価を受けることがある。とくに発注者が委託先の担当者に直接、日々の作業指示を出している場合、契約の形式と実態がずれていないか、注意しておきたい論点がある。発注者として知らないうちにリスクを抱えてしまうことを避けるためにも、基本的な考え方を押さえておく価値がある。
本記事は、システム開発の委託で問題になりやすい「偽装請負」と「多重下請け」について、発注者の視点で確認すべき点を整理する。読者として想定しているのは、中小企業の経営者、発注担当、管理部門の担当者である。なお、これらは労働法・契約法に関わる領域であり、個別の事案がどう評価されるかは、最終的に弁護士・社会保険労務士などの専門家への確認を前提としてほしい。本記事は一般的な考え方の整理にとどまる。
結論：契約の形式と実態を一致させ、再委託の流れを把握する
偽装請負や多重下請けに関するリスクを抑えるうえで、発注者として意識しておきたいのは次の3点である。
- 契約の形式（請負・準委任・派遣など）と、現場での指揮命令の実態を一致させる
- 委託先がさらに別の会社へ再委託する場合、その範囲と承認の仕組みを契約で確認する
- 多重下請けが品質・責任・情報管理に与える影響を、発注前に把握しておく
契約書の文言だけでなく、実際にどう働いてもらうかまで含めて整理しておくことが、後のトラブルを避ける土台になる。
RESTAURANT DX
店長の経験と勘を、仕組みで再現できる店舗にしませんか？
発注／シフト／予約／FLコストを標準化する多店舗飲食特化のDX。食材ロス削減・インバウンド対応まで概算費用をその場で示します。
偽装請負とは何か、なぜ問題になるか
偽装請負は、契約の形式上は請負や業務委託でありながら、実態としては発注者が委託先の労働者を直接指揮命令して働かせている状態を指して用いられる言葉である。労働者派遣法や職業安定法などに関わる論点とされ、行政の指導や是正の対象になりうるとされている。
なぜこれが問題になるのか。請負や準委任では、本来、仕事の進め方や担当者への指示は受託側（委託先）が行うのが基本とされる。一方で、発注者が委託先の担当者に対し、勤務時間や作業手順を直接細かく指示するようになると、実態は労働者派遣に近づく。派遣には派遣に応じた手続きやルールがあるため、形式が請負のまま実態が派遣に近い状態は、適切でないと評価される可能性がある。
ただし、どこからが指揮命令にあたるか、どの程度の関与で問題になるかは、個別の状況により判断が分かれる領域である。具体的な線引きは、弁護士や社会保険労務士などの専門家への確認を前提に考えてほしい。
指揮命令の実態をどう見るか
発注者として確認しておきたいのは、「誰が委託先の担当者に日々の指示を出しているか」である。一般に、次のような関わり方は、指揮命令の実態に近づくと整理されることがある。
横にスクロールして確認できます
| 関わり方の例 | 性質 | 確認したい観点 |
|---|---|---|
| 成果物の仕様・要件を伝える | 発注者の役割の範囲とされやすい | 要件定義書・仕様書で明確化 |
| 進捗や課題を定例で共有する | 連携の範囲とされやすい | 窓口を通じた情報共有 |
| 個々の担当者に作業手順を直接指示する | 指揮命令に近づく可能性 | 委託先の責任者を通す |
| 勤務時間・残業を発注者が直接管理する | 指揮命令に近づく可能性 | 委託先側で管理 |
ポイントは、発注者は「何を作ってほしいか（成果物・要件）」を伝え、「どう作るか・誰がいつ作業するか」は委託先の責任者に委ねる、という役割分担を保つことである。委託先に責任者・窓口を立ててもらい、個々の担当者への直接指示を避ける形を意識したい。要件の伝え方については業務システムの要件定義テンプレートも参考になる。
多重下請けがもたらすリスク
システム開発では、委託先がさらに別の会社へ作業を再委託し、その先がまた再委託する、という多重の構造が生まれることがある。これ自体が直ちに問題というわけではないが、層が深くなるほど、発注者から見えにくくなる点が増える。
- 品質のばらつき：実際に手を動かす会社が誰なのか把握できず、品質の管理が難しくなる
- 責任の所在の曖昧化：問題が起きたとき、どの層の責任かが見えにくい
- 情報管理のリスク：機密情報や個人情報が、把握していない先まで渡る可能性がある
- コスト構造の不透明化：各層がマージンを取ることで、実際の開発に充てられる費用が見えにくい
これらのリスクは、契約で再委託の範囲と承認の仕組みを定めておくことで、ある程度コントロールできる。再委託を一律禁止するのが現実的でない場合も多いため、「事前承認を前提に、再委託先を把握できる状態にする」という設計が選択肢になる。契約条項の確認観点は契約前チェックリストでも扱う。
発注者として契約で確認しておきたい点
偽装請負・多重下請けに関わるリスクを抑えるために、契約段階で確認しておきたい項目を整理する。
契約の種類と実態の整合
請負・準委任・派遣のいずれの契約なのか、そしてその形式が実際の働き方と整合しているかを確認する。常駐して作業してもらう場合は、指揮命令の関係が問題になりやすいため、とくに注意したい。契約の種類ごとの違いは契約類型の選び方で詳しく扱う。
再委託に関する取り決め
- 再委託を認めるか、認める場合は事前承認を必要とするか
- 再委託先の情報を発注者が把握できるか
- 再委託先にも、機密保持や品質に関する義務が及ぶ仕組みか
責任の所在
問題が起きたとき、発注者に対して責任を負うのは誰か（直接の委託先か）を明確にしておく。多重下請けでも、発注者の窓口は直接契約した会社に一本化されているのが望ましい。
常駐・準委任で気をつけたい運用
システム開発では、委託先の担当者が発注者のオフィスに常駐して作業する形や、準委任で人を確保してもらう形がとられることがある。こうした働き方は柔軟で便利な一方、現場での関わり方しだいで、指揮命令の実態に近づきやすい面がある。
- 席や設備の共有：発注者の社員と委託先の担当者が混在して座り、見た目に区別がつかない状態になっていないか
- 朝礼・会議への参加：発注者の業務指示が出る場に、委託先の担当者が一律に組み込まれていないか
- 作業時間の管理：委託先の担当者の出退勤や残業を、発注者が直接管理していないか
- 指示の経路：日々の作業指示が、委託先の責任者を経由しているか
これらは、どれか一つあるから直ちに問題ということではない。ただ、複数が重なると、形式は請負・準委任でも実態は別、と整理されやすくなるとされる。常駐や準委任を選ぶ場合は、委託先に現場の責任者を立ててもらい、その責任者を通じて連携する運用を、契約と現場の両面で意識しておきたい。具体的にどこまでが許される関与かは、個別の状況により判断が分かれるため、弁護士・社会保険労務士などの専門家への確認を前提に整理してほしい。
発注前に整理しておくとよいこと
委託の形式と実態のずれを避けるために、発注前に自社で整理しておくとよい点をまとめる。
横にスクロールして確認できます
| 整理する項目 | 確認の観点 |
|---|---|
| 任せたい仕事の性質 | 成果物を頼むのか、人手を確保したいのか |
| 働く場所 | 常駐か、委託先のオフィスでの作業か |
| 指示の出し方 | 個々の担当者か、委託先の責任者か |
| 再委託の見込み | 委託先が再委託する可能性があるか |
| 窓口の体制 | 委託先に責任者・窓口を立ててもらえるか |
「成果物を頼みたいのか」「人手を確保したいのか」が曖昧なまま発注すると、契約の形式と実態がずれやすい。前者なら請負、後者なら派遣など、目的に合った形式を選ぶ出発点になる。自社の目的を言葉にしておくだけでも、委託先との認識合わせが進みやすくなる。
偽装請負・多重下請けが起きやすい背景
これらの問題は、誰かが悪意を持って引き起こすというより、進め方の都合から自然に生じてしまうことが多い。背景を知っておくと、無自覚に陥るのを避けやすい。
- 早く進めたい：細かい役割分担を整える前に、とにかく人を動かそうとして、発注者が直接指示を出してしまう
- 専門知識の差：発注者がシステムに詳しくないと、委託先に「お任せ」になりきれず、つい現場に踏み込んで指示してしまう
- 人手の確保が目的化：本来は成果物が欲しいのに、いつのまにか「人を出してもらう」感覚になり、形式と実態がずれる
- 委託先の体制不足：委託先が自前で人を確保できず、さらに別の会社へ再委託することで、多重の構造が生まれる
いずれも、悪気なく起こりやすい。だからこそ、発注の段階で「自分が欲しいのは成果物か、人手か」「指示は誰を通すか」を意識しておくことが効く。進め方を急ぐあまり役割分担を曖昧にすると、後から実態を是正するのは難しくなる。最初に形を整えておくほうが、結果的に手戻りが少ない。なお、こうした関わり方が具体的にどう評価されるかは個別判断であり、心配な場合は弁護士・社会保険労務士などの専門家への確認を前提に進めてほしい。
実務判断のポイント
この記事は、経営者、情シス、業務責任者、発注担当向けです。要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。システム開発の契約・要件定義トラブル回避｜偽装請負・多重下請けのリスクに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
自社だけで整理が難しい場合、GXOは業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる。最初から大規模な発注を前提にせず、現状整理や診断から必要な範囲を確認できます。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問
Q1. 委託先の担当者に直接指示を出してはいけないのですか
直接の細かい作業指示は、指揮命令の実態に近づくと整理されることがある。成果物や要件は発注者が伝え、個々の作業指示は委託先の責任者を通す形が無難とされる。ただし、どこまでが許される関与かは個別判断であり、心配な場合は専門家への確認を前提にしてほしい。
Q2. 再委託は禁止したほうがよいですか
一律禁止が現実的でない場合も多い。禁止より、「事前承認を前提に、再委託先を把握できるようにする」設計が現実的なことが多い。重要なのは、発注者が誰に何を任せているかを見える状態にしておくことである。
Q3. 偽装請負かどうかは発注者にも責任が及びますか
偽装請負に関する論点は、委託先だけでなく発注者側の関わり方も評価の対象になりうるとされる。だからこそ、契約の形式と実態を整合させておくことが重要になる。個別の責任の範囲については、弁護士・社会保険労務士などへの確認を前提に考えてほしい。
委託の形式と実態のずれを、発注前に整理しませんか
GXOでは、システム開発の委託にあたり、契約類型の選び方、再委託の取り決め、現場での役割分担の整理をご支援します。偽装請負や多重下請けに関わるリスクを、発注前に見える形にして進めます。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
公式・一次情報（最終確認: 2026年7月12日）
- IPA 情報システム・モデル取引・契約書: https://www.ipa.go.jp/digital/model/index.html
- デジタル庁 デジタル社会推進標準ガイドライン: https://www.digital.go.jp/resources/standard_guidelines
制度、仕様、価格、法令、脆弱性情報は改定されるため、発注・申請・対応の直前にリンク先の最新版と適用条件を再確認してください。
