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