見出し画像

退職エントリ(3/3):どうして人売りは発生するんだろう

「三十五歳定年説とともに、わが国ソフトウェア業界で問題とされているのが、要員派遣という労働形態である。この仕事をする技術者は、会社から指定された顧客企業に出掛けて行って、その企業に机を置いて働く。
 その場合、たいていが顧客企業の従業員と同じ制服を着たり名札も付ける、ときには、システム・エンジニアの場合など、相手先の企業の名刺を使わされる。また多くの場合派遣された技術者は、顧客企業の管理者に管理されている。
 このように表面的には、派遣技術者は出向先の企業の社員となんら変わりのない労働をするのだが、その内実は待遇面での格差など問題が多い」

 とある書籍の記述です。程度の差はあれど、ITエンジニアが聞いたら十中八九ウンウン首を動かす内容でしょう。いっぽうよく聞く話でとくに目新しさはないと思います。この一節が1983年に刊行された本の内容であることを除けば。


人売りとは終身雇用が産んだ鬼子

 前述の本によれば、昭和四十年代の初め、ソフトウェア業界の黎明期にはほとんどの企業が大手コンピューター・メーカーの下請け仕事か、さもなくばユーザー企業のシステム開発のお手伝いが実情だったそうです*1。

*1 下田博次『ソフト技術者の反乱―情報革命の戦士たち』日本経済新聞社(1983) p88~89

 当時は他に仕事がなく、そうする以外に手がなかったからだそうですが、その後のビジネス分野におけるコンピューターの普及にともない、1980年代には情報サービス・ソフトウェア市場が急成長し、大規模な設備投資やインフラ整備の必要性が低いことから、多くの中小情報サービス・ソフトウェア企業が設立されました。
 しかし、みずほ情報総研による調査*2によれば、「大口ユーザーの発注が、大手企業に偏重したこともあり、中堅・中小情報サービス・ソフトウェア企業は、大規模企業の下請、孫請け業務等小規模な業務が主体となり、図1-1 のような多重下請構造と呼ばれる情報サービス・ソフトウェア産業の特徴的な産業構造が形成された」そうです。

*2 経済産業省『情報サービス・ソフトウェア産業における下請取引等に関する実態調査』(2017) p5 
 →経済産業省の業務委託によりみずほ情報総研が作成した報告書

 しかしそれだけでは説明が不十分です。なぜソフトウェア企業(以下ベンダーと呼称します)は独自に製品・サービスを開発せず、大手の下請けに甘んじるのでしょうか。

 典型的なウォーターフォール型のプロジェクトを考えてみます。
 前提として、ユーザー企業は自前でシステムの開発はできません。仮に技術的に可能だとしても、自社社員だけで開発するのは現実的ではありません。システム開発に必要な要員数は工程によって変化するからです。一般に、後工程に行くほど必要な要員数は増えていきます。

システム開発の工程と要員数の関係

 ガバガバなグラフだけどお兄さんゆるして

 そして開発が終われば保守運用フェーズとなり、必要員数は少なくなります。

開発工程と運用・保守工程の要員数の関係

 足りなくなったら雇うのはともかく、必要なくなったからクビにするのは解雇規制の強い日本の雇用慣行ではまず無理でしょう。
 技術的に可能でも自社社員だけで開発するのが不可能なのはそういう理由です。解雇ができないのです。

 この問題を回避するために、企業は外部の開発会社(いわゆるSIer)に予算と期間を決めて開発要員の手配を依頼します。

ユーザー企業とSIer

 さて、ここからが重要です。依頼を受けたSIerも日本企業ですから必要以上に人員を抱えたくはありません。もし不景気で依頼が少なくなり、自社待機の社員が増えても解雇ができず、商売上がったりになってしまうからです。
 ではどうするか。お客様がちょうどいい例を示してくれましたね? そう、SIerもさらに外部の開発会社(二次受けベンダー)に要員手配の依頼をするのです。自社利益は確保したうえで。

ユーザー企業とSIerと二次受け企業

 そして依頼を受けた二次受けベンダーも要員が足りなければさらに3次請けベンダーに要員手配を依頼し、その3次請けベンダーも……。このサイクルが要員数が足りるまで繰り返されます。

ユーザー企業とSIer~三次請け以下企業

 こうして最終的に、大別して3層からなる多重下請け構造が完成します。
 ユーザー企業から案件を受注する元請けSIerが第1層、人を集める2次請けベンダーが第2層、人を出す3次請け以降のベンダーが第3層です。

一層二層三層

 以上をまとめますと、自社だけでは足りない分の要員数を埋め、開発が終われば解散できるよう直接雇用ではなく外部との契約を進めた結果、多重下請け構造が形成されるのです。
 逆に言えば、多重下請け構造は、自社社員の終身雇用を維持しつつ開発に必要な要員を確保するために発生したものだと言えるでしょう。
 誰かが悪意を持って推し進めたのではなく、終身雇用の制約下に適応した自然発生的な現象なのです。


商売としては完成している

 多重下請け構造はエンジニア非エンジニア問わず非難轟々、業界の内外から批判されますが、日本においては動かしがたい利点が存在しています。
 この構造がすでに50年以上続いている*3事実からして、商売としてはかなり強固に完成されているといえるでしょう。

*3 前述の『ソフト技術者の反乱』では要員派遣で成功した企業の例としてCSK(現:SCSK)を挙げている。CSKの設立が1968年。

 多重下請け構造に与するメリットを簡単に挙げてみましょう。

■ユーザー企業
・開発要員を抱えなくて済み、技術力のある開発ベンダーに依頼すれば極論、要件定義まで含めた丸投げが可能。
 
■元請けSIer
・ユーザー企業との安定的な関係を築けていれば自ら製品を作ったり市場開拓する必要がない。
・安定的な稼ぎを得られ、不況時には下請けベンダーを切って自社の雇用を確保できる。

■下請けベンダー
・上流ベンダーとの契約は準委任なので完成責任がなく、人を出すだけで売上が立つ。
・炎上しても儲けが出るので社員教育をしなくても最悪頭数がいればいい。
・コストがかからないので参入も維持が容易。
・下請けの下請けに再委託すれば人を出さなくても利ざやだけ抜ける。

■エンジニア
・仮に下請けベンダーに入ってしまったとしてもとりあえず事務員よりは高い給料が得られる。

 つまるところ、どの立場であっても多重下請け構造に入ってしまえば頭を使わなくても物事が回せるんですね。口さがなく言ってしまえばバカでもできる商売なので、経営者からすれば”こりゃあ笑いが止まんねぇな! 人売り最高!”とこの上なく魅力的に映るでしょう。
 先の調査でも下請けの人売り稼業は経営が楽と回答されています。

会社の規模に関わらず、ユーザー企業や大手ITベンダー等と直接取引をしたくない、すなわち、完成物責任を取りたくないために、二次請け、三次請けのままで居続けることを望む会社もある。情報サービス・ソフトウェア業界では、半数以上がそのような会社といえるのではないか。そのような会社では、準委任契約やSESなどの月単位の契約が多いため、要員は出しても、完成物責任はなく、ビジネス上のリスクは低い。毎月売上が上がるため、経営も楽である。

 経済産業省『情報サービス・ソフトウェア産業における下請取引等に関する実態調査』(2017) p121~122


人売りの弊害

 商売としての完成度が高く、経営者からすれば垂涎の多重下請け構造ですが、いいことばかりではありません。

■ユーザー企業
・不景気になり予算が減らされれば人員も減らされ、外注比率を高める。
 結果、要件定義まで含めた丸投げが横行し、発注者責任を果たさなくなったり、ベンダーコントロールができなくなって、特定のベンダーに依存しなければなにもできない状態ができあがる(いわゆるベンダーロックイン)。

■元請けSIer
・ユーザー企業に安定的に技術者を常駐させられればそれだけで売上が上がるので真面目に経営を考えなくなる。
・良いものを作って売らなければ潰れるという淘汰圧が働かないため、トレンドを追ったり技術を磨くインセンティブが働かず、労働環境や作業能率を良くする意識も向上しない。
・もともとは志を持って起業した人でも、会社存続のため、技術者派遣に手を出して楽に儲けてしまうと、当初の志を忘れてしまう危険がある。

■下請けベンダー
・元請けSIerと同様のリスクを抱えているうえ、不景気になると上位ベンダーから案件を切られるリスクがある。
・仮に潰れないとしても、元請けベンダーやユーザー企業の値下げ圧力や不条理な命令*4に対抗できない。

*4 新型コロナウイルスの蔓延によりリモートワークの必要性が生じたにもかかわらず、現場作業の継続を求めるユーザー企業に唯々諾々と従い、社員の生命を危険に晒す事態になったのが最たるもの

■エンジニア
・元請けに近ければマネジメントが重視されるし、下請けになればなるほど分割に分割を重ねられて誰でもできるようになった作業*5をやらされ、スキルが身につかない。

*5 Excelで証跡をペタペタ貼り付けるような仕事とか。

・労務管理や作業環境がしっかりしている現場にいけるかどうかは運次第
・元請にしろ下請けにしろ自分で企画やプロダクトは作れず、会社に依存しなければ生活ができない。

 そして何よりの弊害が、結局割りを食うのはシステムの使用者、すなわちエンドユーザーです。
 多重下請け構造は結局のところ、仲間内で予算を融通するための生態系にすぎず、いいものを作ろうという力学は働いていません。
 自分たちの必要なものすら決められず(要件定義のできないユーザー企業)、世のトレンドについていけない(SIer)、製品を完成させる義務すら負わない(準委任契約のベンダー)人たちの作ったシステムがどうしてエンドユーザーのためのシステムになっているでしょうか。


人売りSIerの存在意義ってなに?

 現在では下請けベンダーからではなく通常の派遣会社を通して、あるいは直接連絡をとって優秀なエンジニア(フリーランスを含む)を集められます。

 手練れたエンジニアとそうでないエンジニアでは能率が10倍以上異なります*6から、理解のある会社は多少コストが高くついても優秀なエンジニアを雇うでしょうし、一エンジニアとしても、自分自身のスキルとマッチしている・報酬が折り合う・伸ばしたいスキルの方向性と合致している案件を選べるメリットが大きいでしょう。

*6 プロジェクトマネジメントの古典『人月の神話』が刊行された1970年代の時点で、プログラマーの生産性は最高と最低で10倍もの開きがあるとが指摘されている。
 さまざまなツールや、クラウド・AIなどの新しい技術の存在を考慮すると、現在では10倍ではすまないかもしれない。

 そう考えると、多重下請け構造の存在意義ってなんなんでしょうね。かつては開発要員を融通するという点で必要悪ではあったのかもしれません。ですが、現代で人売りを使う会社は、開発するシステムに必要なスキルセット(非機能要件も含む)を評価できず、コストカット以外に利益を出す方法を知らないボンクラ企業を生き長らえさせているだけではないでしょうか。

 かといって仮に解雇規制が撤廃されて多重下請け構造が解消されたとしても、世の幸福に寄与するかどうかはまた別問題ですけどね。学校を出たら勉強が終わりだと思っている人も多いですから。


どうかお幸せに

 さて、ここまで解雇規制が多重下請け構造を生み出す機序、そのメリット・デメリットを書き連ねてきました。

 僕個人としては、多重下請け構造に組み入れられるのはおすすめしませんが、下請けベンダーだったらスキルが浅くても潜り込みやすい(何しろ頭数=売上の世界ですから)ので、未経験者が業務経歴をつくるために1年くらい従事するならありかもしれません。

 ただ、前述したように"とりあえず食ってはいける"ので、そのままズルズル惰性で続けてしまうのが怖いですね。よほど計画と強い意志をもって、時期が来たらすっぱり身を引くつもりでいないと取り込まれてしまいます。
 そこまで計画的にやれる人ならはじめから自社開発しているところを目指してポートフォリオを作ったほうがいいのではないでしょうか。

 最近はクラウドやDXを標榜して少しずつ業界も変わりつつありますが、それでもこの完成された商売が早々になくなったりはしないでしょう。
 あくまでもこの特殊な生態系に飛び込んでいくのか、自主独立してやっていくのか、それともこの業界に近づかないで生きるのかはあなた次第です。どうか悔いのない選択をしてください。


参考文献

 ・ソフト技術者の反乱―情報革命の戦士たち

 冒頭に引用した文章は本書のあとがきから。この本が刊行されたのは1983年ですが、当時からいまと似たような問題が業界にはびこっていたことがわかります。
 30年くらいこの業界変わっていないんですね。エンジニア35歳定年説みたいな一昔前によく言われていた俗説もすでにこのころからあり、その元ネタ、もととなる考えも本書に掲載されています。
 余談ですが、旧エニックス主催のホビープログラムコンテストで大賞を受賞し、「森田将棋」を作った森田和郎さんのインタビューがなかなか興味深かったです。


 ・木村岳史の極言暴論!

 多重下請け構造について強烈なディスをあげている日経クロステック編集委員。内容に賛否両論はあれど、多重下請け構造についての分析は鋭く、本記事執筆にあたって大いに参考にさせてもらいました。
 全文閲覧は会員登録が必要ですが、無料で読めます。とくに注目すべきは以下の記事。

 ・IT部門とIT業界を駄目にした終身雇用、では技術者をクビにしますか?
 →日本の厳格な解雇規制が多重下請け構造を生み出したと喝破した記事。

 ・ITの多重下請けは3層構造、ブラック業界の本質を知るべし
 →IT業界の多重下請け構造が元請けの第1層、人集めの第2層、人出しの第3層からなると分析した記事。

 ・IT業界の多重下請け構造は超快適、変革の志が霧散する理由
 →IT業界の多重下請け構造がいかにぬるま湯であるかを指摘した記事。一度嵌るとやめられない。


 ・情報サービス・ソフトウェア産業における下請取引等に関する実態調査
 →下請取引等の実態調査が報告されている。ヒアリングによる関係者の生の意見も業界人の本音が透けて読みごたえがあります。

この記事が参加している募集

退職エントリ

この記事が気に入ったらサポートをしてみませんか?