エンジニアの働き方は、大きく3つに分かれます。

SES、受託開発、自社開発。

この3つを分けているのは、技術力でも会社の規模でもありません。「誰から仕事を受けるか」という一点です。

そしてこの違いが、担当できる工程、身につく経験、給与の決まり方にまで影響します。

この記事では、その構造を順番に整理します。

働き方は大きく3つある

まず、それぞれの定義を確認します。

【SES（システムエンジニアリングサービス）】

自社に所属しながら、他社の開発現場に常駐して働く形態です。契約は多くの場合「準委任契約」で結ばれます。準委任契約は、成果物の完成ではなく、業務を遂行すること自体に対して対価が支払われる、という契約です。

【受託開発】

顧客から開発案件を請け負い、自社内で開発を行う形態です。契約は「請負契約」であることが一般的です。請負契約では、成果物を完成させる義務が発生します。納品して初めて対価が支払われる、という構造です。

【自社開発】

自社のサービスやプロダクトを、自社で開発する形態です。外部との受発注関係がないため、契約という概念自体がありません。開発するものを決めるのも、優先順位を決めるのも自社です。

誰から仕事を受けるか

ここからが構造の話です。システム開発の仕事は、多くの場合、複数の企業を経由して現場に届きます。

　発注元（事業会社）

　　↓

　元請け（大手SIerなど）＝プライム

　　↓

　一次請け

　　↓

　二次請け

　　↓

　SES企業

　　↓

　エンジニア

これが「多重下請け構造」と呼ばれるものです。

発注元が支払った金額は、経由する各社の管理費や利益を差し引かれながら、下の階層へ流れていきます。

ここで押さえておきたいのは、「下請けだから技術力が低い」という話ではないことです。

構造上、下の階層に届く時点で仕事の内容がすでに決まっている、というだけです。

受託開発の会社も、この構造の中にいます。発注元から直接受注する「直請け（プライム案件）」もあれば、元請けから再委託を受ける二次請けの立場もあります。

同じ「受託開発」でも、どの位置にいるかで実態は変わります。

担当工程が変わる理由

なぜ、働き方によって担当できる工程が変わるのか。理由はシンプルです。上流の工程は、上の階層で先に終わっているからです。

システム開発は、おおまかにこの順で進みます。

　要件定義 → 基本設計 → 詳細設計 → 実装 → テスト → 運用保守

発注元と元請けの間で、「何を作るか」「どう作るか」はすでに決まっています。

その決定を経て、実装やテストの工数が下の階層へ切り出されていきます。結果として、こうなりやすい傾向があります。

・上の階層 → 要件定義、基本設計に関わる機会が多い

・下の階層 → 詳細設計、実装、テスト、運用保守が中心

自社開発の場合は、この構造自体がありません。

作るものを決めるところから自社で行うため、規模が小さい会社ほど、一人が関わる工程の幅は広くなる傾向があります。

ただし、自社開発なら必ず上流に関われるわけでもありません。

組織が大きくなれば役割は分かれますし、既存サービスの保守が業務の中心になることもあります。

単価と給与の関係

もうひとつ、見えにくい部分を整理します。

SESでは、自社と客先の間で「単価」が決まっています。この単価と、エンジニア本人の給与は、同じではありません。

仮に、契約単価が月60万円だったとします。年間で720万円です。

ここから差し引かれるものがあります。

・自社の営業費、管理費

・会社が負担する社会保険料

・待機期間（案件が切れた月）のリスク分

・会社の利益

この「単価に対して、どれだけ本人に支払われるか」を還元率と呼ぶことがあります。仮に還元率が60%であれば、年収はおよそ430万円という計算になります。

ここで重要なのは、金額そのものではありません。単価が上がっても、還元率が変わらなければ、増えた分の多くは会社側に残るという構造です。

「単価が上がった」と言われたのに給与明細がほとんど変わらなかった。

そういう経験がある場合、それは評価の問題ではなく、仕組みの問題である可能性があります。

受託開発では、案件単位で採算を管理し、自社開発では、事業の売上をもとに人件費が決まります。

いずれも、個人の単価が直接給与に紐づく形にはなっていません。

どの型が向いているか

ここまで読むと、SESが不利な形態に見えるかもしれません。

しかし、そうとは限りません。それぞれに向いている場合があります。

【SESが向いている場合】

・幅広い現場や業務ドメインを経験したい

・待機期間中も給与が支払われる安定性を重視したい

・自社に所属したまま、様々な技術に触れたい

・特定のサービスに縛られず、環境を変えたい

【受託開発が向いている場合】

・納期と品質に責任を持つ経験を積みたい

・顧客との折衝を含めて担当したい

・自社チームで開発を進めたい

【自社開発が向いている場合】

・一つのサービスを継続して育てたい

・技術選定や改善提案に関わりたい

・ユーザーの反応を見ながら開発したい

どれが優れているかではなく、何を積みたいかで選ぶものだと考えてください。ただし、一点だけ注意があります。

SESであっても、携わる工程がテストや運用保守に偏り続けると、職務経歴書に書ける内容が広がりにくくなります。

形態そのものより、「実際に何を担当しているか」を確認しておくことが重要です。

会社を移る前に確認すること

働き方を変えることを検討する場合、求人票と面接で確認しておきたい点があります。

【契約形態と立ち位置】

・自社開発か、受託か

・受託の場合、直請けの案件はどの程度あるか

【担当できる工程】

・要件定義や設計に関わる機会があるか

・入社直後は何を担当することが多いか

【開発体制】

・バージョン管理やコードレビューの運用

・チームの人数構成

・使用している技術と、その選定の経緯

求人票の「幅広い業務をお任せします」という表現は、裁量が大きい場合と、役割が定まっていない場合の両方があり得ます。

どちらなのかは面接で確認してください。

なお、客先常駐において、常駐先から直接的な指揮命令を受けている状態は、契約形態によっては問題となる場合があります。

現在の働き方に疑問がある場合は、労働局の相談窓口など、専門の機関に確認することをおすすめします。

まとめ

１. 3つの違いは「誰から仕事を受けるか」で決まる

２. 上流工程は上の階層で終わっているため、担当範囲が変わる

３. 単価と給与は同じではない。還元率という考え方がある

４. SESにも向いている場合がある。形態より「実際の担当工程」を見る

５. 移る場合は、契約形態・担当工程・開発体制の3点を確認する