読者です 読者をやめる 読者になる 読者になる

paiza開発日誌

paiza(https://paiza.jp)の開発者が開発の事、プログラミングネタ、ITエンジニアの転職などについて書いています。

経産省の見解は受託下請けのエンジニアを幸せにするか?IT人材を巡る現状

ITエンジニアのキャリア ITエンジニアの転職

f:id:paiza:20161204174126j:plain
Photo by Robert Couse-Baker

f:id:paiza:20140916135428p:plainこんにちは。谷口です。

近年、経済産業省が日本のIT産業の仕組みに関する調査や審議会を実施し、その際の調査資料等が公開されていることを皆さんはご存知でしょうか?

例えば「IT人材を巡る現状について - 平成27年1月 情報処理振興課」や「IT産業における下請の現状・課題について - 平成27年3月 情報処理振興課」といった調査資料では、

• 景況不況による開発案件増減の調整弁となった多次請け協力会社の労働環境、雇用条件、待遇が悪化
• SI業界を中心に、「ブラック企業」、「デジタル土方」、「デスマーチ」、「新3K」のイメージが醸成
• 業界全体にネガティブなイメージが蔓延し就労先としての魅力が低下、新卒学生がSI業界を敬遠

IT人材を巡る現状について - 平成27年1月 情報処理振興課 P10)

我が国のIT産業の重層的な構造は、事前に仕様を固めるウォーターフォール型開発に適合した構造と考えられるが、プロセス間のやり取りが頻繁に発生するアジャイル型開発等には適合しにくい構造であると考えられる。

IT産業における下請の現状・課題について - 平成27年3月 情報処理振興課 P6)

というように、開発現場や下請けの現状に関する課題への見解もまとめられています。

今回は、これら経済産業省が提示しているデータと業界の現状・課題をもとにお話ししていきたいと思います。

■IT産業における下請の現状

◆IT産業の産業構造

まず、受託開発における元請企業と下請の産業構造を見てみましょう。

受託開発では、まずユーザー企業と呼ばれる顧客、例えば銀行が「ATMのシステムを新しくしたい!」といった場合、「こういうシステムを作ってください」という依頼を直接請けるのがプライムベンダーと呼ばれる元請け企業になります。この元請け企業は、ユーザー企業と「このシステムをいつまでにいくらで作ります」という契約をします。そして、元請け企業は下請け企業に実際の業務を振り分け下請け企業のエンジニアは要件通りの設計やプログラミング実装をします

受託開発企業全体における割合ですが、元請と下請両方を行っている企業が半数で多数(全体の73%)を占める一方、下請のみ行っている企業もおよそ4社に一社の割合となっています。IT人材を巡る現状について - 平成27年1月 情報処理振興課 P2)

・IT企業の取引における立場の割合(アンケート調査)
f:id:paiza:20160302161509p:plain

(情報サービス・ソフトウェア産業における下請ガイドライン改定事業及び取引適正化に関する調査研究報告書/経産省

◇IT産業における外注比率

こうしたIT産業の費用の約3分の2は、内部の人件費(給与)と外注費に占められています。IT人材を巡る現状について - 平成27年1月 情報処理振興課 P3)

f:id:paiza:20160302163857p:plain

また、事業者の規模別に人件費と外注費の割合を見ると、規模の大きい事業者ほど外注費が占める割合が高く100名以上の規模の企業では外注費が人件費を上回っています。
f:id:paiza:20160302164000p:plain

◆1990年代以降の情報システム産業の変遷

情報システム産業では、1990年代以降主にユーザ企業の業務効率化案検討を受託開発するビジネスモデルを形成してきましたが、2000年代後半から協力会社を中心として労働環境の悪化が相次ぎ、受託開発ビジネスの限界に直面しました。IT人材を巡る現状について - 平成27年1月 情報処理振興課 P10)

【1990年代前半】
<ソフト・サービスへのパラダイムシフト>
• 箱売り批判によるメインフレーム事業の収益悪化
• オープン化、ダウンサイジングの進展
• メインフレーマーはソフト・サービス事業へとシフト

 ↓

【1990年代後半~2000年代】
<ベンダ丸投げ、人月単価のビジネスモデル形成>
• ユーザ企業のIT投資の主たる目的は、現行業務の情報化
• フルオーダーメイドの受託開発がシステム開発の中心となり、システムのブラックボックス化とベンダロックインが発生
• 人月換算とソースコードの行数換算で取引価格が形成された結果、技術力が軽視され研究開発が停滞
• ベンダ企業では労働集約型ビジネスを支えるための多重下請け構造が形成

 ↓

【2000年代後半以降】
<業界の疲弊>
• 景況不況による開発案件増減の調整弁となった多次請け協力会社の労働環境、雇用条件、待遇が悪化
• SI業界を中心に、「ブラック企業」、「デジタル土方」、「デスマーチ」、「新3K」のイメージが醸成
• 業界全体にネガティブなイメージが蔓延し就労先としての魅力が低下、新卒学生がSI業界を敬遠

経産省はこの流れを受け、「丸投げ委託、多重下請けと人月ビジネスの横行等により、業界全体の魅力が低下した」と辛辣な見解を表しています。

■IT産業における下請の課題

f:id:paiza:20161204174619j:plain
Photo by ghatamos

◆労働環境・利益格差の問題

Tech総研が22~44歳のIT系企業に勤務するエンジニア1000人にとったアンケートをもとに元請企業・下請企業別に給与水準を比較した場合、下請よりも元請の方が給与が高く、さらに年代が上がるにしたがってその差は広がる傾向があります。

これを受けて、経産省は「契約上立場の弱い下請企業の利幅が圧縮されている可能性がある」ことを指摘をしています。IT産業における下請の現状・課題について - 平成27年3月 情報処理振興課 P5)

f:id:paiza:20160302164850p:plain

さらにTech総研のアンケートには、エンジニアたちから下記のような意見が寄せられていました。

「1次請けのリーダーが仕事もスケジュールも管理できず、そのフォローをしながら自分は仕事をしている。割に合わない」「同程度の仕事をしている元請けと比較して、自分は仕事に見合った給与を受けていないと感じる」、さらにより具体的に「2次請けの我々と元請け(親会社)の社員は同じ業務を行っているのに、我々の方が15%程単価が低い」という指摘もあった。年代を問わず、下請け構造のなかで下に行けばいくほど劣化する待遇・条件についての不満が募っている。

中には「残業代がつかないのに、月100時間程度の残業がある。また、休日出勤も最近多い。顧客のスケジュールにあわすことが多いため、休みが取りにくい」という声もある。ここでは、顧客のスケジュール優先で振り回されることによる不満、さらに企業として残業代を支払わないことへの不満が重層化している。まさに多重下請けの中小企業の悲哀がここに凝縮されているともいえよう。

加えてIPAの第29回情報処理産業経営実態調査報告書における、下請け企業の労働生産性は元請け企業の6割ほどにとどまっているという報告も受けて、経産省

我が国のIT産業の重層的な構造は、事前に仕様を固めるウォーターフォール型開発に適合した構造と考えられるが、プロセス間のやり取りが頻繁に発生するアジャイル型開発等には適合しにくい構造であると考えられる。

としています。

IT業界の給与格差を探る!元請と下請でいくら違う?|【Tech総研】

◆セキュリティリスク管理上の問題

多重下請構造は末端のエンジニアまで適切な管理が行き届かない場合も多く、情報漏洩等セキュリティにおける問題が度々ニュースになっています。

2012年に発生した横浜銀行のシステムを担当していたエンジニアが他人の口座データを抜き取りキャッシュカードを偽造・現金を不正に引き出していた事件や、記憶に新しい2014年に発覚したベネッセの大規模個人情報流出事件を受け、IPAは「組織における内部不正防止ガイドライン」を改訂し、経営層によるリーダーシップの強化、情報システム管理運用の委託における監督強化、高度化する情報通信技術への対応等を促しています。

◆多重派遣における法的な問題

セキュリティ的な面もそうですが、多重下請というのはそもそも法律的にもグレーな部分を含んでいます。

本来、請負労働者(末端のエンジニア)に発注元企業の人間が直接指示を出したり命令を行うことは、多重派遣の扱いとなりNGとされています。

例えば、A社がB社に大規模システムの構築をお願いしたとしましょう。B社は、自社の人材だけでは全ての作業を賄えないため、C社からもエンジニアを要請し、C社はD社に……というのが多重請負の公式です。

多重請負自体は「業務請負」という形式である限り法的には問題ないのですが、実際に請負なのか派遣なのかということは、指揮系統の違いにより区別されます。

この場合、D社がC社から業務を請け負ったとして、D社のエンジニアがB社に常駐し、C社のチームリーダーから指示を受けて指示をするのであれば問題はありません。しかし、元請けであるB社の人間が、本来雇用関係にないD社のエンジニアに直接指揮命令を出してしまうと、多重派遣(偽装請負)となってしまいます。

実際の常駐開発の現場となると、発注元の人も下請から常駐で来ている人も入り混じって開発をすることが多いため、発注元から直接労働者に指示がいくようなことも実質避けられないでしょう。

下請け企業の常駐によるシステム開発は、このように「結果として多重派遣になってしまっている」、もしくは「多重派遣に限りなく近い状態」になってしまうことが多いという問題点もはらんでいるのです。

◆今後の適正化に向けた方向性

経産省は、今後の適性化に向けた政策の方向性として、

○IoTによる産業構造の転換が進む中で、IT化の担い手としてのIT産業は労働集約型から脱却し、生産性・競争力の向上を図ることが重要。
○このため、ITシステム構築に係る発注者・受注者間の取引・契約関係を見直し、受注者への丸投げ等から生じる効率的ではない取引の適正化が必要ではないか。

・様々なプロジェクト形態(アジャイル等)における、契約のあり方と適正な値決めの方法(人月ベースから成果・能力ベースへ)
・請負・派遣の偽装防止のための、下請監督と労働監督の連携

といった論点を挙げています。IT産業における下請の現状・課題について - 平成27年3月 情報処理振興課 P14)

また、「産業構造審議会 商務流通情報分科会 情報経済小委員会 IT人材ワーキンググループ(第2回)‐議事要旨」では

受託開発や下請がだめという単純な議論ではなく、労働集約になっていること自体が一番大きな問題。ある種のビジネスのやり方や契約のあり方自体に関する議論に飛び込まないと、ここに対する解決法はないと思う。これが難しいのは、契約なので片方だけではどうにもならないから。ユーザーとベンダが双方で話をすることが、多分重要になってくる。個人的な意見だが、パフォーマンス・ベースド契約みたいな話は取り入れるべき時期に来ている。

同時に、労働集約になっているもう一つの原因は、要は誰がつくっても同じものをずっとつくり続けていること。これが一番大きな問題。これもベンダ側だけでは改善できないので、ユーザーとベンダで両方でつくっていかないと、そういう仕事が生まれない。ベンダが悪いとかユーザーが悪いというよりは、両方で解決すべき問題。

といった意見が各委員から出ています。

多重請負や受託開発が抱える問題点もよく把握されているのですが、その後実質現場に何かテコ入れがあったかというわけでもないので、業界の産業構造に対する早い改革が期待されるところです。

■受託開発企業の側面

f:id:paiza:20161204174825j:plain
Photo by David Pagano
多重下請の産業構造自体は、経産省指摘の通り多くの問題をはらんでいます。

しかし、もちろん受託開発をしている全ての企業が「ブラック企業」で仕事はいつも「デスマーチ」続き…というわけではありません。

労務管理体制がしっかりしていて、デスマーチに陥らないよう管理部や営業からの手厚いフォローがあって力を発揮しやすい企業や、最新技術を使用する仕事の受託が多くて成長環境が整っている企業もあります。また、大手元請け企業は官公庁や医療系といった景気に左右されにくい業務を請け負うところも多く、会社の経営が安定しているところも多いです。

Web系のベンチャー企業は上場企業も多く、開発でも最新技術が使えてイケてるように見えますが、正直言って安定性とはかけ離れていますし、働くにしても社内制度が整っていない企業も多くあります。また、とにかくフルスピードで動くものを作る!整備はそれから!といったスピード感ある開発が必要となることも多いので、要件を詰めて、設計して、実装して、テストして……という手順を踏むことが好きな人は大手の受託開発企業で働く方が幸せかもしれません

また、私自身新卒で入社した企業は受託開発企業だったのですが、受託開発企業の一番よいところは「プログラミングの心得がない人でも入社できる」「入社後にプログラミング研修がある」という点だと思います。

Webサービスを開発している企業ですと、すぐに開発に取り掛かれる即戦力があってスピード感についてこれる人を求めているところが多いため、中途か新卒でも情報系を専攻してプログラミングの素養がある人しか採用できないというところが非常に多いです。

そのため、大学時代の専攻は情報系じゃないけど、エンジニアになりたいという人や、就活段階でのプログラミングスキルや知識は浅いけど、エンジニアになりたいといった人は入社するのがかなり難しいのが現状です。

対して、受託開発系の企業は学部問わず入社後はプログラミング研修からスタートというところが多いため(中途ですら未経験採用→研修→実務に入るというステップを踏むところもあります)、エンジニアを目指す方に対し、情報系以外の方にも広く門が開かれています。

前述の通り、受託開発イコールブラックというわけでは決してありませんので、労働環境や研修が整い、仕事を通しても成長環境があるような企業に入社することができれば自分の開発スキルを伸ばしていくこともできますし、また経験を積んでから別の企業やWeb系の企業へ転職……というキャリアを積むこともできます。(ブラック受託とホワイト受託の見分け方については、また次の機会にお話ししたいと思います。)

■まとめ

経産省は研究・報告やWG等を定期的に実施し、受託開発及びIT業界の現状や課題の把握に余念がないと感じます。しかし一方で、その適性化や効果的な改善策が現場に降りてくるのはいつになるのだろうとも感じます。

特にこれまでの「人月商売」のままでは、成果物の評価も「労働集約型」で、何人月で作ったかという時間の切り売り部分にしか対価が支払われません。

本来、IT産業はサービスやシステムによる提供価値をもとに「知識集約型」の評価を受ける必要があるので、いつまでも労働集約型に甘んじているのはITエンジニアの価値の安売になってしまいますし、そのような評価構造が横行しているような状態では価値を生み出す先進的なプロダクトを生み出すようなスキルは身につかないのではないでしょうか。

優秀なエンジニアと価値あるサービスが正当な評価を受けられる風潮が業界全体に浸透することを期待しています。


【参考リンク】
IT人材を巡る現状について - 平成27年1月 情報処理振興課
IT産業における下請の現状・課題について - 平成27年3月 情報処理振興課
産業構造審議会 商務流通情報分科会 情報経済小委員会 IT人材ワーキンググループ(第2回)‐議事要旨
IT業界の給与格差を探る!元請と下請でいくら違う?|【Tech総研】




paizaではITエンジニアとしてのスキルレベル測定(9言語に対応)や、プログラミング問題による学習コンテンツ(paiza Learning)を提供(こちらは21言語に対応)しています。テストの結果によりS,A,B,C,D,Eの6段階でランクが分かります。自分のプログラミングスキルを客観的に知りたいという方は是非チャレンジしてみてください。

http://paiza.jp

プログラミング入門講座|paizaラーニング

PHP入門編Ruby入門編Python入門編Java入門編JavaScript入門編C言語入門編C#入門編アルゴリズム入門編