IT業界の多重下請け構造はこうして生まれた！

例えば、Ａ社があるソフトウェア開発をＢ社に発注したとしますよね。このとき、Ｂ社がＡ社からの受託（工程）の一部をＣ社、またはＣ社を含めた複数の会社に発注します。さらにＣ社はから受託（工程）の一部をＤ社、またはＤ社を含めた複数の会社に発注します。さらにＤ社は（以下、繰り返し）……。このような事例は情報サービス産業ではよく見られますね。

この事例のようにある製品を発注者に納品するのに、多くの会社の受発注が介在し、多層化している構造を一般的に多重下請構造と呼んでいます。

多重下請構造は、情報サービス業以外では建設業にも見られ、もともとは建設業において落差の激しい繁忙・閑散期の対応として戦後以降に定着したものといわれています。

多重下請構造はピラミッドに例えることができます。先ほどの事例でいえば、Ａ社（ユーザー企業、発注会社と呼ばれます）から最初にソフトウェア開発を受託したＢ社（元請と呼ばれます）が情報サービス業におけるピラミッドの頂点です。

Ｂ社からＣ社（１次下請と呼ばれます）を含めた複数の会社へ、さらにＣ社からＤ社（２次下請と呼ばれます）を含めた複数の会社に仕事を発注していくにしたがい、介在する会社が増えていき、ピラミッド構造ができ上がります。

Ｂ社のようなにピラミッドの上部の会社はユーザー企業により近いことから、システムを構築する際に、ユーザー企業の業務を把握・分析し、ユーザー企業の課題を解決するようなシステムの企画、構築、運用サポートを中心に業務を行っています。そこからさらに工程を受託する会社はプログラム設計やプログラミングがより業務の中心となってきます。

また、ピラミッドの下方にいくしたがって、介在する会社規模は小さくなり、そこで働く労働者の賃金も低くなる傾向にあることが指摘されています。

１９９０年代以降のユーザー企業のIT投資の主たる目的は、現行業務の情報化による業務効率であり、フルオーダーメイドの受託開発がシステム開発の中心でした。これによりシステムのブラックボックス化とベンダロックイン^※1が発生し、人月^※2換算とソースコードの行数換算で取引価格が形成された結果、技術力が軽視され研究開発が停滞しました。このため、ベンダー企業では労働集約型ビジネスを支える目的で、２０００年までに現在見られるような多重下請構造が形成されたと言われています。

はじめにメリットです。多重下請構造は一つの「発注」を多くの会社でシェアをする仕組みともいえます。労働集約型ビジネスが主流を占める産業では、多くの労働者に仕事を供給する必要があり、多重下請構造がその役割を果たしています。

しかし、このメリットは別の見方をすればデメリットに直結する裏返しの課題でもあります。

会社が他社へ受託（工程）の一部発注する場合は、当然ですが、自社が請けた金額よりも安い金額で下請けに発注することになります。従って多重下請構造のもとで受発注を繰り返すごとに利益が削られることになり、結果として２次よりは３次、３次よりは４次というように高次の下請会社ほど労働者への賃金も低くなっていきます。

どの産業においても超少子高齢化の影響もあり、人手不足の状況になっていますが、とりわけ情報サービス業は人材不足が深刻な状況です。その要因の一つとして、賃金の低さや労働時間の長さが影響しているとの指摘もあります。

賃金の低さと多重下請構造には相関関係がありますので、多重下請構造をなくすことは低賃金を脱却する一つの手立てだと思いますが、実現には時間が必要ですし、現実的にはかなり難しいと思われます。

まずは多重下請構造に介在する会社の役割の明確化による構造の適正化と開発したソフトウェア（成果物）の価値に基づく取り引きを適正に行っていくことがとても重要です。