日本の SIer 業界における多重下請け構造は、30 年にわたり大きく変わらないまま維持されてきました。業界の内側にいる人には当たり前の風景ですが、海外の IT 産業と比較すると極めて特殊な形をしています。
なぜ 30 年も同じ形が続いたのか。制度を変えれば動くのか、それとも制度だけでは説明できないのか。そして、生成 AI の登場はこの風景を変えるのか。
本稿では、SIer の多重下請け構造がなぜ30年変わらなかったのか、海外と比較して何が違うのか、そして AI の登場で何が動き始めているのかを、複数の観点から解きほぐしていきます。
1. 30年、構造が変わらなかった理由は、ひとつではない
日本の SIer にひろがる多重下請け構造は、IT 産業の歴史、雇用慣行、法制度、商慣習が絡み合って成立しています。単一の原因ではないため、どこか一箇所を変えても構造全体が動かない、という性質を持っています。ここでは4つの観点から順に解きほぐしていきます。
歴史的背景：60年代から大型案件を重ねるなかで固まってきた多層構造
日本で情報システムの需要が本格的に立ち上がったのは 1960 年代前半です。1965 年に三井銀行が都市銀行として初めて普通預金業務のオンラインシステムを稼働させたのを皮切りに、都市銀行各行は 1970 年代にかけて第二次・第三次オンラインを順次導入しました。同時期に国鉄の座席予約システム（MARS）、各官庁の統計処理や税務システムが整備され、日本における大型業務システムの「作り方」の原型が形作られます。
供給側では、IBM 日本法人に加え、国産メーカーの NEC・富士通・日立・三菱電機・沖電気などが大型汎用機ビジネスに参入し、通産省主導の「汎用機国産化」政策を背景にメーカー各社が系列化されていきました。ユーザー企業は IBM 系を採るか、国産 3 社（F・N・H）を採るかで系列が決まり、そのメーカーの情報子会社が基幹システム開発を担う、という構図が出来上がります。
業務に合わせてシステムを作るという思想は、この時期に業界文化として定着しました。パッケージソフトを導入して業務を合わせるのではなく、自社固有の業務に合わせて一から開発する。業務仕様書は数千ページに及び、開発はウォーターフォール型で数年にわたる、という大規模・長期・固有仕様の組み合わせが、以降 40 年近く基本形として残り続けます。
1980-90 年代には、銀行第三次オンライン、自治体の住民情報システム、電電公社から民営化された NTT の基幹システム、大手製造業の生産管理システムなど、数百人月〜数千人月規模の大型案件が次々と立ち上がりました。この時期に大手 SIer の人月商売モデル——エンジニアを数千〜数万人単位で抱え、案件の規模に応じて投入する工数として売る仕組み——が完成します。需要変動をバッファするために、協力会社（中堅 SIer）への外注、さらにその下の SES 系企業からの人員補填が常用され、発注元 → 大手 SIer → 中堅 SIer → SES 系協力会社の多層階段が形づくられました。
1990 年代後半になると、クライアント／サーバー型やオープン系への移行が進み、UNIX・Oracle・SAP といったベンダー製品を組み合わせる案件が増えます。ところが多層構造は解体されるどころか、「オープン系スキルを持つ特定人員」を各層から動員する形でさらに深化しました。人月商売は汎用機時代より細分化され、スキル単価 × 人月の掛け算で見積もる文化が定着します。
2000 年前後の Y2K 特需では、短期間で大量の工数を確保するため多層下請けへの依存が露骨な形で表面化しました。その後の住基ネット稼働（2002 年）、e-Tax 開始（2004 年）、マイナンバー制度関連システム構築（2015 年〜）など、公共系の大型案件が繰り返し発注されるたびに、同じ構造が再利用されていきます。
民間でも、みずほ銀行の新勘定系システム MINORI 刷新プロジェクト（2011 年のシステム障害を契機に 2013 年から本格始動し、2019 年に完全移行完了。延べ 35 万人月・投資額 4000 億円超と報じられた史上最大級のプロジェクト）、メガバンクや損保各社の基幹更改、航空・通信インフラの基幹系移行など、数千億円規模の案件で大手 SIer を頂点とする多層体制が常態化しました。
2010 年代後半からクラウド移行（AWS、Azure）が進み、一部のエンドユーザー企業では内製化の動きも出始めています。メルカリ、DeNA、リクルート、SaaS スタートアップ各社のようにエンジニアを自社で抱えて技術で差別化する企業が目立つようになりました。しかし、全国の大手企業の基幹系・業務系の多くは、今も SIer 経由で開発・運用されており、多層構造の骨格は温存されたままです。
「大規模・長期・一社では賄えない人数を短期間に集める」という需要は、60 年代の銀行オンラインから現代のクラウド移行に至るまで繰り返し発生してきました。そのたびに、多重下請け構造はメンテナンスされ、再生産されていきます。
雇用慣行：「どの会社に属するか」が先に立つ日本の働き方
終身雇用と内部育成を前提にした日本型雇用モデル、いわゆるメンバーシップ雇用は、IT 現場にも当然のように持ち込まれました。新卒を未経験で採用し、自社の技術スタンダードやプロジェクト運営手法を社内で習得させ、長期的に戦力化する。専門スキルよりも会社への適応と忠誠度が評価軸になる傾向が強くあります。
この仕組みは、欧米のジョブ型雇用と対をなします。欧米では職務記述書（ジョブディスクリプション）で役割とスキル要件が明示され、個人はその職務に必要な専門性を外部市場で磨き、企業をまたいでプロジェクトに参加します。結果として、IT エンジニアは平均 2〜3 年で転職するのが通常で、個人の市場価値が可視化されやすい構造です。
日本では「〇〇システム社のエンジニア」という所属ベースのアイデンティティが強く、企業をまたいだ流動性が低い。中堅エンジニアが持つスキルは社内の暗黙知と紐づいていて、転職市場で評価されにくい。結果として、上流は上流の会社に、下流は下流の会社に、という層の固定化が進みました。人が動きにくいから、発注と受注の関係も固定される。会社同士の序列が、人の序列として静かに継承されていく構造です。
法制度：請負と派遣の境界線と、SES 契約の普及
SIer 業界の雇用関係には、法的に複雑な論点があります。労働力の提供に報酬が発生する労働者派遣契約と、成果物に報酬が発生する請負契約は、本来まったく別物です。
- 請負契約：受注側が成果物に責任を負う。労働者への指揮命令権は受注側（請負元）が持つ
- 派遣契約：労働者の労働力を貸す。指揮命令権は派遣先（客先）が持つ
ところが実態としては、請負契約を結びながら客先の指示で作業するという運用が長年続いてきました。これが厚生労働省も繰り返し注意喚起している偽装請負です。労働者派遣法（1986年制定、2015年に大幅改正）は偽装請負を規制していますが、実際の業務現場では、指揮命令の実態と契約形式が乖離したままのケースがいまだに散見されます。
加えて、近年の業界では準委任契約の一種である SES（システムエンジニアリングサービス）契約が多用されるようになりました。成果物ではなく「一定の技術サービスを一定期間提供する」という形で契約するため、派遣と請負の厳密な区別を回避しやすい。SES 契約は法的には合法ですが、実務上はエンジニアが客先常駐して客先指示で作業する「派遣に近い運用」になりやすく、ここが多重下請け構造の温床であり続けています。
海外との比較：日本の構造は世界標準ではない
こうして見てくると、日本の多重下請け構造は世界標準ではないことがわかります。
米国では、大手 IT ユーザー企業が社内にエンジニア組織を抱え、内製化を進める流れが主流です。Netflix、Uber、Airbnb、Stripe のような企業は基幹システムを外注ではなく自社で開発する。ベンダーは特定の技術領域（クラウド、データ基盤、セキュリティ）で深い専門性を持つ企業との契約が中心で、多層構造は日本ほど発達していません。
欧州（英国・ドイツなど）では、フリーランスや専門コンサルタント会社がプロジェクト単位で入る仕組みが定着しており、大手 SIer を頂点とする多層構造はあまり見られません。契約はジョブ型・短期型で、個人の専門性と成果が前面に出ます。
インドは世界のオフショア開発拠点として大手 IT 企業（Infosys、TCS、Wipro）を擁しますが、内部の階層は日本ほど深くなく、むしろ大規模オフショアという形で価格競争力を保っています。
日本が特殊なのは、雇用と契約と歴史の産物として、多層の階段が国内で自己完結しているという点です。欧米のジョブ型流動性とも、インドのオフショア競争力とも違う、第三の形として 30 年間再生産されてきました。制度だけで説明できない、歴史・商慣習・人の動きが重なった固有の形です。
2. 多層構造が生んだ、品質とキャリアのしわ寄せ
この構造は、システム開発の品質・コスト・そしてエンジニア個人のキャリアに、具体的なしわ寄せを生みます。
情報が層を介して伝わる過程で、要件の齟齬や誤解が発生しやすくなります。上位層の意図が下位層に届くまでに言葉が丸まり、逆に下位層からの技術的な警告が上位層に届かない。伝言ゲームの副作用は、手戻りとコスト増の常連原因です。
コスト面では、各層で中間マージンが抜かれるため、末端に行くほど開発に投入できる予算が減ります。品質を担保するための余力が削られ、納期が近づくと人海戦術で押し込む、という展開が繰り返されてきました。
エンジニア個人のキャリアにも影響が出ます。
- 担当業務が細分化され、幅広いスキルや全体像を掴む機会が限られる
- 上位工程や要件定義に関わる機会が少なく、技術力や市場価値が伸びにくい
- 貢献と報酬の関係が見えにくく、所属する会社の位置で天井が決まる
若手から中堅へ移る時期に「自分の仕事が何につながっているのか分からない」という感覚が生まれるのは、個人の問題ではなく、層に埋め込まれた情報の非対称が引き起こしている現象ではないでしょうか。
3. AI が迫っているのは、中間層の縮退である
生成 AI の進化は、この多層構造に外部から圧力を加えつつあります。これは業務効率化の話にとどまらず、層そのものの輪郭を動かす変化です。
これまで中間層が担ってきた仕事の一部——仕様書の整形、既存コードの改修、テストケースの作成、ドキュメントの生成——は、AI による自動化の射程に入りました。上から下に仕様を渡し、下から上に成果物を返す、という伝達工程の付加価値が相対的に下がっていきます。
この変化の帰結として見えてくるのが、業界全体の二極化です。
一方には、ビジネス課題を言語化し、要件を引き出し、全体を設計する「賢い発注者」のポジション。もう一方には、高度な技術力で実装と検証を担う「高度な実行者」のポジション。両端の役割は AI による代替が難しく、むしろ AI を使いこなすことで価値を伸ばす領域です。
中間で「仕様を右から左に流すだけ」の工程は、AI と再編成の両方から圧力を受けます。これは脅威というより、長年動かなかった構造が、ようやく動き得る局面に入ったと捉えるほうが実態に近いのではないでしょうか。
4. 「賢い発注者」と「高度な実行者」という二極へ
では、層のなかにいる一人として、どこに舵を取るか。
「賢い発注者」側に寄るなら、ビジネス課題の理解、顧客との対話、創造的な提案、上流設計が主戦場になります。コードを書かない判断ができることも、この側の武器です。AI に要件を整理させながら、人間側が問いの立て方を握る構え。
「高度な実行者」側に寄るなら、特定領域の技術的な深さが頼りになります。AI と組み合わせて設計と実装を往復し、AI が扱いにくい境界領域を押さえる。単なる手数ではなく、判断を伴う実装力が市場価値を決めます。
両方を持つハイブリッド型もあり得ますが、どちらに軸足を置くかを意識的に決めることが、最初の一歩になります。
「自分の仕事が何につながっているのか分からない」という中堅エンジニアに共通する違和感は、AI の進展と構造の変容が重なる局面では、むしろ次の居場所を選ぶための手がかりになるのではないでしょうか。
まとめに代えて
日本の SIer 多重下請け構造は、歴史・雇用・法律・商慣習が重なって30年維持されてきた固有の形です。制度だけを責めても動かないし、個人の努力だけでも動かない。その両方が30年の停滞を支えてきました。
AI は、この停滞のなかで動き得る場所を増やしています。完全な解体が来るわけではなく、層の輪郭が少しずつずれ、いくつかのポジションの意味が変わっていく。その変化をどう読み、自分の立ち位置をどう選ぶかは、それぞれの手にあります。
構造は自分ひとりでは変えられません。けれど、構造の中で どの層にどう居るか は選べる。その選択肢が、いま少しだけ広がっているのではないでしょうか。
