SES・受託開発・ラボ型開発、どの契約形態で発注すべきか迷っていませんか。外部開発リソースを検討する場面で、3形態それぞれの「概要」は調べられても、「自社のプロジェクトにはどれが合うのか」を判断する段階で手が止まる方が大半です。仕様の確定度・期間・社内のマネジメント余力・成果責任の所在——判断材料が多すぎて、結局ベンダーの提案をそのまま受け入れるケースも珍しくありません。
しかし、契約形態の選定を誤ると、「SESエンジニアに直接指示を出して偽装請負と指摘された」「仕様変更のたびに追加費用が発生して予算が膨らんだ」「ラボ型のチームに割り当てるタスクが用意できず稼働率が下がった」といった失敗が現場で起こります。
本記事では、3形態を発注者目線で比較し、5つの判断軸で自社に合う形態を選び分けるフレームを整理します。読み終える頃には、社内稟議で「自社のケースは○○型が適している」と説明できるロジックと、失敗回避のチェックポイントを手にしているはずです。
外部エンジニア活用の戦略立案ガイド（DX推進・内製化ハイブリッド戦略）
この資料でわかること
外部エンジニア活用を検討する経営層・技術責任者が、自社の技術戦略における外部人材の位置づけを明確にし、具体的な活用計画を立てられるようになること。本資料は意思決定の判断軸を提供し、読者が「自社でも実行できる」確信を持って次のアクション（無料相談）に進むことをゴールとする。
こんな方におすすめです
- エンジニア採用に時間がかかり開発が停滞している
- DX推進の外部委託先選定に悩んでいる
- 外部エンジニアと内製チームの役割分担を設計したい
入力いただいたメールアドレスにPDFをお送りします。
3つの契約形態を一言でまとめると
3形態の本質を「誰が成果責任を持ち、誰が指揮を執るか」「どんな単位で借りるのか」の観点で整理します。
- SES（システムエンジニアリングサービス）: 準委任契約の一形態で、エンジニアの「労働力（稼働）」を借りる契約です。指揮命令権はSES企業（受注側）に残り、成果物の完成責任ではなく業務遂行に対して報酬が発生します。
- 受託開発（請負契約）: ベンダーが成果物の「完成」を約束し、検収を通過した時点で対価が支払われる契約です。指揮命令権はベンダー側にあり、発注者はスコープと検収基準で成果をコントロールします。仕様変更時は変更管理を通じて費用・期間が再交渉されます。
- ラボ型開発: 準委任契約をベースに、専属の開発チームを一定期間まとめて借りる形態です。月額固定でチーム単位の稼働を確保し、仕様変更を前提に継続的に開発を回せます。指揮命令権が受注側に残る点はSESと同じですが、SESと異なり「チーム単位」で長期的に伴走します。
3形態の違いをひとことで言えば、「成果物に対して払うのか（受託）、稼働に対して払うのか（SES・ラボ型）」、そして「個人単位（SES）かチーム単位（ラボ型）か」 という2軸に集約されます。
なお、SESと派遣・業務委託は混同されやすく、指揮命令権の所在が異なります。詳細はSES・派遣・業務委託の違いを参照してください。
SES・受託開発・ラボ型開発を選定フレームで比較する
3形態の違いを「定義」ではなく「発注者の選定判断軸」の粒度で並べた比較表です。縦軸を意思決定材料に振り切っており、自社プロジェクトに照らして「どの軸でどの形態が合うか」を読み取れます。
比較軸 | SES | 受託開発（請負） | ラボ型開発 |
|---|---|---|---|
契約類型 | 準委任契約 | 請負契約 | 準委任契約（多くは月額固定） |
向くプロジェクト | 短期スポットの人員補強・既存システム保守・スキル補完 | 仕様が確定済の業務システム・期間と成果物が明確な開発 | 仕様未確定の新規開発・継続改善・MVP〜グロース期 |
成果責任 | 業務遂行責任（完成義務なし） | 成果物の完成責任（ベンダー側） | 業務遂行責任（チームで継続的に成果を出す） |
指揮命令権 | SES企業（受注側）。発注者は直接指示できない | ベンダー側。発注者はスコープと検収で管理 | ラボ提供側（受注側）。発注者は要件・優先順位を提示 |
コスト構造 | 月額（人月単価）× 稼働人数 | 一括または分割の固定金額 | 月額固定（チーム単位） |
契約期間の柔軟性 | 短期〜長期どちらも可 | プロジェクト単位（短〜中期が主流） | 中〜長期前提（半年〜複数年が一般的） |
仕様変更への耐性 | 業務範囲内なら柔軟 | 低い（変更管理プロセスで再見積もり） | 高い（チームで柔軟対応） |
マネジメント負荷 | 中〜高（直接指示は不可） | 低〜中（スコープ管理は発注側） | 中〜高（要件整理・優先順位付け・週次定例） |
想定リスク | 偽装請負・属人化 | 仕様変更コストの肥大化・検収トラブル | チーム稼働率の低下・タスク供給の継続性 |
この表をどう読むか: 自社プロジェクトを「仕様確定度」「期間」「社内の発注管理人員」「コストの固定/変動許容」の4軸で評価し、表の各列と照らし合わせます。仕様が固まっており成果物単位で発注したいなら受託開発、仕様変更前提で継続改善したいならラボ型、特定スキルを短期補強したいならSES、と軸ごとに自然な選択肢が浮かびます。
ラボ型開発自体の費用感や契約管理の詳細はラボ型開発とは？SES・請負との違い・費用・メリットを解説で別途整理しています。
SES契約が向いているケースと避けるべきケース
SESは「労働力を時間単位で借りる」契約です。稼働開始までのリードタイムが短い点が強みですが、指揮命令権が受注側に残るという性質を理解せずに発注すると、偽装請負と指摘されるリスクを抱えます。
向いているケース
- 既存システムの保守・運用: 仕様や仕組みが既にドキュメント化されており、定常タスクをこなす人員が必要なケース
- スポット的な人員補強: 短期繁忙期や特定プロジェクトの人手不足を埋めたい場合。月単位での増減がしやすい
- 特定スキルの短期補完: 自社にいないスキルセット（特定言語・特定SaaS運用・モバイル開発など）を一時的に補いたい場合
避けるべきケース
- 仕様未確定の新規開発: SESは「業務遂行」契約のため成果物の完成は約束されません。仕様が固まらないまま発注すると、開発が長期化しコストが膨らみがちです
- 成果物単位で発注したい場合: 成果物に対価を払いたいなら受託開発が適しています。SESでは時間に対して対価が発生するため、ゴールが曖昧なまま稼働だけが続くリスクがあります
- チーム単位で長期的に伴走してほしい場合: 個人単位の契約が基本のため、メンバーの入れ替えで業務知識が継続しないリスクがあります。継続性重視ならラボ型が向きます
偽装請負リスクへの注意点
SES契約で最も注意すべきは「指揮命令権の所在」です。発注者がエンジニアに対して直接「この機能を作ってください」「明日までに修正してください」と業務指示を出すと、実態としては労働者派遣に近い状態になり、偽装請負と判断される可能性があります。
実務上は、業務指示はSES企業のリーダーや責任者を経由する、勤務時間・休暇の管理はSES企業側に任せる、といった運用が基本です。SESの法的分類や偽装請負の境界線についてはSESとは？派遣・請負・準委任との違いと発注者が知るべきポイントで詳しく整理しています。
受託開発が向いているケースと避けるべきケース
受託開発（請負契約）はベンダーが「成果物の完成」を約束する契約です。「何を・いつまでに・いくらで」を契約時に確定させ、検収を通じて成果を受け取ります。仕様が明確であれば社内のマネジメント負荷を最小化できる選択肢です。
向いているケース
- 仕様確定済の業務システム開発: 業務フロー・画面仕様・データ項目が事前に固まっている社内システム・基幹システムなど
- 期間と成果物が明確な開発: 納期と納品物が明確で、固定金額の予算管理がしやすい
- 品質責任をベンダー側に持たせたい場合: 検収条件を明文化することで、品質責任がベンダー側に発生します
避けるべきケース
- アジャイル開発を前提とするプロジェクト: 契約時のスコープ確定が前提のため、頻繁な要件変更を伴うアジャイル開発と相性が悪いとされます（アジャイル開発は準委任契約の方が請負契約より上手くいく）。変更管理の手続きコストが開発コストを上回ることもあります
- 要件変動が頻繁な開発: BtoC SaaS、PMF前のプロダクト、オペレーション変更を取り込むツール開発など。仕様が動くたびに追加見積もり・追加契約が必要になります
- MVPフェーズの新規プロダクト: 「とりあえず作って試す」フェーズでは仕様変更が前提で、固定スコープの受託契約には馴染みません
契約時に必ず確認したい3点
- スコープ定義: 何を成果物とするかを画面・機能・データ単位で具体的に記述する。曖昧な「等」「など」を残さない
- 変更管理プロセス: スコープ外の要望が発生した際の見積もり手順・承認フロー・契約変更方法を事前に合意する
- 検収条件: 何をもって「完成」とみなすか（受入テスト項目・性能要件・バグ対応期限）を明文化する
請負契約と準委任契約の法的相違はシステム開発の請負契約と準委任契約の違いと選び方｜発注者のためのリスク判断ガイドで詳しく解説しています。
外部エンジニア活用の戦略立案ガイド（DX推進・内製化ハイブリッド戦略）
この資料でわかること
外部エンジニア活用を検討する経営層・技術責任者が、自社の技術戦略における外部人材の位置づけを明確にし、具体的な活用計画を立てられるようになること。本資料は意思決定の判断軸を提供し、読者が「自社でも実行できる」確信を持って次のアクション（無料相談）に進むことをゴールとする。
こんな方におすすめです
- エンジニア採用に時間がかかり開発が停滞している
- DX推進の外部委託先選定に悩んでいる
- 外部エンジニアと内製チームの役割分担を設計したい
入力いただいたメールアドレスにPDFをお送りします。
ラボ型開発が向いているケースと避けるべきケース
ラボ型開発は、専属の開発チームを月額固定で一定期間まとめて借りる契約形態です。「個人単位」ではなく「チーム単位」で長期的に伴走する点がSESと異なります。詳細はラボ型開発とは？SES・請負との違い・費用・メリットを解説で扱っているため、本セクションでは選定文脈に絞って解説します。
向いているケース
- 仕様未確定・継続改善を前提とする開発: 新規SaaS、自社サービスのグロース、ユーザーフィードバックを取り込みながら進める開発に最適
- MVPフェーズの新規プロダクト: PMF前で機能の取捨選択が頻繁に発生するフェーズ。短いスプリントで動くものを出せる柔軟性が強み
- 社内に開発部門を増やしたいケース: 採用が追いつかないが継続的な開発リソースが必要な企業にとって、「社外に開発部門を持つ」感覚に近い体制を構築できます
避けるべきケース
- 短期スポット案件: 1〜2か月で終わる単発案件にラボ型を当てると、月額固定費に対してアウトプットが少なすぎる結果になります。SESや短期受託の方が費用効率が良いです
- 成果物単位で完成を求める場合: 期日までの完成を契約として明確化したいなら受託開発が適切です
- 発注側にタスク供給の余力がない場合: チームに供給するタスクの整理は発注側の責務です。プロダクトオーナー的な役割を担える人員が社内にいないと、稼働率が低下しコストだけが発生します
国内オンショアとオフショアの違い
オフショア（海外拠点）は単価が安い一方、言語・タイムゾーン・文化差によるコミュニケーションコストが発生します。仕様を文書で明確に伝えられる開発に向きます。国内オンショアは単価が高めですが、日本語による高速なやり取り・週次定例での密な伴走・国内タイムゾーンでの即応性が確保できます。仕様未確定・継続改善型の開発に向きます。
ラボ型の契約管理・コスト管理の実務はラボ型開発契約とは？受託・準委任との違いと発注者が知るべきコスト管理のポイントで解説しています。
発注者が選定時に確認すべき5つの視点（自己診断）
3形態の向き不向きを自社プロジェクトに当てはめるための「5つの判断軸」を提示します。各軸に答えれば、自社に適した契約形態がおおむね絞り込めます。
視点①: 仕様はどこまで固まっているか
最も重要な軸です。
- 完全に固まっている（要件定義・画面仕様確定済み） → 受託開発
- 大枠は決まっているが詳細は走りながら確定 → ラボ型
- ほぼ決まっていない・PMF前 → ラボ型一択（受託は変更管理コストが膨れる）
視点②: どのくらいの期間・継続性が必要か
- 1〜3か月で完結する単発開発 → 受託開発またはSES
- 半年〜1年の中期プロジェクト → 仕様確定度に応じて受託 or ラボ型
- 継続的な改善・グロース前提（複数年想定） → ラボ型
リリースまでを受託・リリース後はラボ型に切り替える段階運用も有効です。
視点③: 社内に発注管理ができる人員はいるか
- 発注管理人員が手薄（社内にPMがいない） → 受託開発（ベンダー任せにできる）
- PdM・プロダクトオーナーが社内にいる → ラボ型（タスク供給・優先順位付けを担える）
- 現場マネージャーが直接指示を出せる体制 → SES（指揮命令ルートには注意）
「社内に発注管理ができる人がいないのにラボ型を選ぶ」は典型的な失敗パターンです。
視点④: コストを固定したいか、変動を許容できるか
- 年度予算で固定したい → 受託（固定金額）またはラボ型（月額固定）
- 稼働量に応じた変動を許容できる → SES（需要に応じて増減しやすい）
- 仕様変更時の追加費用を抑えたい → ラボ型（月額固定内で柔軟対応）
視点⑤: 成果責任を誰が持つべきか
- ベンダー側に完成責任を持たせたい → 受託開発
- 業務遂行責任で十分（成果は社内で評価） → SESまたはラボ型
- 社内で品質評価ができる人員がいない → 受託（検収条件を明記）が安全
5つの視点を整理すると、おおむね次のパターンに集約されます。
- 仕様確定 × 期間短〜中 × 完成責任をベンダーに → 受託開発
- 仕様未確定 × 継続前提 × 社内にPdMがいる → ラボ型
- 既存システム保守 or スポット補強 × 短期 → SES
これら5つの問いに自社ケースを当てはめれば、社内稟議で説明できるロジックが組み上がります。
契約形態選定でよくある失敗パターン
契約形態の選定を誤った結果として現場で起こりがちな失敗を4つ取り上げます。いずれも「形態の特性と自社の状況のミスマッチ」から生まれます。
失敗①: SESエンジニアに直接指示を出して偽装請負と指摘された
SES契約で常駐するエンジニアに発注側社員が業務指示・優先順位指示・残業指示を直接出してしまい、実態としては労働者派遣に近いと判断されるケースです。
回避策: 業務指示はSES企業側のリーダーまたは責任者を経由する運用を契約段階で取り決める。タスクリストや進捗報告を書面・チケットで残し、口頭の直接指示を最小化する。
失敗②: 仕様未確定のまま請負契約を結び、追加費用が発生した
新規プロダクトを固定スコープの受託で発注した結果、仕様変更のたびに追加見積もり・追加契約となり当初予算を大きく超過するパターンです。
回避策: 要件定義の段階で「仕様変更が頻発するか」を評価し、変動が前提なら最初から準委任（ラボ型）を選ぶ。受託で進める場合は、変更管理プロセスとバッファ予算を契約に組み込んでおく。
失敗③: ラボ型をスポット案件に適用してしまい、稼働率が下がりコストだけが膨らんだ
ラボ型の柔軟性に惹かれて契約したが、社内で「チームに渡すタスク」を継続的に用意できず、月額固定費だけが消費されていくパターンです。
回避策: ラボ型を選ぶ前に「3か月先までのタスクバックログがあるか」「優先順位を決められる人員が社内にいるか」を確認する。短期スポット案件ならSESや短期受託の方が費用対効果が高い。
失敗④: 契約形態のみで判断し、パートナーの体制・実績を確認しなかった
契約形態として「ラボ型」を選んだとしても、ベンダー側の体制や実績が伴わなければ、結果としてSESと変わらない属人運用に陥ります。週次定例が形骸化したり、メンバーの入れ替えで業務知識が継承されなかったりするケースです。
回避策: 契約形態の選定とは別軸で、パートナーの「過去事例」「チーム運営の方法論」「リーダー人材の体制」を必ず確認する。
失敗の共通構造: 4パターンに共通するのは「形態の特性」と「自社の状況」のミスマッチです。事前の自己診断と、形態・パートナーの両軸での評価により、ほとんどの失敗は回避できます。
契約形態と開発手法（アジャイル／ウォーターフォール）の相性
契約形態を選定する際、もう1つ押さえておきたいのが「開発手法との相性」です。
開発手法 | 適した契約形態 | 理由 |
|---|---|---|
ウォーターフォール | 受託開発（請負） | 工程が逐次的に進むため、スコープが事前確定しやすい |
アジャイル | ラボ型・SES（準委任） | 仕様変更を前提とするため、稼働ベースの契約と相性が良い |
ハイブリッド | フェーズで切り替え | フェーズに応じて契約形態を切り替える運用が有効 |
アジャイル開発と請負契約が衝突する構造
アジャイル開発はスプリントごとに要件を見直し、優先順位を組み替えながら進める手法です。一方、請負契約は契約時にスコープを確定させ、その完成に責任を持つ契約です。両者を組み合わせると、スプリントごとの仕様変更が「契約スコープ外の追加要望」として扱われ、変更管理プロセスに乗せる必要が出てきます。本来のアジャイルの軽快さは失われます。
準委任契約（SES・ラボ型）がアジャイルと相性が良い理由
準委任契約は「業務遂行に対して報酬を払う」形態のため、スコープが動いても契約自体は維持されます。特にラボ型はチーム単位での継続稼働が前提のため、アジャイルのリズム（週次定例・スプリントレビュー・スプリントプランニング）をそのまま回せます。
段階的な使い分け
開発フェーズに応じて契約形態を切り替える運用も有効です。MVPフェーズはラボ型、本格開発フェーズは受託開発、運用・保守フェーズはSESまたは継続ラボ型、というように使い分けます。「契約形態は固定」ではなく「フェーズに応じて切り替える」発想を持つと、コスト効率と柔軟性のバランスを取りやすくなります。
よくある質問（FAQ）
Q. SESとラボ型では費用はどちらが高いですか？
A. 月額ベースで「単価×稼働人数」で比較すると、国内オンショアのラボ型はSESと近いレンジか、やや高くなる傾向があります。ただしラボ型はチーム運営・週次定例・業務知識蓄積を含む価格のため、長期継続ではトータルコストで優位になることが多いです。
Q. 受託開発からラボ型に途中で切り替えることはできますか？
A. 契約上は可能です。初期リリースまでは受託で完成責任を持たせ、リリース後の継続改善はラボ型に切り替える運用は実務でも多く採用されています。パートナー選定の段階で「フェーズに応じた切り替えに対応できるか」を確認しておくと安全です。
Q. SESで直接指示を出してはいけない範囲はどこまでですか？
A. 業務指示・優先順位指示・残業指示・勤怠管理が主な対象で、SES企業側の責任者を経由する運用が基本です。業務上の質問対応・進捗確認・タスクの共有は、運用ルールを取り決めた上であれば直接コミュニケーションを取っても問題ありません。
Q. ラボ型は国内とオフショアでどちらを選ぶべきですか？
A. コスト最適化が最優先で仕様を文書で明確に伝えられる開発ならオフショア、仕様未確定・継続改善・週次でのコミュニケーション密度を重視するなら国内オンショアが現実的です。
Q. 3形態を組み合わせることはできますか？
A. 実務では一般的です。「基幹システムは受託、新規SaaSの開発はラボ型、既存システムの保守はSES」のように、プロジェクトごとに最適な形態を選び分ける運用は多くの事業会社で採用されています。
3形態いずれにも対応する開発パートナーの選び方
契約形態が決まっても、パートナー選定で失敗するリスクは残ります。形態は適切でも、ベンダーの体制や実績が伴わなければ期待した成果は得られません。
パートナー選定で確認すべき3つの観点
- 体制: チーム運営のリーダー人材がいるか、エンジニアが複数案件にまたがる兼任型ではなく専任型か、メンバーの入れ替え頻度が許容範囲か
- 継続性: 過去のラボ型・受託の継続事例があるか、3か月以上の長期契約実績があるか、メンバーの入れ替えに対する業務知識の引き継ぎ方法が確立されているか
- 伴走範囲: 開発だけでなく、要件整理・優先順位付け・プロダクトマネジメントの一部までサポートできるか。発注側のリソースが手薄な場合、伴走範囲が広いパートナーが総コストを抑えます
段階的なフェーズ対応ができるパートナーを選ぶメリット
プロジェクトはフェーズによって最適な契約形態が変わります。MVPはラボ型、本格リリース後は受託、運用保守はSES——この段階運用に対応できるパートナーを最初から選んでおくと、フェーズが進むたびにベンダー乗り換えのコストを払わずに済みます。
複数の契約形態に対応する国内オンショアのパートナーは限られますが、選択肢の1つとして、秋霜堂株式会社（以下、秋霜堂）が提供するTechBandは3形態いずれにも対応しています。国内オンショアの準委任契約をベースに、少人数精鋭・週次定例＋アジャイル進行で社内に開発部門を増やす感覚での伴走を行う形態です。
契約形態の選定とパートナー選定はセットで考える——これが実務での重要なポイントです。本記事で整理した5つの判断軸と4つの失敗パターンを使えば、社内稟議で「なぜこの契約形態を選ぶのか」を根拠を持って説明でき、ミスマッチによる失敗を事前に回避できるはずです。
外部エンジニア活用の戦略立案ガイド（DX推進・内製化ハイブリッド戦略）
この資料でわかること
外部エンジニア活用を検討する経営層・技術責任者が、自社の技術戦略における外部人材の位置づけを明確にし、具体的な活用計画を立てられるようになること。本資料は意思決定の判断軸を提供し、読者が「自社でも実行できる」確信を持って次のアクション（無料相談）に進むことをゴールとする。
こんな方におすすめです
- エンジニア採用に時間がかかり開発が停滞している
- DX推進の外部委託先選定に悩んでいる
- 外部エンジニアと内製チームの役割分担を設計したい
入力いただいたメールアドレスにPDFをお送りします。
