Photo by Camdiluv ♥
こんにちは、谷口です。
日本のIT業界について語られる際、蔓延している「多重下請け構造」について取り上げられることがよくあります。
この多重下請け構造は、企業側や発注者にとっては大変都合のよい仕組みです。
ただ、構造の下の方で実際にシステムを開発している人々にとっては苦労が多く、決して「現場の開発業務をやりやすくするための仕組み」とは言えません。
本来、ITエンジニアは技術を駆使し、スキルを活かしてシステム開発をするのが仕事のはずです。しかし、多重下請け構造の中では、エンジニアの高いスキルも飼い殺されてしまうことが珍しくありません。
今回は、「多重下請け構造」にはどんな問題があるのかを考えて行きたいと思います。
■多重下請け構造とは
Photo by m-louis .®
「多重下請け構造」とは、受託システム開発において、発注元企業から直接仕事を請け負った元請企業が、その仕事を分割して下請け企業に下ろし、一次請け、二次請け、三次請け、四次請け……と下請け企業がさらにその下請けに仕事を分割して下ろしていく、ピラミッド型の構造のことです。
業務の分割については、元請け企業は要件定義や設計等のいわゆる上流工程とされる業務を行い、実装やテスト等の下流工程は、分割されて下請けに委託されていく……というのが多いパターンです。
ITに限らず、どんな仕事でも「自分たちでやるより専門の業者へ委託しよう！」というのは、よくあることだと思います。例えば、仕事でイラストが必要になったけど、社内に描ける人がいない…という場合は、道具を揃えて社員に絵の描き方を学ばせるよりも、イラストレーターに外注をした方が、早く質の高いイラストを手に入れられるでしょう。
では、IT業界の多重下請け構造は、一体何が問題なのでしょうか？
■多重下請け構造の問題点
Photo by teens4unity
◆下の層に行くほど給与が安くなる
n次請けに及ぶまでの下請け企業に仕事が下りてくるのは、「開発技術を見込まれて」ではなく「とりあえず作る人の頭数を集めるため」な場合がほとんどです。
発注する側も、安く作ってもらえるならその方がいいですし、下請けも「うちは他社より安く作れますよ！」とアピールをし、価格競争を招いてしまいます。
そもそも多重下請けの場合、中間の企業はマージンを抜いてから下層の下請け企業に業務を委託していくため、下層になるほど、下りてくる金額は安くなっていくのです。
これが横行すると、末端で開発をする技術者にもしわ寄せが来ます。
たとえ同じようなものを開発したとしても、中間にどれぐらい上位請け企業が入っているかで受ける金額が変わる上、価格競争まで発生しているため、下層に行くほど、現場の技術者が受け取る賃金は安くなってしまい、「技術に対して正当な対価」が支払われない状況を招いてしまうのです。
◆技術者が交換可能な頭数として換算される
受注された開発業務は、技術力がそれほどない人でも作れるように細分化されていきます。業務量が多くて間に合いそうになければ、下請けから作業者がどんどん投入されていきます。
それで開発業務が滞りなく進んでいけばよいのですが、システム開発は下請け企業を増やして頭数さえ増やせば必ずうまくいく……というものではありません。それでうまくいくなら、みずほ銀行のシステムも今ごろ無事にできあがっているはずです。
多重下請けの場合、業務が増えて人が必要になったら下請けから増やす、運用に入って不要になったら契約を切る……といった感じで、技術者は交換可能な頭数として換算されている状態ですが、人海戦術で大規模システムを開発しようとすると、付随して下記のような問題も頻発してしまいます。
◇下請けが増えると責任問題が曖昧になる
プロジェクトの規模が大きくなると、その分多くの下請け企業が介在することになります。
すると、大小さまざまなトラブルが生じた際に「うちはこの部分だけ作る契約ですから他は知りません」「このバグはうちのせいではありません」などと、責任の所在がどこにあるのかわからない……といったことになりがちです。
◇常駐によるトラブル
受託開発の場合、下請けの技術者は、上位層の企業に常駐して開発をしなければならない場合が多くあります。
もちろん労働環境のよい常駐先もたくさんありますが、複数企業から派遣されてきたレベル感の全然わからない人同士で開発を進めていかねばならない、まだ技術的に未熟なのに一人で常駐先に派遣されてしまって相談できる人がいない、自社ではなく常駐先の労働条件に沿って働かなければならない……などなど、常駐開発によるトラブルは絶えません。
◆エンジニアの技術が育たない
先ほども言いましたが、多重下請けで開発を進めていく場合、技術レベルが高くない人でも作れるように、開発業務は分断されていきます。
末端の作業者に下りてくる仕事はシステム内でどう使われるのかわからないレベルにまで細分化されていて、「何のためのシステムを作っているか知らない」「いま作ったものが誰にどう使われるのかわからない」といったパターンもよくあります。
また、実装中に何か問題や改善点が発覚しても、手戻りが許されず、「仕様」として設計通りに作らざるを得ないことも多いです。
さらに、チーム共通で使う開発ツール等は、全員が問題なく使えるように、レベルの低い人に合わせた環境が採用されてしまいがちです。この場合、「もっと便利なもの」があると知っていたとしても、「みんなが使えて、過去に実績がある技術」「客先に指定された技術」しか使えず、スキルが高い人がいても、それを活かした高い生産性を発揮しづらい環境になってしまいます。
こうして、多重下請け構造の中では、エンジニアとして核であるはずの技術を磨くことが難しくなってしまうのです。
■技術を磨きたいエンジニアはどうすべき？
Photo by Wim de Jong
金融系や官公庁等の巨大システムが社会にとって必要なものですし、多重下請けによる開発手法がなくなることはないでしょう。
ただ、上記のように末端の作業者が使いつぶされ、技術を磨くのも困難な環境が、技術を磨いていきたいエンジニアに向いているとは思えません。
日本のIT産業は、かつては事務処理等のシステム化目的で発注される受託開発の割合が高く、「ITはコスト削減のための裏方的な仕事」といった傾向がありました。そのため、「利益を上げるための業務ではないので、いかに安くそれなりに作るか」が重要なポイントで、エンジニアの地位もあまり高いものとは言えず、「技術を磨く」「革新的なシステムを作る」といったことは二の次の扱いでした。
しかし現在では、自社でサービスの開発や人工知能等の新しい分野の技術も台頭し、品質の高いサービスを開発することで、技術者自身が利益を生み出せる時代となっています。IT技術が好きで自分の開発スキルを伸ばしていきたい人の願いが叶いやすい企業も増加していますから、現状に不満がある人は「このままこの仕事を続けるべきか」というところから考え、必要があれば動き出した方がよいでしょう。
■まとめ
受託開発の現場では、こうした多重下請け構造が根幹にあるせいで、個々の企業では改善が難しいレベルで、末端のエンジニアにしわ寄せが行く環境ができあがっています。
ただ昔に比べると、受託でもこの構造にあてはまらない開発手法をとる企業や、自社サービスの開発をしている企業も増えてきているので、望めばよりよい環境に移動することは可能な時代となっています。
日本のITエンジニア全体の評価には、まだまだ伸びしろがあります。paizaも、もともと「エンジニアの技術力がきちんと評価され、またそれを活かせる職場を探せるプラットフォームが必要だ！」といった想いから作り始めたサービスです。
エンジニアの負担が少しでも減らせるよう、そして地位も向上させられるよう、paizaが考えていくべきことは多いと感じます。
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
また、paiza転職をご利用いただいている企業の人事担当や、paiza転職を使って転職を成功した方々へのインタビューもございます。こちらもぜひチェックしてみてください。
詳しくはこちら
