SESからSIerへ転職するには？評価される経験と今の現場で作る実績

SESから次のキャリアを考えるなら、SIerも有力な選択肢です。顧客の業務を理解し、関係者と調整しながらシステムを作る仕事に関わりたい人は、具体的な募集部門と役割を調べてください。

JavaやAWSなどの経験は、担当できる技術領域を伝える材料になります。そこに、顧客が何に困り、どんな仕事の進め方を変えようとしていたかを加えます。顧客の要望を仕様として受け取るだけでなく、要望の背景を確かめた経験が、SIerで任される仕事につながります。

SIerで担当したい仕事を顧客の業務から考える

SIerは、顧客のシステム導入・開発・運用などを担う企業です。応募先によって、実装を担う仕事、顧客との要件整理を担う仕事、複数の開発会社を調整する仕事など、募集される役割は異なります。「SIerに入る」だけでは、次に何をするかは決まりません。

顧客と接する役割を目指すなら、顧客がどんな事業を行い、誰がどの業務で困っているのかを説明できるようにします。たとえば「帳票を追加したい」という依頼でも、担当者が確認したいのは売上なのか、請求漏れなのかで必要な項目や更新時期が変わります。

IPAの要件定義の解説でも、ビジネス上の要求とシステムに求める内容を整理しています。この考え方を職務経験の整理に使うなら、「指定された機能を作った」だけでなく、「その機能で顧客のどの仕事を改善しようとしたか」を確かめます。

他の業態と比較してから決めたい場合は、SESからの転職先の選び方を参照してください。SIerという呼び方だけで、雇用や配属の安定性、担当工程を判断することはできません。

顧客の要望を、実際の業務フローと台帳から確かめる

山田は、2026年5月のクライアントワークについてのnoteで、顧客の言う「作りたいもの」をそのまま受け取らず、業務の流れと実際に使う台帳を確認することを勧めています。システムで何を作るかを決める前に、事業や業務を理解するという順序です。

たとえば「承認画面が欲しい」と言われた場合、まず申請から承認までの流れを確認します。誰が何を入力し、どの情報を別の表へ転記し、何を確認して承認するのか。画面を追加しても、二重入力や確認待ちが残るなら、顧客が困っていることは解決しないかもしれません。

その際、管理者が説明する手順だけでなく、実際の担当者が使う一覧表や、例外時の処理も確認します。見てよい資料や聞き取りの範囲は、現場の責任者に相談してください。

現在は実装担当でも、仕様確認の際に「この項目を誰が使うのか」「値が間違っていると、どの業務が止まるのか」を尋ねられます。回答を設計やテストへ反映すれば、顧客業務を考えた経験になります。顧客の内心を推測で決めつけず、業務上の事実を一つずつ確認します。

技術経験に加えて説明したい7つの役割

次の項目をすべて経験していなければ応募できない、という意味ではありません。求人で求める役割に照らして、経験済みの範囲と今後補う範囲を分けます。

顧客や他社への連絡は、現場で決めた窓口や権限に従います。担当者が勝手に納期や費用を約束する必要はありません。判断に必要な情報を整理し、責任者へ選択肢を示すことも実績になります。

想定ケース：他チームとの連携を顧客調整の実績へ広げる

以下は想定ケースです。SESでバッチ処理を実装しており、別チームから受け取るデータの仕様が未確定なため、テストの準備が進まない状況を考えます。転職や採用の成功事例ではありません。

今のままでは伝わりにくいこと

「Javaでバッチを実装した」だけでは、チーム間の問題にどう対応したかが分かりません。受け渡し仕様が決まるのを待つだけでは、SIerで調整役を目指す根拠も不足します。

現場で具体的に担当すること

まず、上位者に相談して、未確定の項目を一覧にする作業を引き受けます。そのデータが請求に使われるなら、誰が入力し、いつ締め、締めた後の訂正をどう扱うかまで確かめます。入力元の台帳を確認できれば、仕様書では必須の項目が、実際には後から記入されているといった違いを見つける可能性もあります。

確認した内容を、画面・バッチ・担当者の作業の流れに沿って整理します。各未確定事項には、確認先、回答が必要な日、未回答の場合に止まる作業を添えます。

次に、担当窓口を通じて相手チームと確認します。受け渡す形式の違いなら変換方法を比べ、値が確定する時期の違いなら業務の締めや再送の方法を確認します。システム側の変更だけで解決できるのか、顧客側の作業変更も必要なのかを分けます。

作業量とテスト範囲を整理し、最終判断は責任者に求めます。合意後は仕様書の変更に加え、訂正データを受け取ったときの確認方法まで関係者と共有します。

相手が社外ベンダーで、その進捗確認まで実際に担当したなら、その範囲を説明できます。社内の別チームと連絡しただけなら、ベンダー管理を経験したと広げず、「チーム間の仕様調整」と記載します。

転職時に実績として示すこと

顧客の業務で分かったこと、自分が整理した課題、提示した選択肢、責任者の判断、合意後に担当した作業を区別して説明します。「プロジェクトの納期を守った」と全体の成果を自分の実績にせず、未確定だった条件がどう決まったか、テストへ何を引き継いだかまで示します。

選考では自分の判断とチームの成果を分ける

顧客折衝や管理の経験を伝えるときは、役職名より具体的な分担を書きます。「顧客会議に参加」と「顧客へ選択肢を説明し、合意内容を整理」は、任されている範囲が異なります。議事録担当なら、決定事項と宿題を整理した事実をそのまま伝えてください。

技術力を示す説明も省きません。調整の対象だったシステム、変更時の制約、技術的に難しかった点が分かると、何を判断したのかが伝わります。経歴全体の構成は、職務経歴書の整理方法で確認できます。

要件定義や基本設計をこれから目指す場合、調整経験があるだけで工程全体を任せられるとは限りません。上流工程へ進むための経験で具体的な作業を確認し、経験を作る場所に迷う場合は未経験工程への転職判断へ進んでください。

応募先で顧客との距離と配属後の仕事を確認する

募集要項に「上流から関われる」とあっても、入社直後の担当が実装なのか、要件整理なのかは確かめます。次の質問は、顧客業務に関わりたい人が役割を確認するための例です。

• どの業界・業務の顧客を担当し、最初に何を任されますか
• 顧客と直接確認する担当者は誰ですか
• 実際にシステムを使う人から、業務の手順や困り事を聞く機会はありますか
• 要件を整理する仕事と実装する仕事は、同じチームで行いますか
• 協力会社への依頼や進捗確認は、どの役割が担当しますか
• 品質・納期・コストの調整が必要な場合、誰が判断しますか
• 技術の専門性を深める役割と、案件全体を管理する役割をどう分けていますか

今の現場では、担当するデータ項目を一つ選び、誰が入力して誰が使うかをたどるところから始められます。その経験と応募先の役割を比べ、自分が任せてもらえる仕事、レビューが必要な仕事を具体的に伝えてください。