「前回の発注で、納品物の品質が想定よりかなり低く、担当エンジニアも何度も入れ替わった。後から確認したら、契約相手の会社ではなく孫請けの会社が実装していた」。中堅企業の情報システム部門で発注を担当した方なら、似た経験を一度はお持ちかもしれません。
システム開発業界では、元請けが受注した案件を 1 次請け・2 次請け・孫請けへと再委託していく「多重下請け構造」が長年の慣行になっています。公正取引委員会が 2022 年に公表した実態調査でも、ソフトウェア業界における多重下請け構造の存在と、そこに起因する取引上の問題が広く指摘されています。
ここで難しいのは、発注者にとって多重下請けが「契約書に再委託禁止と書けば防げる」という単純な問題ではないことです。市場全体がこの構造で動いている以上、全面禁止は現実的でなく、かといって放置すれば品質低下・情報漏洩・コスト効率の悪化という形で必ず跳ね返ってきます。
さらに 2026 年 1 月には下請法が「取適法（中小受託取引適正化法）」へと改正・施行され、発注者側にも従来以上に踏み込んだ取引適正化の責務が課されます。多重下請けの問題は「業界構造の話」ではなく、自社の発注ルールそのものを見直すべきテーマになりました。
本記事では、発注者の立場から多重下請けが生む具体的なリスクと、見積もり依頼・契約・進行中・検収の各段階で実際に何を確認すればよいのかを、公的データと改正法の情報を踏まえて整理します。社内の発注ルール整備や次回の契約交渉の場で、そのまま使えるチェックリストとして持ち帰っていただければ幸いです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
多重下請け構造とは何か（システム開発業界の実態と発注者から見た構造）
多重下請け構造とは、発注者から仕事を受けた元請け企業が、その作業を別の会社（1 次請け）へ再委託し、さらにその会社が別の会社（2 次請け）に再委託する、という階層的な委託の連鎖を指します。システム開発業界では、この階層が 3 次・4 次にまで伸びることも珍しくありません。
多重下請け構造の基本（元請け・1次請け・2次請け・孫請けの階層と契約形態）
階層の各層には、おおまかに次のような役割分担があります。
- 元請け: 発注者と直接契約する企業。多くの場合、大手 SIer や中堅ベンダーが該当する。営業・要件定義・全体管理を担当
- 1 次請け（協力会社）: 元請けから設計・開発の一部を受託。自社エンジニアで対応するケースと、さらに下に再委託するケースがある
- 2 次請け・孫請け: 実装・テスト・運用などの実作業を担う層。中小の開発会社や個人事業主が含まれる
契約形態は、層が下がるほど「請負」から「準委任（特定の業務を時間ベースで遂行する契約）」、さらに「業務委託」や「準委任の派遣的運用」へと変化していく傾向があります。発注者が結ぶ契約は元請けとの 1 本ですが、実際に手を動かしているエンジニアは、その契約から見て 2 階層・3 階層下にいる、という構造になります。
発注者から見えにくくなる仕組み（表向きの契約相手と実作業者の乖離）
発注者にとって厄介なのは、契約書上の相手と実作業者の所属が異なっていても、それが日常のコミュニケーションでは見えづらい点です。
定例会議に出席するのは元請けの営業担当やプロジェクトマネージャー、進捗報告書のフォーマットも元請けのもの、メールアドレスも元請けのドメインで統一されている。一方で実際にコードを書いているエンジニアは、別会社の所属で、しかも数か月単位で入れ替わっている。発注者の目から見ると、何もおかしなことが起きていないように見える状態のまま、品質の責任主体が層の下へと拡散していきます。
公的データで見る業界の実態
ソフトウェア業界における多重下請けの実態は、行政の調査でも繰り返し指摘されています。
公正取引委員会が 2022 年 6 月に公表した「ソフトウェア業の下請取引等に関する実態調査報告書」では、資本金 3 億円以下のソフトウェア開発業約 2 万 1,000 社にアンケートを送付し、4,739 社（22.6%）からの回答を分析しています。この調査は ITサービス業を対象とした公取委による調査として 18 年ぶりに行われたもので、多重下請け構造の中での買いたたき・成果物の受領拒否・仕様変更への無償対応要求・中抜きといった問題が広範に存在していることが明らかにされました（出典: 公正取引委員会報道発表、2022 年 6 月 29 日）。
経済産業省や中小企業庁も、情報サービス・ソフトウェア産業に対しては独自の下請適正取引等の推進のためのガイドラインを整備しています。これは、当該業界が他業種と比べても多重下請け構造が根深く、契約・取引の適正化に向けた業界横断的な指針が必要だと国が認識していることの裏返しでもあります。
つまり、発注者が「自分の発注先で何かおかしいことが起きているのではないか」と感じる感覚は、決して気のせいではなく、業界全体に確かに存在する構造に基づいた直感だということです。
発注者が多重下請けで被る5つのリスク
多重下請け構造が発注者側にどのような実害をもたらすのか、5 つの観点で整理します。「前回の発注で起きた事象」がここのどれかに当てはまる方も多いはずです。
品質低下と責任の所在不明（バグや障害が起きても誰の責任か追跡できない）
多重下請けが進むと、品質責任が「誰の責任か」追跡できなくなります。
たとえば本番障害が発生したとき、実装したエンジニアは 3 次請けの企業に所属しており、契約上の責任主体である元請けまで情報が上がってくるのに数日かかる、ということが起こります。元請けが「2 次請けに確認します」と言い、2 次請けが「3 次請けに確認します」と言い、その間にも障害は継続している。発注者からすれば、契約相手である元請けに責任を問いたいのに、相手は実態を把握しておらず、損害賠償の交渉にも時間がかかります。
公取委のソフトウェア業実態調査報告書（2022 年）でも、成果物の受領拒否・やり直し要求・買いたたきといった行為が多重下請けの下層で発生していることが指摘されており、最終的な品質責任が曖昧になる構造が浮かび上がっています。
要件の伝言ゲーム（階層を経るたびに要件が要約・再解釈される）
要件は、階層を経るたびに翻訳・要約され、原型をとどめなくなります。
発注者 → 元請け営業 → 元請け PM → 1 次請け PM → 2 次請けリーダー → 実装エンジニア、と情報が流れる間に、「業務上のあいまいな要件」「例外ケースへの配慮」「将来の拡張性に関する含み」といったニュアンスは、ほぼ確実に失われます。実装エンジニアが受け取る指示書は、もはや発注者の意図そのものではなく、PM たちが解釈した「実装可能な仕様」になっています。
その結果、検収段階になって「これは要件と違う」「いや、仕様書通り作っている」という議論が発生し、追加コストの原因となります。
情報漏洩・セキュリティリスク（NDA の実効性が再委託先まで届かない）
機密情報・個人情報を扱う案件では、再委託先のセキュリティリスクが直接の脅威になります。
元請けと発注者の間で NDA を結んでも、その NDA が 2 次請け・3 次請けまで同等の水準で締結・運用されているかは、発注者からは見えません。実装環境（PC・ネットワーク・ソースコード管理）も、層が下がるほど統制が緩む傾向があります。
万一情報漏洩が発生した場合、発注者は元請けに損害賠償を請求することになりますが、実害は対外的な信用低下と顧客対応に直接ふりかかります。賠償金が回収できたとしても、失った信用は戻りません。
担当者の頻繁な交代と属人化（実エンジニアが顔も名前も見えない）
多重下請けの下層では、エンジニアが案件単位で短期的にアサインされるため、人の入れ替わりが頻繁に起こります。
発注者から見ると、「3 か月前まで仕様を理解していた担当者がもういない」「新しい担当者が前任の決定事項を把握していない」「同じ説明を何度も繰り返すことになる」といった状況が日常化します。これは発注側の運用負荷を大きく押し上げ、結果的にプロジェクトの進行速度を落とします。
また、運用保守フェーズに入った後で実装担当者が完全に入れ替わると、コードに対する暗黙知が失われ、軽微な修正にも本来不要な工数が積まれていきます。
中間マージンによるコスト効率の悪化（同じ予算でも実工数が目減りする）
各階層を経るごとに、営業手数料・管理費といった中間マージンが上乗せされます。
たとえば発注者がエンジニア 1 人月 100 万円で発注しても、元請けが 30% を取り、1 次請けが 20% を取り、2 次請けが 10% を取った場合、実作業を担う 3 次請けエンジニアの単価は 50 万円前後まで圧縮されます。同じ予算でも、層が深くなるほど確保できるエンジニアのスキルレベルは下がる、ということです。
公取委の調査でも、「中抜き」が下請取引上の問題として明示的に取り上げられており、決して発注者の感覚的な懸念ではなく構造的な実態として認識されています（出典: 公正取引委員会「ソフトウェア業の下請取引等に関する実態調査報告書」、2022 年）。
多重下請けはなぜ生まれるのか
多重下請け構造は、特定の企業の悪意で発生しているわけではなく、発注者側・元請け側の双方の事情と、業界の市場構造から生まれています。「相手が悪い」のではなく「構造的に起きやすい」と捉えなおすことが、契約や仕組みで対処する第一歩です。
発注者側の要因（丸投げ志向・大手偏重・IT 専門人材の不在）
発注者側の主な要因は次の 3 つです。
- 丸投げ志向: 社内に IT 専門人材がいないため、要件定義から運用まで「丸ごとお願いしたい」というニーズが先に立つ。結果、元請けに過大な範囲を委ねることになる
- 大手 SIer 偏重: 「大手なら安心」という調達基準が今も根強く、自社で完結する規模感の中堅企業ではなく、再委託前提の大手に発注が集中する
- IT 専門人材の不在: 体制図や工数内訳を見ても「これが妥当かどうか判断できない」ため、提示された見積もりをそのまま受け入れざるを得ない
元請け側の要因（リソース不足・専門領域の分散・繁忙期対応）
元請け側にも、再委託を選ぶ合理的な理由があります。
- 自社リソースの恒常的な不足: 受注した全案件を自社エンジニアだけでこなせる元請けは少数派。技術者の採用は難航しており、繁忙期は外部リソースで吸収せざるを得ない
- 専門領域の分散: クラウド・モバイル・データ分析・組み込みなど、求められる技術スタックが多様化し、すべてを自社内に揃えるのが現実的でない
- 繁忙期の調整弁: 案件量は季節や年度末に偏在しがちで、固定費を抑えるためにも外部委託が選ばれやすい
業界慣行としての中間マージン（多段階契約が前提となっている市場構造）
加えて、業界全体として「多段階契約を前提に値付けする」慣行が長年定着しています。元請けは中間マージンを織り込んだ上で発注者に見積もりを提示し、下層の企業もその構造を前提に営業活動を行っています。この慣行は短期的には変わりにくく、発注者個別の交渉だけで解消するのは現実的ではありません。
ここまでを踏まえると、発注者がとるべき姿勢は「多重下請けを完全に排除する」ではなく、「自分の発注先で実態を可視化し、契約と監視で統制下に置く」という方向に切り替わります。次章以降では、その具体的な方法を発注フェーズ別に整理します。
発注段階で多重下請けを見抜く5つのチェックポイント
ここからは検索者が最も知りたい実務パートです。RFP（提案依頼書）の提示や初回商談・見積もり依頼の段階で、発注者が確認しておくべき 5 つのポイントを示します。
体制図と実作業者の所属を確認する
提案書に「体制図」が含まれていることは多いものの、多くの場合は役職と人数のみが書かれ、各メンバーの所属企業が明記されていません。
発注者から「体制図に各メンバーの所属企業を明記してほしい」と要求するだけで、再委託の有無は一気に可視化されます。提案する側にとっては記載が増える手間ですが、健全な企業であれば応じてくれます。逆に「個別の所属はお答えできません」と返ってくる場合、その時点で何かしらの再委託前提があると考えてよいでしょう。
自社エンジニア比率と再委託前提を質問する
「本案件に参画するエンジニアのうち、貴社の正社員（または常駐するパートナー）は何割でしょうか」と直接尋ねるアプローチです。
100% 自社対応とまで言える企業は限られますが、「自社 7 割・協力会社 3 割」「自社 3 割・協力会社 7 割」では、品質統制のしやすさが大きく異なります。あわせて「協力会社の選定基準と契約形態」「協力会社のエンジニアが定例会議に参加できるか」を質問することで、再委託の運用実態がさらに具体的に見えてきます。
過去案件の再委託実績を具体的に聞く
将来の話だけでは判断が難しいため、過去案件での再委託実績を質問します。
「直近 3 年で実施した類似規模の案件で、再委託を行ったケースの割合はどの程度ですか」「再委託を行った案件で、発注者にはどのタイミングで報告していましたか」といった問いかけです。回答の歯切れの良さ、具体性、過去案件への自信が、相手の透明性の度合いを測る材料になります。
見積もりの工数内訳と単価から中抜きを見抜く
見積書には「設計 〇人月」「実装 〇人月」のような工数情報が記載されていますが、単価レンジまで開示されていることは少ないものです。
「役割別の単価レンジを開示してほしい」と依頼し、提示された単価が業界相場（一般的にプロジェクトマネージャー 120〜180 万円/月、シニアエンジニア 80〜130 万円/月程度）と比較して不自然に高いのに、提示される人材のスキル感がそれに見合わない場合は、中間マージンが厚く乗っている可能性があります。逆に単価が極端に安い場合は、深い層の下請けにしわ寄せが行く設計になっていることが疑われます。
キーパーソンに直接会えるかで判断する
最後のチェックポイントは、契約前に「実際に手を動かす中心メンバー（テックリードや主要エンジニア）に会えるか」を確認することです。
営業担当や PM だけでなく、実装の中核を担う人物に会えるかどうかで、その人物が本当に自社所属なのか、そして発注者側との接点を持つ意思がある体制なのかが分かります。「実エンジニアは案件開始後にアサインされるためお見せできない」という回答が返ってきた場合、その時点で実態は不透明だと考えるのが安全です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
契約書で押さえるべき再委託・多重下請け制限条項
事前のチェックで体制を見抜いた次は、契約書での担保です。「再委託禁止」と一行書いて終わりにするのではなく、実務的に運用可能な条項として落とし込みます。なお、ここで紹介する内容はあくまで方向性の整理であり、実際の条文設計は弁護士・法務担当のレビューを必ず経る前提とお考えください。
再委託の事前書面承諾制（全面禁止ではなく統制下に置く）
ソフトウェア開発の実務上、再委託を完全禁止すると元請け側が受託できないケースが多く、結果として発注先の候補が極端に狭まります。現実的な落とし所は、「再委託は原則禁止とし、発注者の事前書面承諾を得た場合に限り認める」 とする条項です。
事前承諾を求める時点で、元請けは「誰に、どの範囲を、なぜ再委託するのか」を発注者に開示せざるを得なくなります。これだけでも、見えないところで孫請け・ひ孫請けへ流れる事態は大幅に抑えられます。
再委託先の管理責任とセキュリティ担保
再委託を認める条項とセットで、「再委託先の行為について元請けが発注者に対し全責任を負う」 ことを明示します。
加えて、再委託先に対して同等水準の秘密保持義務・セキュリティ管理体制・個人情報保護義務を課すことを契約上の義務として明記します。実務的には、元請けと再委託先の間で締結する個別契約のひな型を発注者が事前確認できる旨を盛り込むケースもあります。
再々委託禁止条項で連鎖を断つ
多重下請けを抑える上で、もっとも効果的なのが 「再々委託（再委託先からのさらなる委託）を原則禁止する」 条項です。
再委託 1 段までは現実的に受け入れざるを得ない場合でも、ここで連鎖を断ち切ることで、3 次請け・4 次請けに作業が流れる構造そのものを契約上ブロックできます。発注者から見える階層が「元請け + 再委託先 1 社」までに限定されるだけで、コミュニケーション・品質・セキュリティの統制は大きく改善します。
違反時の解除権・損害賠償の規定
事前承諾なしの再委託や、再々委託禁止条項違反が発覚した場合の、契約解除権・損害賠償請求権を明示します。
「違反があれば即時解除可能」「違反に起因する損害について元請けは全額賠償の責を負う」といった条項を入れておくことで、抑止力になります。同時に、検収不合格時のやり直し対応・成果物の権利帰属・瑕疵担保責任といった一般的なリスク管理条項とも整合させる必要があります。契約全体の設計については、システム開発の損害賠償・リスク管理ガイドもあわせて参考になります。
請負と準委任で異なる再委託の扱い
最後に、契約形態による違いに触れておきます。
- 請負契約: 民法上、原則として再委託は受託者の裁量で可能とされている。発注者が再委託を制限したい場合は、契約書に明示的な禁止・承諾制条項を入れる必要がある
- 準委任契約: 委任の性質上、原則として再委任には委任者の承諾が必要（民法 644 条の 2）。ただし実務上は契約書で明示しておくほうが争いを避けられる
つまり、どちらの契約形態を選ぶにせよ、契約書本文での再委託統制の明文化は欠かせません。発注時の契約形態・条項設計の全体像については、システム開発の契約書｜発注者が確認すべき7条項と交渉アクションが参考になります。
発注後の進行中に多重下請けを監視する方法
契約を結んだ後にも、運用フェーズで多重下請けが発生したり拡大したりする余地は残ります。発注者主体で監視するためのポイントを整理します。
定例会議に実エンジニアの参加を求める
最も効果的な監視策は、定例会議に実装の中心メンバーを参加させることです。
営業担当や PM だけが出席する会議では、現場の状況も実作業者の所属も見えません。「実装上の論点は実装責任者から直接説明してほしい」と要求し、毎回同じメンバーが参加するか、入れ替わりが頻繁すぎないかを観察します。エンジニア本人の所属企業を会議の冒頭で確認するだけでも、契約相手と実作業者の乖離を継続的にチェックできます。
進捗報告書で担当者を可視化する
週次・月次の進捗報告書のフォーマットに、「各タスクの担当者名と所属企業」 を必須項目として組み込みます。
最初は元請けが抵抗を示すケースもありますが、契約に明記しておけば運用上の標準にできます。担当者一覧が更新されるたびに、入れ替わりの頻度・新規アサインされる人物の所属を確認することで、再委託状況の変化が定量的に追えるようになります。
体制変更時の事前承認ルール
プロジェクト途中で体制変更が発生する際、事前に発注者の承認を得ることをルール化します。
「エンジニア 1 名のアサイン変更も事前承認が必要」と一律で運用するのは現実的でないため、「キーパーソン（テックリード、PM）の交代は事前承認必須」「実装メンバーの交代は事後 1 週間以内の報告」というように、影響度別に承認ルールを分けるのが実務的です。発注先とのコミュニケーションを継続的に円滑にするための観点は、開発会社への外注コミュニケーション方法もあわせてご覧ください。
違反を検知した時の対応フロー
監視の結果、契約違反（無承諾の再委託・再々委託の発生など）を検知した場合の対応フローを、事前に社内で決めておきます。
- 事実関係の確認: まず元請けに事実確認の照会を行い、書面で回答を求める。再委託先の特定、契約形態、開始時期を明らかにする
- 是正要求: 違反の事実が確認できた場合、是正要求を書面で発出する（承諾申請の遡及提出 / 体制変更 / 損害の補填など）
- 契約解除の判断: 是正に応じない場合や、損害が現実化している場合は、契約解除・損害賠償請求の検討に進む
「いきなり解除」ではなく、段階を踏んだ対応フローを準備しておくことで、社内稟議・法務との連携もスムーズになります。
2026 年施行「取適法」改正で発注者の責務はどう変わるか
ここまで紹介したチェックリスト・契約条項・監視ルールは、企業間の取引適正化を求める法制度のアップデートによって、ますます重要性を増しています。2026 年 1 月施行の「取適法」改正の概要を整理しておきます。
取適法とは（2026 年 1 月施行の概要）
「取適法」は正式には「中小受託取引適正化法」と呼ばれ、従来の下請法を発展的に改正した法律です。2026 年 1 月 1 日に施行されます（出典: 公正取引委員会リーフレット「2026 年 1 月から『下請法』は『取適法』へ！」）。
法律の目的は、委託取引における不公正な取引慣行を是正し、受託側（中小事業者）の保護を強化することです。多重下請け構造の中で発生していた買いたたき・支払遅延・受領拒否・やり直し要求といった問題が、規制対象として整理されています。
規制対象の拡大（資本金 + 従業員数基準）
最大の改正ポイントは、規制対象を判定する基準の拡大です。
従来の下請法は「資本金」基準のみで親事業者・下請事業者の関係を判定していました。改正後の取適法では、資本金基準に加えて 「従業員数基準」 が新設されます。従業員数基準は委託の区分によって閾値が異なり、製造委託・修理委託等の場合は従業員 300 人超、役務提供委託等（情報サービス・ソフトウェア産業の業務委託はこちらに該当）の場合は従業員 100 人超 が基準とされています（具体的な最新数値は公取委・中小企業庁の最新ガイダンスをご確認ください）。
これにより、たとえば資本金は小さくても従業員数が多い IT 企業が、これまで規制対象外だった取引について新たに「委託事業者」としての責務を負うケースが出てきます。発注者として、自社が委託事業者となる取引については、買いたたきの禁止・支払遅延の防止・不当な減額の禁止といった義務に対応する必要があります。
発注者の義務と禁止行為（買いたたき・遅延・不当な減額等）
取適法では、委託事業者（発注者）に対し、以下のような禁止行為が明示されています。
- 著しく低い価格を不当に定めること（買いたたき）
- 支払期日内に代金を支払わないこと（支払遅延）
- 受領後の不当な減額・返品
- 受領拒否・不当なやり直し要求
- 強制購入・利益提供の要請
これらは多重下請け構造の中で発生していた典型的な問題であり、取適法はそれらに直接対応する形で禁止規定を整備しています。発注者が自社の発注ルールを取適法対応に揃えることは、結果として「下請の下請」へ不当なしわ寄せが行く構造を抑える効果も持ちます。
情報サービス・ソフトウェア産業向けガイドラインの活用
中小企業庁は、情報サービス・ソフトウェア産業向けに 下請適正取引等の推進のためのガイドライン を公表しており、契約書ひな型・再委託に関するルール・支払条件の標準などが整理されています。
取適法改正にあわせて、こうした業種別ガイドラインも参照しながら自社の発注プロセス・契約書ひな型をアップデートしておくことは、法令リスクの低減と、発注品質の向上の両面で有効です。
多重下請けに陥らない発注先の選び方
最後に、リスクを後手で塞ぐのではなく、構造的に多重下請けが起きにくい発注先を選ぶ視点で整理します。「こういうタイプの会社もある」という選択肢の紹介として読んでください。
自社エンジニア中心の小規模・中堅開発会社
自社エンジニアの比率が高い小規模〜中堅の開発会社は、構造的に多重下請けに陥りにくい選択肢です。
社員数が数十名〜百数十名規模で、案件のほぼ全工程を自社内で完結する会社では、契約相手と実作業者が一致するため、コミュニケーションコスト・品質統制・セキュリティ管理のすべてで透明性が高くなります。一方で繁忙期や大規模案件への対応力は限定されるため、発注の規模感とのマッチングは事前に確認が必要です。
上流から下流まで一気通貫の体制
要件定義・設計・実装・テスト・運用までを一気通貫で担う中堅・準大手の開発会社も選択肢の一つです。
複数フェーズを社内で抱えているため、フェーズ間の引き継ぎロスが小さく、再委託の頻度も大手 SIer 比べると低い傾向があります。発注先選びの一般的な観点については、SIerとベンダーの違いとは？種類・特徴・発注先の選び方もあわせて参考になります。
構想段階から伴走するパートナー型の開発会社
要件が固まっていない構想段階から発注者と一緒に考えていくパートナー型の開発会社も、近年増えています。
このタイプの会社は、要件定義から発注者と密に対話することで、後工程での認識齟齬を最小化することを重視しています。結果として、外部への再委託でカバーするよりも自社内で一貫対応する方が品質コントロールしやすい、という発想に立ちます。秋霜堂株式会社が運営する TechBand も、こうした構想段階からの伴走と少人数体制でのプロジェクト推進を志向するタイプの選択肢の一つです。
フリーランス・複業人材を活用するハイブリッド型
近年は、自社エンジニアに加えて信頼関係のあるフリーランス・複業人材を組み合わせるハイブリッド型の開発会社も増えています。
「下請け」ではなく「個別契約のプロフェッショナルパートナー」として、案件単位で必要なスキルセットを柔軟に組み合わせる形態です。多層構造ではなく一層のパートナーシップで案件を構成するため、発注者から見て体制が透明になりやすいというメリットがあります。一方で、契約形態・指揮命令系統・成果物の権利帰属など、運用ルールが従来の請負・準委任とは少し異なるため、契約段階での確認が必要です。なお、ベンダー固定によるリスクを避ける発想については、ベンダーロックインとは？発注者が知るべきリスクと回避策もあわせてご参照ください。
まとめ
最後に、本記事の内容を発注フェーズ別のチェックリストとして整理します。社内の発注ルール整備・契約書レビュー・進行中のレビュー会議で、そのまま流用できる形になっています。
見積もり・提案依頼の段階
- 体制図に各メンバーの所属企業を明記してもらう
- 自社エンジニア比率を質問する（協力会社含めた構成を確認）
- 過去案件での再委託実績を具体的に確認する
- 見積もりの単価レンジを開示してもらい、中抜きの兆候を見抜く
- 実装の中心メンバー（テックリード等）と契約前に面談する
契約締結の段階
- 再委託は原則禁止、事前書面承諾制を盛り込む
- 再委託先に対する元請けの全面的な管理責任を明記する
- 再々委託の禁止条項で連鎖を断つ
- 違反時の契約解除権・損害賠償の規定を明示する
- 請負・準委任の契約形態に応じた再委託条項の整合を確認する
開発進行中の段階
- 定例会議に実装の中心メンバーを参加させる
- 進捗報告書で担当者名・所属企業を可視化する
- キーパーソンの体制変更には事前承認制を適用する
- 違反検知時の対応フロー（事実確認 → 是正要求 → 契約解除判断）を社内で整備する
法令対応の段階
- 2026 年 1 月施行の取適法に自社の発注ルール・契約書ひな型を対応させる
- 中小企業庁の業種別ガイドラインを参照し、買いたたき・支払遅延等を回避する
- 自社が「委託事業者」に該当する場合の責務を法務と共有しておく
多重下請けの問題は、業界構造に深く根ざしているため、一度の発注で完全に解決することは難しい性質を持っています。ただし、発注フェーズごとに「何を見て、何を要求し、どう監視するか」を社内で標準化しておけば、次の発注からは大きな失敗を確実に避けることができます。本記事のチェックリストが、次回の発注ルールづくり・契約交渉の場面で、少しでも実務の支えになれば幸いです。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
