SESから受託開発へ転職すると何が変わる？向いている人と注意点

SESから受託開発へ移れば、案件や技術を自由に選べるとは限りません。会社が受注した仕事を担当するため、顧客の既存環境や納期に合わせて開発することになります。

受託会社の中でも、毎回個別に作る会社と、得意な業務や共通部品を使って提案する会社では、仕事の組み立て方が違います。転職先を見る際は、受注した仕事を納める体制に加え、次の開発へ知識や部品をどう残しているかも確認してください。

受託開発では受注範囲と納期にどう関わるかを見る

受託開発は、顧客から依頼を受けた開発業務を行う形です。SESで担当者として参画していた人が、受託チームへ移ると、実装以外に見積もり、仕様の確認、テスト、納品後の対応まで担当する可能性があります。ただし、SESでも同様の業務を担うことはあり、転職による変化は現在と次の担当範囲を比べて判断します。

「受託」という呼び方だけで契約内容は決まりません。IPAの情報システム・モデル取引・契約書（アジャイル開発版）は、外部委託する開発について、業務の遂行を対象とする準委任契約を前提にしています。受託開発をすべて成果物の完成を約束する請負契約と考えず、応募先がどのように仕事を受注しているか確認します。

転職の判断では、法律用語だけで比較するより、担当する仕事への影響を聞くと具体的になります。

顧客と会社の約束を、社員個人がすべて引き受けるわけではありません。責任者の判断と自分の担当作業を分けて確認します。また、SIerが受託開発を行う場合もあります。顧客業務や複数ベンダーの調整を主に目指すなら、SIerへの転職で見る役割も参考になります。

毎回ゼロから作る会社か、提案に使う資産を育てる会社か

山田は、2026年5月のクライアントワークへの先行投資を論じたnoteで、試作や共通部品へ先に投資し、それを使って顧客へ提案する考え方を示しています。完成したSaaSを最初から作り切るより、顧客の仕事を通じて再利用できる部分を育てる、という主張です。

これは社員の無給労働を勧める話として読むものではありません。会社がどこへ開発費用や時間を使い、受注前の準備と有償の開発をどう組み合わせるかという、事業の作り方の話です。転職先には、検証や共通化を通常の業務として誰が担当するかを確認します。

たとえば承認機能を繰り返し開発する会社なら、顧客ごとに異なるルールと、共通化できる履歴・通知などを分けているかを聞きます。共通化した部分の保守担当、修正時の確認範囲、別案件への適用方法まで決まっていれば、単発の実装以外にも担当できる仕事があります。

ただし、顧客向けに作ったコードを自由に再利用できるとは限りません。契約上の取り扱いと会社の許可を確認し、利用できる範囲で共通化します。共通部品があるという説明だけで、技術的な経験を積めると判断せず、自分が変更や設計に関われるかまで確かめます。

小規模チームの業務量と複数案件を確認する

少人数で納期まで開発する体制では、不具合対応や追加確認が発生しても、代わりに担当できる人が限られます。実装者がテストや顧客への説明も担っている場合、同じ人へ作業が集中しやすくなります。

一方、経験のある技術者から見積もりや設計のレビューを受けられ、小さな開発を最初から最後まで担当できるなら、その範囲を学びたい人には選ぶ理由があります。小規模であること自体を問題にせず、仕事を分担・調整する方法と、誰から何を学べるかを確認してください。

複数案件を並行する会社なら、新規開発の途中に別案件の保守依頼が入る場合も考えられます。案件数だけでなく、割り込み対応が起きた際に、元の作業の期限や担当を誰が調整するかを聞きます。

山田は、2026年5月の顧客への提案から始める開発のnoteで、納品範囲を明確にすることを挙げています。現場の働き方として考えると、追加の要望が来たときに、元の約束との違いを確認し、作業量や期限を相談できるかが判断点になります。

残業については、会社全体の説明だけで判断せず、配属予定のチームの通常期と納品前の働き方を確認します。「納期前は忙しい」という回答なら、繁忙が続くときの増員、作業範囲の変更、納期相談をどう行うかまで尋ねます。受託へ移ること自体が、残業を減らす方法になるとは限りません。

受託でも使用技術を自由に選べるとは限らない

受託会社が使う技術は、会社が受けた案件の要件や顧客の環境に左右されます。顧客が長く使うシステムの改修なら、既存の言語・製品を維持する方針もあり得ます。

技術選定に参加できる仕事でも、候補を自由に採用できるとは限りません。納期内に実装できるか、チームが保守できるか、顧客の運用と合うかを説明する必要があります。「新しい技術を使いたい」という希望と、「案件に合う技術を選ぶ役割」は分けて考えます。

特定顧客の仕事が中心の会社なら、転職後も同じ顧客や技術を長く担当する可能性があります。案件一覧に幅広い技術名が載っていても、配属予定先で何を使い、別案件へ移れる条件は何かを確認してください。

想定ケース：改修の見積もりと、次にも使える手順を作る

以下は、SESで画面改修を担当する人の想定ケースです。実装と単体テストはできるものの、作業の見積もりや顧客の受け入れ確認には関わっていない状態を考えます。実際の転職成功例ではありません。

今のまま移ると不足する説明

受託会社が、改修の作業量を見積もり、納品まで担当できる人を求めているなら、実装スピードだけでは期待に応えられるか判断できません。どこまでを作業に含め、何を確認して完了とするかを説明する必要があります。

今の現場で試す行動

次の小さな改修について、上位者へ見積もり案の作成を申し出ます。実装だけでなく、影響調査、レビュー対応、テスト、リリース準備を分け、作業量が変わる前提も添えます。自分で納期を約束せず、上位者に不足を確認してもらいます。

作業を進めたら、想定との差と理由を記録します。仕様変更で作業が増えた場合は、増えた範囲を整理し、対応順序の判断を求めます。完了前には、依頼された変更と確認結果を照合する作業も担当できるか相談します。

その後、同じ調査を次回も繰り返さずに済むよう、確認項目を社内のひな型へ残す作業を提案します。既存の共通部品を使えるなら、今回の改修に合わない条件を洗い出し、変更の要否を上位者と相談します。独断でコードを共通化せず、再利用できる条件を整理するところから担当を広げます。

実績として話せる状態

転職時には、見積もりに含めた作業、漏れていた項目、途中で報告した変更、完了を確認した方法を説明します。確認手順の整備まで行ったなら、誰がどの仕事で使えるようにしたかも示します。見積もりが外れたとしても、原因を確かめて次の見積もりへ反映した事実は話せます。顧客との費用交渉をしていないなら、その経験まで含めないでください。

未経験の工程をどこから担当するか迷う場合は、転職前に実務経験を作る方法を参照してください。

受託開発との相性を面接で確かめる

担当範囲を広げ、他のメンバーと納品まで調整する仕事を望むなら、受託開発は候補になります。一方、使う技術を自分で決めることや、開発だけに集中することが最優先なら、その希望が配属先で成立するかを確かめます。

面接では、次の質問を仕事内容とセットで聞きます。

• 配属予定のチームは、何人でどの作業を分担していますか
• 同時に担当する案件と、保守の問い合わせ対応はありますか
• 顧客から仕様変更が来た際、費用や納期を誰が調整しますか
• 見積もりやテストのレビューは誰が担当しますか
• 技術を選ぶ余地があるのは、どの案件・どの工程ですか
• 試作や共通部品の改善には、誰がどの時間を使っていますか
• 納品前に作業が集中した場合、どのように調整していますか

回答を今の担当範囲と比べ、増える責任と支援体制の両方を確認してください。他の働き方と迷う場合は、自社サービス・SIer・受託・SESの比較へ戻り、変えたい条件の優先順位を整理できます。