受託開発とSES・SIerの違い｜発注前に確認すべき契約の形と6つの質問

受託開発は「完成したシステム（成果物）」を買う発注、SESは「技術者の稼働」を買う発注、SIerは「システム構築を請け負う会社」の呼び名です。

つまり、3つは同じ物差しで並ぶ言葉ではありません。
発注側が確認すべきなのは呼び名ではなく、①何に対してお金を払うのか ②誰が作業の指示を出すのか ③実際に誰が作るのかの3点です。

「受託開発会社に見積もりを頼んだら、SESという言葉が出てきた」

「SIerと開発会社は何が違うのか、営業担当に聞きそびれた」

システム開発の発注を初めて検討すると、こうした業界用語で手が止まりがちです。
言葉の意味があいまいなまま契約すると、完成まで責任を持ってくれると思っていたのに、実は人を貸すだけの契約だった、といった食い違いが起きかねません。

この記事では、開発を受注する側の立場から、①3つの言葉の関係、②それぞれの発注で気をつけること、③商談の段階で確認すべき項目、を整理します。

なお、本記事では請負契約・準委任契約という契約類型そのものの違い（完成義務、契約不適合責任、中途解除など）には深入りせず、「どの形で発注するか」の判断に絞ります。
契約類型そのものの違いは準委任契約と請負契約の違いで解説しています。

3つの言葉は「比べる軸」が違う

「受託開発・SES・SIerの違い」と並べられることが多いのですが、実はそれぞれ別の軸を表す言葉です。

受託開発とSESは「何を買うか」という発注の形を表す言葉で、SIerは「どんな会社か」という会社の種類を表す言葉です。
SIerが受託開発を請け負うことも、SESの形で技術者を出すこともあるため、会社の看板ではなく、案件ごとの契約内容と体制で判断する必要があります。

受託開発とは——「完成したシステム」を買う発注

受託開発とは、発注者が開発会社にシステムの開発を依頼し、開発会社が完成させて納品する形の発注です。
契約は請負契約で結ぶのが一般的ですが、要件定義など一部の工程を準委任契約に分けることもあります。

発注者から見た特徴は、次のとおりです。

• お金を払う対象：完成したシステム（成果物）
• 作業の進め方を決めるのは：開発会社。発注者は「何を作りたいか」を伝える
• 開発会社の人がどこで作業するか：開発会社の社内が基本

発注側が気をつけること

1. 「何を作るか」を決めるのは発注側

受託開発は完成責任を開発会社が負う形ですが、作るものの中身を決めるのは発注側です。
業務の流れ、必要な機能、優先順位があいまいなまま発注すると、見積もりにリスク分の上乗せが入ったり、完成後に「思っていたものと違う」となったりします。

2. 金額と範囲は「要件が固まってから」確定させる

要件が固まっていない段階で総額を確定させようとすると、開発会社は不確定な部分を見込んで高めに見積もるか、範囲を狭く書くかのどちらかになりがちです。
まず要件定義を切り出して依頼し、作るものが決まってから開発の金額を確定させる進め方も検討してください。

3. 「どこまでが見積もりに入っているか」を確認する

受託開発の見積もりは「一式」で書かれることがあります。
設計書などのドキュメント、テスト、データ移行、操作説明、リリース後の保守が含まれるかどうかは、会社によって違います。

SESとは——「技術者の稼働」を買う発注

SES（システムエンジニアリングサービス）とは、SES事業者に所属する技術者が、一定期間、発注者のプロジェクトで作業する形の発注です。
報酬は「1人あたり月額◯◯万円」のように、稼働に対して支払うのが一般的です。

SESは法律上の契約類型の名前ではなく、業界での呼び方です。
契約書上は準委任契約として結ばれることが多いですが、呼び名ではなく契約書の中身で判断する必要があります。

労働者派遣との違い

SESは技術者が発注者の職場に常駐することも多く、見た目は派遣と似ています。
決定的に違うのは、誰が技術者に作業の指示を出すかです。

SESなのに発注者が技術者へ直接「これをこの順番でやって」「今日は残業して」と指示すると、実態は派遣とみなされ、偽装請負として労働者派遣法違反になるおそれがあります。
判断は契約書の名前ではなく、実態で行われます。

発注側が気をつけること

1. 完成は約束されていない

SESで買っているのは技術者の稼働です。
「このシステムを完成させてほしい」という目的なら、SESではなく受託開発（請負）のほうが目的に合います。
SESを選ぶなら、発注側にプロジェクトを進める役割（何を・いつまでに作るかを決める人）が必要です。
この役割の中身はプロダクトオーナーとは？発注側が担う5つの仕事で整理しています。

2. 「この人を入れて」「この人を外して」は言えない

発注者が特定の技術者を指名したり、面談で選んだりすることは、偽装請負と判断される要素になり得ます。
確認できるのは、個人を特定しない形のスキル情報（技術領域、経験年数など）が基本です。

3. ノウハウが社内に残る仕組みを用意する

契約期間が終われば技術者は離れます。
設計の考え方や運用手順が技術者の頭の中だけに残らないよう、ドキュメントの作成・引き継ぎを業務内容として契約に入れておくと安心です。

SIerとは——システム構築を「まとめて請け負う」会社

SIer（エスアイヤー）は、System Integrator（システムインテグレーター）に「〜する人」を表す er を付けた和製英語です。
顧客の業務に合わせて、システムの企画・設計・開発・導入・運用までをまとめて請け負う会社を指します。

成り立ちによって、次のように分類されることがあります。

• メーカー系：コンピューターメーカーやその関連会社が母体
• ユーザー系：一般企業の情報システム部門が独立した会社
• 独立系：特定のメーカーや企業グループに属さない会社

多重下請け構造と、発注側への影響

SIerの業界では、元請けの会社が受注した仕事の一部または全部を、別の会社に再委託することがあります。
再委託がさらに重なると、いわゆる多重下請け構造になります。

  発注者
    ↓  契約
  元請け（SIer）     ← 発注者が話すのはここ
    ↓  再委託
  二次請け
    ↓  再委託
  三次請け         ← 実際にコードを書いているのはここ、ということも

再委託そのものは違法ではなく、専門分野の会社に任せることで品質が上がる場合もあります。
ただ、発注側としては次の点に注意が必要です。

• 要望が伝言ゲームになる：発注者の意図が、実際に作る人に届くまでに何社も経由する
• 費用の内訳が見えにくい：各社の管理費が積み重なっても、発注者からは見えない
• 責任の所在があいまいになる：不具合が起きたとき、どこで何が起きたのかを追いにくい

大切なのは「SIerかどうか」ではなく、自社の案件を実際に誰が作るのかを、契約前に確認することです。

受託開発とSES、どちらで発注すべきか

SIerは会社の種類なので、発注の形として比べるのは受託開発とSESです。
違いを発注側の目線でまとめます。

迷ったときは、次の3つの質問で考えてみてください。

社内にIT専任の担当者がいない中小企業の場合、SESで技術者だけを確保しても、何を作るかを決めて進める人がいなければプロジェクトは前に進みません。
その場合は、要件の整理から一緒に進めてくれる受託開発会社に相談するほうが現実的です。

一方、システムの規模が大きく、複数の既存システムとの連携やハードウェアの調達まで含む場合は、それらをまとめて扱えるSIerが候補になります。
案件の規模と、社内で担える役割の範囲から逆算して選ぶのが基本です。
開発チームを月単位で専属確保する発注方式については、ラボ型開発とはで解説しています。

商談・見積もりの段階で確認すべき6項目

相手が受託開発会社でも、SIerでも、SES事業者でも、契約前に次の6点を確認しておくと、言葉の食い違いによるトラブルを防ぎやすくなります。

① 契約の形と「何に対して払うか」

「請負ですか、準委任ですか」と聞くのが一番確実です。
あわせて、報酬が成果物の納品に対してなのか、稼働時間・月数に対してなのかを確認してください。
見積書に「◯人月」と書かれていても、契約が請負なのか準委任なのかで意味が変わります。

② 実際に開発するのは誰か（再委託の有無）

「御社の社員が開発しますか、それとも他社に再委託しますか」と、遠慮せずに聞いてかまいません。
再委託がある場合は、どの工程を、どこに任せるのかを確認しましょう。
契約書に、再委託には発注者の事前承諾が必要とする条項があるかどうかも見ておきたいポイントです。

③ 窓口と責任者は誰か

発注側からの要望や仕様変更を、誰に伝えればよいのか。
開発会社側の責任者（プロジェクトマネージャー）は誰で、打ち合わせにどの程度参加するのか。
特にSESの場合、作業の指示は受注者側の責任者を通す必要があるため、窓口の確認は欠かせません。

④ 何をもって「完了」とするか

受託開発なら、納品物の範囲（プログラム、設計書、マニュアルなど）と検収の方法・期間。
SESなら、月次の作業報告書に何が書かれるのか。
完了の定義があいまいだと、支払いの段階で揉める原因になります。

⑤ 担当者が交代するときの扱い

開発の途中で担当者が替わる場合、事前に知らせてもらえるのか。
引き継ぎの期間や費用はどちらが負担するのか。
特にSESでは契約期間の途中で人が入れ替わることもあるため、取り決めておくと安心です。

⑥ ソースコードの扱いと納品後の体制

完成したシステムのソースコードや設計書を受け取れるのか、著作権はどちらに帰属するのか。
そして、リリース後の不具合対応や改修を誰が担うのか。
将来ほかの会社に保守を切り替える可能性も考えて、契約前に確認しておきましょう。
著作権の扱いはプログラムの著作権｜ソースコードは誰のもの？で詳しく解説しています。

よくある質問

Q. SIerと受託開発会社は、何が違うのですか？

明確な境界線はありません。
一般に、SIerはハードウェアやネットワークを含めたシステム全体の構築・統合まで扱い、受託開発会社はソフトウェアの開発を中心に請け負う、という使い分けがされることがあります。
ただし、どちらを名乗るかは各社の判断です。
会社の呼び名より、自社の案件で何をどこまで担ってくれるのかを確認してください。

Q. SESで「このシステムを作ってほしい」と頼むことはできますか？

技術者に作業してもらうことはできますが、SESは完成を約束する契約ではありません。
何を作るかを決め、進捗を管理し、完成を判断するのは発注側の役割になります。
完成したシステムを納めてほしいのであれば、受託開発（請負）で依頼するほうが目的に合います。

Q. 受託開発で頼んだのに、常駐の技術者を提案されました。問題ありますか？

常駐そのものは問題ではありません。
確認すべきは、その提案が請負なのか準委任なのか、そして作業の指示を誰が出すのかです。
常駐であっても、受注者側の責任者が指示を出す体制になっていれば、通常の受託開発として進められます。

Q. 小規模なシステムでも、SIerに依頼できますか？

依頼自体はできますが、会社によって得意な規模は異なります。
大規模案件を主に扱う会社では、小規模な案件だと管理の工程が相対的に重くなり、費用が割高に感じられる場合もあります。
見積もりを比較する際は、金額だけでなく、体制や進め方が案件の規模に合っているかを見てください。
複数社への頼み方と比べ方はシステム開発の相見積もりの取り方で解説しています。

Q. 再委託されているかどうかは、どうすればわかりますか？

開発会社に直接聞くのが確実です。
あわせて契約書の再委託に関する条項を確認し、必要であれば「再委託する場合は事前に書面で承諾を得ること」という取り決めを入れてもらいましょう。
打ち合わせに実際の開発担当者が参加するかどうかも、判断材料の一つになります。

まとめ

• 受託開発は「完成したシステム」を買う発注。契約は請負が一般的で、完成の責任は開発会社が負う
• SESは「技術者の稼働」を買う発注。契約は準委任が多く、完成は約束されていない
• SIerは会社の種類の呼び名。受託開発もSESも扱うことがあり、「SIerだから」で発注の中身は決まらない
• SESでは、作業の指示は受注者側の責任者を通す。発注者が技術者へ直接指示すると偽装請負のおそれがある
• 多重下請け構造では、要望の伝達・費用の内訳・責任の所在が見えにくくなる。実際に誰が作るのかを契約前に確認する
• 社内に開発を取り仕切る人がいなければ、要件整理から伴走してくれる受託開発が現実的
• 商談では、契約の形／再委託の有無／窓口と責任者／完了の定義／担当交代／ソースコードと保守の6点を確認する

業界用語の違いは、突き詰めると、何にお金を払い、誰が責任を持つのかの違いです。
呼び名に惑わされず、自社の案件について、この2点を開発会社にはっきり確認してから契約に進んでください。

※本記事は一般的な情報提供を目的としたもので、個別の法律相談に代わるものではありません。
具体的な契約内容の判断は弁護士に、偽装請負に関する個別の事案は各都道府県労働局にご相談ください。

株式会社みんなシステムズは、中小企業のお客様からシステム開発を受託しています。
「受託開発とSESのどちらが合うのかわからない」「そもそも何を作ればよいのか整理できていない」という段階からでも、ご相談をお受けしています。
専門用語を使わず、お客様の言葉でお話を伺いますので、お気軽にご相談ください。