SESと請負開発は何が違う？発注側から見た使い分け

2 日前
読了時間: 9分

外部の開発力を補うとき、「SESでエンジニアに入ってもらうか」「開発会社へ請負で任せるか」は、SIer・開発会社にとってよくある選択です。

ただし、判断すべきなのは単純な「人手不足かどうか」ではありません。不足している仕事を外部の人に担ってもらうのか、それとも一定の責任範囲を外部の会社へ任せるのか。この違いを整理すると、案件に合った発注方法を選びやすくなります。

SES・準委任型の技術支援と請負開発を、発注対象・管理単位・責任範囲で比較した図

はじめに：SESと請負は、同じ「外注」でも任せ方が違う

まず押さえておきたいのは、「SES」という呼び方だけで契約上の義務や運用方法が決まるわけではないことです。

IT業界でSESと呼ばれる取引には、準委任型の業務委託として行われるものがあります。本記事では比較を分かりやすくするため、SESを主に準委任型の技術支援として扱います。

一方、請負は「仕事の完成」を約する契約です。

ただ、発注実務で重要なのは法律上の名称を覚えることではありません。

たとえば同じ「バックエンドエンジニアが足りない」という状況でも、自社チームの中で継続的に技術支援を受けたいのか、決済連携やAPI開発といった一定の範囲をまとめて別会社へ任せたいのかで、適した発注方法は変わります。

「なぜ人が足りないか」ではなく、「不足している仕事をどう外部へ任せるか」を考える。

これが、SES・準委任型支援と請負を使い分ける出発点です。

結論：継続的な技術支援を受けるか、責任範囲を持った仕事を任せるか

発注側から見ると、両者の違いは次のように整理できます。

発注の観点	SES・準委任型の技術支援	請負開発
外部へ期待するもの	継続的な業務遂行・専門的支援	合意した仕事の完成
仕事のまとめ方	役割や業務領域を決める	機能・工程・成果物などの範囲を決める
進め方	状況に応じて業務や優先順位を調整する	合意した範囲を受託会社が管理して進める
発注側の主な役割	要求や優先順位を継続的に整理する	要件・変更・受入条件を判断する
向いている場面	チーム内で継続的な技術支援が必要	独立した仕事を外部会社へ任せられる

ここで注意したいのは、SESなら発注者が外部エンジニアへ自由に直接指示できる、という意味ではないことです。

厚生労働省は、労働者派遣と請負等の区分について、契約形式ではなく実態に即して判断するとしています。発注者が受託会社の作業者へ直接指揮命令する運用は、契約形態によっては労働者派遣との区分が問題になります。

また、時間や工数を基準に費用を精算する契約であっても、それだけで発注者に個々の作業者への指揮命令権が生じるわけではありません。

詳しくは、厚生労働省「労働者派遣・請負を適正に行うためのガイド」を確認してください。

「エンジニアを補充したい」のか、「仕事を切り出したい」のか

たとえば、

「バックエンド担当が1人足りない」

という状況だけでは、SESと請負のどちらが適しているかは決まりません。

既存チームの中で、設計レビュー、技術調査、実装などを継続的に支援してほしいのであれば、準委任型の技術支援が選択肢になります。

一方で、認証機能、決済API連携、バッチ処理、特定のバックエンド機能など、一定の範囲をまとめて外部へ任せられるのであれば、必要なのは「人員」ではなく、その仕事を引き受ける開発会社かもしれません。

つまり、人手不足をそのまま「1名補充」という発注単位へ置き換える必要はありません。

バックエンド開発をどのように成果物として分けられるかは、バックエンド開発を外注するとき、どこまでを成果物として切り出せるのかで詳しく解説しています。

発注側が個々の作業を管理するか、受託会社に仕事を管理してもらうか

もう一つ大きな違いが、開発管理の単位です。

請負で仕事を切り出す場合、発注側が外部エンジニア一人ひとりへ「今日はこのAPIを実装してください」「明日はこの不具合を直してください」と日々の作業を割り当てる形ではありません。

発注側と受託会社の間で対象範囲、仕様、成果物、前提条件、スケジュール、変更時の扱い、受入条件などを整理し、その範囲をどう進めるかは受託会社側が管理します。

発注側から見ると、個々の作業者を自社側で管理する必要があるのか、それとも一定の仕事を外部会社へ任せられるのかを考えることになります。

これは単なる契約書上の違いではありません。発注後に自社がどこまで開発管理を担うかにも関わる違いです。

具体例：開発管理ごと外部へ任せたシステム開発

筆者が担当した証券関連のシステム開発では、当初から作るものの形や必要な技術がすべて決まっていたわけではありませんでした。

そこから要件を整理し、設計、実装、インフラ構築、本番リリースまで一連の工程を担当しました。個々の実装作業だけを受け持つのではなく、システムを形にしてリリースするまでのまとまった範囲を担当した案件です。

このような仕事の切り方であれば、発注側が外部の開発者一人ひとりへ日々の作業を割り振るのではなく、受け持った範囲の開発管理を外部側へ任せることができます。

反対に、既存チームの中で日々優先順位を相談しながら、多様な技術課題へ継続的に対応してもらうことが目的なら、仕事を無理に一つの完成物へ固定するより、準委任型の技術支援が適する場合があります。

同じ「バックエンドの技術力が足りない」という状況でも、外部に担ってほしい役割によって発注方法は変わるということです。

実装まで全部任せなくても、まとまった仕事として切り出せる

外部会社へ仕事を任せるというと、「設計から実装、試験まで全部まとめて発注しなければならない」と考えるかもしれません。

しかし、仕事の切り方はそれだけではありません。

筆者が担当した旅行販売システムでは、要件定義と基本設計を担当し、設計文書を納品したうえで、実装は発注側が行いました。

実装そのものを外部へ出さなくても、要件整理や設計といった工程を一つの仕事として切り出すことはできます。

重要なのは「全部任せるか、自社で全部やるか」ではなく、どこまでを外部会社の責任範囲として分けられるかです。

成果物単位での発注については、システム開発を「人月」ではなく「機能・成果物単位」で外注するにはで詳しく整理しています。

要件が固まっていないなら、まず発注できる単位まで整理する

現行仕様が分からない、技術調査をしなければ実装範囲が決まらない、といった案件では、最初から開発全体を一つの完成物として定義するのが難しいことがあります。

その場合でも、すぐに「人を入れてもらうしかない」と決める必要はありません。

調査や要件整理を先に行い、現在地が見えた段階で、どこから先をまとまった仕事として発注できるかを決める方法があります。

要件が固まっていない状態から請負へつなげる具体的な進め方を知りたい場合は、要件が完全に固まっていなくても、請負開発で相談できるのかを参考にしてください。

SES・準委任型支援と請負を単純に二択にできないケース

ここまで両者を対比してきましたが、すべての案件をきれいに二つへ分けられるわけではありません。

適法な労働者派遣として人材を受け入れる場合は、発注側が作業者へ指揮命令することを前提とした制度になるため、SESか請負かという二択とは整理が異なります。

また、準委任型の契約でも、調査報告書や設計資料、レビュー結果など、業務遂行の結果としてアウトプットを定めることがあります。そのため「成果物があるから請負」と機械的に判断することもできません。

さらに、数日の調査や小規模な技術支援では、仕事を細かく分割して見積・契約・検収を繰り返す管理コストの方が大きくなる場合もあります。

契約形態そのものを目的にせず、任せたい役割、責任範囲、期間、変更の多さ、管理方法を踏まえて選ぶことが重要です。

プレイリーソリューションズでは、バックエンドを「仕事」として切り出せるか整理します

プレイリーソリューションズでは、バックエンド開発について、単に「エンジニアを何人出すか」ではなく、どの仕事をどこまで外部へ任せられるかという観点から発注範囲を整理します。

Javaを中心としたバックエンド開発に対応しており、Spring Bootをはじめとする主要フレームワークだけでなく、Strutsや独自フレームワークなど既存・レガシー環境の改修も対象としています。AWS、外部API連携、決済連携、既存Webシステムの改修なども含め、要件定義・設計から実装・試験・リリースまで、案件に応じて担当範囲を設定できます。

すべてを一括で任せる必要はありません。

要件整理や基本設計だけを切り出す、技術調査から始める、調査後に実装可能な範囲を切り出すなど、案件の状態に合わせて進め方を分けることも可能です。