SES（常駐）と受託開発はどちらが向く？｜要件の曖昧さ別の選び方
目次 クリックで開く
システム開発を外部に依頼する際、多くの企業担当者が直面するのが「SES（システム・エンジニアリング・サービス）による常駐」と「受託開発（請負）」のどちらを選ぶべきかという問題です。
特に「まだ要件がふわっとしている」「どこまで作るか決まっていない」という状況では、契約形態の選択ミスが、予算の膨張やプロジェクトの頓挫、さらには法的なリスクを招くことになります。本記事では、IT実務者の視点から、要件の曖昧さを軸にした選び方の基準と、それぞれのメリット・デメリットを徹底的に解説します。
1. SES（常駐）と受託開発の決定的な違い
まずは、両者の契約的な性質を正しく理解する必要があります。ここを混同すると、現場でのトラブルが不可避となります。
受託開発（請負契約）：「完成」に対して対価を支払う
受託開発の多くは「請負契約」です。受託側は「システムの完成」を約束し、発注側は「成果物の納品」に対して対価を支払います。仕様が明確であれば、予算の変動が少なく、品質保証（契約不適合責任）も求めやすいため、確実性を重視する場合に適しています。
SES（準委任契約）：「善管注意義務」に対して対価を支払う
一方、SESは一般的に「準委任契約」です。こちらは「完成」を保証するものではなく、エンジニアが「専門家として適切に業務を遂行すること」に対して対価を支払います。時間の切り売り（工数提供）に近い性質を持つため、仕様変更が頻発する現場に向いています。
2. 要件の曖昧さ別・最適な選び方
プロジェクトの成功可否は、契約形態が「要件の固まり具合」と合致しているかどうかで決まります。
【要件定義済み】仕様が明確なら「受託開発」
「既存のExcel業務をそのままシステム化したい」「基幹システムのデータを抽出してBIツールで見たい」といった、ゴールが数値やフローで明確に定義できる場合は、受託開発が最適です。受託側が見積もりを出しやすく、工数超過のリスクは受託側が負うため、コストパフォーマンスが高くなります。
例えば、経理業務のデジタル化において、すでに業務フローが整理されている場合は、受託形式で一気に構築するのが効率的です。あわせて、
freee会計導入マニュアル｜旧ソフト移行ガイド
などを参考に、ツール側の仕様に業務を寄せる（Fit to Standard）ことで、開発コスト自体を抑えることも可能です。
【要件が流動的】作りながら考えるなら「SES（準委任）」
「新規事業のMVP（最小機能版）をリリースし、ユーザーの反応を見ながら改善したい」「社内のDXを進めたいが、現場の要望が二転三転しそう」という場合は、SESによる常駐や工数提供型が向いています。受託開発で要件変更を繰り返すと、その都度「追加見積もり」が発生し、結果として割高になるだけでなく、スピード感が失われます。
要件の解像度チェックリスト
以下の項目に「いいえ」が多い場合は、受託開発ではなくSESまたは伴走型のコンサルティングを検討すべきです。
- 全ての画面遷移図と画面項目定義が揃っているか？
- 外部システムとの連携仕様（APIドキュメント等）が確定しているか？
- 非機能要件（同時アクセス数、セキュリティ基準）が合意されているか？
- 開発期間中に大きな組織変更や業務変更の予定がないか？
3. コストと品質の徹底比較
実名的な業態やサービスモデルを想定した比較を以下の表にまとめました。
| 比較項目 | 受託開発（請負） | SES（準委任） |
|---|---|---|
| 成果物の責任 | 完成義務・契約不適合責任あり | 完成義務なし（善良な管理者の注意義務） |
| 指揮命令権 | 受託会社が自社エンジニアへ行う | SES企業が自社エンジニアへ行う（客先指示はNG） |
| コスト構造 | プロジェクトごとの一括払い | 月額：80万円〜150万円程度/名（単価×人数） |
| 主な利用シーン | 基幹システム、定型のWebアプリ | 大規模開発の増員、保守運用、R&D |
| 代表的な企業形態例 | SIer、制作会社、パッケージベンダー | エンジニア派遣会社、技術支援ベンダー |
特にコスト面で見落としがちなのが「管理コスト」です。受託開発は「丸投げ」ができると思われがちですが、検収（納品物の確認）には発注側にも高いリテラシーが求められます。逆にSESは、現場のエンジニアと密なコミュニケーションが取れる一方、指示系統を誤ると「偽装請負」というコンプライアンス違反に繋がります。
4. 実務上の注意点と法的リスク
IT実務担当者が最も警戒すべきは、契約と実態の乖離です。
偽装請負の回避
SES（準委任）でエンジニアを自社に受け入れる際、自社の社員が直接「明日の朝までにこの機能を修正しておいて」と指示を出すことは法律（労働者派遣法・職業安定法）で禁止されています。指示は必ず、SES企業の責任者（リーダー）を通じて行わなければなりません。
セキュリティとアカウント管理
常駐案件で頻発するのが、契約終了後のアクセス権限削除漏れです。
SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ
で解説されているような、ID管理（IdP）の仕組みがない場合、スプレッドシート等で手動管理を行うことになりますが、外部パートナーが関わるプロジェクトでは、この管理負荷が非常に高くなります。契約開始時に「どのアカウントに、どの権限を付与し、いつ削除するか」のプロトコルを確定させることが実務上の鉄則です。
5. 導入・運用のステップバイステップ
失敗しないための具体的な導入手順を解説します。
ステップ1：現状の要件定義レベルを測定する
まずは自社の要望が「要件」としてドキュメント化されているか確認します。
もし、ビジネス要求（やりたいこと）はあるが、技術的な仕様（どう作るか）が不明確な場合は、いきなり受託開発の見積もりを取ってはいけません。不確実性リスクを乗せられた高い見積もりが出るか、安く受けて後にトラブルになるかの二択です。
ステップ2：RFP（提案依頼書）の作成
受託かSESかに関わらず、RFPは必須です。特にデータ連携が絡む場合、
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』
のような全体俯瞰図を提示できると、ベンダー側も正確な見積もり・アサインが可能になります。
「何を作ってほしいか」だけでなく「なぜ作りたいか（背景）」を共有することで、準委任契約であってもエンジニアのコミットメントが高まります。
ステップ3：契約書のリーガルチェックポイント
以下の条項が自社に不利になっていないか確認してください。
- 受託の場合：検収期間が短すぎないか（通常1〜2週間）、契約不適合責任の期間（通常6ヶ月〜1年）。
- SESの場合：再委託の可否（再委託の再委託といった多重構造になっていないか）、中途解約の通知期間（1ヶ月前通知が一般的）。
よくあるエラーと対処法
エラー1：受託開発で「あれもこれも」と追加要望を出してしまう
対処：チェンジコントロールボード（変更管理委員会）を設置し、追加費用とスケジュールへの影響を可視化する仕組みを契約に盛り込む。
エラー2：SESで優秀なエンジニアがアサインされない
対処：スキルシート（経歴書）の確認だけでなく、必ず面談（事前面談は派遣法抵触の恐れがあるため「打ち合わせ」名目）を行い、実務能力を確認する。また、単価に見合った技術セットかを公式な資格や実績で裏取りする。
まとめ：自社にとっての最適解を見極めるために
SES（常駐）と受託開発は、どちらが優れているというものではなく、「プロジェクトの不確実性をどちらがコントロールするか」の違いに過ぎません。
- 受託開発：不確実性が低い、またはベンダーにリスクを委ねたい場合に適する。
- SES：不確実性が高い、または自社でコントロールを握りながら柔軟に開発したい場合に適する。
自社のIT資産を中長期的にどう育てていくかという視点を持ち、適切なパートナーシップを選択してください。もし、社内に適切な判断を下せる人材が不足している場合は、まずは小規模な準委任契約でアドバイザーを招き、要件定義の整理から着手することをお勧めします。
補足：契約締結前に知っておくべき「準委任」の二つの形式
SESで一般的に用いられる「準委任契約」は、2020年の民法改正により、実務上二つのタイプに明確に分かれています。ここを混同すると、支払い条件や責任の所在でトラブルになるため注意が必要です。
- 履行割合型：提供した「労働時間」に対して対価を支払う形式。一般的なSESはこちらに該当します。
- 成果完結型：「報告書の提出」や「特定の事務作業の完了」など、作業の結果に対して対価を支払う形式。完成義務（請負）とは異なりますが、結果が出ない限り報酬を請求できない場合があります。
【比較】フェーズ別・契約形態の切り替え判断基準
プロジェクトの進捗に応じて、最適な契約形態は変化します。以下の表を参考に、契約更新のタイミングで形態の見直しを検討してください。
| プロジェクトの状態 | 推奨される契約形態 | 切り替えのメリット |
|---|---|---|
| 立ち上げ期（仕様未定） | SES（準委任・履行型） | 柔軟な軌道修正、スピード優先の開発が可能。 |
| 安定期（機能追加中心） | 受託開発（請負） | 予算の固定化と、品質保証（不適合責任）の確保。 |
| 内製化・自走期 | 内製化支援（準委任・技術指導） | 外部依存からの脱却、社内ノウハウの蓄積。 |
エンジニアに「丸投げ」しないための準備
「SESなら何でもやってくれる」「受託ならお任せでシステムができる」という考えは、開発現場の崩壊を招きます。特にDX推進においては、ITツール側に業務を合わせる判断（Fit to Standard）が求められる場面が多く、現場主導の意思決定が不可欠です。
例えば、スクラッチ開発にこだわらず、Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドで紹介されているようなローコードツールを併用することで、SESの工数を削減しつつ、自社でメンテナンス可能な範囲を広げる戦略も有効です。
公式ドキュメント・参考リソース
契約の実務に関しては、以下の公的ガイドラインを必ず一読しておくことを推奨します。
よくある質問（FAQ）
Q. SESと受託開発、どちらが安いですか？
要件が固まっているプロジェクトでは、受託開発の方が総コストを抑えやすい傾向があります。受託側が工数超過リスクを負うため、見積もり内で完成させようとする動機が働くためです。一方、仕様変更が多い案件で受託形式を選ぶと変更対応の追加費用が累積し、割高になるケースも少なくありません。SESは月額単価（ミドルクラスのエンジニアで70万〜120万円/名程度）×稼働月数の積み上げなので、プロジェクト期間が長引くほど総額が増加します。
Q. 要件定義だけSESで、開発フェーズは受託に切り替えることはできますか？
可能です。「フェーズ分離型」と呼ばれる方法で、実務でも広く採用されています。要件定義・基本設計を準委任（SES）で柔軟に進め、仕様が確定した段階で請負（受託開発）に切り替えることで、各フェーズに適した契約形態を使い分けられます。ただし、フェーズ切り替え時に引き継ぎドキュメントの整備コストが発生するため、その工数を計画に含めておくことが重要です。
Q. SESのエンジニアに直接「今日中にこの機能を修正して」と指示を出してよいですか？
原則として不可です。SES（準委任）契約では、発注側が常駐エンジニアに直接指揮命令を行うと「偽装請負」とみなされ、労働者派遣法・職業安定法違反となるリスクがあります。業務の優先順位や期限については、SES企業側のプロジェクトリーダーを通じて伝えてください。「打ち合わせ」名目での事前の意思疎通は許容されていますが、日常的な業務命令の経路は明確に守る必要があります。
Q. 受託開発で仕様変更が発生した場合、追加費用はどうなりますか？
請負契約では、契約締結後の仕様変更には原則として追加見積もりが必要になります。変更が多いプロジェクトでは、事前に「変更管理プロセス（チェンジコントロール条項）」を契約書に盛り込み、変更発生のたびに追加費用とスケジュール影響を合意する仕組みを整えることが重要です。これがないと「言った・言わない」のトラブルに発展しやすくなります。
Q. ラボ型開発とSES・受託はどう違いますか？
ラボ型開発（オフショアラボ）は、海外（ベトナム・インドなど）の開発チームを長期的に「専属ラボ」として確保する形態です。コスト面ではSESより割安になるケースが多く、チームの継続性も確保しやすいのが特徴です。一方で、タイムゾーンの差・コミュニケーションコスト・品質管理の難しさがあるため、一定のPM（プロジェクトマネジメント）体制が必要です。要件の安定している長期開発や保守に向いています。
業務システム・DX全般のご相談
業務の課題整理からツール選定、システム導入・連携・運用までを幅広く支援します。何から手をつけるべきか迷う段階でも、貴社の状況に合わせて最適な進め方をご提案します。
AI×データ統合 無料相談
AI・データ統合・システムの最適な組み合わせを、企業ごとに設計・構築します。「何から始めるべきか分からない」という段階からでも、まずはお気軽にご相談ください。