SESから自社開発へ転職する方法｜実務経験別・90日の準備ロードマップ

「自社開発」を六つの責任へ分ける

最初に、自社開発で期待する仕事を「利用者・課題」「要件・優先順位」「設計・実装」「品質・セキュリティ」「リリース・運用」「利用後の改善」の六つへ分けます。利用者の声を直接聞けることと、その要望をそのまま作ることは別です。誰のどの課題を優先し、何を作らないかまで決める人を確認します。

設計・実装では、画面数やコード量より、データ、API、権限、例外、性能、変更しやすさを誰が決め、誰がレビューするかを見ます。品質・セキュリティでは、テスト基準、脆弱性、個人情報、障害時の判断が担当者任せになっていないかを確認します。公開後は、監視、問い合わせ、障害、利用状況から次の改善へ戻る流れを見ます。

job tagはWebサービス開発について、要件定義、基本・詳細設計、テスト、公開、保守・管理までを仕事として示しています。しかし、求人ごとに担当範囲は異なります。「自社サービス」「アジャイル」「裁量が大きい」という単語を合格条件にせず、六つのうち入社後90日と一年後に何を作成・レビュー・承認するかを質問してください。

六つ全部を最初から必須にすると、現在の経験との差が大きすぎて求人を比較できません。今回の転職で必ず増やす責任を一つ、できれば増やす責任を二つまで選びます。常駐をやめる、年収を上げる、技術を変える、働き方を変えるという条件も、六責任とは別の列へ置きます。

• 利用者・課題: 誰のどの行動を変えるか
• 要件・優先順位: 作るもの・作らないもの・受入条件
• 設計・実装: データ・API・権限・例外とレビュー
• 品質・セキュリティ: テスト基準・脆弱性・障害判断
• リリース・運用: 配備・監視・問い合わせ・復旧
• 利用後の改善: 利用状況・品質・事業指標から次を決める

今のSES経験を、五つの証拠へ変える

案件ごとに「依頼・制約」「調査」「選択・判断」「品質・結果」「再利用」の五つを一枚へ並べます。依頼・制約は、期限、既存仕様、担当範囲、利用できる環境です。調査は、仕様書、既存コード、ログ、SQL、関係者への確認から何を明らかにしたか。選択・判断は、比較した案と採用理由、確認を求めた時点です。

担当工程がテストでも、用意された項目を消化しただけなのか、仕様差分から境界値・異常系・権限・データ不整合の観点を追加したのかで証拠は変わります。保守なら、問い合わせを転送しただけか、再現条件、ログ、データから原因範囲を切り分け、恒久対応や監視へつないだかを分けます。運用でも、手順実施から失敗条件の検知・自動化・復旧確認へ責任を広げられます。

実装経験は、言語と機能名だけでなく、既存仕様との整合、API・DB・バッチへの影響、レビューで直した理由、リリース時の確認まで書きます。品質・結果は、測定できた件数や時間だけでなく、防いだ不具合、追加した確認、残った制約でも構いません。再利用は、観点表、手順、共通処理、後任説明など、自分以外が使える形です。

判断した経験が見つからない場合は、経歴を盛らず、次の30日で作る対象にします。顧客や会社の資料、コード、画面を私物端末へ持ち出してはいけません。案件名は業種と用途へ一般化し、公開できない数字は無理に書かず、自分が説明できる範囲だけを職務経歴書へ移します。

• 依頼・制約: 目的、期限、既存仕様、担当範囲
• 調査: 仕様・コード・ログ・データ・関係者確認
• 選択・判断: 比較案、採用理由、承認を求めた時点
• 品質・結果: テスト、障害、手戻り、残った制約
• 再利用: 観点表、手順、共通化、後任への引継ぎ

実務年数ではなく、説明できる工程から不足を選ぶ

実務1〜2年では、大きな要件定義を経験したと見せるより、一つの変更を正しく終える証拠を作ります。既存仕様とコードから影響先を挙げ、実装前の確認、単体・結合テスト、レビュー修正、リリース前後の確認を一本につなげます。指示された作業の中でも、確認事項と品質観点を一段増やせます。

実務2〜3年では、複数機能や他担当との境界を一つ持ちます。API仕様、DB変更、データ移行、外部連携、監視、リリース手順のいずれかで、依存関係、失敗時の戻し方、担当間の合意を説明します。フロントエンドだけ、バックエンドだけという担当でも、境界で何を保証したかが持ち運べる経験になります。

実務3年以上では、個人の実装量に加え、品質基準とチームへ残る仕組みを一つ示します。設計・コードレビュー、テスト方針、障害の再発防止、共通化、監視、後続メンバーの立ち上がりなどです。役職がなくても、提案し、合意を取り、小さく運用した範囲は書けます。最終承認者でなかった場合は、その責任まで自分の成果にしません。

年数は支援サービスや求人の対象条件を確認する材料にはなりますが、採用後の担当を保証しません。三年以上でもテスト実施だけなら、次は影響調査か観点設計を増やす。二年未満でも設計から運用まで持つ小規模案件があれば、その範囲を正確に出す。年数、工程名、責任の証拠を別々に記録してください。

• 1〜2年: 一変更の調査・実装・テスト・レビューをつなぐ
• 2〜3年: API・DB・移行・監視など担当境界を一つ持つ
• 3年以上: レビュー・品質・再発防止をチームへ残す
• 全年数: 作成・レビュー・承認のどこを担ったか分ける
• 対象条件: 年数の下限を申込・応募前に確認する

ポートフォリオは、不足する一工程だけを補う

実務経験者にポートフォリオが必須とは限りません。職務経歴書だけで、対象求人が求める言語・工程・品質・運用を具体例で示せるなら、応募準備と面接へ時間を使う選択があります。作る場合は、未経験技術を大量に並べるためでなく、現職で持てない一工程を補うために使います。

チュートリアルと同じCRUD画面を増やすだけでは、業務との違いが伝わりにくくなります。「誰のどの作業を変えるか」「利用者と管理者の権限をどう分けるか」「重複や失敗をどう扱うか」「何を監視するか」「公開後にどの指標で改善するか」をREADMEへ残します。画面が少なくても、要件から運用まで一周できる方が説明しやすくなります。

認証、入力検証、権限、テスト、自動デプロイ、ログ、監視のうち、狙う求人で繰り返し求められる二項目を選びます。採用した方式だけでなく、比較した案、捨てた条件、残った課題を書きます。READMEにはローカル実行手順、構成図、主要な判断、テスト方法、デモ環境の制約を置き、面接官が再現できる状態にします。

現場の成果物を公開できない場合は、架空の要件で同じ種類の判断を作り直します。顧客名、画面、データ、コード、設定、障害情報を持ち出しません。生成AIを使った場合も、生成量ではなく、自分が要件を決め、出力を検証し、セキュリティとライセンスを確認した範囲を説明します。

• 対象利用者と変える作業
• 機能・非機能要件と置いた制約
• 選ばなかった方式と理由
• 権限・入力・異常系のテスト
• デプロイ・ログ・監視・復旧方法
• 公開後に見る品質・利用指標
• 残った課題と次の改善

求人へ同じ八問を出し、入社後の責任を確認する

一問目は、採用ポジションが入社後30・60・90日に作成・レビュー・承認する成果物です。二問目は、直近の機能が誰の課題から始まり、要件と優先順位を誰が決めたか。三問目は、プロダクトマネージャ、デザイナー、エンジニア、営業、運用、顧客との責任分界です。チーム人数だけでなく、決定の流れを聞きます。

四問目は設計・コード・テストを誰が、どの基準でレビューするか。五問目はデプロイ頻度ではなく、リリース判断、監視、障害対応、当番、振り返りを誰が持つかです。自動化されていても責任者が不明なら、入社後の働き方と品質を判断できません。障害当番は頻度、時間帯、人数、勤務扱い、代休まで確認します。

六問目は、利用状況、品質、売上、コストなど、開発後の指標を誰が見て次の改善を決めるか。七問目は、評価項目、評価者、評価日、基本給、賞与、固定残業、試用期間です。八問目は、採用時と異なる配属、担当変更、事業撤退が起きた場合の決め方です。自社サービスであっても事業・組織の変更は起こるため、変更時の選択肢を確認します。

IPAのモダン化に関する解説は、仕様の可視化、ブラックボックス対策、内製化、経営層と情報システム部門の情報共有を取り上げています。内製率の数字だけで会社を選ばず、要件、設計、実装、受入、運用の成果物を自社と外部パートナーのどちらが持ち、どこで合意するかを求人ごとに確認してください。

• 入社30・60・90日の成果物と承認範囲
• 課題・要件・優先順位を決める人
• 職種間と外部パートナーとの責任分界
• 設計・コード・テストのレビュー基準
• リリース・監視・障害当番・振り返り
• 利用・品質・事業指標を改善へ戻す方法
• 評価者・評価日・給与内訳・試用期間
• 配属・担当・事業が変わる場合の決め方

職務経歴書と面接を、求人の六責任へ合わせる

職務経歴書は「Javaを三年」「基本設計からテスト」「自社開発を希望」で終えません。案件の目的、体制、担当工程、技術に加え、五つの証拠を一案件へ入れます。自分が作成したもの、レビューしたもの、承認を受けたものを分け、チーム成果を自分一人の数字にしません。マイジョブ・カードの公式情報も、転職理由とキャリア・プランの整合、在職中の努力、強みを転職先でどう活かすかという整理を案内しています。

転職理由は「SESは成長できない」「客先常駐が嫌」で止めず、現職で広げようとした責任、残った制約、次に持ちたい成果物、応募先で確認できた仕事へつなげます。自社開発への志望動機も、サービスへの共感だけでなく、現在の影響調査・品質・運用経験をどの工程で使い、入社後にどの責任を増やすかを説明します。

面接では、最も強い案件一つを、依頼、調査、判断、結果、学びの順に三分で話します。深掘りに備えて、別案、失敗、レビューで変えた点、自分が決めていない点を用意します。知らない技術は経験を作らず、近い経験、調べる順序、小さく検証する方法、レビューを求める時点を答えます。

転職エージェントへ相談する場合は、「自社開発求人をください」ではなく、現在持つ責任と次に増やす責任、八問を渡します。同じ職務要約を対象条件に合う二社までへ出し、求人の選定理由、共通する不足、回答の具体性を比較します。相談したから応募する必要はなく、求人ごとに本人が同意して進めます。

• 案件目的・体制・工程・技術
• 依頼・調査・判断・品質・再利用の証拠
• 作成・レビュー・承認した範囲の区別
• 現職で試した行動と残った制約
• 応募先で確認した成果物と入社後の責任
• 別案・失敗・学び・未経験を補う手順

90日で「残る・案件変更・転職」を判定する

1〜30日目は、直近三案件を六責任と五証拠へ棚卸しします。求人を十件程度見て、繰り返し求められる工程と現在説明できない工程を一つ選びます。上司や営業へ、現職または次案件でその成果物を担当できる時期、支援者、期限を確認します。同時に、職務経歴書メーカーで根拠のある案件事実だけを一枚へ整理します。

31〜60日目は、不足経験を現職の小さな改善か、公開可能な個人開発で一つ作ります。影響範囲、テスト、レビュー、リリース、監視のうち一工程を増やし、開始前の状態、選択肢、失敗、結果を記録します。大きなサービスを完成させることではなく、求人で求められる判断を一度再現し、説明できる状態が完了条件です。

61〜90日目は、現職に残る、案件を変える、会社を変える三案を比較します。増える責任、実現時期、支援者、給与内訳、働き方、失う条件を同じ列へ置きます。応募する場合は八問へ回答できた求人だけを残し、提示年収だけでなく入社後90日の成果物と一年後の評価条件を確認します。内定後も、口頭で重要な条件は労働条件通知書など正式な提示と照合します。

対象条件に合う相談先が二つある場合は、同じ職務経歴書と八問を渡し、どの経験を評価し、どの求人をなぜ選んだかを比較します。対象年齢、実務経験、勤務地、希望進路から外れる場合は外部申込を急がず、現職で作る証拠か別の進路へ戻します。90日で転職を決めるのではなく、責任が増えない求人を断れる材料を作る計画です。

TechClipsエージェントの主な対象は、ITエンジニア経験者で、転職支援を利用する意思がある人です。ITエンジニア経験がない場合や、面談・求人提案を利用する意思がない場合は申込を見送ってください。公式ページはSIer・SESから事業会社への転職支援と首都圏の求人例を案内していますが、自分の勤務地・経験で現在紹介できる求人があるかは面談前後に個別確認が必要です。

公式の利用の流れは、キャリア面談後に企業の提案を受け、求職者がどの企業へエントリーするか判断し、書類を本人が確認した上で応募する順序を掲載しています。相談時には「企業名、職種、労働条件の説明後、私の個別同意を受けてから応募する」と確認します。運営会社notari株式会社は公式会社情報で有料職業紹介許可番号13-ユ-308393を公開しています。これは事業者確認の材料であり、求人の質や転職結果の保証ではありません。

公式サイトには年収アップ率、書類通過率、内定率、離職状況などの実績表示がありますが、自分に同じ結果が出る保証として使いません。集計期間、対象者、母数、比較対象が公開されているかを確認し、面談後は「今の経歴で紹介可能な求人数」「求人を選んだ理由」「入社後90日の成果物」「給与内訳」「業務・就業場所の変更範囲」という自分向けの回答だけを比較表へ残します。

• 30日: 三案件を六責任・五証拠へ棚卸し
• 60日: 不足する一工程を現職か個人開発で再現
• 90日: 残る・案件変更・転職を同じ列で比較
• 応募: 八問へ回答できた求人だけを残す
• 内定: 役割・給与・働き方を正式な提示と照合

職務経歴書の変換例

会社分類だけを希望せず、現在再現できる調査・品質の証拠、次に増やす責任、求人で確認する条件を一続きで示します。実際の経歴にない判断や成果は追加しません。

行動前チェックリスト

• 自社開発を六つの責任へ分けた
• 直近三案件を五つの証拠へ整理した
• 作成・レビュー・承認した範囲を分けた
• 次に増やす責任を一つに絞った
• ポートフォリオが本当に必要か判定した
• 求人へ入社90日を含む八問を出した
• 障害当番・評価日・給与内訳を確認した
• 転職理由を現職で試した行動へ接続した
• 残る・案件変更・転職を同じ列で比較した
• 対象条件に合う相談先だけを比較した