松田 幸裕 記
建設業界でよく話題になるゼネコン問題。豊洲市場、東京オリンピック会場の話題の裏にも、常にゼネコン問題がささやかれています。大手の業者（＝ゼネコン）がすべてを一括して請け負い、実際の作業を下請け、孫請けに安く出して利益を得ます。
この多重下請け構造は、ITの世界にも同様に存在します。
ただ、最近は「多重下請け構造 ゼネコン」などでWebを検索すると、ヒットするのはほとんどが建設業界ではなくIT業界でのトピックになってきています。建設業界でのゼネコン問題はどちらかというと「落札率」「談合」「天下り」などのキーワードに関連する話が多いですが、IT業界の問題はその先の下請け構造に着目されることが多く、ITに携わる人々への影響が大きいためかもしれません。
本投稿では、ITの多重下請け構造の問題、原因、解決の糸口などに触れていきたいと思います。
ITでの多重下請け構造は、主にSIビジネスにおいて見られます。大手ITベンダーが公共機関やユーザー企業からSI案件を受注し、そのSI業務の一部または大部分を中規模のITベンダーへ再委託します。そして委託されたITベンダーはそれを更に小規模ITベンダーに委託します。
ちなみに、「SIビジネスにおいて見られる」と書きましたが、ITコンサルの世界にも同様に存在します。ただ、悪影響が大きく問題として根深いのはどちらかというとSIビジネスであるため、本投稿ではSIビジネスをイメージして書きたいと思います。
多重下請け構造がなぜいけないのでしょうか？まずは多重下請け構造が引き起こす問題について触れます。
＜中間搾取による問題＞
中間に位置する企業が多ければ多いほど、企業のマージンによって最終成果物であるシステムの価格は上昇します。また、末端の業者に入る額は減少します。このことは、発注者であるユーザー企業としては「高い買い物になる」という問題を引き起こし、末端の業者としては「大変な割に実入りが少ない」という問題を引き起こします。
末端で頑張っている技術者、開発者の給与は安いままで、プログラミングは「IT土方」「デジタル土方」などと言われるくらいです。人手不足、資金不足、長時間労働などの劣悪な環境下で開発するため、システムの品質低下も懸念されます。
本来、プログラミングは最終成果物であるシステムの良し悪しを決定する重要な要素です。優秀なプログラマーは一般の数倍、場合によっては数十倍のパフォーマンスを発揮し、短い時間で多くのアプリケーションを開発することができます。しかも成果物の品質が良いため、テストなど後工程での工数削減、後戻りの減少などにもつながり、全体のコスト削減にも大きく寄与します。それなのに、「プログラマーは人月50万円」のように一律で決められてしまうような、不思議な世界になってしまっています。ITインフラ構築やパッケージ導入作業なども、プログラミングの世界ほどではありませんが同様の問題を抱えています。
＜役割の分離による問題＞
大手ITベンダーの社員は単価（≒給料）が高いため、SIにおけるすべての工程を自分たちで行ってしまうと、赤字になってしまいます。そのため、赤字を出さないためにも多くの工程を下請けに出さざるを得ません。よって、大手ITベンダーではプログラミングを経験できるとしても新卒入社直後の一時期のみで、多くはプログラミングを知らずに要件定義や設計を行うことになります。
一方、多重下請け構造では、実際にコーディングをする末端業者の技術者はユーザーを見たことがないというパターンも多いです。
このように、大規模システムは「技術を知らない設計者による上流設計」と「ユーザーを知らない技術者による開発」で成り立ってしまっているのです。
問題点を書くだけでずいぶん長くなってしまいましたが、多重下請け構造には問題が多く、ITがより社会に寄与するためにはこの構造を壊していかないといけません。しかし、簡単に壊せるものでないという現実もあります。
次回以降では、このような構造が生まれてしまう原因について深掘りし、解決策を探っていきたいと思います。