現場に入ってから「こんなはずではなかった」と気づいても、すでに遅いことがあります。契約は締結済み、常駐は始まっている。そこから条件を変えようとすれば、相手も体制も、すでに「あなたがいる前提」で動いています。
エージェントは案件を紹介します。しかし、「あなたがその案件に合っているか」「その現場が安全か」を判断するのは、最終的にあなた自身です。エージェントが持ってくる情報だけで判断すると、入場後に取り返しのつかない状態になることがあります。
あなたはこれまで、参画前に何を確認してきましたか。「なんとなく合いそう」で入ってから詰まった経験はありませんか。
エージェントが渡してくる情報は、すでに加工されている
エージェントから届く案件情報には、使える情報と使えない情報が混在しています。問題は、どちらも同じ「案件票」という形式で届くことです。
経歴書は営業都合で書き換えられる
エージェントが作成・調整する経歴書は、採用側へのアピールを優先します。半年以下の経験でも「3年以上経験者」として提示される構造は、SES業界では珍しいことではありません。
現場は経歴書の通りに仕事を振ります。「3年以上の経験がある人材」として送り込まれた以上、その水準を前提に扱われます。結果として、経歴と実力の乖離は現場に入ってから全て本人が引き受けることになります。
自分の経歴書がどう書かれているか、エージェントに確認を取ったことはありますか。
案件票に書かれない情報が、現場の実態を決める
最近届いた基盤案件を見ていると、表向きは「構築」「試験」「不具合修正」と書かれていても、
実際には既存資源を読み解き、自力で立ち回り、曖昧な責任分界を吸収することが前提になっている案件が多いです。
たとえば、こういった案件が実際に届いています。
- 案件例1（首都圏・金融系基盤更改）
本番・試験環境の構築、ミドルウェア設定、技術調査、ドキュメント作成が作業範囲。
工程は試験フェーズで、不具合修正の比重が高い。
Linux系サーバー構築・Shell作成・解析・ミドルウェア設定経験が必須。夜間・休日対応あり。 - 案件例2（首都圏・金融系基盤構築）
詳細設計以降、構築・試験・リリースまでを担当。
Linux系サーバー構築、Shell、複数ミドルウェアの設定経験が必須。
既存資源を踏まえて自走できることが前提。月額固定型での募集。
どちらも技術要件は明確に書かれています。しかし案件票には書かれていないことがあります。
こういった案件情報を見るときは、技術要件より先に下記の情報を詳細に確認する必要があります。
- 「何が未整理のまま渡されるか」
- 「どこまでが担当範囲か」
- 「既存資源の読み解き負荷がどれくらいあるか」
案件票は現場の入り口を説明するものですが、入った後の実態は書かれていない部分に集中していることが多いです。
これらのポイントを具体的に説明できないエージェントは、技術的な話がそもそも通じません。現場で問題が起きて状況を伝えても、理解が追いつかないため解決の糸口にならないことがほとんどです。案件票の読み方を知っているかどうかは、何かあったときに頼れる相手かどうかの判断基準にもなります。
ここで確認しておきたいのは、そのエージェントが本来の役割を果たせる相手かどうかという点です。
そもそもエージェントとは、プロスポーツ選手の代理人を見れば分かる通り、契約者の利益を守るために交渉事を代行する存在です。選手の代わりに条件を交渉し、不利な契約を防ぎ、キャリアを守ることが本来の役割です。
SES業界のエージェントは、その役割を果たせていません。
技術要件の精査も、現場の実態確認も、参画後のフォローも、実際にはほぼ機能していないのが実態です。
なぜそうなるかといえば、商流の中間に立って人を動かすことで収益を得る仕組みである以上、エンジニアの利益より参画を成立させることが優先されるからです。
案件票のポイントを具体的に説明できないエージェントは、技術的な話がそもそも通じません。
現場で問題が起きて状況を伝えても、理解が追いつかないため解決の糸口にならないことがほとんどです。
参画前にこの点を見ておくことが、入場後に一人で詰まるリスクを下げる最初の判断になります。
参画前に確認すべき5つの項目
入場後に困る原因の多くは、参画前に確認できた情報の欠落から来ています。
この5項目は、後から取り戻すことが最も難しい情報です。
① 商流の深さと指揮命令系統
何社を経由して案件に入るか、直接の発注者はどの会社か。この確認を怠ると、現場で「誰に何を確認すればよいか」がわからなくなります。
商流が深い案件ほど、エンジニアの発言権は弱くなります。問題が起きても、上流への伝達には何社かを経由する必要があり、修正の指示が届くのも遅れます。3社以上の商流であれば、指揮命令の実態がどこにあるかを明確にしてから入場する必要があります。
② 責任範囲と担当境界
下記に近しい言葉が面談で出た場合、それは責任範囲が未定義の案件である可能性が高いです。
- 「何でもやってください」
- 「柔軟に動いてください」
入場後に責任範囲を後から決めようとすると、すでに「なんでもできる人」として周囲の期待が固まっており、境界線を引くことが難しくなります。
特に後々問題になりやすいのが、システム基盤・AP基盤・アプリ開発それぞれの境界です。仮にあなたが3層システムのAP基盤担当として参画を提案された場合、たとえばWeb-AP環境であれば責任分界は以下のように整理できます。
ここまで明確に答えられなくても構いません。ただ、この内容を読んで意味が通じるかどうかで、そのプロジェクトの技術レベルと責任分界の成熟度がおおよそ分かります。
面談や事前確認の場でこの話が全く通じない相手であれば、現場に入ってから責任の境界を自分で引き続けることになると思っておいた方が無難です。
参画前に「担当範囲の境界はどこか」「範囲外の依頼が来た場合の対応は誰が判断するか」を確認しておく必要があります。
③ 体制と教育・サポートの有無
現場にメンターや教育担当がいるかどうかは、案件票では判断できません。エージェントは「初心者でも大丈夫です」と言って経験の浅いエンジニアを案件に送り込みます。しかし現場には既存のエンジニアがいて、その人たちが面倒を見る前提で話が進められていることがあります。
問題は、その話が現場側のエンジニアに一切伝わっていないことです。エージェントは現場の受け入れ担当や管理側とだけ話を進めます。実際に隣で作業するエンジニアは、蓋を開けて初めて「なぜか自分がフォロー役になっている」と気づきます。
当然、納得できません。自分の作業をこなしながら、合意もしていないフォロー役を押しつけられる形になるからです。これがいざこざの温床になります。歓迎されない空気、露骨な無視、雑な扱い。あなたがその現場に入った場合、技術以前の問題としてこの空気の中でスタートすることになります。
エージェントは人を席に座らせた時点で売上が発生します。参画が成立すれば振り上げも発生するため、その後に現場で何が起きようと直接の損失にはなりません。「初心者でも大丈夫」という言葉は、現場の実態を確認した上での発言ではなく、参画を成立させるための言葉だと思っておく必要があります。
体制図と、相談先が誰になるかを事前に確認しておくことが必要です。「チームで協力して進めてください」という言葉が出た場合は、体制の実態が何も決まっていないまま話が進んでいる可能性があると思っておいた方が無難です。
もうひとつ見落としやすいのが、貸与PCの問題です。多くのSES案件はAIの使用を禁止しています。現場で優秀とされるエンジニアほどAIを武器として活用していますが、貸与PCでは社内ポリシーの制約からそれができません。実際、ベテランエンジニアが「自分のPCで作業させてもらわないと間に合わない」と直談判するケースは珍しくありません。
皮肉なのは、AIを最も必要としているのは初心者であるという点です。調べ方が分からない、質問の切り出し方が分からない、そういう場面でAIは大きな助けになります。しかしAI禁止・貸与PC前提の現場では、その手段が最初から封じられています。「初心者でも大丈夫」と言って送り込んでおきながら、助けになるツールは使えない環境に放り込まれるのが、SESの実態のひとつです。
④ 仕様や要件の確定度
仕様が未確定の状態で入場すると、「とりあえずやってください」で動くことになります。しかしSES現場の実態として、そもそも仕様書や設計書がまともに存在しないケースが珍しくありません。
SESは寄せ集めの集団です。プロジェクトごとに人が集まり、案件が終われば散っていきます。その構造の中で作られる設計書や仕様書は、実情を正確に反映したものにはなりにくいです。作成者自身が理解しきれていない状態で書かれるため、必要な情報が抜け落ちていることが当たり前になっています。ここ数年で仕様書の品質が驚くほど低下しているのは、その積み重ねの結果です。
つまり「仕様書があるかどうか」を確認するだけでは不十分です。あったとしても、そこに書かれている内容が実際の現場の動きと一致しているかどうかは別の話です。素人同然のエンジニアが作成した設計書を渡されて「これを読んで自走してください」という前提で進む案件は、入場後に自分で仕様を読み解き、抜けを埋め、判断し続けることが暗黙の役割になります。
参画前に確認すべきは「仕様書の有無」ではなく「仕様書を見せてもらえるか」「その内容で実際に動けるか」です。「仕様は入ってから固めていきます」という案件は、責任も仕様も入ってから全て本人に集まる構造を持っていると思っておいた方が無難です。
🖥️ インフラエンジニアとして参画する場合
インフラエンジニアとして参画する場合、論理図が作成されているかどうかが最初の確認軸になります。論理図がない現場は、ネットワーク構成・サーバー間の通信経路・役割分担が誰の頭の中にもきちんと整理されていない可能性があります。「構成は把握している人に聞いてください」という現場は、その「把握している人」が離脱した時点で情報が消えます。論理図の有無は、その現場がインフラの実態をどこまで言語化できているかを測る最初の尺度です。
💻 プログラマとして参画する場合
プログラマとして参画する場合は、フレームワークの有無とDBの管理体制が最初の確認軸になります。フレームワークがない現場は、設計の一貫性がなく、人によって書き方がバラバラになっていることが多いです。DBについては専任のDBチームが存在するかどうかを確認しておく必要があります。DBチームがいる現場であれば、テーブル設計や接続管理はそちらの責務になります。しかしDBチームが存在しない、あるいは曖昧な体制の現場では、本来DBチームが担うべき範囲まで自分が関わることになります。参画前にどこまでが自分の担当範囲かを確認しておかないと、入場後に際限なく作業が広がる構造になりやすいです。
職種を問わず共通して確認が必要なのが、開発環境が自分たちで自由に使えるかどうかです。本番・評価・テストの各環境が存在していても、それが全て顧客資産である場合、自分たちの判断で自由に検証やテストを行うことはできません。実際にこういった現場では、環境を使うたびに顧客側の承認が必要になり、試行錯誤ができない状態で作業を進めることになります。これはぶっつけ本番で本番環境を触らせられるのと実態としては変わりません。環境が存在するかどうかではなく、その環境を自分たちが自由に使えるかどうかを参画前に確認しておく必要があります。
⑤ 契約上の役割と現場で振られる実務のズレ
契約書や発注書に記載された役割と、実際に現場で振られる作業が一致しているかを確認します。しかし参画前の面談でこういった詳細を確認しようとすると、「細かいことは現場の担当者に確認してください」と返してくるエージェントがいます。
「現場で確認してください」は危険なサイン
これは危険なサインです。現場の実態を把握していないか、把握していても意図的に曖昧にしているかのどちらかです。人を席に座らせて売上が発生すれば目的は達成されるため、参画後に何が起きるかはエージェントの関心の外にあります。「現場で確認してください」という言葉は、その案件について責任を持って説明できないという意味だと受け取っておく必要があります。
問題はここからです。こちらに経済的な余裕がない場合、そのエージェントが危険だと分かっていても断ることができません。断れば収入が途絶えるため、リスクを承知の上で参画するしかない状況に追い込まれます。SES現場で理不尽な役割を押しつけられるエンジニアが後を絶たない背景には、この構造があります。
参画前に確認する3点
だからこそ、余裕があるうちに動くことが重要です。参画前に「契約上の役割」「実際の作業範囲として想定されるもの」「範囲外と判断した場合の対応」の3点を確認しておくことで、入場後に便利屋として固定されるリスクを下げることができます。エージェントがこの3点に答えられない場合は、その時点で判断材料のひとつになります。
SESに参画して現場に満足できることは、まずありません。環境・体制・役割、どれをとっても理想通りにはいかないのが実態です。それを前提に、目的を最初から絞っておくことが必要です。
「技術の習得」「キャリアの加算」「自立への資金確保」この3点のどれを取りに行くのかを参画前に決めておく。現場への期待を捨て、自分が何を得るための場所として使うかを設計しておくことで、理不尽な環境に消耗しきらずに済みます。3点全てを追う必要はありません。この案件では何を取りに行くのかを一点に絞るだけで、現場での判断軸が変わります。
割り切りと撤退ラインを先に決める
もうひとつ決めておくべきなのが、逃げる判断基準です。SESはゴールではなく次に行くための踏み台です。であれば、いつその踏み台から降りるかを入場前に設定しておく必要があります。「この状態になったら離脱を検討する」という基準を感情ではなく条件として先に決めておくことで、限界まで消耗してから気づくという最悪のパターンを避けることができます。
現場に入ってから考えようとすると、追い詰められた状態で判断することになります。余裕があるうちに、自分なりの撤退ラインを決めておくことが、長く生き残るための基本的な構えです。
離脱を引き止める「損害賠償」は法的に成立しない
離脱時に最も困るのが、全ての責任を押しつけてくるエージェントの存在です。「損害を与えた」という言葉を持ち出して引き止めにかかるケースがあります。しかしSESは準委任契約です。
法律上、成果物に対して責任を負う請負契約とは異なり、準委任契約は時間と労務を提供することへの対価であるため、エンジニア個人に損害賠償責任は発生しません。仮に整理が曖昧なままエージェント側が顧客から契約を打ち切られるような事態になっても、それはエンジニア個人が負うべき責任ではありません。
⚠️ 知っておくべき重要な事実
SESは準委任契約です。法律上、エンジニア個人に損害賠償責任は発生しません。「損害を与えた」という言葉は、引き止めのための脅しとして使われているに過ぎません。
「損害を与えた」という言葉は法的な根拠ではなく、引き止めのための脅しとして使われています。この点については、別の記事で詳しく扱います。
エージェントへの確認の切り出し方
確認したい項目が明確になっても、それをエージェントにどう聞くかが次の問題です。「不信感があると思われたくない」「案件を流されたくない」という心理が働くと、確認が甘くなります。
不信感ではなく「業務遂行の前提確認」として聞く
エージェントへの確認は、疑っているからではなく「確実に価値を出すための情報収集」という立場で行います。「現場に入ってから確認できなかった」では双方にとって損失なので、事前に固めたいという姿勢で伝えます。
たとえば「商流と指揮命令系統を入場前に確認しておきたいのですが」と聞くことは、不信感の表明ではなく、プロとしての準備姿勢です。これに対してエージェントが「そういう細かいことは入ってから」という反応を示した場合、それ自体が案件の危険信号として機能します。
確認できない情報の扱い
確認を求めても「先方に聞いてみます」「詳細は入場後に」という返答しか得られない項目は、現場側が把握していないか、意図的に曖昧にしている可能性があります。
実際に「商流は何層か」という質問をエージェントに投げると、どうなるか。この質問をした全てのエージェントから、その後連絡が来なくなりました。これは偶然ではありません。答えられない、あるいは答えたくない質問だったということです。裏を返せば、この一問だけで相手の質と案件の実態をある程度見極めることができます。
全ての情報を事前に得ることはできません。しかし「確認できなかった」のと「確認を試みたが返答がなかった」は、参画判断として意味が異なります。返答が来なくなった時点で、それは答えとして受け取ってください。無視されたのではなく、相手が自分で答えを出したということです。
まとめ
エージェントが渡してくる案件情報は、すでに営業都合で加工されたものである可能性があります。経歴書の内容・案件票に書かれない現場の実態、どちらも「渡された情報をそのまま信じる」では不十分です。
参画前に確認すべき5項目は、商流と指揮命令、責任範囲の境界、体制とサポートの有無、仕様の確定度、契約役割と実務のズレです。これらは入場後に取り戻すことが最も難しい情報です。
エージェントへの確認は不信感ではなく、プロとしての準備姿勢として行うことができます。確認できなかった項目は、リスクとして参画判断に織り込むことが必要です。
最後に、ひとつ動きを紹介しておきます。最近「新SES」と呼ばれる取り組みが生まれています。従来のSESはエージェントがエンジニアをどう使うかという構図でしたが、新SESではエンジニアがエージェントにどこまでの取り分を許可するかという構図に変わりつつあるようです。エンジニア側に主導権が移る動きとも言えます。
この内容については詳細を調査した上で、改めて記事にします。
当ブログでは、必要な場面に向けたお手伝いも始めています。
論点整理、仕様整理、責任分界の切り分けなど、実務で前に進めなくなった場面を対象にしています。
まずは、対応できる内容を下記ページにまとめています。
依頼・問い合わせは、下記のページからお願いします。
