SESと受託開発の違いを発注企業の視点で整理する

SESと受託開発を比べるときは、単価や契約名より先に、外部へ何を任せたいかを整理する必要があります。社内チームの不足する役割を補いたいのか、要件の整理から設計・開発・公開までを相談したいのかで、発注の準備と社内に残る仕事が変わるためです。

また、SESはサービスを表す業界用語であり、言葉だけで契約形態や責任範囲が確定するものではありません。本記事では、発注企業が依頼範囲、体制、費用、連絡経路、成果物、引き継ぎを整理するための確認方法を説明します。個別の契約の適法性や条項の判断は、契約責任者や専門家へ確認してください。

最初に「不足する役割」と「任せる範囲」を分ける

社内に要件や開発体制があり、設計、実装、テスト、インフラ、PMOなどの役割が不足しているなら、その工程に合う外部人材を検討します。この場合も、候補者が参加すれば自動的に全体が進むわけではなく、社内の判断者や受け入れ準備が必要です。

一方、何を作るか、どう進めるか、誰が運用するかまで整理が必要なら、人材一人の募集だけでは解決しない場合があります。対象業務の整理、設計、開発、公開のどこまでを委託するかを考え、支援先の体制と提案範囲を確認します。

「人を増やす」と「開発を任せる」は、どちらか一つしか選べないものではありません。工程ごとに組み合わせる場合もありますが、その分、担当の境界と連絡窓口を明確にする必要があります。

SES・準委任・請負・派遣を同じ言葉として扱わない

SESという呼び方だけから、「必ず準委任」「成果物がない」「発注側が自由に指示できる」と判断しないでください。受託開発も、工程ごとの進め方や契約の組み合わせによって、責任や報酬の条件を確認する必要があります。

民法では、請負や準委任に関する規定が設けられています。契約を読む際は、仕事の完成をどのように扱うか、委ねる業務と報酬をどう定めるかを、実際の条項に即して確認します。条文はe-Gov法令検索「民法」から参照できます。

また、厚生労働省は、労働者派遣と請負の区分に関する疑義応答集で、契約形式だけでなく実態に即して判断する考え方を示しています。システム開発についての関連資料も公開されています。

日々の連絡や指示の経路、労働時間の管理、業務遂行の責任は、契約と運用の両方で確認する事項です。本記事の一般的な整理を、特定の契約が適法であるという判断の代わりにしないでください。

発注前に用意する一枚の依頼条件

依頼条件は、技術名だけで作らず、目的、現在の体制、不足する役割、希望時期、未決定事項をまとめます。候補者や支援先が、何を担い、何を社内へ確認する必要があるか判断できる内容にします。

例として「既存の顧客管理システムを改善したい。要件の判断は社内責任者が行い、外部には設計と実装を相談したい。テスト環境はあるが、公開時の担当は未決定」という書き方が考えられます。これは説明用の架空例です。

• 目的と対象業務：何を改善し、どこまでを今回の対象にするか。
• 現在の体制：業務、技術、契約の判断をそれぞれ誰が行うか。
• 任せたい役割：工程、経験、作業範囲、期待する記録や成果。
• 時期と働き方：開始希望、期間、出社や遠隔の条件、必要な時間帯。
• 環境と情報：端末、アカウント、権限、利用できる資料、制約。
• 予算と未決定事項：費用の上限、精査したい条件、今後の判断者。

条件が固まっていない場合は、未決定のまま記載します。未確認事項をすべて「対応可能」とみなして進めるより、確認すべき工程を明らかにする方が、後の行き違いを防ぎやすくなります。

社内の判断者がいない状態を、そのまま外部へ渡さない

外部人材を受け入れる場合も、業務上の優先順位、予算、仕様の変更、公開の判断を行う人が必要です。会議に参加する人はいても、最終判断をする人が決まっていなければ、確認待ちが増えます。

開発全体を委託する場合も、支援先だけでは、顧客に必要な業務ルールや社内の承認を決められません。業務を説明する人、質問へ答える人、受入確認を行う人を用意します。外部へ任せる範囲が広くても、社内の判断がなくなるわけではありません。

受け入れ準備には、資料の説明、環境の申請、関係者との顔合わせも含みます。稼働の開始日だけを決めて、アカウントや権限が後から整う計画では、契約期間が始まっても仕事を進められない時間が生まれます。

見積もりは、同じ前提で比較する

人材や役割の補完を検討する場合は、期間、勤務形態、対象業務、費用の計算単位、精算の条件、交通費や機器などの扱いを確認します。月額の数字だけで、必要な業務をどこまで担えるかは判断できません。

開発を委託する場合は、要件整理、設計、実装、テスト、データ移行、公開、保守のどこまでが含まれるかを確認します。仕様の前提が曖昧な案と、移行や運用まで整理した案を、総額だけで比較しないことが大切です。

初期費用だけでなく、社内の管理や説明に使う時間も別に見込みます。社内側で設計や進行管理を担う前提と、その支援を含む前提では、外部の金額が同じでも会社全体の負担は異なります。

候補者の確認では、技術名より担当した仕事を聞く

スキルシートには、使用製品や言語と合わせて、担当した工程、チーム内の役割、判断したこと、運用まで関わったかを確認します。同じ技術を使っていても、既存の手順で作業した経験と、設計の判断をした経験では、依頼できる仕事が変わります。

質問は「その技術はできますか」だけでなく、「仕様が曖昧なときに何を確認したか」「障害時にどの情報から原因を切り分けたか」「社内担当へ何を引き継いだか」と具体化します。守秘義務に配慮し、前の顧客の実データや秘密の資料の提出を求めないようにしてください。

受託の支援先を選ぶ場合は、提案担当だけでなく、実際の進行体制、技術判断の担当、連絡窓口、担当変更時の引き継ぎも確認します。個人の経歴が良くても、今回の体制へどう組み込むかが曖昧なら、依頼範囲を再確認します。

データ領域の候補者を検討する場合は、データエンジニアの外部調達で確認する事項も参考にしてください。

連絡経路と変更の手順を、開始前に決める

日々の確認では、業務の質問、作業の依頼、契約に関する調整を区別します。誰がどの窓口へ伝え、どの判断を受けて進めるかを、契約内容と整合する形で決めます。伝達経路を省いて個別に指示を積み重ねる運用は避けてください。

新しい要望が出たときは、対象、理由、費用や日程への影響、承認する人を記録します。小さな修正か、大きな設計変更かは、見た目の大きさだけでは判断できません。影響を説明してもらい、追加、入れ替え、次の工程へ延期のどれにするかを決めます。

進捗は、作業時間や完了件数だけでなく、未決定事項、確認待ち、リスク、次に必要な判断を共有します。外部側の作業が止まっている理由が社内の返答待ちなら、会議を増やすより、判断者と期限を明確にする必要があります。

成果物・知識・権限の引き継ぎを条件に入れる

引き継ぐものは、プログラムだけではありません。設計、設定、運用手順、未解決の課題、テストの結果、アカウントや外部契約の情報が必要になる場合があります。何を、どの形式で、誰へ渡すかを依頼範囲へ含めます。

外部人材の参加期間が終わる場合は、社内や後任が作業を続けられるかを確認します。終了の直前に資料作成をまとめて依頼せず、日々の作業の中で、決めたことと理由を残す方法を決めておくと引き継ぎを進めやすくなります。

アクセス権限の回収、貸与物の返却、データの扱い、外部サービスの名義も確認します。成果物の権利、利用できる範囲、保守の責任などは、名称から推測せず、契約の条項で確認してください。契約の論点を整理する資料として、IPAのモデル取引・契約書も参照できます。

依頼後の見直しは、体制と業務の変化で行う

最初の依頼で合っていた体制も、要件定義から開発、公開後の運用へ進むと、必要な役割が変わる場合があります。契約更新の直前だけでなく、工程の切り替わりで、役割、範囲、期間を見直します。

例えば、構築の経験を重視して受け入れた人に、長期の運用や利用者対応まで当然に任せると、当初の前提が変わります。追加で必要になった仕事を整理し、体制を変えるのか、別の支援を組み合わせるのかを相談します。

単価や人数だけを目標にせず、社内が必要な判断をできているか、業務が引き継げるか、情報へのアクセスが適切かも確認します。調達した役割を活かせる準備が、発注側にも必要です。

発注条件を具体化するための例

同じ改善目的でも、依頼の切り方で体制が変わる

架空の例として、営業の見積管理を改善する会社を考えます。社内に業務責任者と開発リーダーがおり、要件と進行計画は決まっているが、実装を担う人が不足している場合です。この場合は、対象の工程と必要な経験を示し、社内体制へどう参加するかを確認します。

一方、同じ見積管理でも、現状のExcelが部門ごとに違い、業務ルールも未整理なら、実装できる人を一人増やすだけでは進め方を決められません。業務整理や要件の具体化から支援を受ける範囲を考え、社内で何を決めるかも計画へ入れます。

どちらが常に優れているという比較ではありません。業務の目的が同じでも、社内の準備と不足している役割が異なれば、適する依頼が変わるということです。提案を受けた後も、社内に残る仕事を同じ表で確認すると判断しやすくなります。

よくある行き違いを、開始前の確認へ変える

「経験者だから全体の進行も任せられるはず」という期待があるなら、設計や実装と、進行管理のどちらを依頼するかを確認します。担当工程が決まっていない状態で、候補者の経験だけから役割を広げないようにしてください。

「定例会で依頼したので追加費用はないはず」という行き違いには、変更の承認手順を用意します。会議の参加者が、契約条件の変更まで承認できるとは限りません。作業上の相談と、費用や期間に関わる決定を分け、承認者を明記します。

「資料を受け取ったので引き継ぎは終わり」という行き違いには、後任が確認する場を設けます。実行手順をたどれるか、未解決の課題を理解できるか、障害時に連絡先を見つけられるかを確認し、不足を終了前に戻せるようにします。

これらの確認は、外部の支援先を細かく管理することだけが目的ではありません。社内がいつ何を判断し、どこで情報を渡すかを決めることでもあります。発注側と支援側の両方で確認できる条件にすると、開始後の調整を進めやすくなります。

パブロフへ相談する際に伝えたいこと

パブロフのSES（エンジニア提供）では、開発、PM・PMO、インフラ、データ・AIなど、必要な役割に応じた人材のご相談をお受けします。準委任契約が基本で、開始日、勤務形態、精算幅、商流などを個別に確認します。

要件整理から公開・改善までを相談したい場合は、業務アプリ開発もご覧ください。サービス名を先に決めるより、目的、現在の体制、不足する役割、希望時期、予算、未決定事項を伝えていただくと、必要な支援を整理しやすくなります。

この記事のまとめ

条件が未確定でも、相談のために全項目を埋める必要はありません。SESの相談フォームまたは問い合わせ窓口から、課題と依頼したい範囲の概要をお知らせください。