SESから自社サービスへ転職するには？技術力に加えて必要な事業への視点

SESから自社サービスへ転職するなら、担当できる技術業務に加え、その会社の事業へどう関わりたいかを考えます。機能を実装して終わりではなく、使われ方や運用、売上や業務効率への影響にも関心を持てるかが、働き方との相性を判断する材料になります。

自社サービスは、エンジニアが好きな技術を試すためだけの場所ではありません。サービスを使ってもらい、継続して提供するために開発します。技術の専門性を深めたいのか、技術以外の仕事も含めて事業に関わりたいのかで、応募先へ確認する内容は変わります。

自社開発という言葉より、誰の事業を担うかを見る

求人の「自社開発」が、自社サービスを指すのか、社内で行う受託開発を指すのかは、募集内容から確認します。働く場所が自社内でも、顧客から受注したものを開発するなら、ここで扱う自社サービスとは仕事の前提が異なります。

この記事の対象は、自社が企画・運営するサービスの開発です。自社で決めることが増える一方、何を作るかは事業の状況や利用者の課題から判断します。新しい技術を試すことより、既存機能の改善や運用上の問題解決を優先する場面も考えられます。

自社サービスなら必ず技術力が伸びるとは限りません。レビュー体制、技術上の課題、担当範囲を求人ごとに確かめます。他の働き方も含めて検討したい場合は、SESからの転職先を比較する親記事を参照してください。

山田がミッションへの共感を重く見る採用に異論を示す理由

山田は、2024年6月の開発チームづくりを扱ったnoteで、事業へのコミットやミッションへの共感を重く見る採用観に異論を示しています。採用では技術力を見て、入社後にエンジニアを事業へ向けるのはマネジメントの仕事だ、という主張です。一般的な採用基準の説明ではなく、採用時の共感に頼りすぎることへの山田のアンチテーゼです。

同じ記事で山田は、技術を最優先し、事業への意識がない開発組織にも否定的な見方を示しています。技術を使って事業を進める必要があるからこそ、そのための組織づくりやマネジメントも経営側に求めています。

応募者としては、担当できる設計・実装・運用の範囲を示したうえで、その会社の事業への関わり方を考えます。「御社のサービスが好きです」という志望理由を、入社後に担いたい仕事まで具体化してください。

応募先には、開発の目的を誰が説明し、優先順位を誰が決め、営業やサポート部門とどう情報を共有するかを聞きます。事業への関与を社員個人の熱意だけに任せず、開発者が判断できる体制を作っているかも確認できます。

技術選択をサービスの成果と結び付ける

事業へのコミットとは、開発者が一人で売上責任を背負うことではありません。担当する機能について、作る理由を理解し、技術上の判断が利用者や運用に与える影響を説明することから始められます。

たとえば問い合わせを減らす目的なら、機能追加の前に、既存画面の案内や運用手順を変えるだけで解決できるかも考えます。開発する場合も、利用者が迷わず完了できるか、サポート担当が説明できるかまで確かめます。測定できる項目や方法は事業担当者と相談し、確認していない効果を成果として扱わないようにします。

技術選定では、性能や実装のしやすさに加え、今いるメンバーが保守できるか、担当者が替わっても運用できるかを考えます。山田が同じnoteで述べる、採用や分業を含めて開発組織を作る視点にもつながります。使いたい技術を採用する理由だけでなく、採用しない場合の利点も説明できると、事業の制約を踏まえた提案になります。

売上などの情報にアクセスできない立場でも、利用目的を尋ねたり、許可された範囲で問い合わせの傾向を確認したりすることは検討できます。担当範囲を超えて成果に関わる姿勢は、権限外の情報を集めることとは異なります。

自社サービスなら育ててもらえるとは限らない

山田は、2023年12月のエンジニアの育成を論じたnoteで、自社サービスでは事業の成果を求められ、実践の機会から自分で学ぶ必要があると述べています。長期の育成体制を持つ企業と、すぐに仕事を任せたい企業を分けて考えた意見です。

そのため、教育目的だけで自社サービスへ移る判断は慎重に行います。入社後の担当作業、レビューする人、技術的な相談先が具体的かを確かめてください。自社のシステムに詳しくなることと、次の職場でも使える設計・実装の経験を得ることも同じではありません。

今は技術や工程の経験を作ることが優先なら、現場で指導を受けながら担当範囲を広げる方法もあります。経験を作る場所の選び方は、未経験の工程・技術への転職準備で扱っています。

想定ケース：SESの実装経験から自社サービスを目指す

以下は行動を考えるための想定ケースであり、採用や転職の成功事例ではありません。既存Webシステムの画面改修を担当し、実装とテストの経験はあるものの、改修理由や公開後の状況を説明できない状態を考えます。

今のまま応募すると説明が弱いこと

使用言語と実装内容だけでは、仕様が決まる前や公開後に、どう仕事へ関わるかが伝わりません。「自分もサービスを育てたい」と話すなら、現在の仕事でも利用者の問題を知ろうとした行動を示したいところです。

今の現場で取りに行く経験

次の改修で、上位者に「この画面で利用者が困っていること」と「改修後に確認すること」を尋ねます。たとえば入力エラーへの対応なら、問い合わせの要旨を共有してもらえるか相談し、どの操作で迷うのかを整理します。

そのうえで、表示文言の修正、入力手順の変更、サポート時の案内変更を比較します。開発量、利用者の手間、問い合わせ対応への影響を整理して提案し、担当者と実施する案を決めます。

自分は改修とテストを担当し、問い合わせへの回答例はサポート担当に確認してもらうなど、役割を分けます。実装以外の問題にも目を向けながら、各担当者と協力して進めたことが、事業への関わりを示す材料になります。

公開後は、合意した方法で状況を確認します。問い合わせが減ったかを測れなければ、担当者の確認結果や、まだ検証できていない点を記録します。効果の数値を得られないことと、目的を考えずに実装することは分けて考えられます。

転職時に説明する内容

「依頼どおりに画面を修正した」から、「利用者の操作上の問題を確認し、変更案を比べ、合意した範囲を実装した」と説明できる状態を目指します。実際に公開後の確認まで担当した場合だけ、その方法と分かったことを追加してください。

未経験の言語や工程も同時に求められるなら、事業への関心だけでは不足を補えません。未経験の工程・技術への転職準備で、今の経験との差を確認します。

選考では判断の理由と確認できた結果を伝える

経験を整理するときは、「利用者の問題→検討した案→自分の担当→確認できた結果」の順に書きます。技術の説明は、なぜその方法を選んだかが分かる位置に置きます。

たとえば性能改善なら、単に処理を高速化したことに加え、待ち時間がどの業務を妨げていたかを説明します。改善値を測定した場合も、そのまま売上向上の実績にはしません。自分が確認できた変化と、事業全体の結果を区別します。

採用されなかった提案でも、利用者の課題と比較した選択肢、見送った理由は説明材料になります。機密資料を持ち出さず、社名や固有の数値を伏せて担当範囲を整理してください。経歴全体のまとめ方は、SES向け職務経歴書の書き方で確認できます。

応募先で開発後の役割まで確認する

選考は、応募先が求める関わり方と自分の希望を確かめる場でもあります。次の質問で、担当する仕事を具体化します。

• 配属予定のチームは、サービスのどの課題を担当していますか
• 開発の優先順位を誰が、何を根拠に決めていますか
• エンジニアが利用者の反応や事業上の結果を知る機会はありますか
• 入社直後は何を担当し、仕様の検討や公開後の改善へどこまで関わりますか
• 保守・問い合わせ対応と新規開発を、チーム内でどう分担していますか
• 技術上の改善案を提案し、レビューを受ける機会はありますか
• 特定の人しか保守できない部分を、チームとしてどう引き継いでいますか

自社サービスへ移る前に、今担当している機能を一つ選び、作る目的と確かめたい結果を書いてみてください。その説明ができると、応募先のサービスでどの仕事に関わりたいのかも具体的に伝えられます。