Photo by Jonathan Kos-Read
今回のpaiza開発日誌は片山がお送りします。
SIerについて語られる際にIT業界の「多重下請け構造」についての問題点が良く取り上げられますが、「多重下請け構造」がITエンジニアにとってどのような問題点があるのでしょうか？
その点について今回は少し整理してみようと思います。
■「多重下請け構造」とは何か
説明するまでもないかもしれませんが、「多重下請け構造」とは、受託システム開発において、発注者から直接仕事を請け負った元請（たいていの場合が大手SIer）が、請けた仕事を切り出して2次請け、3次請け、4次請けと仕事を下ろしていくピラミッド構造の事を言います。
良くある例で言うと、元請は要件定義や概要設計等の上流工程を請負い、開発・実装などの下流工程は2次請けに委託する、というような構造です。2次請けは自社リソースで開発を賄えない場合に3次請けやフリーランス等に一部業務を外注（再委託）という事を、3次請け、4次請けを繰り返し、自分が今まで聞いた限りの最大で言うと7次請けまで存在します。
システム開発に限らず一般的な仕事でもそうですが、自分たちでやるよりもメリットがあれば外部の業者に仕事を委託する(デザインを外注するとか、個人で言えばスーツをオーダーするとか)というのはよくある事です。外注された仕事は、専門分野ごとにさらに2次請け等に出されていることもよくあると思います。では何故、IT業界の受託開発における多重下請け構造が問題視されるのでしょうか。
■「多重下請け構造」の何が問題なのか？
「多重下請け構造」の結果として、どのような事が問題になるのかを考えていくと下記の4項目になるかと思います。
- 適切な対価が払われない
- 交換可能なモノ扱い
- エンジニアが育たない
- 法的にグレー
Photo by Jonathan Kos-Read
◆１.適切な対価が払われない
まず多重下請け構造における大きな問題として、中間業者が数多く入るため、下の層に行けばいくほど中間搾取により現場で働いているエンジニアの給与レンジが低くなってしまうという問題が挙げられます。1段階階層が下がるだけでも、月間数万～数十万程度のマージンが抜かれるのが一般的でしょう。
その結果、同じような作業をしても、どの階層にいるかで給与レンジは大きく異なり、業務内容に対する適正な対価が得られないという事が発生します。多重下請けの構造でも、専門性による業務の委託が行われており、業務内容に対する適切な対価が支払われていれば問題は無いのですが、そうでないところに問題があります。
多くの場合、専門性ではなく、人手不足を補うため外部に委託をするため、下請け業者の競合優位性は価格しかなくなり、より安い業者が選ばれるようになり、下に行くほど安い単価になります。（これはそもそも下請けの企業が価格以外の競争力がない事自体も課題といえますが。）
中間搾取の問題は、安く請け負ってくれるところにツテがあると、単純に仕事を流すだけでマージンが得られるようになり、そればかりするようなところも生まれてしまうという点です。付加価値をほぼ出さず、マージンを抜くモデルが横行すると、実際に働くITエンジニアには適正な対価が支払われなくなってしまいます。
◆２.交換可能なモノ扱い
日本は雇用流動性が低く、おいそれと人を解雇できないため、プロジェクトごとにシステム開発に必要なエンジニアをかき集めやすくするよう全体プロセスを最適化しています。そのため特にSI業界では、実装工程のITエンジニアをライン工のような位置づけとして捉えられているように感じます。
具体的に言うと、設計と実装に分業化し、特に実装工程ではレベルの低い人に作業レベルを合わせ、誰でもできる仕事に落とし込むという形になります。こうする事で、実装工程のエンジニアを交換可能な部品として扱えるようになり、人を集める事も容易になります。
ただ実際問題としては、そこまで理想的にはいかず、設計面の問題を実装側がかぶる事になったり、出来る人にばかり仕事が降りかかったり、設計・実装の問題が運用時に課題に持ち越されたり、というような事態が多発します。
こういった開発スタイルの元では、「人的リソースを交換可能なモノとして扱う事」が思想として織り込まれているため、組織としてもITエンジニアをモノとして扱ってしまい、「潰れたら次」というように考えがちです。
特に実装工程のエンジニアは、プロジェクトごとに見ず知らずの人たちでチームが組まれる事も日常茶飯事で、様々な会社が入り乱れるため、管理責任があいまいになり、長時間労働が強いられたり、不明瞭な指示やパワハラなどにより使い潰される事が発生するわけです。
設計は上流、実装は下流という意識があるため、上流工程の人たちは仕事の場でも実装工程の人を下流の人達、下々の人達という扱いをしがちにもなる訳です。自社サービスやってるとこういう意識って生まれる事はほとんどないですが。。
もう一つモノとしてエンジニアを扱う問題点としてあるのが、経歴のごまかしです。派遣元(請負元)もITエンジニアをモノとして扱っているようなところだと、使い潰してもいいという発想になり、経歴を盛って仕事を取る、単価を上げるという方向に動くことになります。
こういった場合、発注側（派遣先）企業はエースが来ると非常に期待して受け入れ、高度な要求をするが、派遣された本人は出来ないが、やらなければいけないという状況に追い込まれ、板挟みになってしまうという事が起きてしまいます。とくに一人で常駐するようなことになった場合、相談相手もおらず潰れてしまう、という話を何度も聞きます。
IT業界は他の業界に比べるとうつ病発生率が倍以上とも言われていますが、これらの事に起因しているように思われてなりません。
◆３.エンジニアが育たない
多重下請け構造は過度な分業化を招くため、各ITエンジニアのレベルに落ちてくる仕事は「これが何のための仕事なのかわからない」「何を作っているのかよく知らない」という事がおきがちです。プロジェクト全体像を知る事がないため、前後の工程で何が起きるのかよく知らないという人も多くなります。
多重下請け構造の中では、良くも悪くもなるべく各タスクを人に依存せず交換可能な仕事として設計をしていくため、事細かな指示書と作業のやり方が決められており、自分が関わってるパート以外の事を知らされる事も少ないため、誰が何のために使うシステムで、自分がやってることがどう役立つのかもわからない訳です。
先日の日経新聞にプログラマーの説明として下記のようなものが載っていました。
プログラマーはシステムを規定した「詳細設計書」をプログラム言語に置き換える専門家を指し、システム設計を担うシステムエンジニア（ＳＥ）とは区別される。
http://www.nikkei.com/article/DGXLASDZ2705Y_X20C14A8TJ1000/
SIerの人達と話していると、プログラマーに対する認識がこの認識と特に変わらなくて驚く事が多いですが、詳細設計とやらで完全なロジックが組まれていて、それをプログラミング言語に置き換えるだけだとしたら、それはむしろコンパイラなのではないか？と思ってしまいます。
開発において事前に完全な設計が出来るというような事はほぼ無くて、それぞれのステップで発見される問題がある訳ですが、完全分業の世界だと手戻りは基本的に許されないため「仕様」という言葉に押し込まれ、実装段階でのクリエイティビティは完全にスポイルされ、使いにくいシステムが作られます。
また都度都度人がかき集められるような現場では、作業の基準は一番レベルの低いエンジニアでも仕事ができる状態にしなければなりません。そのため一番レベルの低い人に合わせた環境、ツール、ルールになり、出来る人の能力を殺す非生産的な仕組みになっています。（paizaランクでいうとランクD～C程度のレベルに合わせてすべてを進めるイメージでしょうか。）
これらの結果ITエンジニアが全く育たない環境になってしまっている、と言うのが多重下請け構造と分業化による大きな問題点です。
◆４.法的にグレー
ここ迄書いてきたような事は、このブログで問題視しているだけではなく、法律的にもグレーな事が非常に多く、社会的な問題となっています。
そもそも多重派遣は、中間業者による労働搾取につながることや、派遣元・派遣先の企業と労働者に対する責任の所在が不明瞭にもなるため職業安定法第44条、労働基準法第6条（中間搾取の禁止）でも禁止されています。
■職業安定法
（労働者供給事業の禁止）
第四十四条 何人も、次条に規定する場合を除くほか、労働者供給事業を行い、又はその労働者供給事業を行う者から供給される労働者を自らの指揮命令の下に労働させてはならない。
■労働基準法
（中間搾取の排除）
第六条 何人も、法律に基いて許される場合の外、業として他人の就業に介入して利益を得てはならない。
これを見ると、多重下請け構造全て違法に見えてしまいますが、派遣先からさらに別の企業で業務委託の作業をする事自体は違法ではありません。多重派遣は禁止されていますが、業務委託であれば問題ないのです。この為、多重下請け構造だからといって法的に問題があるわけではないのです。
派遣なのか委託なのかの違いは、契約形態ではなく実体としての指揮系統の違いにより区別されます。一番のポイントは請負労働者に対して、発注者が指揮命令を行うと偽装請負(実質は多重派遣)となりNGです。
問題なのは下請け企業の常駐によるシステム開発だと、実体として「多重派遣になってしまっている」or「多重派遣に限りなく近い状態」が非常に多いからです。常駐開発の現場だと、発注元企業の社員と請負企業の常駐で来ている社員が入り混じって作業をするのはなかなか避けがたい事です。(分けられるならそもそも常駐する必要もないわけで。。) そうなると発注元から直接請負労働者対して指示が飛ぶというのも起きてしまう事は避けられないでしょう。
法律の趣旨としても、職業安定法第四十四条で言っている事は「指示系統があいまいになり労働者が使い潰されてしまうのを防ごう」という事で、労働基準法第六条は「付加価値を作らず中間搾取し、労働に対し適切な対価が払われない事する事を防ごう」というのがその趣旨です。
Photo by Jonathan Kos-Read
多重下請け構造はこういった様々な問題を抱えています。元受、2次請けぐらいまでは良いとしてもそれ以降の下請けの状況を見ていると、非人間的な仕事になりがちであり、エンジニアとしてもスキルレベルの上がらない仕事になっているように感じます。
■なぜそうなるのか？
ここまでは、多重下請け構造の結果として生まれる問題について整理しましたが、何故このような多重下請け構造が生まれるのでしょうか。大きくは下記二つではないかと考えています。
- 雇用流動性の低さ
- ユーザー企業のIT理解度の低さ
◆１.雇用流動性の低さ
原因として一番大きいのは、これまで何度かブログにも書いてきましたが日本の雇用流動性の低さだと考えられます。日本の雇用制度では一度正社員として雇い入れるとなかなかクビを切る事が出来ないため、一時的に開発者が多く必要というような場合、外注を使わざるを得ません。
特に非IT企業におけるシステム開発などでは、開発時のみ一時的に数多くのエンジニアが必要となるが、運用段階になると少数で良いという場合も多く、そのような一時的にエンジニアが必要という場合にSIerの出番となります。
◆２.ユーザー企業のIT理解度の低さ
またもう一つの要因として、システムを使うユーザー企業のIT理解度の低さも、多重下請け構造助長の一因ではないかと思います。企業としてITに理解が無いと、情報システム部の社内での地位が低く、優秀な人材が配置されなくなり、ただの伝書鳩のようになってしまうため、システム利用部門との調整が上手くできず、ベンダーコントロールもうまくできないため、大手SIerに丸投げし、そのような仕事に最適化する為に多重下請け構造が生まれているのです。
規模にもよりますが、ある程度システム開発経験があり、社内調整が出来る人間であれば、多重下請け構造の元で開発するより、直接n次請け企業とやり取りをしてしまった方が、安くより良い物が出来ます。
また、ユーザー企業側がITに対してもっと理解があるのであれば、既存業務のIT化だけでなく、既存の枠組みではできないような事をITの使い方（コアコンピタンスになりうるようなITの使い方）をする事になってくるので、内製化が進み、元請け的な動きは全て社内で賄うようになります。（コアコンピタンスを外部に出すって有り得ませんので。）
つまり、ITへの理解度が高ければ丸投げしようという発想になりません。難しいシステムは専門の人達にお願いしようと言う丸投げ体質は、ユーザー企業のIT理解度の低さから来ているとも言えます。
これらの結果として多重下請けモデルにならざるを得なかったのが、これまでと現在の状況と言えるでしょう。特に巨大なシステムを開発するために「多重下請け構造」は組織として必要な機能であり、逆に言うとこうしなければ官公庁や銀行系などの巨大な案件には対応できないでしょう。つまり「必要悪」としてしょうがない事だったのかもしれません。
しかしこの多重下請け構造は、ITエンジニアが育たず、またITエンジニアの地位を低め、日本でITにおけるイノベーションが起きにくい一因ともなっています。これまではしかたなかったとしても、現在のグローバルな環境下で、ITエンジニアを育てず、使い捨てるようなやり方は、日本の国力を削ぐことにもなり、IT事業者として自殺行為です。
ITにおける多重下請け構造は、これまでは「必要悪」だったのかもしれませんが、現在では日本のIT産業の力を削ぐ「社会悪」になってしまいっている部分も少なからずあると思います。
■ITエンジニアと多重下請け構造
Photo by Thomas Leuthard
官公庁や銀行系のシステムなどは無くなるわけではありませんし、そういった巨大なシステムを作る際にはやはり今後もSIerは重要な役割を果たしていくでしょう。ただし多重請負構造は中間搾取が横行し、下流工程のシステムエンジニアを使い潰し、工程分業により使いにくいシステムしか作れない仕組みです。ITエンジニアとしてより良い仕事をしたいと考えるならば、あまり適した環境でありません。
基本的にSIerはITエンジニアとしてのスキルを上げるには適していないため、今後もSI業界に身を置くならば早々にエンジニアとしての道は捨てPMになる方向にシフトしたほうが良いでしょう。それが出来ないのであれば多重下請け構造の中にいるのは危険です。多重下請けに流通する仕事は、今後より単価の安い海外の労働力に置き換えが進むことは明白です。（移民政策も今後どうなるかわかりませんし…）
また現在の日本の置かれている環境を鑑みると、今後雇用の流動性は徐々に高まっていく事が要されます。それと同時に、今後ITが企業戦略の中でなくてはならい中心的役割を果たすようになっていくと、ユーザー企業内でも少なくとも元請けぐらいの能力の内製化が進むと考えられます。この流れによりSIのニーズは徐々に減っていくと考えられます。（IT人材白書を見ると、すでにSIからユーザー企業への転職は年々増えています）
一方で経済産業省発表の「情報サービス産業の現状」によると、Webビジネス市場は2011年の11兆円から20年の47兆円まで、約4.5倍に拡大すると予測されており、Webエンジニアの人材不足は今後も加速していく事が予測されるため、そうそうに転向してしまったほうが良いかもしれません。paizaの求人をみても自社サービス/自社製品の求人がかなり増えてきています。
Web業界は、常に勉強する事が求められる厳しい業界でもあるので、勉強が嫌だという人には向かない世界ではありますが。。技術力の面で言ってもpaizaランクでいうとB以上は欲しいところです。
■まとめ
多重下請け構造は、日本の受託開発の最適化の中で生まれた産業構造です。グローバル化が進まないのであれば、「必要悪」としてこの形態のままでもよいのかもしれませんが、多重下請け構造はITエンジニアを使い潰し、技術者を育たないため、イノベーションを阻害する大きな要因となっています。
その結果ソフトウェア産業における日本の国際競争力が大きくそがれる事となってしまうため、多重下請け構造は「社会悪」になりつつあると言えます。SI業界は今後なくならないとはいえシュリンクしていく事は明らかなので、特に多重下請け構造の下流工程にいるエンジニアは早くそういった場から脱し、競争の中でも生き残れる技術力を身につける方に動いた方が健全だと思います。
※こういった状況に対して嘆いているだけではしょうがないので、技術力がきちんと評価され、またそれを活かせる職場を探せるプラットフォームとしてpaizaを作りました。
■関連記事
地方の常駐・運用PGが、東京の開発エンジニアになるためにやった一つの事
paizaの開発エンジニアとして働き始めたのが今年2月から。日々Railsと格闘しつつpaizaのWebサービスの開発を行ってますが、それ以前は北陸のとある地方でC#メインの運用保守エンジニア（常駐型）を...
paizaは、技術を追い続けることが仕事につながり、スキルのある人がきちんと評価される場を作ることで、日本のITエンジニアの地位向上を目指したいと考えています。
「paiza転職」は、自分のプログラミング力が他社で通用するか（こっそり）腕試しができる、IT／Webエンジニアのための転職サービスです。プログラミングスキルチェック（コーディングのテスト）を受けて、スコアが一定基準を超えれば、書類選考なしで複数の会社へ応募ができます。
まずはスキルチェックだけ、という使い方もできます。すぐには転職を考えていない方でも、自分のプログラミングスキルを客観的に知ることができますので、興味がある方はぜひ一度ご覧ください。
