IT業界の下請け構造を知る：情報系学生のためのIT業界入門（5）（1/2 ページ）

就職活動を行ううえで欠かせない「業界研究」。学生にとっては非常に分かりづらいIT業界について、新人社員の行貝くん、色主さんと一緒に学んでいこう。

[イノウ，＠IT]

今日の講義は、少々ショッキングなタイトルですが、IT企業の「下請け構造」についてです。色主さんは、下請けについてどんな印象をお持ちですか。

行貝知蔵（ぎょうかい しるぞう）

ABCソフトウェアサービスの新入社員。何にでも興味を持って前向きに知識を吸収するが、おっちょこちょいで早とちりな一面も。先輩にかわいがられる愛すべきキャラクター。22歳。

色主識代（しょくしゅ しるよ）

ABCソフトウェアサービスの新入社員。真面目で業界研究をしっかりやるタイプ。もともとは別業界を志望していたが、ABCソフトウェアサービスの会社説明会に参加したことをきっかけに入社。22歳。

冠里邦彦（かんり くにひこ）

ABCソフトウェアサービスのプロジェクトマネージャ。国立大学理学部卒。駄洒落好きで気のいいオジさんだが、仕事には厳しい。いまだに自分でもコードを書く。お洒落を自認し、いつもベストを着用している。44歳。

ええと、……ううん……あんまり良い印象はありません。

はっきりしませんね。行貝くんはどうです？

ブラック企業の温床というか、正直に言うとネガティブなイメージです。でも、うちの会社も、大手システム開発会社の下請け業務は、日常的に行っているのですよね。

はい、そうですよ。皆さんが下請けという言葉に悪いイメージを持っていることは認識していますが、下請けがすべてダメなわけではありません。日本企業として世界で最も成功している企業の1つであるトヨタだって、デンソーやアイシン精機といった下請け企業の存在なくしては、あの高品質な自動車を生み出すことはできないわけですし、必ずしも「下請け＝悪」ではないのです。必要に応じて外部の力を借りるのはある意味、当たり前のことです。Webサービスの事業者だって、新しいサービスを生み出す際、われわれシステム開発会社の力を借りることだってありますからね。

じゃあなぜ、下請けにネガティブなイメージがつきまとうのですか。

下請けで多くの場合、問題になっているのは、「元請けが何もせず、下請けに仕事を丸投げすること」「下請け自身が何の強みも持たず、元請けからの仕事に依存していること」、そして「それが、労働生産性を大きく下げ、労働環境を悪化させていること」です。

でもなぜ、わざわざ外部の会社を使うのですか。元請けが、取ってきた仕事を自社のリソースでやればいいような気がするのですけど……。

それには、2つの理由があります。1つは、システム開発の仕事のほとんどがプロジェクト型の業務であることです。

　プロジェクト型の業務では通常、プロジェクトの稼働状況や時期に応じて、必要とされるスタッフの数やスキルが変わります。そのため、元請け会社は状況に応じて、外部の会社から必要なスタッフを調達した方が固定費を下げられますし、下請け会社は、自社の社員が持つスキルを、それが求められるプロジェクトで有効に生かせます。建設・土木業界でも、同様の理由から元請け会社が必要なスキルに応じて、下請け会社をアサインしています。

要は、きちんと強みを持って、対等な関係で仕事ができれば、下請けの仕事が悪いというわけではないということですね。

そのとおりです！ それに、元請け会社ばかりが、必ずしも利益を得ているわけではありません。前回もお話ししたように、一般にユーザー企業（発注した企業）と元請け会社（受注した会社）との契約は「一括請負契約」なので、最初に見積もった金額で基本的にすべての要件を満たしたシステムを開発しなくてはなりません。しかし、実際のプロジェクトでは、要件定義で洗い出せなかった要件が発生したり、トラブルが起こったりします。そのような場合、たとえ採算が合わない状態になっても、元請け会社はシステムを完成させる責任があります。いわゆる「赤字プロジェクト」ですね。

　そしてこれこそが、IT業界に下請け構造が必要とされる、もう1つの理由なのです。つまり、元請け会社は、一括請負契約でリスクを取る代わりに、比較的高い利益を乗せた金額をユーザー企業に請求します。

　一方、そのようなリスクを取れない下請け企業は、元請け企業と「時間契約」を結んで、通常、「人月単価」ベースで元請け企業に料金を請求します。まあ、元請け企業の仕事に人員をアサインしておけば取りあえず売り上げが上がるという状況が、「従業員のケアをしない下請け企業＝ブラック企業」が生まれる土壌を作り出しているのですけれど。

	一括請負契約	時間契約
契約者	ユーザー企業／元請け企業	元請け企業／下請け企業
支払い形態	基本的に契約時の見積もりに基づいての支払い	基本的に業務従事日数（人月）に基づいての支払い
リスク	一般的に高い	低い
利益率	トラブルが起こらなければ高い	一般的にそれほど高くない
表1　一括請負契約と時間契約

でも、受託システム開発の仕事をやる以上、やっぱり元請けとしてお客さんと話しながら、作り上げていきたいですね。大手企業の基幹システムは無理だとしても、その会社の業務をきちんと支えるものができて喜んでもらえたら、僕らもやりがいありますし。

うちみたいな中堅システム開発会社の場合、相手が中堅・中小企業なら元請けになることも多いけど、お客さんが大手だと2次請けの仕事がほとんどですからね。そもそも、大手企業の基幹システムには新規案件がほとんどないから、メーカー系の独壇場になっていますし。ただ最近は、グローバル化の波を受けて大手企業同士の合併が進んでいるから、メーカー系も合併後のシステム統合で、自社のシステムが切られないか、ひやひやしているみたいですよ。

そういう場合、技術的に優れたシステムが採用されるのですか。

ううむ、残念ながらそうともいえないみたいで、政治的な要素で決まることも多いようです。通常のプロジェクトでは、われわれシステム開発会社がメインで付き合うのは、ユーザー企業の情報システム部門やシステム子会社の人たちですが、こういう大きな案件になると、経営トップ同士の話し合いで決まることがほとんどですから。

でも、この間アサインされたプロジェクトでは、経営企画部門の人が中心になって要件を取りまとめていましたけど。

いい指摘です、行貝くん。実は最近、開発するシステムの種類によって、発注側の中心メンバーも、開発メンバーとして関わるようになっているのです。下の図を見てください。

図1　システムの種類によって異なる発注側と受注側の中心メンバー （クリックで拡大します）

以前は、一定規模以上のシステムであれば、情報システム部門やシステム子会社がシステム開発会社に仕事を発注し、小規模なシステムであれば、業務部門が直接、システム開発会社に仕事を発注するケースがほとんどでした。ところが、ユーザー企業にさまざまなシステムが導入され、さまざまなユーザーがシステムを使うようになると、システムの種類によって、発注側の中心メンバーが変わるようになりました。