2015年 7月

IT業界(ここでは主にエンタープライズ系SIベンダーを指す)の構造を指して、良くも悪くも、多重下請構造と称されることが多い。
これは業界の構造が、元請企業であるSIベンダーを頂点として、その配下に1次下請け企業、2次下請け企業、・・・という具合にピラミッド構造をなしていることを指す。
この構造は元請企業に対して、SE・プログラマーなどの人的資源の調整弁としての機能を提供している。元請け企業にとって、受注案件が多い時には多くのSE・プログラマーが必要になるが、案件が少ない時には必要とする人的資源も減少する。
また、1つの案件をとってみても必要な人的資源の量は、システムライフサイクルの中で変動する。一般の開発案件では、人的資源である工数山積みは、製造・単体テストフェーズを頂点とした釣鐘形の形状になる。
元請け企業にとって、多重下請構造は人的資源のボリュームを計画的に(時には突発的に)、柔軟に、速やかに調整するのに適した構造だといえる。このような業界構造が形成されている背景には、正規社員/職員は簡単には解雇できないという労働法上の制約があることも確かである。

さて、この多重下請け構造はIT業界に限った話ではない。
製造業や建設業界でも同様の構造がみられる。例えば製造業の場合は、自動車会社などの親企業の配下に系列の部品メーカーがあり、さらにその下に下請け企業が存在し、それぞれの企業は親企業の生産体制の下に組み込まれている。
一般に、下請け企業の下部構造になるほど企業規模は小さくなり、企業数は増える(すなわち、中小企業や小規模企業が数多く存在する)。
2015年版中小企業白書では、近年の傾向として大企業と中小企業・小規模事業者との間の相互依存関係が「希薄化」しつつあると分析している。相互依存関係が希薄になる理由は幾つかあるが、主な理由は以下の3つである。

①グローバル化の進展
海外生産比率、海外売上高比率が年々増加していく中で、海外展開できない中小企業は大企業との取引が縮小し、相互依存関係が希薄化する。

②親企業による下請け企業の選別強化
親企業の、下請け企業に対するコストや技術への要求が高度になり、下請け企業の選別が進んでいる。

③脱下請け
下請け企業においても、脱下請けや、親企業の分散化など、親企業への依存度を低下させる動きがある。

相互依存関係が希薄化することで、下請分業構造は「ピラミッド型」から「ネットワーク型」へと変化してきている。ネットワーク型とは、下請け企業が複数の親企業と関係を築いたり、市場(顧客)と直接取引するなど、取引関係が網目状に変化していることを指している。中小企業白書では、「中小企業・小規模事業者は、自ら市場と向き合い、需要を獲得する必要に迫られている」と指摘している。

下請構造の変化次に親企業と下請け企業の間の力関係をみてみよう。
一般には発注元である親企業がパワー(下請け企業を選択するパワー)を持っているが、技術力のある下請け企業や独自能力を有する下請け企業の場合は、親企業に対して強いパワーを有する場合がある。

次に利益率については、(ある意味当たり前だが)高い技術力や優れた製品力、販売力を持った企業が高い利益率を確保している。また、同じ規模の企業同士の収益力の差は、年々拡大する傾向にあり、特に小規模企業の間でも差が開いている。

以上は主に製造業にみられる親企業と下請け企業の関係の変化であるが、これらの様相はIT業界にも共通するところが多い。
例えば系列。1次下請けあたりまでは系列化されているところが多いが、2次下請け以降は必ずしも系列に縛られない。ある案件でA社の下請け/孫請けとして開発作業をしていた企業が、次の案件ではB社の下請け/孫請けになっている、といったようなことはしばしば見受けられる。但し、このようなケースでは守秘義務の問題に注意する必要がある。

親企業と下請け企業の依存関係に着目したとき、IT業界でも今後ネットワーク型の関係が増えるであろうか?
また、下請け企業において、脱下請けの動きが出てくるだろうか?
「脱下請け」というキーワードはかなり昔からあったが、近年その可能性は高まってきたと言える。その主な要因が、AWS(Amazon Web Services)やGCP(Google Cloud Platform)などのクラウド基盤の発達である。クラウド基盤を使うことで、従来のオンプレミス型システムに比べ、インフラ基盤を構築することが格段に容易になった。
従って、SIベンダーの下請け/孫請けとして仕事をしていたソフトウェアベンダーでも、インフラからアプリまでトータルな対応が可能になった。反対に、ハードウェアからアプリまでトータルでインテグレーション出来るSIベンダーのパワーは相対的に弱まったと言える。
IT業界の多重下請け構造もネットワーク型へと変化する可能性はありそうだ。

PJ管理のINDEX

Update

2015年7月
« 6月   8月 »
 12345
6789101112
13141516171819
20212223242526
2728293031  

Navigation