この人って、どこの会社から来たんだろう…。契約書には一次請けの名前しかないし、実際の雇用先が全然見えない。
IT業界30余年、フリーランスのシルバーエンジニア。おにぎりです。
SESの現場で「この人、どこの会社からきたの？」と思ったことはありませんか？発注側の担当者でさえ、実際の雇用元を把握していないケースは珍しくありません。これが「SES多重下請け構造」の実態です。
この記事では、SES多重下請けの仕組みと問題点、そして現場リーダーが知っておくべき対処法を、30年の現場経験をもとに解説します。
結論：「見えない構造」を可視化することがリーダーの第一歩
SES多重下請けは業界に根付いた構造的問題であり、個人では変えられません。しかし「誰が、どこから、どういう経路で来ているか」を把握し、現場の透明性を高めることは、リーダーにできる最も有効な対策です。
SES多重下請けとは？その実態
SESの現場では、複数の会社が重なった「多重下請け構造」がよく見られるよ。仕組みを知っておくことが大切。
SES（System Engineering Service）とは、エンジニアを客先に常駐させる形の契約です。SESの現場では、案件を受注した元請け企業がさらに別の企業に発注し、その先にまた別の企業が…という「多重下請け構造」が起きやすい特性があります。
構造の例：
発注元（エンドユーザー）→ 一次請け → 二次請け → 三次請け → エンジニア
4〜5階層になることも珍しくなく、エンジニアが実際に働く現場と、雇用契約を結んでいる会社が全く別というケースも生まれます。
私自身、フリーランスとして働く際には「知人の会社の契約社員」という形で参画することが多く、エンドユーザーから見ると何次請けなのか分からない存在になることも。これが多重下請け構造の現実です。
なぜ多重下請けが生まれるのか？3つの理由
階層が増えるほど問題が起きそうなのに、なんでこんな構造が続くんですか？
理由1：元請け企業がリソースを埋めきれない
突発的なプロジェクト増加や特殊なスキルが必要な場合、元請け企業だけではエンジニアを確保できません。そのため協力会社に声をかけ、その会社もさらに別の会社に声をかける——という連鎖が起きます。
理由2：各階層で利益を確保する仕組みがある
各社がマージンを取りながらエンジニアを斡旋するビジネスモデルが成立しているため、階層が増えてもそれぞれの会社にインセンティブがあります。結果として「問題がなければ続く」構造が維持されてしまいます。
理由3：契約上の可視性が低い
元請けとの契約書には「一次請け会社との取引」しか記載されないため、その先の構造が発注元に見えにくくなっています。法的に問題がなければ通ってしまうのが実態です。
現場に起きる3つのリスク
構造が見えないことで、現場では具体的にこういうトラブルが起きるよ。
リスク1：情報伝達が遅れる・歪む
階層が多いほど、情報は伝言ゲームになります。要件変更・障害報告・スケジュール調整など、現場にとって重要な情報が届くのが遅くなったり、内容が変わって届いたりします。
- 一次請けへ連絡 → 二次請けへ転送 → エンジニアに届く……という経路を経るたびに時間がかかる
- 「聞いていない」「そんな話は来ていない」というすれ違いが頻発する
リスク2：責任の所在が不明確になる
問題が発生したとき、「誰が責任を持つのか」が曖昧になります。
- バグが発生しても「うちは報告しただけ」「うちは発注しただけ」という状態になりやすい
- クレームが来ても、エンジニアまで正確に届かないことがある
- トラブル対応の窓口が誰なのか、現場では判断できないことも
リスク3：スキル・品質の不透明化
採用・面談のプロセスも多重化されるため、現場に来る人のスキルや信頼性が見えにくくなります。
- 「面談では印象が良かったが、実際のスキルが不足していた」
- 「誰がどういう基準で選んだのかわからない」
- 素性が不明確なメンバーが現場に入るリスクも、ゼロではない
リーダーとして取るべき対策（3ステップ）
構造そのものを変えることは難しくても、リーダーとしてできることは確実にあるよ。
ステップ1：現場の人員構造を把握する
まず「誰が、どこの会社から、どういう経路で来ているか」を整理します。
- プロジェクト参加時に、所属会社と担当業務を一覧化する
- 面談の段階で「どの会社の紹介か」を確認する
- メンバー表に会社名と役割を明記する習慣をつける
ステップ2：情報伝達の経路を短縮・明確化する
階層が多くても、現場での情報共有ルールを整備することで伝達ロスを減らせます。
- 日報・チャット・課題管理ツールを全メンバーが使える状態にする
- 「報告は誰に・どのチャンネルで」を最初に決めておく
- 変更・障害発生時は即時報告ルールを設ける
ステップ3：契約・発注段階で条件を設ける（可能なら）
発注者側や一次請けの立場があるなら、契約段階で制限を設けることも有効です。
- 「二次下請け以降への発注は事前承認制」とする
- ベンダーにメンバー情報（所属会社・スキル）の事前開示を求める
- 契約書にSLA（サービスレベル合意）を明記する
おにぎりの実体験
あるプロジェクトで、突然「新しいメンバーが来週から入ります」という連絡がありました。面談なし、スキルシートなし。一次請けが二次請けに頼み、その会社がさらに別の人に声をかけた結果でした。
現場に入ってみると、コミュニケーションが取りにくく、スキルのミスマッチも明らかでした。しかし、誰に「戻してほしい」と言えばいいのかもわからない状態。一次請けに連絡しても「うちでは対応できない」という返答でした。
そのとき私が学んだのは「構造が見えないと、問題が起きてから対応できない」ということです。以来、プロジェクト参加の初日に必ず人員の経路を確認するようにしています。
まとめ：「見えない」を「見える」に変えるのがリーダーの仕事
明日からできるアクション
- 現在のプロジェクトのメンバー一覧に「所属会社名」を追記する
- 情報共有の報告ルートを明文化してチームに周知する
- 新メンバー参入時は「どこ経由か」を必ず確認する習慣をつける
多重下請けって、こんなに身近なリスクだったんですね。まず自分のチームの構造を把握してみます！
この投稿が悩んでいる人へのヒントになればうれしいです。もし、ご意見や扱ってほしいテーマなどがあれば、気軽にコメントしてください！
コメント