SESと派遣の違いを徹底比較

契約と責任の本質的な違い（現場がつまずくポイント）

互いに「外部の人が現場で働く」構図は同じでも、SESと派遣は根っこの前提がまったく違います。SESは準委任が中心で「成果の完成」ではなく「専門的な業務遂行」に対価が支払われ、現場での具体的指揮命令はベンダー側のリーダーが担います。一方、派遣は受け入れ企業が日々の指示を直接出す前提です。ここを取り違えると、SESに対して細かな作業指示を出してしまったり、派遣に成果責任を乗せてしまったりして、炎上の芽になります。

指揮命令と成果の線引き

• SES：受け入れ側は「依頼と優先度の提示」「検収の観点」を示す。日々の進め方やタスク分解はSES側リーダーが設計。
• 派遣：受け入れ側が「作業手順・品質基準・スケジュール」を直接指示。足りない手順は受け入れ側が整備。
• 成果物責任：SESは合意した範囲での業務遂行責任（不確実性を一緒に潰す）。派遣は与えられた手順に基づく作業責任（段取りは受け入れ側）。
• 避けたいリスク：SESへの直接指揮（偽装請負リスク）、派遣社員の再配置を重ねる二重派遣。

受け入れの実務チェックポイント

• 役割分担表：指示系統（誰が依頼し、誰が計画し、誰が承認するか）を1枚で明文化。
• 作業範囲の定義：チケットテンプレート（目的/完了条件/制約/参考資料/セキュリティ分類）。
• 検収基準：レビュー観点、テスト通過条件、出来高の示し方（例：バックログ消化率）。
• コミュニケーション窓口：プロダクト側1名、ベンダー側1名のペアを固定。
• 時間精算の運用：精算幅、超過/減額の判断日と承認フロー。
• アクセス管理：アカウント発行と権限棚卸の頻度、退場時の回収手順。
• 知財と秘密情報：成果物の権利帰属、二次利用可否、生成AIの取り扱い。
• 撤退計画：引き継ぎリスト（設計、スクリプト、手順書、ダッシュボード、環境変数）。

コスト・生産性・リスクを数字で見比べる

コストは「見える単価」より「運用の総コスト」を見ます。派遣は時給が分かりやすい反面、手順書の整備・指示出し・レビューに社内工数が乗ります。SESは人月や時間精算（例：140〜180h）で見える化され、計画と品質設計をベンダー側が持つため、受け入れ側の管理工数を削れます。

• 調達リードタイムの目安：派遣は1〜2週、SESは2〜4週（スキルサーチと体制設計に時間を使う）。
• KPI例：バーンダウンの予実差±10%以内、レビュー実施率95%、欠陥密度をスプリントごとに-10%改善。
• 隠れコスト：属人化解消のドキュメント整備、オンボーディング、引き継ぎ期間の二重稼働。
• リスク対応：SESは要件の曖昧さを前提に「探索→設計→実装」の仮説検証で前倒しに潰す。派遣は要求が明確な定型業務に当てることで品質を安定。

生成AIや支援ツールの併用で生産性はさらに変わります。要件整理や仕様の明文化にはChatGPTやClaude、コード補完にはCopilot、テスト観点出しにはGeminiを使うと、設計・ドキュメントの欠落を減らせます。ツール利用ポリシーとレビュー工程をセットで設計するのがコスト最適化の近道です。

現場での使い分けパターンと判断フロー

派遣が向くケース

• 定型の運用・監視・キッティング・ヘルプデスクなど、手順とSLAが明確。
• 短期の欠員補充、繁忙期の一時的な増員。
• ツールや社内手順が整っており、指示を細かく出せるマネージャがいる。

SESが向くケース

• 新規開発、アーキテクチャ見直し、SRE改善など、不確実性が高い領域。
• 要件が曖昧で、探索・設計・プロトタイプから伴走してほしい。
• 内製化の立ち上げで、型（レビュー/CI/CD/計測）を一緒に作りたい。
• 高い守秘や知財配慮が必要で、成果物の品質・再現性を担保したい。

判断フローはシンプルで構いません。「要件は固いか」「手順は書けるか」「成果の不確実性は高いか」を三問で評価し、固い×書ける×不確実性低＝派遣、どれか一つでもNoならSESで体制を組みます。混在も有効で、SESで設計と型を作り、派遣で日々の運用をスケールさせるのが実務的です。

身近な企業活用例：従業員200名規模の製造業、基幹刷新の迷走→立て直し

地方の従業員200名規模の製造業が販売・在庫・生産をつなぐ基幹システムを刷新。最初は派遣3名で着手し、業務部門が日次で指示を出す形にしました。ところが、要件が毎週変わり、チケットは増えるのに設計が追いつかず、3カ月でスケジュールが6週遅延。属人化したSQLと手作業の移行手順がボトルネックになりました。

転機は体制の再設計です。派遣1名を運用準備に残し、SESでテックリード1名とスクラムマスター1名を追加。契約も「作業指示」から「バックログ単位の成果定義」に改め、2週間スプリントで進行。ChatGPTで議事録要約とユーザーストーリー整形、Copilotで単体テストの雛形生成、Geminiで負荷テスト観点の洗い出し、Claudeで設計レビューの論点整理を実施しました。

8週間後、バーンダウンの予実差は±8%に収まり、欠陥密度はリリース前テストで30%低下。退場時の引き継ぎパッケージ（データモデル、移行スクリプト、運用Runbook、監視ダッシュボード）を整備でき、運用移管は2週間で完了。派遣は手順が固まったキッティングと一次対応に集中し、SESは不確実性の高い設計と移行の山場に専念することで、コストとリスクの山を平らにできました。

結局のところ、派遣は「決まっている仕事を速く・漏れなく回す」ための選択肢、SESは「まだ決まっていないことを一緒に決め、仕組みに落とす」ための選択肢です。内製化や継続改善を視野に入れるなら、まずSESで型と基準を作り、その後に派遣や自社メンバーへ展開する流れが現場では扱いやすいはずです。常駐エンジニアとしてのSESは、変化が前提のフェーズで真価が出ます。契約と受け入れの設計を丁寧に行い、意思決定に使える指標を置けば、事業のスピードと品質は両立できます。