SIerからWeb系案件へ移るフリーランスの準備｜通過条件と案件選び

SIerとWeb系の実務的な違い

自社サービス企業や内製開発寄りの案件では、プロダクトを継続的に改善する現場が多く見られ、SIerが担う受託開発による顧客業務の実装とは求められる立ち回りが異なります。両者を単純な優劣で語らず、案件選びに直結する4つの軸で整理します。

業務内容の違い

• SIer：顧客要件をもとに設計〜開発〜テスト〜運用を一括受託。ドキュメント文化が厚く、上流と下流の分業が明確

• Web系：自社プロダクトのバックログを消化するチーム開発。仕様は社内PdM（プロダクトマネージャー）やデザイナーとの対話で固め、コード起点で議論が進む

SIer出身者は「要件整理→仕様書化→実装依頼」の型でチームを動かしてきたケースが多く、Web系のチケット単位でPR（プルリクエスト）を起こして議論する運用に慣れるまで時間がかかることがあります。逆にWeb系は仕様の抽象化・非機能要件の整理が弱い現場もあり、SIerの設計スキルが評価される場面は少なくありません。

技術スタックの違い

• SIer：Java／VB.NET／COBOL／Oracle／WebLogic 等、業務システムに強いエンタープライズ寄りのスタックが残っている

• Web系：TypeScript／React／Vue／Next.js／Node.js／Go／Rails／PostgreSQL／AWS 等、コミュニティが厚くOSSで学べるスタックが中心

Java経験自体はWeb系のバックエンド（Spring Boot／Kotlin）へ活かせますが、フロントエンドはモダンFW経験を別途求められるケースが多く、既存の業務Web（jQuery＋JSP等）の経験だけでは通りにくくなっています。詳細な技術別レンジはReactフリーランス単価相場｜案件動向・スキル別レンジ・獲得の実務やバックエンドフリーランスの単価相場｜言語別・レイヤー別レンジと動向を参照してください。

商流・契約形態の違い

• SIer：多重下請けが混じるケースがあり、二次請け・三次請けだと単価が抑えられがち

• Web系：自社サービス企業からの直請け／エージェント直、または元請SIerの新規事業部門が中心で、商流が比較的短い傾向

同じ月単価でも商流が短いほど中間マージンが増えにくく、単価交渉や契約条件の見通しを立てやすい傾向があります。ただし最終的な条件は企業予算やロールにも左右されるため、商流が短いこと自体を単独の判断軸にはしないほうが安全です。契約形態も準委任が中心で、成果物責任を負う請負契約は少ない構成です。契約種別による向き不向きは受託開発と準委任の違いと使い分け｜フリーランスの収入構造と向く人にまとめました。

稼働・働き方の違い

• SIer：客先常駐・出社比率が高いケースが残る。夜間バッチや月次リリースで残業が固まる時期がある

• Web系：公開案件サイトやエージェントの募集要項を見ると、フルリモートや週1〜2出社の募集も見られ、稼働時間も比較的柔軟な現場があります（公開募集ベースの傾向で、非公開案件を含む市場全体を示すものではありません）

ミニFAQ

• Q. SIerの現場でもリモートが増えたが、Web系との違いはあるのか？

A. リモート比率自体は縮まりましたが、Web系はGitHub・Slack・Notion などを使った非同期コミュニケーションが中心の現場が多く、SIerの「会議での合意→議事録→仕様書」型と運用が異なります。ツールの流儀に慣れておくと参画直後の摩擦が減ります。

移行が現実的な人・準備が要る人

SIer経験は職種・レイヤーによってWeb系での評価が変わります。まずは自分の位置を素直に確認してください。

移行が比較的スムーズな人

• バックエンド寄りの開発経験がある：Java／Kotlin／C#／Python等でAPIやバッチを実装した経験

• AWSやAzureで運用構築の経験がある：IaC（Infrastructure as Code）・監視・CI/CDを触っている

• アジャイル運用またはSRE寄りの開発運用経験がある：スクラム・カンバンなどのアジャイル運用、または信頼性設計・監視自動化などのSRE寄り現場で稼働した

• 直近1〜2年で新規開発フェーズに携わった：レガシー保守だけでなく設計・実装で手を動かしている

追加の準備が必要な人

• 上流工程が長く実装から離れている：管理系のスキルは通用しても、コード面談で手が動かず不利になる

• VB.NET／COBOL／PL/SQL中心の経験：モダンFWの独学とポートフォリオが別途必要

• アプリ側の経験がなくインフラ運用のみ：SREやDevOps案件への切り替えを先に検討したほうが早い

ミニFAQ

• Q. 40代でSIer上流経験しかない場合、Web系案件は無理か？

A. 難しさはありますが、PMO・技術PM・アーキテクト枠であれば大手の自社サービス企業やDX推進部門からの募集が見られるケースがあります。実装より意思決定・レビュー・非機能設計で評価されるロールを狙うと通りやすくなります。年代別の判断軸はフリーランスエンジニアのキャリアパス｜年代別の選択肢・年収推移・必要スキルを徹底解説を参照してください。

移行前の準備｜スキル棚卸しと不足の補完

「Web系に移りたい」と決めたら、まず直近3年の実務を分解し、Web系案件の募集要件で使われる語彙に翻訳します。

スキルの棚卸し手順

1. 直近3案件の担当機能・使用言語・使用FW・DB・クラウド・チーム規模・体制・成果を洗い出す

2. 各項目をWeb系の募集要件で使われる語彙（TypeScript／React／CI/CD／DevOps／IaC 等）に置き換える

3. 足りない要素（コンテナ運用、GitHub Actions、モダンFW経験、非機能要件の設計 等）をリスト化する

4. 足りない要素はまず個人開発・OSS参加で公開可能な証跡を作り、資格は補助材料として使う（写経は学習用と位置づけ、公開できる成果物や実装ログにつなげる）

不足を埋める現実的な選択肢

• 個人開発：Next.js＋Prisma＋Vercel等の小さな成果物を1つ完成させてGitHub公開

• OSS参加：既存OSSのissue対応・翻訳・ドキュメント修正から始めるとハードルが低い

• 短期プロトタイプ案件：クラウドソーシングでフロントの単発案件を1〜2件消化し、守秘義務や公開可否を確認したうえでポートフォリオに載せる

• 資格：AWS認定・LPIC・Kubernetes系（CKAD）は面談で話の起点になる。ただし資格単体では評価されず、実装例とセットで示す

学習投資の優先順位は単価を上げる学習の優先順位｜案件需要から逆算する技術投資4ステップに整理しています。

スキルシートの書き方｜SIer経験をWeb系目線で翻訳

特にWeb系の直請け・スタートアップ案件では、一次選考でスキルシートに加えてGitHubや成果物を確認されることがあります。SIer時代の書き方をそのまま使うと通過しにくくなるため、担当機能・使用技術・体制・成果の4点に粒度を落として書き換えます。

通りやすい書き換えの型

• NG（SIer型）：「A社基幹システム再構築PJにおいて要件定義〜結合テストを担当」

• OK（Web系型）：「会員管理API（Kotlin＋Spring Boot／PostgreSQL）の新規実装。エンドポイント設計・OpenAPI定義・単体テスト（JUnit）まで担当。チーム6名／スクラム／2週スプリント」

書き換え時のチェック

• 使用技術を必ず列挙：言語・FW・DB・クラウド・監視・CI/CDまで書く

• 担当フェーズを明示：「要件定義〜結合」ではなく「担当機能名＋担当作業（設計／実装／レビュー／リリース）」

• チーム規模と体制：3名か30名かで求められる立ち回りが違うため、必ず記載

• 成果：数値（レスポンス改善率・障害削減・リリース頻度等）で書けるものは書く

• 上流工程の翻訳：「要件定義」→「PdMとの仕様調整・OpenAPI定義」等、Web系の語彙に寄せる

汎用の書式はフリーランスエンジニアのスキルシートの書き方を徹底解説！記入例や今すぐ使えるフォーマットも紹介！を参照。案件詳細の粒度はスキルシートの案件詳細の書き方｜担当フェーズ・規模・体制の粒度、書類選考で落ちる原因の整理はフリーランスのスキルシートが通らない7つの原因｜書類選考の改善策にあります。

ミニFAQ

• Q. 大規模SIerでチーム50名の上流を担当していた。この規模感は書くべきか？

A. 書くべきですが、Web系読者向けに「なぜ50名必要だったか（サブシステム分割・拠点分散等）」を1行補足すると評価につながります。規模だけを強調すると「Web系の小回りに合わないのでは」と誤解されることがあります。

案件の選び方｜最初の1本の見極め

Web系実務がまだ薄い場合、移行1本目は通過率を上げつつミスマッチを避ける基準で選びます。単価の最大化は2本目以降で考えるほうが現実的です（すでにモダンスタック実務がある人や、SRE/PMクラスで移る人は初回から単価を落とさなくてよいケースがあります）。

最初の1本で狙うべき条件

• 準委任契約：請負でなく準委任だと、成果物責任を負わずに済み、SIer出身者が慣れやすい

• 週4〜5日リモート：初回参画で継続評価を取りにいくなら、週4〜5日のほうが立ち上がりや成果を示しやすい傾向がある

• 小〜中規模チーム（目安として5〜15名程度）：役割分担が極端に細かすぎず、レビューや仕様確認に入りやすいため、SIer時代の設計経験が評価されやすい

• モダンFW主体：TypeScript＋React／Next.js／Node.js／Rails／Go 等

• 既存プロダクトの改修＋新機能開発：フルスクラッチより既存改修のほうが立ち上がりが早い

避けたほうがよい条件

• 技術検証だけの短期PoC（概念実証）：継続に繋がりにくく、スキルシート上の実績も薄くなりがち

• 技術リーダー不在のスタートアップ初期：裁量を楽しめる人には向く一方、初回移行案件としては難度が高い

• Web系タグだが実態はSES二次請け：商流を面談で必ず確認

案件選定の優先順位は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位、初案件の判断基準はフリーランス初案件の決め方｜独立後に外さない5つの選定基準、地雷案件の見分け方は地雷案件の見分け方｜参画前に確認する危険サイン15項目にまとめています。

面談で確認すべきこと・聞かれること

面談は技術質問＋現場理解＋文化フィットの3層で見られます。SIer出身者が落ちやすいのは、技術質問より「Web系の運用に馴染めるか」の判断で不利になるパターンです。

面談で聞かれる典型パターン

• 直近の実装内容：使った技術・担当機能・チーム体制。3〜5分で説明できるよう準備

• なぜWeb系に移りたいか：単なる待遇改善だと弱い。プロダクト思考・改善サイクル・非同期運用への適応等、具体的な志望動機を用意

• モダンFWの経験：TypeScript・React・Docker・GitHub Actions 等の触った経験を実例で答える

• 設計判断のエピソード：SIer時代のエピソードでも、判断軸を言語化できれば強く評価される

面談対策の詳細はフリーランスエンジニアの面談で聞かれる質問と回答例｜職種別Q&Aと逆質問まで解説とフリーランス面談で落ちる7つの原因｜通過率を上げる対策と準備を参照。

こちらから確認すべきこと

• 商流：発注元・元請・自分の位置。二次請け以降だと単価と裁量が落ちやすい

• プロダクトのフェーズ：0→1／1→10／10→100 のどこか。SIer出身は 1→10 と 10→100 が親和性高い

• チーム体制と技術リーダーの有無：意思決定の速度と品質を左右する

• 既存コードベースの規模とテスト整備状況：立ち上がり時間の見立て

• オンボーディングの支援体制：ドキュメント整備・ペアプロ・週次1on1の有無

現場側に聞く質問集はフリーランス面談で聞くべき質問リスト｜ミスマッチを防ぐ確認事項にあります。

移行後の単価と収入設計

Web系案件の単価は、技術スタックと参画レイヤーの影響を受けやすく、商流や稼働条件でも変わる傾向があります（企業フェーズや採用難易度・緊急度・地域でも変動）。SIer時代の年収レンジをそのまま持ち込む前提だと、初回オファーで折り合わないケースが増えます。

単価が上がる要素

• モダンFW×クラウド×アジャイルの3点セット経験

• PM／テックリード／アーキテクトの意思決定レイヤー

• 既存プロダクトの改善実績（非機能改善・スケール対応・監視設計等）

• 英語ドキュメント読解の実務経験（AWS・GitHub・OSS等）

単価が抑えられる要素

• フロントエンド実装経験が浅い（jQueryのみ等）

• AWSアカウントを触ったことがない

• アジャイル・スクラムの参画経験がゼロ

• GitHubアカウントが空、または非公開のみ

自分のスキルで狙える単価目安は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。相場の全体像は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。

ミニFAQ

• Q. SIer時代に副業でReactを触っていた程度でも単価は上がるか？

A. 副業経験は「Web系実務」ではないと見なされるケースが多いですが、GitHubに実装例と稼働ログが残っていれば加点材料になります。副業をスキルシートに書くときは「案件」ではなく「個人開発／副業開発」と正直に位置づけたうえで、コード規模・使用技術・稼働時間まで書くのが安全です。

よくある失敗と対策

失敗1：スキルシートを「上流工程担当」だけで埋めてしまう

• 原因：SIer時代の役職ベースで書いてしまう

• 対策：担当機能名・使用技術・成果を必ず併記。役職より「直近半年で何を実装したか」で評価されると理解する

失敗2：Web系タグの案件に応募したが実態はSES二次請けだった

• 原因：商流を面談で確認しなかった

• 対策：エージェントに発注元・元請・自分の位置を必ず聞く。契約書の第三者委託条項も確認

失敗3：初回面談で技術質問に答えられず落ちた

• 原因：SIer時代の設計論だけで答えてしまい、実装レイヤーの質問に対応できなかった

• 対策：直近半年で書いたコードを必ず用意し、リポジトリを見せながら説明できる状態にする

失敗4：単価を前職ベースで押した結果、初回オファーが流れた

• 原因：Web系の相場感を把握せず交渉した

• 対策：技術スタック別の相場をフロントエンドエンジニアのフリーランス単価相場｜経験別・技術別レンジと動向等で事前に確認し、移行1本目は単価より通過・稼働継続を優先する

失敗5：参画後に社内Slack・GitHubフローに馴染めず契約更新されなかった

• 原因：SIer時代の会議・メール中心の運用から切り替えられなかった

• 対策：参画初月にPRサイズを小さく刻む・レビューへ即応・Slackを定時前に読むを徹底。参画直後の立ち回りはフリーランス参画初月の立ち上がり方｜30日で信頼を得るオンボーディング型を参照

ケース別ロードマップ

同じ「SIer出身」でも背景により最適な移行順序は変わります。3つの典型ケースで整理します。

ケース1：大手SIerの上流経験者（35〜45歳）

• 強み：規模の大きい案件の設計・体制設計・品質管理の経験

• 弱み：直近の実装経験が薄く、コード面談で不利

• 順序：まずPMO／技術PM／アーキテクトのWeb系案件を狙う → 参画中にモダンFWをキャッチアップ → 2〜3年後に実装ロールへ広げる

ケース2：中小SIer／SESで開発中心（27〜35歳）

• 強み：手が動く。バックエンド・DB・クラウドの実務経験

• 弱み：フロントエンドの経験が薄い、GitHub運用に慣れていない

• 順序：個人開発でReact＋Next.jsを1つ作る → バックエンド寄りのWeb系案件へ移行 → フルスタック化して単価を上げる

ケース3：組込・業務システムのレガシー保守（30〜50歳）

• 強み：低レイヤ・非機能要件の知見

• 弱み：Webのモダンスタック経験がほぼゼロ

• 順序：SRE／インフラ側のWeb系案件（AWS・Kubernetes中心）から入る → 開発チームとの接点を作り徐々にアプリ側へ広げる

SESからの独立ルート全体はSESエンジニアからフリーランスに転身する手順｜準備・契約・独立タイミングを徹底解説、SEからの独立手順はシステムエンジニアがフリーランスになる手順｜必要経験・単価相場・独立の判断基準にまとまっています。

まとめ

SIerからWeb系フリーランス案件へ移る際の通過条件は、直近の実装経験を具体的に示し、モダンな開発フローへの適応を証明し、公開可能な成果物を1つ用意することです。移行は業務内容・技術スタック・商流・稼働の4軸を意識的に切り替える動きで、SIer時代の経験を Web系の語彙に翻訳できるか、モダンFWの実装経験を短期間で証跡化できるかに大きく左右されます（実際には商流・タイミング・面談力・案件選定も影響します）。

• SIer経験はバックエンド・上流設計・非機能設計の面でWeb系でも評価される

• 移行1本目は準委任・週4〜5日リモート・小〜中規模チームを狙い、通過率を優先する

• スキルシートは担当機能・使用技術・体制・成果の粒度でWeb系語彙に書き換える

• 面談では直近半年のコードとGitHubを用意し、志望動機を Web系運用の適応で語る

• 単価は前職ベースで押さず、技術スタックと参画レイヤーで市場相場を確認したうえで交渉する

• 最初の3ヶ月は稼働継続と信頼獲得を優先し、更新時に単価を上げる二段構えが現実的

まずやること3つ

1. 直近3案件のスキルシートを、担当機能・使用技術・体制・成果の粒度で書き換える

2. GitHubに小さな成果物を1つ公開する（Next.js＋DB＋デプロイまで含む最小SaaS推奨）

3. エージェント面談で「移行後に狙うロール」を具体化して伝え、案件候補を数件比較する

案件の紹介を受けたい方はフリーランス案件一覧から、自分の市場単価を確認したい方はフリーランスエンジニア単価診断から次のステップに進めます。