会社情報
採用情報
お問い合わせ
Article

SESと派遣・受託の違いを徹底比較：開発人材調達モデルはどれを選ぶべき？

高田晃太郎
SESと派遣・受託の違いを徹底比較：開発人材調達モデルはどれを選ぶべき？

経済産業省の推計では2030年に最大79万人のIT人材が不足するとされ、外部リソース活用（IT人材調達）は多くの開発組織で戦略の中核になっています¹。一方で、現場ではSES、派遣、受託開発の違いを十分に理解しないまま選定が進み、契約形態と運用が噛み合わずにコスト超過や品質劣化、法務リスク（偽装請負など）が顕在化する例が後を絶ちません。CTO視点では、モデルの選択は単価比較だけでは解けません。法的な枠組み（準委任契約・請負契約・労働者派遣法）、指揮命令の線引き、知財帰属、期待価値と総所有コスト（TCO）のバランスを同時に設計して初めて最適化できます。この記事では、SESと派遣・受託の違いを現実の運用でどう使い分けるかに焦点を当て、CTOやエンジニアリングマネージャーがすぐ判断に使える解像度で整理します。

定義と法的枠組みの違いをまず正しく固定する

SESは準委任契約（仕事の完成ではなく「一定の作業を遂行すること」への対価）を典型とする時間対価モデルで、成果物の完成責任は負いません。一方、開発の進め方や実装手段の選択など、業務遂行に必要な技術的裁量は供給側にあります。現場での指示が発注側から細かく及ぶと疑似的な指揮命令になりやすく、偽装請負のリスクに接近します⁵⁴。派遣は労働者派遣法の対象で、派遣先（発注側）の指揮命令下で就労します²。契約は派遣元と派遣先の間で結ばれ、雇用関係は派遣元にあります。受託（請負契約）は成果物の完成責任を受託側が負い、発注側は具体的な指揮命令を行いません。進め方や体制は受託側が自律的に設計し、検収により成果物を引き渡します³。実務では「誰が何を決めるか（指揮命令）」と「誰がどこまで責任を負うか（完成責任）」を混同しないことが、後工程のコストを大きく左右します。

指揮命令と責任の線引きが運用コストを決める

現場で発生するコストの多くは、意思決定権と責任の不明確さから生まれます。SESで発注側が日々のタスクを直接指示する運用は疑似派遣となりうるため⁶、実務では「受入側の成果定義（何をもってDoneか）」を粒度高く記述し、レビューと優先順位づけは発注側、実装の手段選定は供給側、と権限分界を契約書・運用ガイドの両方に言語化しておくのが現実的です。例えば「バックログは発注側が週次で優先順位づけ、技術選定・設計詳細は供給側が提案し、PRレビューは発注側のコードオーナーが承認」という役割分担にすると、疑似派遣を避けながらスピードも担保できます。派遣は指揮命令が前提のためオンボーディングは迅速ですが、アーキテクチャなどの技術的意思決定まで委ねると属人化リスクが増し、監督コストが跳ね上がります。受託は完成責任が明確で管理の可視性は高い一方、要求変更が多い環境だと変更管理（CR: Change Request）にかかるトランザクションコストが重くなります。ここでの要点は、モデルごとのメリット・デメリットを理解し、現場の変動性と意思決定能力に合わせて線引きを設計することです。

知財・成果物の帰属は契約で先回りする

成果物の著作権は原始的には作成者に帰属します⁷。派遣の場合、職務著作の要件を満たせば雇用者である派遣元に帰属する可能性があるため⁸、発注企業に譲渡・許諾される旨を契約と就業条件で二重に明記し、オープンソースの利用範囲やライセンス遵守（OSSコンプライアンス）もセットで管理するのが安全です。SESでも同様に、成果物の権利処理を準委任の付随条項で明確化します。受託は契約で権利移転と保証のスコープを定めやすく、第三者知的財産の混入保証やSBoM（Software Bill of Materials: ソフトウェア部品表）の提出を義務化すれば、将来の監査コストを抑えられます⁹。実務では「コード、ドキュメント、テスト資産、設計成果」の帰属・ライセンス・再利用可否を品目ごとに明文化しておくと、受け渡し時の齟齬を避けられます。

コスト・スピード・品質を数値で直視する

都市圏の開発領域でSESの人月単価はおおむね80〜120万円のレンジに分布し、専門性が高い領域では140万円超も珍しくありません¹⁰。派遣は時給単価での見積もりが一般的で¹¹、3500〜6000円台が多く、フルタイム換算で人月60〜100万円相当になることが多い印象です。受託は固定価格か準委任のハイブリッドが増えており、PM費や品質保証費まで含めた実効単価は人月110〜180万円相当まで広がります。スピードの観点では、派遣は職種が合えば1〜3週間で着任、SESはスキルマッチングに2〜6週間、受託は要件確定と体制構築に4〜12週間を見込むのが現実的です。検索されやすい観点で言えば、「SESと派遣の費用相場の違い」「受託開発の見積もりの考え方」を数値で把握しておくことが、初期判断の精度を上げます。

品質は単価よりも決定権とレビューの設計に強く相関します。アーキテクチャの意思決定を発注側が保持し、コードオーナーシップを自社に集約する運用は、モデルを問わず欠陥密度とリードタイムの安定に効きます。逆に、方針が空白のまま供給側に丸投げすると、受託でもSESでも品質は揺れ、再作業コストが増幅します。現実的な策は、スプリント単位の受入基準（例：SLI/SLOやテストカバレッジ、パフォーマンス閾値）を計測可能に定義し、レビュー責務を二重化しないことです。これらはDORAレポートでも、リードタイムや変更失敗率に影響する主要プラクティスとして示されています¹²。

単価比較の罠を避け、TCOで語る

判断は常に総所有コスト（TCO）で行います。TCOはおおざっぱに、外部費用に加えて、要件定義と受入の内製工数、コミュニケーション損失、知識の持ち帰り率を含めて見積もります。例えば、機能Aの市場投入繰り上げで月間300万円の追加売上が期待できるなら、2カ月前倒しできるモデルの期待価値は600万円です。これに対して、外部費用400万円、内製受入工数80時間（時給8000円換算で64万円）、コミュニケーション損失10%を見込むと、期待純価値はおよそ600−(400+64)×1.1で約76万円となります。単価が高くても前倒し効果が大きければ採算が合い、単価が低くても受入コストが膨らめば赤字化する。この当たり前を数字で確かめることが、「SESと派遣・受託のどれを選ぶべきか」の一番の近道です。

ナレッジ蓄積率が中長期の差になる

外部を使うほど、仕様と暗黙知をどう社内に残すかがリターンを左右します。派遣は就業終了とともにナレッジ流出の確率が高く、延長を重ねるほど依存リスクが高まります。SESは供給側の裁量を活かして設計改善に寄与してもらえる反面、業務委託先のベストプラクティスが優先されやすい。受託は成果物ドキュメントやテスト資産を体系化しやすいので、引継ぎ要件を契約の納品物に組み込めば持ち帰り率を高められます。実務では「ドキュメントの粒度（例：ADRとAPIスキーマの更新必須）」「コードレビューへの発注側参加率（例：80%以上）」「社内メンター配置（例：週4時間のレビュー/質疑窓口）」を仕組みに埋め込み、ナレッジ残存率を追跡する発想が要諦です。

現場の3シナリオで選び方を具体化する

新規機能のPoCを3カ月で形にする

仮説検証が主目的で、要件は変動し、将来の捨てやすさも許容できる場面では、強い個人に賭けられるSESが噛み合います。発注側がバックログの優先順位と受入基準だけを握り、アーキの最小原則（例：単一リポジトリ、DBは1種、監視は既存のスタックへ統一）と非機能要件を明記し、実装詳細は委ねます。オンボーディングに時間がかかるなら、派遣でプロダクト理解の速い人材を短期で迎え、技術的骨格は内製側で決める混成も現実的です。受託でやるなら、変化幅に合わせて準委任を多めにし、固定価格は「デモ可能な小さな塊（例：主要ユーザーフローのE2Eが通る）」に限定すると失敗確率が下がります。実務の目安として、週次デモ、2週間スプリント、受入基準は「主要KPIの仮説が検証可能か」を軸にします。

基幹刷新で長期の品質と責任を担保する

複数システムに跨る依存関係、可用性SLO、規制対応が絡む刷新なら、完成責任を持てる受託のアカウンタビリティが効きます。アーキレビューと移行計画、性能試験と回帰自動化、運用引継ぎを納品物として固定し、変更はCRプロセスで折衝します。並行して、内製チームをSESで厚くし、受託側のノウハウをスプリントレビューやペア設計に乗せて移植します。派遣は運用設計やデータ移行の大量作業の平準化に適し、統制の効いた手順書と品質ゲートのもとで威力を発揮します。典型的な進め方は「受託で基盤・移行の完成責任＋SESで内製側の設計力を強化＋派遣で運用・移行のピーク平準化」という三層構成です。各層のSLO/SLA、検収基準、エスカレーション経路を最初に合意しておくと、品質とスケジュールを両立できます。

プロダクトの性能・信頼性を短期で改善する

レイテンシの劣化やエラー率の上昇に迅速に手を打つには、SREやパフォーマンスエンジニアの希少スキルを持つ人材をピンポイントで投入するのが効果的です。この領域は単価が高くても、ダウンタイムコストや機会損失が大きいので採算が合いやすい。コアとなるボトルネック特定とアーキ再設計をSESに託し、派遣で運用改善の実装・定常運用の自動化を平行稼働させる構成は、2〜4週間で体感できる改善を出しやすいアプローチです。受託を選ぶなら、性能目標をSLOで数値化し（例：p95レイテンシ300ms以下、エラー率0.2%未満）、検収条件に負荷試験の閾値と回帰基準を入れておくと、期待がぶれません。

意思決定フレームと契約実務の要点

モデル選定は六つの問いに置き換えると整理が進みます。成果責任を誰が持つのか、要件の変動はどれほどか、投入までのリードタイムにどれだけ価値があるか、知財とナレッジをどこに残すのか、内部の監督能力は十分か、そして解約・縮退の柔軟性をどれほど確保したいのか。これらを案件ごとに数値で埋めると、感覚論から離脱できます。例えば、変動が大きく価値の減衰が速いなら時間対価モデル（SES/派遣）に寄せ、変動が小さく検収の客観性が高いなら完成責任モデル（受託）が有利に働きます。検索ニーズの高い「SESと派遣の違い」「受託開発のメリット・デメリット」は、この六つの問いで自然に答えが出ます。

契約の実務では、SESは成果物の権利、セキュリティ遵守、優先順位づけの手続、交代時の引継ぎ要件を明文化し、疑似派遣（偽装請負）を避ける働き方を運用設計に落とし込みます⁶。派遣は就業条件と守秘、著作権の譲渡・許諾、サブタスクの範囲、時間外の扱いを明確にし、日次の業務指示は記録に残します²。受託は検収基準、変更管理、品質保証の範囲、第三者権利不侵害の保証、SBoMや脆弱性対応のSLAまで踏み込み、移行と教育を納品物に含めます⁹。どのモデルでも、成果の受入をする内製側の責務と時間（レビュー、E2E検証、運用受入）を先に確保することが、コストと品質の両立には不可欠です。

最後に、ベンダーマネジメントは数字で回します。契約種別に関わらず、リードタイム、欠員率、受入不合格率、再作業比率、ナレッジ残存率、そしてビジネスKPIへの寄与を継続計測し、四半期ごとに配分を見直すと、調達ポートフォリオは自然と最適化されます。単価交渉に偏らず、期待価値とTCOの差分で会話するのが、関係を建設的に保つコツです。

まとめ：最適解は毎期変わる、だから見える化して選ぶ

人材調達の最適解は固定化できません。市場とプロダクトのフェーズ、チームの成熟度が変われば、同じ案件でも選ぶべきモデルは変わります。大切なのは、指揮命令と責任の線引きを明確にし、価値の前倒し効果と受入コストを数字で比較し、ナレッジが社内に残る設計にすることです。今日の案件で一度フレームを当て、仮説のポートフォリオを組んでみてください。小さく試し、計測し、配分を変える。あなたの組織にとっての最適なSES・派遣・受託の配合比は、その反復の先に見えてきます。まずは直近のプロジェクトで、着任リードタイム、受入工数、期待価値の三つを見える化するところから始めてみませんか。

参考文献

  1. NTTコミュニケーションズ（ドコモビジネスWatch）. 2030年にIT人材が最大79万人不足するとの経産省推計の紹介. https://www.ntt.com/bizon/d/00491.html
  2. 厚生労働省. 労働者派遣事業について（定義等）. https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/roudoushahakennjigyou.html
  3. e-Gov法令検索. 民法 第632条（請負）ほか. https://elaws.e-gov.go.jp/document?lawid=129AC0000000089
  4. e-Gov法令検索. 民法 第643条〜（委任）・第656条（準委任）. https://elaws.e-gov.go.jp/document?lawid=129AC0000000089
  5. ビジネスロイヤーズ（弁護士ドットコム）. 請負・準委任（SES）・派遣の違いの解説記事. https://www.businesslawyers.jp/articles/753
  6. ビジネスロイヤーズ（弁護士ドットコム）. 偽装請負の不正類型と関連規制・罰則. https://www.businesslawyers.jp/articles/753
  7. e-Gov法令検索. 著作権法 第17条（著作権の帰属）. https://elaws.e-gov.go.jp/document?lawid=345AC0000000048
  8. e-Gov法令検索. 著作権法 第15条（職務著作）. https://elaws.e-gov.go.jp/document?lawid=345AC0000000048
  9. CISA. Software Bill of Materials（SBOM）Resources. https://www.cisa.gov/sbom
  10. レバテック（Levtech）. SESの費用相場（目安）. https://levtech.jp/partner/guide/article/detail/83/
  11. スタッフサービス. SESと派遣の違いについての解説. https://www.staffservice.co.jp/client/contents/knowledge/column158.html
  12. Google Cloud DORA. Accelerate State of DevOps Report. https://cloud.google.com/devops/state-of-devops