SES（常駐）と受託開発はどちらが向く？｜要件の曖昧さ別の選び方

システム開発を外部に依頼する際、多くの企業担当者が直面するのが「SES（システム・エンジニアリング・サービス）による常駐」と「受託開発（請負）」のどちらを選ぶべきかという問題です。

特に「まだ要件がふわっとしている」「どこまで作るか決まっていない」という状況では、契約形態の選択ミスが、予算の膨張やプロジェクトの頓挫、さらには法的なリスクを招くことになります。本記事では、IT実務者の視点から、要件の曖昧さを軸にした選び方の基準と、それぞれのメリット・デメリットを徹底的に解説します。

1. SES（常駐）と受託開発の決定的な違い

まずは、両者の契約的な性質を正しく理解する必要があります。ここを混同すると、現場でのトラブルが不可避となります。

受託開発（請負契約）：「完成」に対して対価を支払う

受託開発の多くは「請負契約」です。受託側は「システムの完成」を約束し、発注側は「成果物の納品」に対して対価を支払います。仕様が明確であれば、予算の変動が少なく、品質保証（契約不適合責任）も求めやすいため、確実性を重視する場合に適しています。

SES（準委任契約）：「善管注意義務」に対して対価を支払う

一方、SESは一般的に「準委任契約」です。こちらは「完成」を保証するものではなく、エンジニアが「専門家として適切に業務を遂行すること」に対して対価を支払います。時間の切り売り（工数提供）に近い性質を持つため、仕様変更が頻発する現場に向いています。

2. 要件の曖昧さ別・最適な選び方

プロジェクトの成功可否は、契約形態が「要件の固まり具合」と合致しているかどうかで決まります。

【要件定義済み】仕様が明確なら「受託開発」

「既存のExcel業務をそのままシステム化したい」「基幹システムのデータを抽出してBIツールで見たい」といった、ゴールが数値やフローで明確に定義できる場合は、受託開発が最適です。受託側が見積もりを出しやすく、工数超過のリスクは受託側が負うため、コストパフォーマンスが高くなります。

例えば、経理業務のデジタル化において、すでに業務フローが整理されている場合は、受託形式で一気に構築するのが効率的です。あわせて、
freee会計導入マニュアル｜旧ソフト移行ガイド
などを参考に、ツール側の仕様に業務を寄せる（Fit to Standard）ことで、開発コスト自体を抑えることも可能です。

【要件が流動的】作りながら考えるなら「SES（準委任）」

「新規事業のMVP（最小機能版）をリリースし、ユーザーの反応を見ながら改善したい」「社内のDXを進めたいが、現場の要望が二転三転しそう」という場合は、SESによる常駐や工数提供型が向いています。受託開発で要件変更を繰り返すと、その都度「追加見積もり」が発生し、結果として割高になるだけでなく、スピード感が失われます。

要件の解像度チェックリスト

以下の項目に「いいえ」が多い場合は、受託開発ではなくSESまたは伴走型のコンサルティングを検討すべきです。

• 全ての画面遷移図と画面項目定義が揃っているか？
• 外部システムとの連携仕様（APIドキュメント等）が確定しているか？
• 非機能要件（同時アクセス数、セキュリティ基準）が合意されているか？
• 開発期間中に大きな組織変更や業務変更の予定がないか？

3. コストと品質の徹底比較

実名的な業態やサービスモデルを想定した比較を以下の表にまとめました。

特にコスト面で見落としがちなのが「管理コスト」です。受託開発は「丸投げ」ができると思われがちですが、検収（納品物の確認）には発注側にも高いリテラシーが求められます。逆に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資産を中長期的にどう育てていくかという視点を持ち、適切なパートナーシップを選択してください。もし、社内に適切な判断を下せる人材が不足している場合は、まずは小規模な準委任契約でアドバイザーを招き、要件定義の整理から着手することをお勧めします。