SESから自社開発・元請けSIerへ転職するには？職務経歴書と面接の準備

SESを抜けたい理由を分ける

SESを抜けたいという気持ちには、収入・スキル・評価という別々の問題が重なっていることがあります。どれが自分にとっての主因かによって、次に向かうべき先も、準備すべきものも変わってきます。まずは3つに切り分けてみてください。

単価と給与の差が見えない

常駐先に請求されている単価を何かのきっかけで知り、自分の給与との差に戸惑うことがあります。差額の一部は営業や間接部門の費用、待機期間の人件費に充てられているはずですが、その内訳が説明されないまま昇給だけが止まっていると、根拠のない差に見えてきます。

この差が主因なら、確かめるべきは自社の評価制度よりも、そもそも自分の会社が発注元から数えて何番目にいるかです。次のセクションで、その確かめ方を扱います。

身につく技術が案件で決まる

次にどの現場へ行くかを自分で選べないため、身につく技術が配属先に左右されます。運用保守や単体テストの現場が続くと、経験年数の割に設計や要件定義に触れないまま時間が過ぎることになります。3年働いて振り返ったときに、書ける経験が現場の名前だけになっているという状態は、能力の問題ではなく配属の偏りから生まれます。

これが主因なら、腰を据えて一つのプロダクトに関われる自社開発企業が候補に入ります。

評価する人と現場が離れている

日々の働きぶりを見ているのは常駐先の人で、給与を決めるのは自社の人です。この分離があるかぎり、現場での評価がそのまま処遇に反映されるとは限りません。「正当に評価されていない」という感覚の正体は、努力の量ではなく、評価する人と観察する人が別だという構造にあります。

これが主因なら、評価者と同じ場所で働ける環境、つまり自社開発企業や事業会社の情報システム部門、あるいは自社で案件を持つ元請けが選択肢になります。

今いる商流の位置を知る

不満の出どころを見極めるには、自分の会社が発注元から数えて何番目にいるかを先に確かめます。仕事は上の層から下の層へ、工程を切り分けながら渡されていきます。要件定義や基本設計は発注元と直接やり取りする層が受け持ち、下の層に渡されるのは切り出された製造やテストが中心になります。つまり自社がどの層にいるかで、会社に発注されてくる工程の範囲があらかじめ決まっているということです。設計を任されないのは頑張りが足りないからではなく、その工程が自社に発注されていないためという場合があります。

公正取引委員会が令和4年6月に公表した「ソフトウェア業の下請取引等に関する実態調査報告書」は、この多層化を数字と事例で示しています。同調査では、資本金3億円以下の事業者2万1000社にアンケートを依頼し4,739社から回答を得ており（回答率22.6%）、報告書は「細分化と再委託の繰り返しで商流が多層化・複雑化し、極端に長い商流が形成される場合がある」と記しています。回答者の声としては「個人事業者として活動していた際に6次下請の末端技術者として参加したことがある」「エンジニアの準委任契約では最大5社が中間に入るケースがある」といった事例が報告されました。

商流上は関与するものの実際の業務を行わない「中抜き」事業者について、存在を感じたことがあると答えた割合は、全体で25.9%、最終下請では33.5%に上ります。実際に受注してから商流を辿ったところ、聞いていた1社ではなく4社が間に入っていたという回答も掲載されています。買いたたきについても報告書は、再委託のたびに中間マージンが差し引かれるため「下層に行くほど、受注金額が低くならざるを得ない」と説明しています。

自分の位置は、次のような点から推し量れます。

• 注文書や契約書の宛先が、実際に業務を発注している会社と同じか
• 常駐先の会議に、自社と常駐先以外の会社の担当者が何社分いるか
• 自分の担当が設計以降まで及ぶか、製造とテストに限られているか
• 常駐先の担当者が、自社の営業や管理者を通さずに直接作業を指示してこないか

最後の点は契約形態にも関わります。同じ報告書はSESを「技術者を派遣しシステム開発・インフラ環境構築等を行うサービスを提供する契約。準委任契約、常駐型が多い」と定義しています。準委任契約であれば、作業の指示は自社の管理責任者を通すのが原則です。厚生労働省の疑義応答集は、発注者から請負事業主への注文自体は指揮命令にあたらないとしたうえで、「発注者が直接、請負労働者に作業工程の変更を指示したり、欠陥商品の再製作を指示したりした場合は、直接の指揮命令に該当することから偽装請負と判断されることになります」と示しています。区分は契約書の形式ではなく実態で判断されるとされており、気になる点があれば都道府県労働局が相談先になります。

自社開発企業へ移る

移り先は自社開発企業と元請けのSIerに大きく分かれます。ここでは前者を、次のセクションで後者を扱います。

自社開発企業に移ると、対象が自社のプロダクトになるため、企画や要件の検討から実装、運用改善までの一連に関われる可能性が高くなります。技術の選定に意見を出せる場面も生まれます。そして評価する人が同じ会社にいるので、現場での働きが処遇に届くまでの距離が短くなります。

一方で選考の関門は変わります。書類のあとに技術面接が置かれることが多く、設計力を測るために面接で設計課題が出されるケースも増えていると説明されています（出典: GeeklyMedia「SIerと自社開発の違い｜求められるスキルや転職のポイントを解説」）。求められるのは幅広い言語の知識よりも、自社が使う言語への深い理解と、他部署の担当者と日常的にやり取りする力だとされています。

もしあなたの実務が運用保守中心で、まとまった量のコードを書いた経験が少ないのであれば、応募を始める前に小さくても動くものを一つ作っておくほうが選考は進みやすくなります。規模の大きさより、設計の意図を自分の言葉で説明できることのほうが面接では効きます。

ただし良い面だけではありません。扱う技術がプロダクトに固定されるため、触れる範囲はむしろ狭くなります。事業の状態がそのまま自分の職に跳ね返る点も、複数の現場に分散していたSES時代とは違います。複数の業界の現場を渡り歩いて業務知識を広げるような働き方は、ここでは選べなくなります。

この記事の最初に挙げた収入・スキル・評価の3つのうち、身につく技術の偏りが主因だった人には、この方向が噛み合いやすいといえます。収入の差が主因だった人は、次のセクションもあわせて読んでから決めてください。

元請け・プライムへ移る

元請け、いわゆるプライムの立場に移ると、発注元と直接契約する側になるため、要件定義や基本設計といった上流の工程が業務範囲に入ります。プロジェクトの予算と期間を決める側に回るということでもあります。階層が下にあるほど上流が回ってこないという構造を裏返せば、商流を上げること自体が担当工程を広げる方法になります。

賃金の水準も、規模によって分布が変わります。厚生労働省の令和6年賃金構造基本統計調査（一般労働者・産業計）で職種別に見ると、ソフトウェア作成者の所定内給与額は企業規模計で357.0千円ですが、常用労働者1,000人以上の企業では384.5千円、10〜99人では343.3千円です。差がより大きいのは年間賞与その他特別給与額のほうで、1,000人以上が1,433.9千円、100〜999人が1,050.0千円、10〜99人が799.4千円と、上下で60万円以上開きます。

職種そのものが上流側に寄ると、水準はさらに変わります。システムコンサルタント・設計者の所定内給与額は431.7千円で、ソフトウェア作成者との差は月あたり70千円を超えます。ここまで挙げた金額は、いずれも男女計の数値です。ただしこれは職種と規模ごとの分布であって、移れば必ずこの差額が得られるという意味ではありません。システムコンサルタント・設計者は平均年齢41.4歳、平均勤続14.5年と、ソフトウェア作成者の38.0歳・10.7年より上の層である点も割り引いて読む必要があります。

選考で見られる中身も自社開発とは異なります。SIerではクライアントと円滑にやり取りする力、論理的に筋道を立てて説明する力、そして幅広い言語や技術に対応できる知識が挙げられています（出典: ウィルオブテック「SIerと自社開発の違いとは? 必要なスキルや転職での注意点を解説」）。コードそのものより、担当した工程の広さと扱ったシステムの規模が評価の材料になります。

もしあなたが常駐先の会議で顧客の担当者と直接やり取りしているなら、それはこの方向の選考で評価される経験です。窓口が自社の営業だと思って書き漏らしがちな部分なので、職務経歴書に残してください。

こちらも良い面だけではありません。組織が大きくなるほど一人が受け持つ範囲は狭くなり、設計そのものより進捗や品質の調整に時間が割かれます。手を動かし続けたい人にとっては、上流に上がったはずが実装から遠ざかったという結果にもなり得ます。

収入の差が主因だった人は、まずこの方向から見ることになります。ただし規模による違いは分布の話なので、応募先ごとに給与の決め方と賞与の算定方法を確認したうえで判断してください。評価のされ方が主因だった人は、自社で受託している案件の比率が高い会社を選ぶと、評価する人と働く場所が離れる状態を避けやすくなります。

動くタイミングの目安

在籍年数そのものより、職務経歴書に書ける案件が一つ完結しているかどうかが判断の材料になります。次の2点で見てください。

一つの案件を通せているか

同じ現場で、要件を受け取ってから本番稼働までを一度経験しているかどうかです。経験していれば、担当した工程・使った技術・関わった規模の3点が書けます。案件を一つも完結させないまま動くと、書けるのは参加した事実だけになり、次の会社でも同じ立場からの再スタートになりやすくなります。

担当が広がっているかも合わせて見ます。テストだけだった人が詳細設計を任され始めた、後から入った人に手順を教える側になった、といった変化があれば、それ自体が書ける材料です。

契約更新の区切りに合わせる

常駐の案件は契約更新の単位で区切られていることが多く、区切りに合わせて離れるほうが引き継ぎの負担は軽くなります。ただし更新を待ち続けると動けないまま次の更新が来るので、更新月の1〜2か月前には職務経歴書の作成と情報収集を始めておくのが現実的です。

在職中に活動するか、辞めてからにするかも早めに決めておきます。常駐していると平日日中の面接は組みにくく、日程調整に時間がかかるためです。ここまで読んで「今の環境が自分に合っている」と感じたなら、無理に動く必要はありません。現場が変わるたびに新しい技術に触れられることを楽しめている人や、複数の業界の業務知識を広く積みたい人にとっては、SESという働き方のほうが噛み合っている場合もあります。

在職中に進めるとなると、求人を自分で探し続ける時間はほとんど取れません。経験者を対象にした転職サービスの得意領域をあらかじめ見比べて、当たりをつけてから登録するほうが、限られた時間を使い切らずに済みます。

参考記事：ITエンジニアにおすすめの転職エージェント10選｜経験者向けに比較

客先常駐の実績の書き方

SESから転職できないと言われることがありますが、書類で止まる原因は経験不足そのものとは限りません。経験が職務経歴書の上で見えなくなっている場合があります。常駐先の名前と案件名だけが並んだ書類からは、その人が何をどこまでできるのかが読み取れません。ここを直すだけで、通過する書類に変わることがあります。

担当工程・技術・規模の3点を添える

案件ごとに、担当した工程、使用した技術、関わった規模の3点を添えます。工程は要件定義・基本設計・詳細設計・製造・単体テスト・結合テスト・運用保守のどこにいたのかを書きます。技術は言語、フレームワーク、ミドルウェア、クラウドまで。規模はシステムの利用者数、チームの人数、自分が見ていた範囲です。

書き換えの例を2つ挙げます。運用保守の場合、記載例は次のように変わります。

【前】大手金融機関のシステム運用保守を担当。

【後】金融機関の勘定系サブシステムの運用保守を担当。夜間バッチの異常終了に対する一次切り分けと再実行の判断を受け持ち、手順書に載っていない事象は原因を絞り込んだうえで開発チームへ引き継ぎました。環境はLinux、Oracle、シェルスクリプト。運用チーム6名のうち、一次対応の当番を週1回担当。

開発に参加した場合は次のようになります。

【前】Webシステムの開発に参加。

【後】会員管理システムの追加開発に、詳細設計から結合テストまで参加。担当機能は会員情報の一括更新とCSV出力の2本で、JavaとSpring Boot、データベースはPostgreSQLを使用。開発メンバー8名の体制で、担当機能の詳細設計書の作成と単体テスト項目の設計を任されました。

前後で経験そのものは何も変わっていません。変わったのは、読んだ人が「この人にどの工程を任せられるか」を判断できるかどうかです。

常駐先の社名を書けないとき

常駐先の会社名を書くことは避けるべきとされています。SES契約ではクライアントと秘密保持契約を結んでいることが多く、企業名を書くと契約違反になる可能性があるためです。どのような案件に携わったかを書き、常駐先や製品名は書かない、という切り分けになります（出典: レバテックキャリア「SESの職務経歴書の書き方・例文を紹介！フォーマットや記載注意点を紹介」）。

書けない代わりに使うのは、業界とシステムの種別と規模の組み合わせです。「金融機関の勘定系サブシステム」「通信事業者の会員管理システム」「自治体の基幹系システム」のように書けば、社名を出さずに現場の性格が伝わります。逆に情報量が乏しいのが「大手企業のシステム」という書き方で、これでは何も伝わりません。所属は自社名を書けるので、自社に在籍しながら常駐していた関係は、会社名と配属先の記載を分けて表します。

複数の案件をどう並べるか

短い案件を時系列に並べるだけだと、採用担当者が全部を追い切れません。重要度の高い案件や応募先と関連の深い案件を先に置き、そうでないものは簡略化するか記載自体を省く工夫が必要とされています。共通する技術領域でまとめる書き方も有効です。「Java系の業務システム」「Linux/ネットワーク基盤」のように束ねると、渡り歩いた経歴が一貫した専門性として読めるようになります。

いちばん長く関わった案件を厚く書き、他を数行に収める配分にすると、書類全体の分量も収まります。専門用語を並べすぎない配慮も必要です。最初に書類を見るのが人事部門の担当者である場合、技術用語が続くと経歴の理解が止まってしまいます。

自分で動いた事実を一行足す

指示された作業をこなしただけの記述が並ぶと、受け身な人だと読まれかねません。指示されていない範囲で動いた事実を一つ拾い出して、案件ごとに一行足してください。思い出すための問いを3つ挙げます。

• 手順書やマニュアルを、自分で書いた、あるいは直したことはないか
• 障害や問い合わせで、自分が最初に見て原因を切り分けた場面はないか
• 後から入ってきた人に、業務や環境を説明した経験はないか

一つでも当てはまれば、「手順書を改訂した」「障害の一次切り分けを担当した」「新規参画者の教育を担当した」と書けます。この一行があるかどうかで、書類の読まれ方は変わります。

面接で問われる転職理由

SESからの転職では、志望動機より先に「なぜ今の会社を出るのか」が問われます。ここで不満をそのまま述べると、環境が変わればまた同じことを言う人だと受け取られかねません。不満を消す必要はありませんが、話の重心を移す必要があります。

組み立ては3段で考えます。最初のセクションで特定した主因を出発点にして、その原因がSESという働き方の構造から来ていることを説明し、次の環境で何をしたいかへつなげます。原因を構造に置くと、今の会社への非難にならずに済みます。

言い換えの例を2つ挙げます。

【前】単価と給与の差に納得できません。

【後】担当範囲が運用の一次対応に固定されていて、設計から関わる経験が積めていません。次は要件を決める段階から関わり、その結果まで見届けられる環境で働きたいと考えています。

【前】案件を自分で選べないのが不満です。

【後】金融と通信の現場を経験して、業務知識よりデータベース周りの設計に手応えを感じました。特定のプロダクトに腰を据えて、性能の改善まで責任を持てる立場に移りたいと考えています。

不満が無かったことにするわけではありません。事実として一度認めたうえで、次に何をしたいかに時間を使う、という配分の話です。聞かれてもいない不満を先に長く話す形にしなければ、誠実さは損なわれません。

SESの経験が強みとして働く場面もあります。複数の現場に短期間で入り、その都度やり方の違う環境に合わせてきたこと。自社と他社の混成チームで、指揮系統が単純でない中を動いてきたこと。どちらも入社直後の立ち上がりの速さを裏づける材料になります。エピソードは「慣れました」ではなく、参画から何をして何日で立ち上がったかまで話せるものを選んでください。

逆質問では、移った先で同じ悩みを繰り返さないための点を確認します。

• 配属や担当プロジェクトはどのように決まるのか
• 自社で受託している案件と、常駐を伴う案件の比率はどのくらいか
• 評価は誰が、どの情報をもとに決めているのか
• 入社して1年で任される範囲はどのあたりか

退職前に確認すること

常駐している以上、退職は自社との話だけでは終わりません。案件の区切り、常駐先への伝え方、入社時に交わした書類の3つを、辞めると決める前に確認しておきます。

申し入れの時期は、まず自社の就業規則を見ます。期間の定めのない雇用契約については、解約の申入れから2週間が経過すると雇用契約が終了すると民法第627条第1項に定められており、退職届の場合は使用者の承諾は不要とされています（出典: 連合「労働相談Q&A 22．退職の自由」）。とはいえ実務では、就業規則の定めと案件の区切りを見ながら日程を決めるほうが摩擦は少なくなります。

案件の途中で離れる場合、常駐先への連絡は自社の営業や管理者を通すのが原則です。準委任契約の当事者は自社と発注元であり、要員の変更もその間で調整されるためです。引き継ぎは口頭ではなく形に残します。担当していた機能の一覧、手順書に書かれていない運用上の注意、問い合わせ先の対応表などをまとめておくと、後任にも自分にも後腐れが残りません。

入社時の誓約書や雇用契約書に、競業避止義務や引き抜きの禁止、常駐先への直接転職の禁止といった条項が入っていることがあります。ここで押さえておきたいのは、条項があるからといって、そのまま効力が認められるとは限らないという点です。経済産業省の「秘密情報の保護ハンドブック」（平成28年2月策定、令和6年2月最終改訂）は、参考資料として競業避止義務契約の有効性を整理しています。退職後の競業避止義務は職業選択の自由を侵害し得ることから制限的に解されているとしたうえで、有効性の判断でポイントになる項目として次を挙げています。

• 守るべき企業の利益があるかどうか
• 従業員の地位
• 地域的な限定があるか
• 競業避止義務の存続期間
• 禁止される競業行為の範囲に必要な制限が掛けられているか
• 代償措置が講じられているか

同資料は、守るべき利益を保全するために必要最小限度の制約であれば有効性は認められると考えられるとし、個別の事案は民法第90条に該当するか否かで判断されると説明しています。

常駐先から直接誘われた場合も、この条項が関わってきます。自社を通さずに話を進める前に、まず手元の誓約書を読んでください。

相談先の選び方

自社開発を狙うのか元請けを狙うのかで、使う窓口が変わります。担当者に相談しながら求人を絞りたいのか、企業の中身を自分で見て直接やり取りしたいのかで選んでください。

レバテックキャリア

ITエンジニアとWebデザイナーに対象を絞った転職支援サービスです。アドバイザーへの相談から始まり、1〜1.5時間のカウンセリング、求人の紹介、書類の添削と企業ごとの面接対策、内定後の年収交渉と入社日の調整まで担当が付きます。電話やオンラインにも対応しており、常駐先での勤務が続く状況でも時間を作りやすい形になっています。

公式サイトが特徴として挙げているのは求人票の情報量で、業務の中身と開発環境に加えて、エンジニアをどう評価するかの方針まで記載されているとしています。今の環境で評価の仕組みが見えないことに悩んでいるなら、求人票の段階でそこを読み比べられる意味は小さくありません。登録は無料で、応募を強制されることはないと明記されています。

Green（グリーン）

アトラエが運営する、IT・Web業界を中心とした転職サービスです。エージェントを介さず、企業の担当者と直接メッセージをやり取りする形をとっており、企業からスカウトを受け取ることも、自分から気になる求人へ応募を送ることもできます。自分のペースで選考を進められる点を公式が特徴として挙げています。

掲載企業のページには写真や記事が置かれ、職場の雰囲気やカルチャーを見てから判断できる作りです。自社開発企業を候補にするなら、技術スタックや開発体制を自分の目で確かめてから応募したい場面が出てきます。そのときにこの形が向きます。

どちらを使うにしても、相談や応募の前に手元で済ませておくことがあります。担当工程・技術・規模を書き足した職務経歴書の素案です。これがあるかないかで、初回の面談で出てくる求人の質が変わります。

まとめ

SESから次に移るまでの流れは、不満を切り分けるところから始まります。押さえておきたいのは次の4点です。

• 収入・スキル・評価のどれが主因かを分ける
  • 主因によって、向かう先も準備するものも変わる
• 自分が商流のどの層にいるかを確かめる
  • 契約書の宛先、常駐先の会議の顔ぶれ、担当工程から推し量れる
• 自社開発企業と元請けのどちらが自分に合うかを選ぶ
  • 前者はコードと設計、後者は担当工程の広さと顧客との折衝が見られる
• 職務経歴書を書き直してから動く
  • 常駐先名は書かず、業界とシステム種別と規模で表す

最初の一歩は、職務経歴書の案件欄を開いて、いま書いてある一行に担当工程・使用技術・規模の3点を足すことです。今日書けるのは直近の案件だけで構いません。そこに一行足せたら、次の案件へ遡ってください。