日本のIT業界やソフトウェア産業は多重下請け構造であることが少なくない。IT業界だけでないかもしれないが、日本が異常であることの一例である。この記事では、下請けに丸投げすることの問題点と、あるべき姿について述べていく。
１．多重下請け構造は日本特有である
多重下請け構造とは、システム開発等において下請け企業に発注する構造が、多重に行われることを指す。大元の「発注元」がシステム開発を依頼した際に、これを直接受注する企業を「元請け」という。「元請け」はシステム開発を行う一部のサブシステムもしくは一部の開発工程を下請けに発注する。これを「一次請け」とも表現する。下請け企業は、受注したシステム開発の一部または全部をさらに下請けの企業に発注する。「二次請け」や「孫請け」とも表現する。このように受注したシステム開発の一部または全部を他社に発注する流れが、多段階に渡っている。
o08usyu7231.hatenablog.com
多重請負は、ひとつのシステム開発に多くの企業が関連し、コミュニケーションの齟齬をはじめ問題が多い。多くの企業を取りまとめることは至難の業である。多重請負の末端の企業には、発注元の企業の要求や業務内容に関する知識が伝わりにくく、要求通りのシステムが完成されにくいこともある。酷い場合は、末端に企業は言われた通りにプログラミングするのみであり、そもそも（セキュリティ面の都合もあって）何を作っているのかわからないこともある。下請けになるほど、労働環境がブラックとなることも当然のようにある。
２．多重下請け構造における中間業者が存在することの問題
ここでは、下請けに丸投げする中間業者による影響について着目したい。中間業者が下請け企業を適切にマネジメント出来ているならまだ許容範囲である。
しかし、発注元から支払われる開発費のうち、自分たちの利益を差し引いた安い賃金で下請け企業に開発を丸投げしているだけのケースが少なくない。これではデメリットばかりが目立つ。具体的に思い当たるものを挙げてみよう。
- 実際にシステムを開発する多重下請け構造のうちの末端の企業は、大元の「発注元」企業との 直接コミュニケーションがとりづらく、中間業者を経由するため、コミュニケーションのスピードが遅くなる。
- 開発費用の面では前述の通り中間業者がマージンを引き抜くため、末端の企業はそれほど売上・利益にならない。悪条件の中で、直接システム開発に貢献しているわりには、投資対効果に見合わない。
- 企業と企業は契約で結ばれており、下請け企業となるほど労働環境がブラックになりやすい。末端企業がソフトウェアを開発しているならば、労働環境が悪い中で品質の良いソフトウェアは作れない。
- 前項と関連して、粗悪な製品・サービス・システムが世の中に流通し、誰も報われない。某金融機関におけるシステムトラブル多発により、経営体質が問われているニュースは有名だ。
- 中間業者は下請けに丸投げしているだけなので、労働環境が悪い下請け企業の苦労がわからない。システムが悪ければ下請けのせいにする。
- 大元の「発注元」は、高い金額でシステム開発を依頼している。それなのに粗悪なシステムが納品され、投資対効果に見合わない結果となる。
- 中間業者で本当に技術を身に着けたい社員にとっては、技術的な仕事を下請けに丸投げするため、自分たちのスキルが身につかない。これを理由に優秀な人材から見切りをつけて転職していくケースがある。
下記は、システム開発における中間業者の窓口社員が未熟かつ力関係が上と勘違いしており、下請け企業のエンジニアが迷惑を受けているパワハラの事例である。
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
o08usyu7231.hatenablog.com
３．企業間の協力関係が必要、あるいはメーカー企業でソフトウェアを作成することが必須
前述した中間業者は、システムの仕様はある程度わかるものの、ソフトウェア開発が難度の高いものであることがわからなかったり、マネジメントも未熟な割には給料もそこそこであり、下請け企業に対してはスケジュールの遵守を厳しく求めるなど圧力をもってのアプローチが目立つ。
一方で優良な中間業者、もしくはあるべき姿は次の２点のうちのいずれかである。
- 自社での開発に対応できない領域のスキルを持つ専門の業者に丸投げするなら高い開発費を支払う。
- 下請け業者に安い開発費を払って業務依頼するなら、自社でしっかりマネジメントし、結果に対する責任を持つ。
私の経験上、多重請負の階層が少ない場合や、メーカーの社員がソフトウェアを開発している場合は、前項以前に挙げた問題が起きにくいように感じる。ただ、部門ごとの力関係等存在し、要求元の方が立場が強いような状態であれば同じことが起きると言えるので問題発生がゼロであるとはいえない。いずれにしても、企業間同士、部門間同士がお互いに歩み寄り、協力関係が必要である。
これも私見であるが、メーカーでソフトウェア開発をすることは、ソフトウェアエンジニアのスキルアップにとって良いと思う。市場を知り、要求を知り、製品を知り、ソフトウェアを知る。また、多重請負と異なりシステム開発に関わる企業数が少なければコミュニケーションのスピードが早まりスムーズな開発となりやすい。企業対企業なら、契約関係が発生するから厄介である。
下請けに丸投げする中間業者をなくし、発注元と発注先が円滑にコミュニケーションが取れ、発注元と発注先ともに投資対効果に見合った結果となり、互いの労働環境が良くなるような状態になってほしいと願っている。
４．これからはソフトウェアが主流の時代、モノ・ハードウェア中心の時代は終わりだ！
歴史的な背景を考えると、日本は製造業が強く、経済の発展に貢献してきた。しかし、その成功体験から未だに抜け出せていないのである。完成品メーカーが上位の位置づけにあり、ITやソフトウェアは「業務効率化のツール程度」と軽視されてきている点が問題である。海外はこの逆である。ソフトウェアで様々な機能、サービスを実現している。ソフトウェアが事業の中核を成し、ポテンシャルの位置づけが高い。ここの違いである。日本は「ソフトウェア」開発を下請けに丸投げ、もしくはオフショアを活用することで、世界から遅れをとってしまった。企業の上層部がここに気づかなければいけない。
ソフトウェアが主流となっていくことを示す「ソフトウェア・ファースト」という言葉が最近浸透している。経営者や管理職のみならず、一般社員も一度下記書籍をお読みいただき、「ソフトウェア」の重要性を認識していただきたい。
「ソフトウェア・ファースト」とソフトウェアエンジニアの労働環境についての関連記事も紹介しておく。
o08usyu7231.hatenablog.com
ソフトウェア開発者に求められる内容は、以下の２パターンがあると考えている。
- ソフトウェア開発の上流工程へ踏み込み、開発を丸投げする中間業者の存在価値を無くす。ソフトウェア技術者の価値をアップし、受注の費用アップを交渉する。
- 丸投げをしてくる中間業者に上流工程の部分を教育・移管し、ソフトウェア設計に専念できる環境作りを行う。
上記２パターンのどちらも満足できない企業は、安い賃金で高いアウトプットを求められて、それに応えようとしているため、そのしわ寄せが従業員にのしかかるブラック企業の可能性が高い。
粗悪なソフトウェア企業や、システム開発を丸投げし圧力でコントロールするブラック企業を淘汰し、業界、国全体がスリムになるよう、優秀な人材は上位企業に転職してほしい。
一方、ソフトウェアが主流の時代になるなかで、企業側としては発注側・受注側ともに「ソフトウェア開発は下請けが当たり前」のような感覚は、一刻も早く捨て去り、健全な環境でソフトウェアエンジニアが活躍できるような環境づくりが求められる。
