「SES出身だから不利」は正確ではない

自社開発企業の採用担当者がSES出身者を見るとき、「SES経験＝不利」という判断をしているわけではありません。確認しているのは、SESの現場でどの工程に関わり、どれだけ自分で考えて動いてきたかという中身です。運用・保守やテスト作業が中心だった場合は、開発経験として評価されにくい傾向があります。一方で、設計や実装に関わった経験があれば、客先常駐という形態に関わらず評価の対象になります。SESという働き方への先入観よりも、経験の中身が判断の軸になります。

自社開発企業が実際に確認していること

採用面接でよく確認されるのは、実装や設計にどの程度主体的に関わってきたかという点です。「言われたことをこなしていた」のか「課題に対して自分で考えて動いていた」のかを、具体的な経験の話を通じて見ています。また、業務外での技術学習や個人開発の有無も確認されることがあります。自社開発の現場では、プロダクトの改善を主体的に考えていく姿勢が求められるため、学習継続の有無がその姿勢を示す材料として扱われます。GitHubでのコード公開や技術書での学習記録は、具体的な根拠として機能します。

IT人材不足が採用の背景にある

DXを推進するためのIT人材が不足しているという状況は、多くの調査で示されています。エンジニアの採用競争が続く中で、SES出身者に対する間口も広がっています。この市場背景は、転職活動の難易度そのものを下げる要因にはなりますが、準備なしで通過できるという意味ではありません。採用側の要求水準は変わらず、準備の質が選考結果に直結します。市場の追い風を活かすためにも、経歴の整理と志望動機の具体化は欠かせません。

職務経歴書で何を書くか

職務経歴書に書く内容は、案件の名前や期間の羅列ではなく、各案件でどの工程を担当し、どのような技術的判断をしたかという中身になります。「テスト工程を担当」という記述では伝わらないため、「どのテスト項目を設計し、どのような不具合を検出したか」という粒度まで落とします。設計や実装に関わった案件は、使用した技術と担当範囲を具体的に書き出します。複数の現場を経験しているSESの場合、案件ごとに技術環境が異なることが多く、それ自体が幅広い環境への適応力として読まれます。担当範囲・使用技術・工夫した点の3点を軸に各案件を整理します。

面接で経歴をどう話すか

面接での経歴説明は、「何をしていたか」だけでなく「なぜそうしたか」を伝えることが鍵になります。例えば、特定の技術を選んだ理由や、現場で課題が生じたときにどう対応したかという話が、自社開発企業が見たい「考えて動く姿勢」につながります。SESの現場では、クライアントの業務背景やシステムの利用者を意識して動いていた経験があれば、それは自社開発との相性が良い素材です。「業務の目的を理解した上で開発に関わっていた」という説明が、プロダクト志向の姿勢として伝わります。

業務外の経験をどう活かすか

個人開発・GitHubの活用

業務外での技術学習や個人開発は、自社開発企業が重視する「自分で考えて動く力」を示す材料になります。GitHubにコードを公開している場合は、何を作り、なぜそれを作ったかという説明を準備します。リポジトリがあるだけでなく、コミット履歴や実装の意図を説明できる状態にしておくと、面接での説明の根拠として機能します。

学習の継続を示す方法

技術書や学習記録は、継続的に学習していることを伝える手段になります。「どの技術を、なぜ学んでいるか」という文脈を持たせると説得力が増します。「React を業務で使う機会がなかったため、個人開発で習得した」という説明は、業務外の学習が自社開発への志向と結びついていることを示します。学習の積み上げは数ヶ月単位でも十分な材料になります。

「自社開発」と書いてある求人の実態を確認する

求人票に「自社開発」と記載されていても、実態はSESや受託開発が主体の企業という場合があります。確認の鍵になるのは、自社プロダクトの開発がどの程度の割合を占めているかという点です。企業の公式サイトでプロダクトの紹介ページが充実しているか、採用ページに「自社開発○割」といった記載があるかを確認します。また、求人票の「事業内容」欄にプロダクト名や提供サービスの説明があるかどうかも判断材料になります。自社サービスへの具体的な言及がない求人は、開発の実態が異なる可能性があります。

仕事内容とスキル要件から読み取ること

担当工程の確認

求人票の「仕事内容」欄で、実装・設計・企画など上流から下流までどの工程が含まれているかを確認します。「テスト・運用・保守」のみが記載されている場合は、転職後も下流工程が中心になる可能性があります。「機能設計から実装まで」「プロダクトの改善提案も担当」といった記述があると、開発への主体的な関与が期待されていることが分かります。

使用技術とチーム構成の確認

使用技術の欄には、モダンな技術スタックが並んでいるかを確認します。技術の選定が現場のエンジニアに委ねられているかどうかも、面接で確認できる観点です。また、チーム構成やエンジニアの人数が記載されている場合は、チームでの開発体制が整っているかの目安になります。少人数でも役割が明確なチームは、自社開発の現場として機能していることが多いです。

面接で確認しておくこと

求人票では分からない情報は、面接の場で直接確認します。確認しておきたいのは、現在稼働中のプロダクトの概要と開発フロー、エンジニアが企画や改善提案に関与できる余地があるかどうか、そして入社後に担当する業務範囲です。「御社のエンジニアはプロダクトの改善提案にどの程度関われますか」という問いかけは、開発への関与度を確認する上で有効です。面接で質問できる機会は判断材料を集める場として活用します。

在職中に動き始めるタイミングの考え方

SESから自社開発への転職活動は、在職中に進めるケースが多くあります。現在の案件が一段落するタイミングや、次の案件への移行前の期間を活用して準備を進めることが現実的です。転職活動に使える時間の見通しを立ててから、書類作成・求人調査・応募の順で動きます。SES特有の働き方として、案件の切り替えタイミングが転職活動の区切りと重なることがあるため、現場の状況と並行して動けるよう準備の範囲を絞ることが大切です。

準備として先に動かしておくこと

GitHubとポートフォリオの整備

書類応募の前に、GitHubのプロフィールや個人開発のリポジトリを整備しておきます。コードの品質よりも、何を作ろうとしたかという意図と、継続的にコミットしているかという姿勢が見られます。既存のリポジトリに README を追加し、プロジェクトの目的と使用技術を整理するだけでも、面接での説明材料として機能します。

職務経歴書の草案作成

応募を始める前に、現時点での職務経歴書の草案を作成します。書いてみると、案件ごとに経験の厚みが異なることが分かり、どの案件を中心に伝えるかの判断ができます。書きにくい部分が出てきたら、そこがエージェントや転職経験者に確認すべき観点になります。草案の段階で第三者に見てもらうと、「伝わる書き方」と「事実の羅列」の差が分かります。

転職先を選ぶときの判断軸

自社開発への転職で確認しておきたい軸は、入社後に担当できる工程の範囲、プロダクトへの関与度、そして技術環境の3点です。年収の水準も判断材料ですが、入社後に担当する業務の中身が合わないと長続きしにくくなります。SESで経験した技術スタックと大きくかけ離れた環境の場合は、入社後のキャッチアップにかかる時間も考慮します。「この企業のプロダクトに関わりたい」という動機が持てる企業を選ぶと、選考の場での説明にも一貫性が生まれます。