日本のSIer構造とは？多重下請けSESと人月商慣行はなぜ非効率なのか

この記事が扱う「構造」とは何か

最初に立場をはっきりさせておきます。この記事は、特定の企業や個人の不正・怠慢を告発するものではありません。 扱うのは構造的非効率、つまり「関係者それぞれが自分の立場で合理的に振る舞った結果、 システム全体としては非効率な均衡に落ち着いてしまう」タイプの問題です。 日本のシステムインテグレーション(SI)産業について語られる不満の多くは、誰かの悪意ではなく、 契約類型・課金単位・調達手続き・産業の歴史という4つの層が互いを補強し合って できあがった構造から出てきます。逆に言えば、個々のプレイヤーの努力だけでは動かしにくい、 ということでもあります。

以下では、(1)基幹系を担う大手ベンダーの市場構造、(2)多重下請け構造、(3)人月商慣行、 (4)請負契約と準委任契約という法的な枠組み、(5)1980年代に定着したウォーターフォール文化、 の順に見ていきます。最後に、この5つがどう噛み合っているのかを整理します。

基幹系を支える大手ベンダーの寡占と、その歴史的な成り立ち

企業や官公庁の基幹系システム(会計・人事・生産管理・勘定系・住民記録など、 止まると業務そのものが止まる種類のシステム)の大規模構築案件は、日本では歴史的に少数の 大手ベンダー——NTTデータ・日本IBM・NEC・日立製作所・富士通——を中心に受注されてきました。 これは業界内では特に論争的でもない、広く知られた市場構造の記述です。実際、IDC Japanや Gartnerによる国内ITサービス市場のベンダー別売上ランキングでは、長年これらの企業が上位を 占め続けています(IT Leadersによる2024年IDC調査の報道では、 国内ITサービス市場規模は7兆205億円、上位に富士通・日立・NEC・NTTデータ・日本IBMが並ぶ、 と報じられています)。

なぜこうなったのか。歴史的な経路依存があります。1960〜70年代、日本の大型コンピュータ市場は 国産メーカー(富士通・日立・NEC・東芝・三菱電機・沖電気)と日本IBMを中心に形成され、 ハードウェアを売る会社が、そのハードウェア上で動くソフトウェアも面倒を見る という商売の形が自然にできあがりました。メインフレームは高価で、OSもミドルウェアも ベンダー固有で、業務アプリケーションはそのベンダーの技術者でなければ書けない。 ハードウェアの販売競争が、そのままシステム構築の受注競争になったわけです。

1980年代以降、各メーカーは肥大化したソフトウェア部門を子会社として切り出していきます。 これがいわゆるメーカー系SIerです。同時に、ユーザー企業側も情報システム部門を 子会社化する動き(ユーザー系SIer)が広がりました。結果として、それぞれの大手ベンダーを 頂点とする協力会社の系列——業界用語で言う「NEC系」「日立系」「富士通系」 といったグループ——が形成されます。これらの系列は、単なる取引関係ではなく、使用する開発標準、 ドキュメントの様式、見積りの単価表、品質管理の手続き、さらには技術者の教育カリキュラムまで ベンダーごとに異なる、独自の商慣行の集合として育ちました。ある系列で10年働いた技術者の スキルセットが、別の系列にそのまま持ち込めるとは限らない——このロックインが、 寡占構造を人材の流動性の面からも補強しています。

多重下請け構造:元請け・二次請け・三次請けとマージンの階段

多重下請け構造は、この系列のうえに乗っている実装の仕組みです。 発注者(エンドユーザー)から案件を受注した元請けが、開発業務の全部または一部を 一次請けに再委託し、一次請けはさらに一部を二次請けへ、 二次請けは三次請けへ、と再委託の連鎖が下へ伸びていきます。 しばしば建設業の重層下請け構造との類似が指摘されますが、建設業と違い、SI業界では 各階層が持ち込むのが資材や重機ではなく技術者の稼働時間そのものである点が 決定的に違います。

この連鎖は、しばしば想像よりも深くなります。公正取引委員会が2022年6月に公表した 「ソフトウェア業の下請取引等に関する実態調査報告書」は、 資本金3億円以下のソフトウェア業約2万1000社を対象にしたアンケートと関係者ヒアリングをもとに、 再委託の繰り返しで商流が多層化・複雑化し、極端に長い商流が形成される場合があることを指摘しています。 報告書に寄せられた回答には「6次下請の末端技術者として参加したことがある」「最大で4次請け案件の 経験がある」といった記述が含まれ、また実質的な業務をせずに商流に入って利ざやだけを取る、 いわゆる中抜き事業者の存在を認識している下請け事業者が相当数にのぼることも 報告されています。同報告書はこの構造を、買いたたきや仕様変更への無償対応要求といった 下請法上の問題行為が発生しやすい土壌として位置づけています。

構造の輪郭を押さえたうえで、ではなぜこれがソフトウェア開発と相性が悪いのかを 具体的に見ていきます。

• 各階層でマージンが抜かれる:発注者が支払う単価と、最下層の技術者に届く単価の間に階段ができます。中間層が実質的な付加価値(設計・品質保証・プロジェクト管理)を提供していれば正当な対価ですが、案件を右から左に流すだけの階層が混ざると、差額はそのまま非効率になります。
• 情報が伝言ゲームで劣化する:ソフトウェア開発で最も高価な資産は、発注者が「本当は何をしたいのか」という文脈です。これは仕様書に完全には書けません。階層を1つ下るごとに、書かれなかった前提・却下された代替案・後回しにした懸念が落ちていきます。最下層の技術者が、自分の書いているコードのエンドユーザーが誰なのかすら知らされない、という事態は珍しくありません。
• 責任が拡散する:障害や遅延が起きたとき、要件定義の曖昧さ・設計の不備・実装の質のどこに原因があるのかを、契約の階層をまたいで切り分けるのは極めて困難です。結果として、誰も全体に責任を負っていないのに、全員が部分的に責任を負っている状態が生まれます。
• インセンティブが逆を向く:これが最も本質的です。工数(人月)で課金される階層にとって、経済的に合理的な行動は「少ない人数で早く終わらせること」ではなく「妥当な範囲でより多くの技術者を、より長く稼働させること」です。優秀なエンジニアが自動化やリファクタリングで工数を半分にしたとして、それは請求額を半分にする行為であって、その階層の売上には貢献しません。個々の技術者の職業倫理がこれに抗っているのが実情で、つまり構造と現場の良心が逆向きに引っ張り合っている状態です。
• 技術者が育つ経路が歪む:下層に行くほど上流工程(要件定義・アーキテクチャ設計)から遠ざかり、「言われた仕様のとおりに書く」経験だけが蓄積されます。設計判断の訓練を受ける機会が構造的に上層に偏ります。

なぜユーザー企業は内製しないのか

ここで当然の疑問が出ます。そんなに非効率なら、発注側の企業が自社でエンジニアを雇って 内製すればいいのではないか、と。この問いが、構造のもう一方の端です。

日本では、IT技術者の大半がユーザー企業ではなくITベンダー側に所属しているという 人材配置の偏りが、長年にわたり繰り返し指摘されてきました。IPA(情報処理推進機構)が公表してきた IT人材白書やDX白書の日米比較調査では、日本はIT人材の多数がベンダー企業に所属するのに対し、 米国は逆にユーザー企業側に多く所属する、という対照的な分布が一貫して示されています (最新の調査結果はIPAのデジタル人材の動向調査で 確認できます)。数字の細かい値は調査年や定義によって変動するため、ここでは比率そのものより 方向性が日米で逆であるという点を押さえてください。

この偏りは、多重下請け構造の原因であると同時に結果でもあります。ユーザー企業に技術者がいないから ベンダーに丸ごと任せる。丸ごと任せるので、社内に知見が蓄積せず、次の案件でも任せざるを得ない。 ベンダー側は大量の技術者を抱える必要があるが、案件の量は景気や年度予算で大きく上下するので、 自社の正社員だけで需要のピークを吸収するのはリスクが高い。そこで変動分を協力会社に流す—— つまり多重下請け構造は、需要変動に対するバッファ(雇用調整弁)としても機能している わけです。経済産業省が2018年の DXレポートで 「2025年の崖」として警告したレガシーシステム問題——老朽化した基幹系の刷新が進まず、 中身を理解している技術者が引退していくという問題——も、この「自社システムの中身が 自社に分からない」という構図と地続きです。

人月という単位が、見積りと予算を規定する

人月(man-month)は、技術者1人が1か月稼働する量を1単位とする作業量の単位です。 日本のSI案件では、見積りも、契約も、進捗報告も、請求も、この単位を基礎に組み立てられるのが一般的です。 「この案件は120人月」「単価は1人月あたり◯◯万円」という会話は、業界のほぼ全域で通じます。

人月が定着した理由は理解できます。ソフトウェアには物理的な出来高がありません。何メートル掘ったか、 何トン納入したかに相当する、外形的で検証しやすい単位が存在しないのです。 一方で、予算を承認する側——企業の稟議、自治体の議会、官庁の会計——は、 なぜその金額なのかを事前に説明できる根拠を必要とします。人月は、 「何人が何か月働くか」という、非技術者にも検証可能な形でその根拠を与えてくれます。 調達手続きと親和性が高いのです。

しかし、課金単位は必ずインセンティブを作ります。人月で課金する以上、 ベンダーの売上は「投入した人数×期間」に比例し、「生み出した価値」には比例しません。 この単純な事実から、いくつもの帰結が出ます。

• 生産性向上が売上減になる:同じ機能を、10人で6か月かけても、3人で3か月で作っても、発注者にとっての価値は同じ(むしろ後者のほうが高い)ですが、ベンダーの売上は前者が約6.7倍です。効率化の成果がベンダーに還元される経路が、契約上存在しません。
• 見積りが「規模」の推定になる:本来なら「この課題を解決するのにいくらかかるか」を見積もるべきところ、実務上は「この仕様を実装するのに何人月かかるか」を見積もることになります。課題の定義そのものが妥当かどうかは、見積りの対象外に置かれがちです。
• 予算が年度と人数に縛られる:公的調達や大企業の予算編成は年度単位です。人月見積りはこの年度予算に載せやすい反面、「作ってみて分かったので方針を変える」という反復開発とは相性が悪い。予算の組み替えが、技術判断ではなく会計手続きの問題になってしまいます。
• 優秀な技術者の価値が単価表に潰される:人月単価は、多くの場合スキルランク(SE・PG等の区分)で決まります。生産性が同僚の5倍あるエンジニアがいても、単価表が5倍を許容しないなら、その差は価格に反映されません。

契約類型の話:請負契約と準委任契約

ここが、この記事でいちばん正確さが要求される部分です。日本の民法は、 システム開発でよく使われる契約類型として請負契約と準委任契約を 用意しており、この2つは責任の構造が根本的に異なります。

請負契約(民法632条)は、「仕事の完成」を目的とする契約です。請負人は約束した 成果物を完成させる義務を負い、報酬は原則として仕事の完成に対して支払われます(633条)。 引き渡された成果物が契約の内容に適合しない場合、請負人は契約不適合責任を負い、 注文者は追完(修補)請求・報酬減額請求・損害賠償請求・契約解除を求めることができます (2020年4月施行の改正民法により、従来「瑕疵担保責任」と呼ばれていた枠組みが、 売買の規定を準用する契約不適合責任として再構成されました)。 ソフトウェアで言えば、「動くものを納める」ことそのものが債務になります。

準委任契約(民法656条)は、法律行為でない事務の処理を委託する契約で、 委任の規定が準用されます。受任者は善管注意義務(644条)——専門家として 通常期待される注意を尽くして事務を処理する義務——を負いますが、 成果物を完成させる義務は負いません。報酬は原則として履行の割合に応じて 支払われ(648条2項。いわゆる履行割合型)、2020年改正では成果に報酬を紐づける 成果完成型(648条の2)も明文化されました。ただし成果完成型であっても、 完成義務を負わない点は履行割合型と同じで、そこが請負との分水嶺です。

実務上の使い分けはこうなります。IPAが公表している 「情報システム・モデル取引・契約書」第二版が 推奨するように、大規模開発では工程ごとに契約を分ける多段階契約が標準的な考え方です。 要件がまだ固まっていない企画・要件定義工程は準委任、仕様が固まった内部設計〜製造工程は請負、 運用・保守は準委任、といった分け方になります。ただしこれは発注者と元請けの間の話で、 その下の階層——二次請け・三次請け以降、そして個々の技術者を送り出すSES契約——は、 圧倒的に準委任が中心です。SES(システムエンジニアリングサービス)契約は、 準委任契約の一形態として、技術者の労働時間(工数)を提供する取引です。

なぜ準委任が選ばれるのか。理由は率直で、請負は完成リスクをベンダーに全部乗せるからです。 ソフトウェア開発は、着手前に正確な工数を見積もることが構造的に難しい営みです。 要件は動き、前提は崩れ、既存システムの実態は調べてみないと分からない。 にもかかわらず請負で受ければ、見積りを超えた分の損失はベンダーが飲むことになり、 さらに完成物が契約内容に適合しなければ契約不適合責任まで負います。 この不確実性を階層の下まで請負で流すのは現実的でないため、 下層は「工数を提供する」準委任にして、結果ではなく稼働で決済する—— これが最も自然な選択になります。そして工数で決済する以上、単位は人月になります。 契約類型の選択が、課金単位を決め、課金単位がインセンティブを決めるという 因果関係が、ここで閉じます。

誤解のないように補足すると、準委任だからベンダーが無責任でよい、という話ではありません。 日本の裁判例は、システム開発の頓挫をめぐる紛争において、ベンダー側の プロジェクトマネジメント義務(専門家として進捗・リスクを管理し、 問題をユーザーに適時に説明する信義則上の義務)と、ユーザー側の協力義務 (仕様を適時に決定し、必要な情報・資料を提供する義務)を、いずれも信義則上の義務として 認めてきました。完成義務がないことと、何の義務も負わないことは別です。 ただし、この義務は裁判で事後的に評価される規範であって、 契約時点でベンダーの報酬を成果に連動させる仕組みではありません。

1980年代の「ソフトウェア工場」とウォーターフォールの定着

最後のピースが開発方法論です。日本のSI産業がウォーターフォール型開発 (要件定義→基本設計→詳細設計→製造→テスト→移行、と工程を順に進め、 各工程の終わりにレビューで「凍結」して次へ渡す方式)を標準としてきたことは広く知られていますが、 これは単なる技術的選択ではなく、ここまで述べてきた契約構造と不可分です。

歴史的な文脈としてよく参照されるのが、MITのMichael A. Cusumanoが1991年に著した Japan's Software Factoriesです。 同書は、日立・東芝・NEC・富士通といった日本の大手メーカーが、1960年代後半から1980年代にかけて 製造業の工程管理・品質管理の手法をソフトウェア開発に持ち込み、 「ソフトウェア工場」として標準化された開発プロセス・再利用・ 工程別の分業体制を構築していった過程を詳細に記録しています。 当時の文脈では、これは先進的な取り組みでした。品質のばらつきを抑え、 大規模開発を予測可能にし、技術者の属人性を減らす——製造業で有効だった思想を、 当時の主戦場だったメインフレーム上の基幹系開発に適用したわけです。

国内での用語と工程の標準化も進みました。ISO/IEC 12207をベースに、発注者と受注者が 同じ物差しで会話できるようにするための共通フレーム(SLCP-JCF)が 1994年以降整備され、1998年版・2007年版などとして更新されてきました (経緯はIPAのSLCP解説ページにまとまっています)。 工程の名前と成果物の定義が業界共通になったことで、見積りの相互比較や、 工程単位での外注が容易になりました。

ここが重要な点です。ウォーターフォールは、多重下請けと人月課金を成立させる前提条件でした。 考えてみてください。仕様が凍結されていない工程を、契約でくくって外部に切り出すことはできません。 「三次請けに詳細設計とコーディングを出す」という分業が成り立つのは、 基本設計が終わって仕様が固定され、その工程の入力(設計書)と出力(モジュール)が 文書として定義されているからです。同様に、「何人月かかるか」を事前に見積もれるのも、 スコープが凍結されている前提があってのことです。反復的に要件を見直すアジャイル型の進め方は、 技術的に優れているかどうか以前に、スコープ凍結を前提にした階層的外注と人月見積りの 枠組みに、そのままでは載らないのです。

だからこの方法論は、他国でアジャイル/反復型が主流化した後も、日本のSI産業では粘り強く残りました。 残っている理由は「日本の技術者が新しい方法論を知らないから」ではありません (知識としては完全に普及しています)。 調達手続き・契約類型・下請け構造・予算制度という周辺の制度が、 すべてウォーターフォールを前提に最適化されているからです。 方法論だけを差し替えても、予算の取り方と契約の切り方が変わらなければ、 「ウォーターフォールの工程をスプリントと呼び替えただけ」の運用に着地しがちです。

4つの層はどう噛み合っているのか

まとめると、因果はおおむね次のように循環します。

• 市場構造:ハードウェア商売から出発した少数の大手ベンダーが基幹系を握り、各社が独自の商慣行を持つ協力会社系列を形成した。
• 人材配置:ユーザー企業側に技術者が薄いため、要件定義から運用まで外部依存になり、ベンダーは需要変動を系列に流して吸収する必要が生じた。
• 契約類型:ソフトウェアの見積り困難性から、完成義務を負う請負を階層の下まで流せず、下層は準委任(SES)になった。
• 課金単位:準委任で決済する以上、単位は成果ではなく工数=人月になり、ベンダーの売上は投入人数×期間に比例するようになった。
• 開発方法論:人月見積りと工程別外注が成立するには、スコープの事前凍結が必要であり、ウォーターフォールがその前提を供給した。
• そして循環する:ウォーターフォールで工程を切るから外注しやすく、外注しやすいから内製が育たず、内製が育たないから外部依存が続く。

この循環のどこか1点だけを改革しても効きにくい、というのがこの構造のいちばん厄介なところです。 アジャイルを導入しても契約が準委任の工数課金なら、インセンティブは変わりません。 成果連動の契約を設計しても、発注側に成果を定義できる技術者がいなければ運用できません。 内製化を掲げても、業界全体の人材がベンダー側に偏っている限り、採用の競争になります。 実際に構造が動くとすれば、発注者側の技術力回復・契約類型の設計・課金単位の見直しが 同時に進む場合だろう、というのが本記事の見立てです。

まとめ

• 日本の基幹系システム構築は、歴史的にNTTデータ・日本IBM・NEC・日立・富士通を中心とする少数の大手ベンダーが担い、各社が独自の商慣行を持つ協力会社系列を形成してきた
• 元請け→一次請け→二次請け→三次請けと再委託が連鎖する多重下請け構造では、各階層でマージンが発生し、情報が劣化し、責任が拡散する
• 公正取引委員会の2022年の実態調査は、極端に長い商流の形成や中抜き事業者の存在を指摘している
• 日本ではIT技術者がユーザー企業よりベンダー側に偏って所属しており、これが外部依存の原因であり結果でもある
• 人月課金は、ベンダーの売上を「投入人数×期間」に比例させるため、生産性向上が売上減になるという逆向きのインセンティブを生む
• 請負契約(民法632条)は仕事の完成を目的とし契約不適合責任を伴うが、準委任契約(民法656条)は善管注意義務を負うのみで完成義務はない。SES契約は準委任の一形態である
• 見積り困難性ゆえに下層契約が準委任に寄り、準委任ゆえに課金単位が人月になり、人月見積りが成立するためにスコープ凍結型のウォーターフォールが要請される、という相互補強が起きている
• ただしこの構造は需要変動の吸収や品質下限の担保という機能も果たしてきており、大手各社も内製化支援やアジャイル組織への投資を進めている。問題は悪意ではなく制度の噛み合わせにある