意思決定ガイド

エンジニア採用・SES・受託開発の違いは?外部開発チームを含む4つを比較

社内にエンジニアがいない会社が、開発体制をどう持つか。採用・準委任型の開発支援・受託開発・継続型の外部開発チームを、契約の対象・責任・終了時のリスクで比べ、いま検討すべき選択肢を3つの質問で絞ります。

社内にエンジニアがいない会社が「開発をどう持つか」を決めるとき、選択肢は大きく4つあります。正社員として採用する、準委任型の開発支援を受ける、請負で成果物の完成を依頼する、継続型の外部開発チームと契約する、の4つです。

「SES」は法令上の契約名ではなく、準委任・請負・労働者派遣などを含みうる商慣用語です。この記事ではSESのうち準委任型の開発支援を比較対象とし、派遣との違いは後段で説明します。

4つ目の「継続型の外部開発チーム」は一般に統一された契約類型ではありません。Heygoodが「外付け開発室」と呼ぶサービスもこの形に含まれますが、契約期間、完成責任、成果物の帰属は提供会社ごとに異なります。この記事は、この方式だけを勧めるのではなく、実際の契約条件を同じ観点で比べるためのものです。

採用・準委任・受託・外部開発チームは、何が違うのか?

違いは契約の対象と責任です。雇用、業務の遂行、成果物、継続支援のどれを求めるかで選択肢が変わります。

正社員を採用すると、何を作るか、どの順番で進めるか、成果をどう評価するかは自社が決めます。準委任では受注者が業務を遂行しますが、完成物そのものを約束する契約とは限りません。請負では、契約で定めた仕事を完成させる責任を受注者が負います。

継続型の外部開発チームは、要件整理から保守までを月額契約に含めることがあります。ただし、毎月解約できるとは限らず、最低契約期間や対象業務の上限が設けられる場合もあります。「月額だから変動費」と決めつけず、解約条件まで確認してください。

4つの選択肢は、どの契約条件を比べればよいのか?

契約の対象、費用、要件整理、完成責任、終了時の引き継ぎを同じ順番で確かめると、方式ごとの差が見えます。

表は横にスクロールできます →
観点正社員採用準委任型の開発支援受託開発(請負)継続型の外部開発チーム
契約の対象労働契約業務の遂行定めた仕事の完成継続的な開発支援
主な費用給与・社会保険・採用費期間や稼働量に応じた委託料案件ごとの見積額月額料。最低期間や上限は契約による
要件整理自社で行う自社と受注者の分担を決める契約前に範囲と検収条件を決める契約範囲に含むかを確認する
完成責任自社が開発結果を管理原則として仕事の完成は契約目的ではない受注者が契約範囲の完成責任を負う請負・準委任など契約類型による
担当者への直接指示自社社員なのでできる発注者から受注者の担当者へはできない発注者から受注者の担当者へはできない準委任・請負ならできない
終了時の主なリスク休職・退職時に知識が失われる担当者交代や契約終了で知識が失われる追加変更や保守が別契約になる月額費用の継続、特定会社への依存
契約前に残し方を決めるもの仕様・運用手順・アカウント作業記録・設計・ソースコード納品物・仕様・検収記録履歴・データ・ソースコードの引渡条件
向く場面開発判断が継続し、採用後の仕事がある業務を切り出せて受注者と分担できる作るものと検収条件が決まっている要件整理と改善を継続して委託したい

表の「直接指示」は、法令上の指揮命令を指します。準委任や請負でも、発注者が優先順位や成果物への要望を受注会社の責任者へ伝えることはできます。個々の担当者へ勤務方法や作業手順を直接命じることとは分けて考えてください。

自社はどれを検討すべきか、どこで見分けるのか?

3つの質問で絞れます。作るものが決まっているか、続く仕事か一度きりか、技術的な良し悪しを社内で判断できるか、です。

たとえば「取引先からFAXとメールで届く注文を、担当者が販売管理システムに手入力していて、繁忙期に残業が集中している」という状況を考えてみてください。この段階では、直したい業務は分かっていても、何を作れば解決するかはまだ決まっていません。入力画面を作るのか、読み取りを挟むのか、そもそも注文の受け方を変えるのかは、実際の帳票と例外パターンを見ないと決められません。

表は横にスクロールできます →
質問はいいいえ
作るものと範囲が確定しているか受託開発が検討対象になる受託開発は時期尚早
開発の仕事が毎月続くか採用・継続型の外部開発チームが検討対象単発の受託で足りる可能性
技術的な良し悪しを社内で判断できるか採用・準委任型支援を管理しやすい技術評価の支援を契約に含める

3つとも「いいえ」に寄る場合、まず必要なのは開発そのものではなく、何を作るべきかを決める工程です。ここを飛ばして契約形態だけ先に決めると、どの選択肢でも同じところでつまずきます。

いま4つとも検討しなくていい条件はあるか?

あります。既存ツールで足りる、発生頻度が低い、解決したい作業がまだ絞れていない場合は、開発を急ぐ必要はありません。

具体的には、次のような状態であれば、開発体制を持つ判断はまだ先送りしてかまいません。

  • 既存のパッケージやSaaSの設定・オプションで要件を満たせる見込みがある
  • 発生頻度が低く、開発費と保守費を含めると現行手順のほうが安い
  • 現場から出ている要望が、まだ「使いにくい」という段階で、どの作業をなくしたいかまで言語化されていない
  • 入力データ、必要な出力、例外処理が分からず、試す業務範囲を切り出せていない

いま使っている表計算ソフトやパッケージが悪いわけではありません。これらで回っている業務をわざわざ作り替える必要はなく、まず現行手順にかかる時間とミスの影響を記録します。そのうえで、設定変更、運用変更、開発の順に比べるほうが、作った後に使われないシステムを避けられます。

人が採れないのは、市場にエンジニアがいないからか?

供給が減っているわけではありません。国の試算では供給は増える見通しで、それでも足りないのは需要の伸びが速いためです。

経済産業省の「IT人材需給に関する調査」によると、IT人材の供給は2018年の103万人から2030年には113万人へ増加すると試算されています。一方で需要の伸びを年平均2.7%程度、労働生産性の上昇を年0.7%と置いた試算では、2030年時点の需給ギャップは45万人と見込まれています(IT人材需給に関する調査(概要))。

同じ2019年調査の詳細報告書には、需要の伸びを高位に置いた場合の約79万人という試算もあります(IT人材需給に関する調査報告書)。45万人と約79万人は新旧の置き換えではなく、前提が異なる試算です。どちらか1つを確定した将来予測として扱うべきではありません。

不足感は事業会社側でも確認できます。IPAの「DX動向2025」によれば、DXを推進する人材の量について「やや不足している」「大幅に不足している」と回答した日本企業は8割を超えており、米国・ドイツと比べて高い水準にあります(IPAプレス発表「DX動向2025」、調査対象は事業会社の人事・情報システム・DX推進部門等、回収数は日本1,535社・米国509社・ドイツ537社)。ここでいう人材はエンジニアに限らず、DXの取組を担う人材全般を指します。

つまり、採用がうまくいかない原因を自社の魅力や採用手法だけに求めると、打ち手を見誤ります。母集団の争奪が起きている前提で、採用以外の選択肢も同じ土俵に載せて比べるほうが現実的です。

準委任・派遣・請負は、契約上どこが違うのか?

準委任と請負は受注者が業務を管理し、派遣は派遣先が指揮命令します。請負だけが仕事の完成を目的にします。

労働者派遣では、派遣先が派遣労働者へ業務上の指揮命令を行います。準委任や請負では、受注者が自ら担当者を管理し、発注者が個々の担当者へ直接指揮命令する形にはできません。請負は契約で定めた仕事の完成を目的とし、準委任は業務の遂行を目的とする点も異なります。

労働者派遣にあたるか請負にあたるかは、契約書の表題だけでなく実態で判断されます。厚生労働省は「労働者派遣事業と請負により行われる事業との区分に関する基準」(37号告示)とその疑義応答集を公開しており、システム開発を請負業務とする場合の取扱いについても事務連絡を出しています。詳細は37号告示関係疑義応答集で確認できます。

契約類型の使い分けについては、IPAが情報システム・モデル取引・契約書を公開しています。第二版とアジャイル開発版があり、開発工程ごとにどちらが責務を負うかの解説と契約書のひな型が示されています。発注側の担当者が事前に目を通しておくと、見積書の前提を読み解きやすくなります。

仕様が固まっていない段階で請負契約を結ぶと、契約後の変更が追加費用や納期変更につながります。この段階では、要件整理を別の準委任契約に分ける方法があります。ただし、準委任なら自動的にうまくいくわけではありません。検討期間、成果物、意思決定者、次の請負契約へ移る条件を先に決めてください。

決める前に、社内で確認しておくことは?

4点です。要件の決定者、稼働後の窓口、担当者が抜けたときに残すもの、最初に触る業務範囲を決めてください。

  • 要件を決める人: 現場と経営の間で優先順位を決められる人を1人置く。ここが空席だと、どの契約形態でも進みません
  • 稼働後の窓口: 作って終わりではなく、直し続ける前提で誰が受けるかを決める
  • 引き継ぎの形: 仕様書、変更履歴、データの持ち出し方法を、契約時点で条件に入れる
  • 最初に触る範囲: 全社ではなく、1つの業務に絞る。FAX注文の入力なら、まず1商流分から

この4点が埋まらないまま選択肢を比べても、比較の前提が揃いません。逆にここが埋まっていれば、見積もりを取ったときに各社の前提の違いが見えるようになります。

自社の状況に合わせて整理したい場合は、お問い合わせからご相談ください。作るものが決まっていない段階でも、何から決めるべきかの整理からお手伝いできます。

この記事の情報源

2026年7月28日時点で各一次情報のURLと記載内容を確認

  1. 経済産業省「IT人材需給に関する調査(概要)」(平成31年4月)
  2. 経済産業省「IT人材需給に関する調査」調査報告書(平成31年3月)
  3. IPA「DX動向2025」日米独比較で探る成果創出の方向性
  4. IPA プレス発表「日本・米国・ドイツ企業のDX推進状況を調査した「DX動向2025」を公開」
  5. 厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準(37号告示)関係疑義応答集」
  6. IPA「情報システム・モデル取引・契約書」

よくある質問

エンジニアを1人採用すれば、社内で開発できるようになりますか。

開発範囲が狭く、外部の設計レビューやインフラ運用を利用するなら、1人から始められる場合もあります。採用を選ぶ前に、その人が担う範囲と外部に任せる範囲、休職・退職時の引き継ぎ方法を決めてください。

SESと受託開発(請負)は何が違いますか。

SESは契約名ではありません。実際の契約が準委任なら原則として完成責任はなく、発注者は受注者の担当者へ直接指揮命令できません。労働者派遣なら派遣先が指揮命令します。名称ではなく契約と業務実態を確認してください。

作りたいものがまだ言語化できていません。どれを選べばよいですか。

仕様が固まっていない段階で請負契約を結ぶと、認識のずれがそのまま費用と納期に跳ね返ります。まずは要件を発見する期間を設ける前提で、準委任型の関わり方から検討してください。

Next reading

すべての記事を見る →
乗り換えガイドkintone乗り換えの判断軸記事を読む乗り換えガイド在庫・原価管理をkintoneで続けられるか?向く条件と限界記事を読む乗り換えガイドkintoneの限界はどこか?レコード数・連携・改修費で判断する記事を読む