「SESでもリモートで働けますか？」という質問は、最近の面談でほぼ毎回出てくる。
コロナ禍以降、リモートワークは多くのエンジニアにとって「あって当たり前」のものになった。
しかし現実には、SES業界のリモートワーク事情は一様ではない。
「完全リモートで稼働しています」というエンジニアもいれば、「週5出社を求められています」というエンジニアも同じ会社の中にいる。
Heydayの営業サポートを担当している野沢だ。案件のマッチングや条件調整を日常的に行う中で、リモート希望のエンジニアとクライアントの条件をすり合わせる場面が多い。その経験から言えることは、「SESでリモートが可能かどうか」は、案件・業種・技術スタック・個人のスキルセットによって大きく変わる、ということだ。
一般論で「SESはリモート無理」と諦めているなら、それは情報が古いか、そもそも案件選びの視点が違う。
この記事では、SESのリモートワークの実態を数字で示しながら、リモート案件を増やすための実践的な方法を解説する。
読んでほしい人は「今より在宅を増やしたい」「リモートOKの案件を探したい」「SESとリモートの相性を正しく理解したい」と感じているエンジニアだ。
結論から言えば、リモートは「案件の選び方」と「スキルセットの磨き方」次第で十分に実現できる。
SESリモートワークの現状と実態
コロナ後に起きた変化と、その後の揺り戻し
2020〜2022年のコロナ禍では、強制的にリモート化されたIT現場が多かった。
「SESエンジニアも全員リモートに」という状況になった企業も少なくない。
弊社でも、コロナ禍のピーク時には稼働中のエンジニアの約70%が何らかの形でリモートを経験した。
しかし2023年以降、多くのクライアント企業が「出社回帰」の方針を打ち出した。
週5リモートだった案件が「週2出社」になり、さらに「週3出社」になった、という話をエンジニアから何度も聞いた。
特に大手SIer・金融・官公庁系の現場で、この揺り戻しは顕著だった。
完全リモートへの揺り戻しが起きている一方で、「完全出社」に戻った案件ばかりでもない。
実態は「週2〜3出社のハイブリッド」が現在のボリュームゾーンだ。
コロナ禍以前と比べると、業界全体でリモートへの許容度は明らかに上がっている。
「リモート可能な現場文化」が定着したことで、以前なら出社必須だったWeb系・スタートアップ系の案件が、今では完全リモートで動いていることも珍しくない。
弊社の現場で見えてくる割合感
弊社で稼働中のエンジニアの状況を見ると、おおよそ次のような分布になっている（2026年Q1時点・稼働エンジニアn=約80名）。
- 完全リモート（週0出社）：約15〜20%
- ハイブリッド（週1〜2出社）：約40〜45%
- ハイブリッド（週3出社）：約20〜25%
- 週4〜5出社：約15〜20%
「完全リモート」の割合は決して高くない。
しかし「週1〜2出社のハイブリッド」を含めると、半数以上のエンジニアが実質的にリモート中心の働き方をしていることになる。
この割合は、案件の種類・クライアントの業種・扱う技術によって大きく変わる。
たとえば同じ「Javaエンジニア」でも、スタートアップのバックエンド案件なら完全リモートが珍しくないが、大手銀行の基幹系案件なら週4〜5出社が当たり前、というギャップが普通に存在する。
案件の条件調整をする中で感じるのは、リモート可否はクライアント企業の「方針」だけでなく「現場のPMの考え方」で大きく左右されるということだ。同じクライアント企業でも、チームAは完全リモートOK、チームBは週3出社必須、ということが普通にある。だから「この会社はリモートOK」という情報だけでは不十分で、「この案件のこのチームはどうか」まで確認する必要がある。
また、同じエンジニアが次の案件で急にリモート率が下がることもある。
「前回は完全リモートだったから次も同じはず」という思い込みで案件を選ぶと、入場後にギャップを感じることが多い。
案件ごとに条件を確認する習慣が重要だ。
どういう条件の案件がリモートになりやすいか、次のセクションで解説する。
リモートOK案件とNG案件の違い
リモートになりやすい案件の特徴
10年間で見てきた傾向をまとめると、以下の条件が重なる案件ほどリモートになりやすい。
クラウドインフラ・SRE・DevOps系
AWSやGCPのインフラ構築・運用、Terraform・Kubernetes・CI/CDパイプラインの整備といった案件は、リモートになりやすい代表格だ。
作業が完全にクラウド上で完結するため、物理的に現場に行く理由が薄い。
弊社でも、AWSのインフラ案件に入っているエンジニアの大半は完全リモートか、週1の定例出社で稼働している。
SaaS・スタートアップのWeb開発
上場スタートアップや、もともとリモートカルチャーで成長してきたSaaS企業は、SESエンジニアに対してもリモート前提で受け入れるケースが多い。
使っている技術がReact/TypeScript・Next.js・Go・Rustといったモダンスタックであることも多く、技術的な成長という観点でも選びやすい案件だ。
技術コンサル・アーキテクチャ設計
設計・レビュー・ドキュメント作成が中心の案件も、リモートと相性が良い。
ただし、このクラスの案件に入るには5〜8年以上の経験と、上流工程の実績が求められることが多い。
リモートになりにくい案件の特徴
反対に、以下の特徴がある案件は出社比率が高い傾向がある。
金融・官公庁・インフラ系の大規模SIer
セキュリティポリシーが厳しく、「作業は管理された場所で行うこと」というルールが社内規定に明記されていることが多い。
特に、開発環境へのアクセスが「社内LANのみ」や「特定のVPN環境のみ」に制限されている現場は、物理的に出社以外の選択肢がない。
銀行・証券・保険・中央省庁・電力・通信インフラといった領域の案件で、この傾向は顕著だ。
製造業・物流系の基幹システム
オンプレミス環境が残っている現場では、そもそもリモートアクセスの仕組みが整備されていないことが多い。
「サーバーに直接つなぐ作業がある」「物理機器の操作が必要」という場合は、出社必須になる。
既存システムの保守・運用（24時間対応あり）
監視・障害対応・定期バッチの確認といった業務が含まれる案件も、「何かあればすぐに現場に行ける状態」を求められることがある。
SES企業→SES企業の多重商流案件
これは見落とされがちだが、商流が深い案件（自社→一次請け→二次請け→クライアント）では、クライアントのポリシーが直接届かないことが多く、中間に入っている会社の方針で「念のため出社」というルールになっていることがある。
商流が深くなるほど、情報の伝言ゲームが起きやすく、「クライアントは別にリモートでもいいと言っているが、間に入っている会社がNGと言っている」という状況が発生する。
このため、リモートを希望するなら、できるだけ商流が浅い（エンドクライアントに近い）案件を選ぶことが重要だ。
商流の深さとリモートのしにくさには、相関がある。
関連記事: 商流の深さとは何か（なぜ単価が下がるのか）
リモート案件を増やすための現実的な方法
「リモートで働きたい」という希望自体は、多くのエンジニアが持っている。
しかしその希望が案件に反映されるかどうかは、スキルセットと交渉の仕方で大きく変わる。
クラウドスキルの取得がリモート率を上げる最短ルート
繰り返しになるが、クラウドインフラ案件はリモートになりやすい。
AWS・GCP・Azureのいずれかの認定資格を取得し、実務経験を1案件でも積むと、リモート案件へのアクセスが一気に広がる。
現実的な順番として:
- AWSであれば Solutions Architect Associate を取得する
- 現在の案件でクラウド関連の業務を少しでも担当する（コスト管理・EC2の操作でも可）
- その経験を職務経歴書に明記して、インフラ寄りの案件に転換する
「今の案件がJavaの業務系で、クラウドが触れない」という場合でも、副業・自己学習でAWSの経験を作り、次の案件交渉に使うことは可能だ。
上流工程の経験が交渉を有利にする
要件定義・基本設計の経験があると、「設計作業はリモートで、実装フェーズのキックオフだけ出社」という交渉が成立しやすくなる。
これはシンプルな理由で、上流工程はアウトプットが「ドキュメント」「議事録」「設計書」であり、物理的な場所に縛られる理由が薄いからだ。
「上流経験がない」という場合は、今の案件の中で「議事録を書く」「ドキュメントを整備する」「レビューに参加する」という経験を少しずつ積み、次の面談でその点を具体的に語れるようにしておく必要がある。
「フルリモート希望」より「週2出社まで可」の方が選択肢が広がる
案件を探す際、「完全リモート必須」という条件にこだわると、選べる案件数は激減する。
弊社の案件データ（2026年Q1時点）では、「完全リモートのみ」という条件だと候補案件は通常の10分の1以下になる。
一方、「週1〜2出社なら可」という条件にすると、ハイブリッド案件が一気に視野に入る。
ハイブリッドの案件に入って実績を作り、次の案件で「前回の案件もほぼリモートでした」という事実を武器に交渉する、という段階的な戦略の方が現実的だ。
また、週1〜2出社のハイブリッド案件には「チームとの関係構築ができる」「コミュニケーションコストが減る」という実務上のメリットもある。
完全リモートにこだわりすぎて選択肢を狭めるより、まずハイブリッドでスキルと実績を積み上げることを優先した方が、長期的には条件のいい案件にアクセスしやすくなる。
フルリモート（週0出社）に絞った案件条件・スキル要件・入場後の注意点については、SESでフルリモートは現実的かで詳しく解説している。
リモート案件の探し方・交渉術
担当営業への伝え方
「リモートで働きたい」と伝えるだけでは、担当者が動きやすい状況を作れない。
以下の情報をセットで伝えると、精度の高い案件が出てきやすい。
伝えるべき情報の型
「リモート比率の希望（週何出社まで可か）」「希望技術スタック」「経験年数と得意領域」「希望単価レンジ」「入場可能時期」
たとえば:「React/TypeScriptの経験が3年あります。週1〜2出社のハイブリッドで、単価60万以上のフロントエンドかフルスタックの案件を探しています。来月から動けます。」
この粒度で伝えると、担当者が案件を絞り込みやすくなる。
「リモートが希望」「スキルはJavaとAWS」という情報だけでは、担当者も動きにくい。
もう一点付け加えると、「リモートを重視する理由」を伝えると、担当者が案件のマッチ度を判断しやすくなる。
「介護中で緊急対応が必要な場合がある」「副業と掛け持ちするため集中時間を確保したい」「育児中で保育園のお迎えが週3ある」といった背景情報は、担当者が「この人には週5出社の案件は提案しない方がいい」という判断をする上で重要だ。
過度に個人情報を開示する必要はないが、働き方の希望の背景を共有することで、ミスマッチを防ぎやすくなる。
面談前に確認すべきリモートに関する質問
案件の面談が決まった時点で、以下を事前に確認しておくと認識のズレを防げる。
- リモート比率は固定か、フェーズや状況によって変わるか
- 現在のチームメンバーのリモート状況はどうか（SESエンジニアだけ出社、というパターンを避けるため）
- 出社が必要な理由は何か（セキュリティポリシー、定例会議、客先のルール等）
「週2出社」と聞いていたのに入ってみたら週4になっていた、という話は珍しくない。
入場前に、どういう場合に出社が必要になるかの条件を明確にしておくことが重要だ。
フリーランスエンジニアのリモート状況
正社員SESと比較すると、フリーランスエンジニアの方がリモート案件へのアクセスはやや有利になる傾向がある。
理由は2つある。
ひとつは、フリーランスエージェントが取り扱う案件はIT・Web・スタートアップ系の比率が高く、もともとリモート親和性が高いこと。
もうひとつは、フリーランスは「業務委託契約」として成果で評価されるため、クライアントとしても「週5管理」する必要がなく、リモートを許容しやすい。
ただし、フリーランスへの転身はスキルの水準が問われる。
「リモートしたいからフリーランスになる」という動機だけで動くと、単価が期待ほど上がらず、リモートも得られない、という結果になることもある。
参考: SESからフリーランスへの転身ガイド
リモート案件の単価相場と注意点
リモート可能な案件の単価感についても触れておく。
クラウドインフラ・SRE系のリモート案件は、単価が高い傾向がある。
AWSの設計・構築・運用の経験が3〜5年あれば、週1〜2出社のハイブリッドで月単価65〜80万円という案件は珍しくない。
Kubernetes・Terraform・CI/CDの実務経験があれば、完全リモートで月単価80〜100万円以上の案件にアクセスできるケースもある。
一方、Web系のフロントエンド案件（React/Vue/TypeScript）は案件数が多く競争が激しいため、単価は50〜65万円が中心帯になることが多い。
ただしフルスタック（フロント＋バック＋インフラ）まで担当できるエンジニアは単価が上がりやすく、70万円以上の案件も出てくる。
「リモートだから単価が低い」という構造はない。
単価を決めるのはあくまでスキルセットと経験年数だ。
リモートで「成長できない」問題の対処
リモートで孤立するエンジニアの共通点
リモートで働きたいと思っているエンジニアの一方で、「リモートになったら成長が止まった」という声も聞く。
この問題を抱えやすいエンジニアには共通点がある。
わからないことを「後で調べよう」で終わらせる
出社していれば隣の人に聞けたことが、リモートでは聞きにくい。
その結果、「まあいいか」と曖昧なまま進めてしまい、理解の穴が積み重なる。
コードレビューの機会が減る
リモートになると、気軽に「ちょっと見てください」という状況が作りにくくなる。
レビューの頻度が下がると、自分のコードの癖や問題に気づくフィードバックが減る。
「ついで学習」がなくなる
出社していると、周囲の会話から技術的なキーワードを拾ったり、隣のエンジニアが使っているツールに気づいたりする「ついで学習」が起きる。
リモートではこれが完全になくなるため、意図的に学習しないと情報が入ってこなくなる。
リモートでも成長を維持する具体的な方法
非同期でも「聞く文化」を作る
Slack・Teamsで質問する際、「〇〇という状況で、△△を試みましたが、□□というエラーが出ています。原因として××と××を考えていますが、他に可能性はありますか？」という形で質問する。
この形式で聞くと、相手が答えやすく、自分の思考整理にもなる。
出社時より考えてから聞く分、却って質問の質が上がることもある。
週次で「学んだこと・詰まったこと」を記録する
週に1度、15分でいいので「今週学んだこと」「今週詰まったこと・解決した方法」を記録する習慣を持つ。
記録するだけでも振り返りと定着が促され、「リモートだとなんとなく過ぎていく」という感覚を防げる。
外部コミュニティへの参加を意図的に入れる
社内での自然な交流が減る分、外部の勉強会・OSS活動・技術ブログへの参加を意図的に増やす。
LT登壇・Pull Request・Qiita投稿といった「アウトプット」は、インプットの動機にもなる。
実例：リモートに移行して成長が止まりかけたエンジニアの話
入社2年目で完全リモートの案件に入った山田さん（仮名）という方の事例を紹介したい。
AWSの案件で技術的には申し分ない環境だったが、6ヶ月経過した頃に「なんとなく頭打ち感がある」という相談が来た。
話を聞くと、案件の業務は一定のルーティンになっていて、わからないことは「調べれば解決できる範囲」になっており、詰まることがない状態になっていた。
提案したのは2つだ。
ひとつは、案件の担当領域を自分から広げること。具体的には、「コスト最適化のレポートを月次で作成する」という業務を自ら提案し、クライアントから承認を得た。
もうひとつは、AWS認定資格のSolutions Architect Professionalへの挑戦。Associate資格は既に持っていたが、Professional取得を目標にしたことで学習の動機が生まれた。
3ヶ月後、単価の引き上げ交渉の場で「コスト最適化によって月XX万円の削減を実現した」という実績を提示できるようになっていた。
リモートでも成長できるかどうかは、環境よりも自分から動いているかどうかの差が大きい。
Heydayでは契約単価・マージン・商流をすべて開示しています
「自分の単価が適正か分からない」「もっといい条件の案件があるのでは」という方のご相談を受け付けている。
Heydayでは稼働前に契約単価を本人に開示し、マージン構造についても質問があればすべて回答している。
案件例を見てみる →
キャリア相談をする →
よくある質問
Q. SESでリモート可能な案件はどのくらいありますか？
弊社が扱っている案件のうち、「週3以上リモート可」の案件は全体の約60%程度だ（2026年Q1時点）。
ただしこの割合は業種・技術スタック・時期によって変動する。
「完全リモート必須」という条件まで絞ると、選択肢は大幅に減る。
「週1〜2の出社は許容できる」という前提で案件を探すと、かなりの数から選べる状態になる。
Q. リモート案件を希望したら案件が決まりにくくなりますか？
全体の母数は減るが、リモート希望を伝えること自体で案件が決まらなくなることはない。
ただし「完全リモート・月単価60万以上・最新技術スタック」のように複数の条件が重なると、候補が絞られて決まるまでに時間がかかることはある。
優先順位をつけて、「完全リモート」か「最新技術スタック」かを担当者と一緒に整理することをすすめる。
Q. 入場後にリモート比率を増やすことはできますか？
できることはある。ただし入場直後からの交渉は難しい。
目安として、3〜6ヶ月稼働して「この人に任せられる」という信頼が積み上がってから提案するのが現実的だ。
「最近、集中作業が多く、リモートで進めた方が生産性が上がると感じています。週1回だけ試させてもらえますか？」という形で実績を作り、そこから「週2回」と段階的に増やすアプローチが成功しやすい。
Q. リモート案件はスキルが低いエンジニアには無理ですか？
経験年数が浅い場合、完全リモートの案件に入るのは難しいことが多い。
理由はふたつある。ひとつは、クライアント側が「フォローしやすい環境（出社）」を求めることが多いこと。もうひとつは、本人にとっても出社して学ぶ方が成長が早いケースが多いこと。
経験3年未満であれば、ハイブリッド案件で実績を作ることを優先した方が、長期的にリモート比率を上げやすくなる。
Q. リモートでも単価は変わりませんか？
案件の単価はリモートか出社かではなく、技術スタックと経験年数で決まることがほとんどだ。
「リモート可能な案件は単価が低い」ということはなく、クラウドインフラ系のリモート案件はむしろ高単価の傾向がある。
単価を上げたいなら、「リモートか出社か」ではなく「どのスキルを磨くか」を優先する方が合理的だ。
まとめ
SESのリモートワーク事情を整理すると、以下の3点に集約される。
1. リモートになれる案件とそうでない案件の差は明確に存在する
クラウドインフラ・スタートアップ・SaaS系はリモートになりやすい。
金融・官公庁・製造業の基幹系・多重商流のSIer案件は出社比率が高い傾向がある。
「SESはリモート無理」という認識は古い。ただし「全部の案件がリモートOK」という認識も現実と乖離している。
2. リモート率を上げるためにできることはある
クラウドスキルの習得、上流工程の経験、担当営業への具体的な条件提示。
「完全リモート必須」から「週1〜2出社まで可」に条件を緩めるだけで選択肢は大きく広がる。
まずハイブリッドで実績を作り、次の案件交渉を有利にする段階的アプローチが現実的だ。
3. リモートで成長し続けるには、意図的な仕掛けが必要
学習の記録、質問の習慣化、外部コミュニティへの参加。
リモートは環境のせいにしにくい分、成長するかどうかは自分の動き方に直結する。
SESの案件マッチングに関わってきた経験から言えることは、「リモートで稼げるかどうか」はスキルの問題だということだ。
リモートを実現するために必要なスキルを積み上げることで、自然とリモート可能な案件単価も上がっていく。
「リモートで働きたいけど、どんな案件を選べばいいか分からない」という状態なら、まず自分のスキルセットと市場単価を客観的に把握することからはじめてほしい。
今の自分がどのポジションにいるのかを知ることで、次のアクションが具体的になる。
あなたの市場単価を診断する →
案件例を見てみる →
関連記事
キャリアについて相談する →