「SES案件ガチャ」という言葉を聞いたことがあるだろうか。
SESで働くエンジニアの多くが、案件選びに不安を感じている。案件の当たり外れが収入やキャリアに直結するにもかかわらず、入ってみるまで実態が分からないケースが多い。面談で聞いた話と現場の実態が違った、という経験を持つエンジニアも少なくない。
私はHeyday株式会社でSES営業を担当している篠田だ。日常的にクライアント企業から案件の依頼を受け、エンジニアに紹介する立場にいる。案件票を見た瞬間に「これは危ない」と感じることがある。急募なのに業務内容が曖昧、単価が相場から明らかに外れている、前任者の退場理由を聞いても歯切れが悪い——こういう案件は、営業側では「触らない方がいい」と判断する。
ただ、エンジニア側にはその判断基準が共有されていないことが多い。「営業が選んできた案件だから大丈夫だろう」と思って入場した結果、現場とのミスマッチに苦しむケースを何度も見てきた。
この記事では、営業として案件を仕分ける際に実際に使っている判断基準を、エンジニア側にも共有する。案件票や面談の段階で危険信号を見抜くための7つのチェックリストだ。
SES案件選びが重要な3つの理由
年収に直結する
SESの案件単価は、言語・フレームワーク・工程・商流によって月額20万円以上の差がつくことがある。同じスキルセットのエンジニアでも、案件次第で年収に240万円もの開きが生まれる。
案件を「選ぶ」のではなく「振られるがまま受ける」状態では、市場価値に見合った報酬を得るのは難しい。
キャリアの方向性を決める
SESエンジニアのスキルは、参画した案件の内容で形作られる。モダンな技術スタックの案件に入れば最新技術が身につき、レガシーシステムの保守案件ばかりでは市場価値が停滞する。
1年間の案件選択が、3年後のキャリアの選択肢を広げるか狭めるかを決める。これは大げさな話ではなく、エンジニアの案件移動を何十件も見てきた中で繰り返し目にしてきた現実だ。
たとえば、Java+Springの保守案件を3年続けた方と、途中でクラウド移行案件に入った方では、3年後の市場単価に月10〜15万円の差がつくことがある。案件を「選ぶ」かどうかで、この差が生まれる。
メンタルヘルスに影響する
案件先の人間関係や業務内容がストレスの源になるケースは多い。特にSESは客先常駐であるため、合わない現場に入ると逃げ場が少ない。
案件選びの段階でリスクを見極めることが、健全に働き続けるための予防策になる。
ハズレ案件に共通する特徴
営業として案件を見続けていると、「このパターンは危ない」という嗅覚が身につく。実際にエンジニアから「この案件は失敗だった」と報告される案件には、共通する特徴がある。
正直に言うと、営業側が「条件は悪くないから紹介しよう」と判断した案件でも、現場に入ると想定と違ったということは起きる。だからこそ、エンジニア自身にも判断基準を持ってほしい。
業務内容が曖昧な案件
案件票に「開発業務全般」「その他付随する業務」としか書かれていない場合、入ってから何をやらされるか分からない。最悪のケースでは、開発のつもりで入ったのにテスト要員として使われる、ということが起きる。
単価が相場より極端に低い案件
Java経験3年のエンジニアに対して月額40万円の案件が来た場合、相場（55〜70万円）から大きく外れている。単価が低いということは、商流が深い（多重下請け）か、クライアントが案件を安く買い叩いているかのどちらかだ。
急募・即日参画の案件
もちろん正当な理由で急募になるケースもある。しかし、急募案件の一定割合は「前任者が辞めた」「トラブルプロジェクトで人が足りない」という背景がある。急募の理由を確認せずに飛びつくのは危険だ。
面談なしで決まる案件
通常、SES案件ではクライアントとの面談（顔合わせ）がある。面談なしで決まる案件は、誰でもいいからとにかく人を入れたいという状況であり、案件の質が低い可能性がある。
SES案件を見極める7つのチェックリスト
ここからが本題だ。案件票や面談の段階で確認すべき7つのポイントを、優先度順に解説する。
チェック1: 商流の深さ（何次請けか）
最も重要なチェックポイントだ。商流の深さは単価と案件の質の両方に影響する。
- エンド直（1次請け）: 単価が高く、要件が明確で、上流工程に関われる可能性が高い
- 2次請け: 業界では一般的。単価は1次より下がるが、案件の質はまだ保たれることが多い
- 3次請け以降: 単価が大幅に下がり、指示系統が複雑になりやすい
確認方法は単純で、「この案件は何次請けですか？」と営業担当に聞けばいい。答えをはぐらかす場合は3次請け以降の可能性が高い。商流が深い案件のリスクと具体的な判別方法はSES多重派遣の見分け方で詳しく解説している。
チェック2: 開発工程と具体的な業務内容
「開発」と一口に言っても、設計・実装・テスト・保守で求められるスキルもキャリアへの影響もまったく異なる。
確認すべきポイントは以下だ。
- 自分が担当する工程は具体的に何か（基本設計、詳細設計、実装、単体テスト、結合テスト等）
- チーム構成と自分のポジション（リーダー、メンバー、テスター等）
- 使用する技術スタック（言語、フレームワーク、インフラ、CI/CDツール等）
- コードレビューの有無と開発プロセス（アジャイル/ウォーターフォール）
案件票に「詳細設計〜テスト」と書かれている場合、実態としてテストがメインになるケースがある。面談時に業務の比率を具体的に確認すべきだ。
チェック3: チーム構成と現場の体制
一人で客先に常駐する「単独常駐」と、チームで入る案件では、働きやすさが大きく異なる。
- 単独常駐: 技術的な相談相手がおらず、孤立しやすい。ただし裁量が大きい場合もある
- チーム常駐: 同じ会社のメンバーがいれば安心感がある。技術的なフォローも受けやすい
- 現場のエンジニア人数: 5名以下の小規模チームか、50名超の大規模プロジェクトかで雰囲気が変わる
特に経験が浅いエンジニアは、チーム常駐かつ先輩エンジニアがいる案件を選ぶことを強く推奨する。
チェック4: 残業時間と稼働の安定性
案件票に「残業月20時間程度」と書かれていても、繁忙期には40〜60時間に膨れ上がるケースがある。
確認すべきは以下の3点だ。
- 直近3ヶ月の平均残業時間
- 繁忙期のピーク残業時間
- 過去1年で休日出勤が発生した頻度
SES契約の場合、稼働時間の精算幅（例: 140〜180時間/月）が設定されていることが多い。この精算幅の上限が200時間以上の案件は、長時間稼働を前提としている可能性がある。
チェック5: 契約期間と更新条件
SES契約の多くは3ヶ月更新だ。しかし、中には1ヶ月更新の案件もあり、いつ契約終了になるか分からない不安定な状態に置かれる。
- 長期案件（1年以上の見込み）: 安定した稼働が期待できるが、スキルの固定化リスクがある
- 短期案件（3〜6ヶ月）: 多様な経験が積めるが、次の案件が見つかるまで待機リスクがある
自分のキャリア段階と目的に応じて、適切な期間の案件を選ぶべきだ。
チェック6: 勤務地とリモートワークの条件
コロナ以降、リモートワーク可の案件が増えたが、最近はオフィス回帰の傾向も見られる。
確認すべきは以下だ。
- フルリモート/ハイブリッド/フル出社のどれか
- ハイブリッドの場合、出社頻度はどの程度か（週1、週3等）
- リモートワークの条件が将来変更される可能性はあるか
「フルリモート」と聞いて入ったのに、3ヶ月後に「週3出社に変更」となるケースも実際にある。面談時にリモートワークの継続方針を確認しておくべきだ。
チェック7: 案件を紹介する営業担当の姿勢
これは案件そのものではなく、案件を紹介するSES企業の営業担当に対するチェックだ。
以下のような営業担当には注意が必要だ。
- 案件の詳細を聞いても曖昧な回答しかしない
- 「とりあえず面談に行ってみましょう」と案件の中身を確認せず面談を急かす
- エンジニアの希望条件を聞かずに案件を押し込もうとする
- 商流や単価について質問すると不機嫌になる
逆に、案件のリスクも正直に伝え、エンジニアの希望と案件のミスマッチを事前に指摘してくれる営業担当は信頼に値する。
これは自分自身に言い聞かせていることでもある。営業にとって「案件を決めること」は売上に直結する。だから、エンジニアに「この案件は見送った方がいい」と言うのは、正直なところ勇気がいる。それでも「ここに入っても長続きしない」と判断した案件を無理に紹介して、3ヶ月で退場になれば結局は誰も得をしない。短期の売上より、エンジニアが長く稼働できる案件を選ぶ方が、営業としても合理的だ。
案件選びで営業担当に聞くべき質問
上記7つのチェックリストをもとに、面談前に営業担当に確認すべき質問を整理する。
案件の背景に関する質問
- 「この案件は新規募集ですか？前任者の交代ですか？」
- 「前任者がいた場合、なぜ抜けたのですか？」
- 「このポジションはいつから募集していますか？」
長期間決まらないポジションは、条件が厳しいか、現場に問題があるかのどちらかだ。
現場環境に関する質問
- 「現場のPMやリーダーはどんな方ですか？」
- 「過去にこの案件に入ったエンジニアの評価はどうでしたか？」
- 「現場で使っているツール（Slack、Jira、Git等）を教えてください」
使用ツールを聞くだけで、現場の技術レベルがある程度推測できる。未だにExcelでの管理がメインの現場は、技術的に保守的な可能性が高い。
契約条件に関する質問
- 「契約単価はいくらですか？」
- 「精算幅は何時間ですか？」
- 「契約更新のタイミングと判断基準はどうなっていますか？」
単価を開示しない方針の企業もあるが、聞くこと自体は当然の権利だ。単価が分からなければ、自分の報酬が適正かどうかも判断できない。
案件選びを失敗したときのリカバリー方法
どれだけ慎重に選んでも、入ってみたら想定と違うという状況は起こりうる。その場合のリカバリー方法を3つ示す。
営業担当に早期相談する
問題を感じたら、1ヶ月以内に営業担当に報告すべきだ。「もう少し様子を見よう」と3ヶ月我慢した結果、心身を消耗するケースは多い。
営業担当にとっても、エンジニアの不満が蓄積して突然退場されるより、早期に相談してもらった方がリカバリーしやすい。
契約更新時に条件交渉する
業務内容や残業時間が当初の説明と異なる場合、契約更新のタイミングで条件改善を求めることができる。交渉材料として、具体的な事実（「月40時間の残業が常態化している」等）を記録しておくことが重要だ。
案件変更を依頼する
改善の見込みがない場合は、契約更新をせず別の案件への移動を依頼する。この際、次の案件が決まる前に退場すると待機期間が発生するため、営業担当と連携して並行で次の案件を探すのが理想だ。
SES契約は3ヶ月ごとの更新が多いため、正社員のように「辞めるのは大変」ということはない。合わない案件に長期間縛られる必要はない。
技術スタック別：案件がキャリアに与える影響
案件選びをチェックリストだけで判断するのは不十分だ。「どの技術スタックの案件に入るか」が、3年後のキャリアの選択肢を大きく変える。
モダンスタックが身につく案件の見分け方
モダンな技術スタックが使われている案件には、以下の特徴がある。
- CI/CDツールの利用: GitHub Actions、CircleCI、ArgoCD等
- コンテナ環境: Docker、Kubernetes
- クラウドネイティブ: AWS ECS/EKS、GCP CloudRun等
- アジャイル開発: Scrum、2週間スプリント
これらのツール・手法を使っている案件に入れば、市場価値の高いスキルが自然に身につく。面談時に「現場で使っているCI/CDツールを教えてください」と聞くだけで、現場の技術レベルがある程度分かる。
レガシー案件に入るリスク
一方、以下の特徴を持つ案件はレガシー寄りである可能性が高い。
- ソースコード管理がSVN（Subversionでバージョン管理）
- Excelでの設計書・テスト管理が主流
- JavaのバージョンがJava 8以前
- ウォーターフォールで半年〜1年単位のリリースサイクル
レガシー案件でも経験を積むことはできるが、3〜5年後に転職やフリーランス転向を考えた際に、市場価値が低く評価されるリスクがある。入る前に、現場の技術環境を必ず確認すべきだ。
経験年数別の案件選びの優先度
| 経験年数 | 最優先すること |
|---|
| 1〜3年 | モダンスタック・メンター有・チーム常駐 |
| 3〜5年 | 上流工程へのチャレンジ・エンド直案件 |
| 5年以上 | リーダー経験・要件定義・PM関与 |
| 10年以上 | 顧客折衝・提案・アーキテクチャ設計 |
まとめ
SES案件選びで確認すべき7つのチェックリストを整理した。
- 商流の深さ: 何次請けかで単価と案件の質が大きく変わる
- 開発工程と業務内容: 「開発」の具体的な中身を確認する
- チーム構成: 単独常駐かチーム常駐かで働きやすさが異なる
- 残業時間: 直近の実績値と精算幅の上限を確認する
- 契約期間: キャリア目的に合った期間の案件を選ぶ
- 勤務地とリモート条件: 変更の可能性も含めて確認する
- 営業担当の姿勢: 案件のリスクを正直に伝えてくれるか
SESの「案件ガチャ」は、正しいチェックリストを持つことで大幅にリスクを下げられる。エンジニア自身が案件を選ぶ力を持つことが、キャリアを自分でコントロールする第一歩だ。
断り方の実例：案件を上手く断るコミュニケーション
「断れます」と聞いていたのに、実際に断ると空気が悪くなる——そういう経験をしたエンジニアは多い。断ることは権利だが、伝え方が重要だ。
感情ではなく理由で断る
悪い断り方：「この案件は嫌です」
良い断り方：「現在のキャリア目標として上流工程の経験を積みたいと考えています。今回のテスト中心の案件では、その目標との整合性が取れないと感じています。他の案件の可能性はありますか？」
理由が明確であれば、営業担当も「次はこういう案件を探そう」という方向で動ける。感情的な拒否よりも、建設的な断り方が双方にとってプラスだ。
断る基準を事前に伝える
入社時や最初の面談で「自分のキャリア方針」を明確に伝えておくと、合わない案件を提示される頻度が下がる。
「Pythonを使った開発案件を希望している。テスト専任や運用保守は、よほど条件が良くない限りお断りしたい」と伝えておく。これにより営業担当が最初から案件を絞って提示するようになる。
代替案を一緒に考えてもらう
「断る」と同時に「次をどうするか」の議論を始めることで、関係を壊さずに断れる。「今回の案件は合わないが、〇〇の条件が揃った案件なら前向きに検討したい」という姿勢を示す。
Heydayでは契約単価・マージン・商流をすべて開示しています
「自分の単価が適正か分からない」「もっといい条件の案件があるのでは」という方のご相談を受け付けている。
Heydayでは稼働前に契約単価を本人に開示し、マージン構造についても質問があればすべて回答している。
案件例を見てみる →
キャリア相談をする →
よくある質問（FAQ）
Q. 良い案件と悪い案件の見分け方を一言で教えてください。
「業務内容・商流・残業実績の3点が面談前に開示されているか」が最大の判断材料です。これらを明示できる案件は、クライアント・SES企業ともに情報を隠す必要がない状態です。逆に「詳細は参画後に」「商流は答えられない」という案件は、何かしら不利な実態を隠している可能性が高いです。
Q. 単価だけを基準に案件を選んでも大丈夫ですか？
単価だけで選ぶのは危険です。単価が高くても、商流が3次以降であれば手取りが大幅に下がります。また、レガシーシステムの保守案件は単価が高くてもキャリアへの影響がマイナスになる場合があります。単価・商流・開発工程・技術スタックの4点をセットで評価することが、短期の収入と長期のキャリアを両立させる案件選びの基本です。
Q. スキルアップできる案件の特徴は何ですか？
CI/CDツール（GitHub Actions等）・コンテナ（Docker/Kubernetes）・クラウドネイティブ開発を使っている案件は、市場価値の高いスキルが自然に身につきます。また、設計フェーズから参画できる案件は上流工程の経験が積めます。面談時に「現場で使っているCI/CDツールを教えてください」と聞くだけで、その現場の技術レベルを手軽に推測できます。
案件を選ぶ前に、自分の市場単価を確認しよう
良い案件を選ぶためには、自分のスキルが市場でどう評価されているかを知ることが必要だ。言語・経験年数・クラウドスキルを入力するだけで、現在の市場単価レンジが分かる。
関連記事
良い案件を選ぶ基準を理解した上で、所属企業の選定や単価交渉に活かしたい方は以下の記事も参考にしてください。
案件の単価・商流を評価するための知識
所属企業そのものを見直す
面談・スキルアップで次の案件を取りに行く
実際にHeydayに移った人の声
この記事の内容を、実際に経験した人の話で確かめてほしい。