「SES案件ガチャに外れた」——この言葉は、ここ数年でSESエンジニアの間にすっかり定着した。聞いた話と実態が違う、業務内容がスキルに合わない、現場の人間関係が崩壊している、成長が止まる気配がする——こうした「外れ」のパターンを、運任せのガチャに例える表現だ。
私はHeyday株式会社の代表、小川将司だ。SES事業を6年運営し、これまで80件以上の案件マッチングに関わってきた。エンジニア側からだけでなく、案件を「仕入れる」側から見たSES業界の景色には、エンジニアにはなかなか見えない構造的な問題がある。
正直に書くが、私自身も「これはハズレだった」と振り返る案件をいくつも経験している。営業として案件票を読み、面談して、配属して、それでも蓋を開けたら想定と違ったケースがある。だからこそ言える。案件ガチャはエンジニア個人の運の問題ではなく、業界構造の問題だ。
この記事では、案件ガチャに外れた後の動き方を経営者目線で整理する。具体的には次の4点だ。
- ハズレ案件の3パターン（スキル不一致／現場文化崩壊／成長ゼロ）の構造的見分け方
- なぜ案件ガチャが起きるのか（商流と情報非対称の解説）
- 外れた後の3段階の選択肢（改善交渉／更新拒否／即時離脱）
- 次に案件ガチャを引かないために選ぶべき会社の条件
「選び方」ではなく、引いてしまった後どうするかを中心に書いている。入る前のチェックリストが必要な方はSES案件の選び方｜ハズレを入場前に見抜く7チェックリストを先に読んでほしい。
SES案件ガチャとは何か
「案件ガチャ」という言葉が広まった背景には、SES特有の構造がある。エンジニアは自社（雇用主）に所属しながら、クライアント先で働く。案件は会社の営業が決め、配属が確定するまでエンジニアが現場の実態を知る手段は限られる。
ガチャと呼ばれる理由は、シンプルに3つだ。
- 配属前に得られる情報が案件票と短時間の面談に限られる
- 営業が把握している情報と、エンジニアに伝わる情報には差がある
- 配属後に「想定と違った」と気づいても、契約期間中は動きづらい
つまり、エンジニア視点では「中身が見えないカプセルを引いている」状態に近い。これがガチャと呼ばれる所以だ。
ただし、ここで重要なのは、ガチャの確率は会社や案件の「仕入れ方」によって大きく変わるという点だ。経営者として複数のSES会社の動きを見てきた立場から言うと、ガチャ率が低い会社と高い会社では、同じエンジニアが配属されてもハズレを引く確率が体感で2〜3倍違う。これは後半で解説する。
ハズレ案件の3パターン｜経営者目線で見た外れの構造
ハズレ案件と一口に言っても、外れ方には型がある。私がこれまで関わってきた80件以上の案件のうち、エンジニアから「失敗だった」と報告された案件を分類すると、以下の3パターンに集約される。
パターン1：スキル不一致型
最も頻度が高いのがこのパターンだ。案件票に書かれていた業務内容と、現場の実態が乖離しているケース。
具体的には次のような例がある。
- 「Java/Spring Bootでの新規開発」と書かれていたが、入ったら95%が既存システムのバグ修正だった
- 「クラウド移行案件」のはずが、実態はオンプレミスの仕様書を読んでExcelに書き写す作業だった
- 「フロントエンドエンジニア募集」だが、実際にはコーディングよりも仕様調整・ドキュメント整備が中心だった
このパターンの厄介さは、契約上は「IT関連業務」「開発業務全般」と広く定義されているため、契約違反を主張しづらいことだ。
経営者目線で言うと、こうしたミスマッチが起きるのは商流の途中で情報が削ぎ落とされるからだ。元請けから2次請け、2次請けから3次請けへと案件票が伝わる過程で、現場の細部が消えていく。3次請けの営業が読む案件票は、元請けが書いた原票のサマリーのサマリーになっていることが珍しくない。
パターン2：現場文化崩壊型
入ってみたら、現場の人間関係や運用が崩壊していたパターンだ。具体例を挙げる。
- プロパー（クライアント正社員）と協力会社の間に明確な序列があり、SES側に質問できる人がいない
- レビュー文化がなく、コードの品質チェックなしに本番反映される
- ミーティングで意見を出すと「協力会社は黙っていてほしい」と空気で釘を刺される
- 朝会・週次の進捗報告以外、まともなコミュニケーションが存在しない
このタイプは、案件票や面談ではほぼ察知できない。面談に出てくる人と、配属後に一緒に働く人が違うことが多いからだ。クライアントの人事・PMが面談を担当し、現場の実務はリーダーや先輩エンジニアが取り仕切るというパターンが典型的だ。
私が「これは現場が崩れている」と判断した案件で共通していたのは、面談中にプロジェクトの直近トラブルを聞いたときの反応だった。「最近のトラブルや課題はありますか？」と聞いて、明確に答えられない案件・「特にない」と即答する案件は、内部の情報共有が弱い可能性が高い。
パターン3：成長ゼロ型
スキル不一致や現場崩壊は明確に「外れ」と認識しやすいが、最も気づきにくく、長期的なキャリアダメージが大きいのがこのパターンだ。
成長ゼロ案件の特徴は次の通りだ。
- 業務はExcel保守・テスト消化・ドキュメント更新が中心
- 新しい技術スタックに触れる機会がない（5年前と同じ環境で動いている）
- レビューや技術的議論がなく、自分のコードが上達しているか分からない
- 1年いても、職務経歴書に書ける成果が「保守対応1年」しかない
このパターンは案件単価で見ても明確に出る。Heydayが取り扱う案件のレンジで比較すると、生成AI／RAG／LLM系の案件平均単価は97〜106万円、保守／テスト系の案件平均単価は68万円程度だ。約40%の差がつく（n=Heyday取扱案件、抽出期間：2025〜2026年Q1）。
問題は、保守/テスト系案件は短期で見ると居心地が良いことが多い点だ。残業が少なく、業務難度も高くなく、ストレスが小さい。だが3年続けると、市場価値の差は埋めようがないところまで広がる。私が見てきた中で、最も後悔の声が多かったのはこのパターンだった。
なぜ案件ガチャは起きるのか｜商流と情報非対称の構造
ハズレ案件の3パターンを示したが、根本原因を理解しないと再発する。なぜ案件ガチャという現象が起きるのか、経営者目線で構造を整理する。
原因1：商流の多重構造
SES案件は元請け→2次請け→3次請け→4次請けと階層化していることが多い。エンジニアが所属する会社が3次請け以下にいる場合、案件の元情報は2〜3社を経由してから営業のもとに届く。
経営者として複数のSES案件を仕入れている立場から正直に言うと、商流が深くなるほど案件票の情報密度は明確に下がる。元請けが書いた原票には「直近3ヶ月で離任者2名・現在炎上中」と書かれていても、3次請けに渡る頃には「急募・即日参画希望」とだけ書かれた状態になっていることがある。
これは仕入れる側のSES会社が情報を隠しているのではなく、商流の各段階で「ネガティブ情報を削らないと取引が継続できない」という力学が働いているからだ。元請けは「炎上案件」と書いた原票を出すと2次請けが受けてくれない。だから「急募」とだけ書く。2次請けも同じ理由で3次請けに対して情報を絞る。結果として、エンジニアに届く頃には案件の実態がほぼ消えている。
原因2：情報非対称（営業 vs エンジニア）
商流に加えて、同じ会社の中でも営業とエンジニアの間で情報の非対称が起きる。
営業は案件票・クライアント担当者からのヒアリング・過去の取引履歴という情報源を持っている。一方エンジニアは、案件票の抜粋と面談で得た情報しかない。営業が把握している「この案件、前任者が3ヶ月で離任した」「クライアントPMが厳しい人」「ドキュメントが整理されていない」といった文脈情報は、配属前にエンジニアに伝わるとは限らない。
私自身、Heyday立ち上げ初期に営業として案件を仕分けるとき、「ネガティブ情報をどこまで伝えるか」で判断に迷ったことがある。全部伝えると案件が成立せず、エンジニアの待機期間が伸びる。伏せると後で問題になる。この板挟みが、SES業界の情報非対称の根っこにある。
Heydayでは現在、ネガティブ情報も含めて案件票を共有する運用に切り替えているが、これは経営判断として「短期の成立率より中長期の信頼関係を優先する」と決めた結果だ。逆に言えば、こうした方針を取らない会社では、情報非対称はずっと残り続ける。
原因3：契約構造（更新サイクルとの不一致）
SES契約は3〜6ヶ月単位の自動更新が一般的だ。問題は、エンジニアが「これはハズレだ」と気づくタイミングが、契約更新サイクルと一致しないことが多い点だ。
具体的には、入場後1〜2ヶ月で違和感を感じても、契約期間が3ヶ月単位なら次の更新タイミングまでは原則動けない。動けないまま2ヶ月我慢している間に違和感は確信に変わり、ストレスが蓄積する。これが「ガチャに外れた」という強い感覚を生む構造的要因だ。
詳細な抜け方の段取りはSES案件を抜けたいときの言い方7パターンに書いたが、本記事では次のセクションで「外れた後の3段階の選択肢」を整理する。
ハズレを引いた後の3段階の選択肢
ガチャに外れたと気づいた後、いきなり「抜ける」を選ぶのは得策ではないことが多い。経営者として案件離脱の段取りを何度も見てきた立場から、3段階で考えることを推奨する。
段階1：改善交渉（即日〜2週間）
最初に試すべきは現場の改善交渉だ。「抜ける前に言うべきこと」がある。
具体的には次の3つのチャネルを使う。
- 自社営業に状況共有：「想定と業務内容が違う」「現場の運用に問題がある」と、客観的な事実ベースで伝える
- クライアントPMへの相談：業務範囲・期待役割の確認をしたい、という建付けで面談を依頼する
- チームリーダーとの1on1：業務内容の調整可能性を打診する
改善交渉のポイントは、感情ではなく事実とギャップで話すことだ。「思っていたのと違う」ではなく、「案件票には◯◯と書かれていたが、実際の業務は△△が95%を占めている」と数字で伝える。
実例を1つ挙げる。Heydayで配属したエンジニアが「クラウド移行案件のはずが、ほぼ仕様書をExcelに転記する作業」という状況に陥ったことがある。本人と相談し、自社営業からクライアントPMに「契約書の業務範囲確認」を申し入れた結果、業務分担が見直され、本来のクラウド移行業務に戻った。改善交渉で半数程度は状況が動くというのが私の体感だ。
段階2：更新拒否（契約満了の1〜2ヶ月前）
改善交渉が機能しない、もしくは「動いたが本質的な問題は変わらない」と判断したら、次の更新タイミングでの離脱を選ぶ。
更新拒否は法的に正当な権利だ。SES契約は契約期間ごとに更新可否を判断するもので、エンジニアが「次の更新は希望しない」と意思表示することに何の問題もない。
タイミングは契約満了の1〜2ヶ月前が理想とされる。これより遅れると、自社営業がクライアントに通達する余裕がなくなり、関係性が悪化する。逆にこのタイミングを守れば、多くの場合スムーズに離脱できる。
具体的な伝え方・文例はSES契約更新の断り方ガイドで解説しているが、要点は「ネガティブな現場批判ではなく、ポジティブなキャリア軸で伝えること」だ。
段階3：即時離脱（契約期間中の例外対応）
契約期間中の即時離脱は、原則として推奨されない。SES契約は会社間の準委任契約として結ばれており、一方的な離脱は会社とクライアントのトラブルにつながる。
ただし、例外的に即時離脱が正当化されるケースがある。
- ハラスメント・違法な労働条件・偽装請負の疑いがある場合
- 健康（メンタル含む）に明確な悪影響が出ている場合
- 案件票・契約書と実態が著しく乖離している場合（債務不履行に近い状態）
このケースでは、まず自社（雇用主）に相談し、医師の診断書や具体的な記録（メール・チャットの保存）を残した上で、書面で離脱の意思を伝える。労働基準監督署や弁護士に相談する選択肢もある。
経営者として正直に書くが、即時離脱が必要な状況に陥っている時点で、会社側にも問題があることが多い。すなわち、入場前のスクリーニングが甘い、エンジニアからのSOSを受け取る体制がない、案件継続のために問題を矮小化している、といった構造だ。離脱後の次案件・転職検討も同時に進めるべきだ。
抜けた後の動き方についてはSES待機期間の平均・給与・何するか完全ガイドを参考にしてほしい。
案件ガチャを次に引かないための「会社選び」3条件
3段階の対応が終わった後、次にやるべきはそもそも案件ガチャを引きにくい環境を選ぶことだ。エンジニア個人が案件票を読む力を上げることも有効だが、それ以上に大きいのが「所属する会社の仕入れ構造」だ。
経営者目線で、ガチャ率が構造的に低いSES会社の条件は3つある。
条件1：商流が浅い（できれば1次請け中心）
商流が浅い会社は、案件の原票に近い情報を扱える。元請けや1次請けと直接取引している会社なら、案件票の情報密度が高く、現場とのミスマッチが起きにくい。
確認方法はシンプルで、面接や面談で「今紹介できる案件のうち、何次請けが何割ですか？」と聞くことだ。明確に答えられない、もしくは「ほとんど2次請け以下」という会社は、ガチャ率が構造的に高い。
条件2：案件票の情報解像度が高い
案件票に書かれている情報の粒度を見ると、その会社の仕入れ姿勢が分かる。
良い案件票の特徴は次の通りだ。
- 業務内容が「フロント開発全般」ではなく「Next.js + TypeScriptで新機能開発／既存改修7：3」のように具体的
- チーム構成（プロパー/協力会社の比率・PMの経歴）が書かれている
- 直近のプロジェクト状態（炎上中／安定／立ち上げフェーズ）が明示されている
- 過去にそのクライアント案件に入ったエンジニアからのフィードバックが共有される
逆に「IT業務全般・開発業務」のような抽象表現が多い会社は、仕入れの段階で情報を取れていない可能性が高い。
条件3：抜けやすい運用が組み込まれている
ガチャに外れたときの「抜けやすさ」も重要だ。具体的には次のような運用があるかを確認する。
- 配属後1ヶ月時点で営業との振り返り面談がある
- 「合わなかった場合の離脱手順」が事前に共有されている
- 待機期間中の給与が明示されている（労働基準法26条で60%以上保証だが、Heydayは100%支給）
- 営業・エンジニア双方からの案件評価データが社内に蓄積されている
抜けやすい運用がある会社は、入場後にミスマッチが発覚しても短期で軌道修正できる。これだけで案件ガチャの実質的なダメージは大幅に下がる。
ホワイトSES会社の見極め方はホワイトSES会社の見つけ方｜現役経営者が教える13の見極めポイントで詳細を解説している。
Heydayが「案件ガチャ」を構造的に減らしている仕組み
宣伝目的の話ではなく、構造の話として書く。
Heydayでは案件ガチャを減らすために、次の運用を組み込んでいる。
- 商流の浅い案件中心：1次請け・直契約の比率を意識的に高めている
- 案件票の解像度向上：業務内容・チーム構成・直近トラブルを必ず記載するフォーマットに統一
- 配属後フォロー：1ヶ月時点・3ヶ月時点で営業がエンジニアと面談し、ミスマッチを早期検出
- 待機期間の給与100%支給：抜けたいタイミングで「次が決まらないから我慢」を発生させない
- ネガティブ情報の事前共有：契約成立率より中長期の信頼を優先するという経営判断
これらは「案件ガチャゼロ」を保証するものではない。商流の構造上、どんな運用をしてもガチャ率はゼロにならない。ただし、構造的にハズレを引きにくく、引いてしまっても短期で抜けやすい仕組みは作れる。透明性プラットフォームとしてSES業界に必要なのは、この種の仕組みだと考えている。
まとめ｜案件ガチャは「運」ではなく「構造」で決まる
最後にこの記事の要点を整理する。
- ハズレ案件は「スキル不一致」「現場文化崩壊」「成長ゼロ」の3パターンに集約される
- 案件ガチャの根本原因は商流の多重構造と情報非対称・契約サイクルのズレにある
- 引いてしまった後は「改善交渉→更新拒否→即時離脱」の3段階で考える
- 次にガチャを引かないために「商流の浅さ・案件票の解像度・抜けやすい運用」の3条件で会社を選ぶ
- 単価レンジの差（生成AI系97〜106万円 vs 保守系68万円）は、ガチャの当たり外れの実態を数字でも示している
案件ガチャは、エンジニア個人が運悪く外れを引いた問題ではない。SES業界の構造が生み出している現象だ。だからこそ、対処法も「個人で頑張る」ではなく「構造を理解して動く」ことが重要になる。
今の案件にハズレ感を覚えている方、次の案件選びで失敗したくない方は、まず自分の市場価値と相場を把握することから始めてほしい。Heydayの診断ツールでは、技術スタック・経験年数・希望条件から、現実的な単価レンジと案件の方向性を確認できる。
関連記事：
