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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

完成した要件書がないため相談をためらっている場合は、要件書がなくてもシステム開発を相談できるか？発注前に決める7項目で、初回相談までに社内から集める情報を確認できます。

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

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