社内SE

社内SEから見たIT業界の多重請負構造。誰にどんなインセンティブが働いている?

IT業界に携わっている方にとって多重請負構造はよく聞く言葉だと思います。

僕は社内SEになったとき、この多重請負構造なる存在を理解しておらず、その独特な文化に面を食らうことになりました。。。

参考 : 「Re:ゼロから始める社内SE生活」#01 丸投げ、多重請負との出会い

社内SEの経験を積むにつれて、多重請負構造の力学が見えてきてから分かったことがたくさんあります。

システム開発が失敗する原因、ものすごいお金をかけて作ったシステムを誰も使っていない原因、そしてデスマーチが多発する原因、それらのひとつは多重請負構造にあると感じます。

この記事では、社内SEの視点から、多重請負構造の中で何が起こっているかについて考えてみます。

ユーザー企業の組織構造

まず、ユーザー企業、すなわち、実際に開発したシステムを使う企業側の組織構造を考えてみます。

社内システム部門はコストセンター

ユーザー企業のシステムに関係する部署として、「事業・業務部門」および「社内システム部門の2つの部門があります。他にも経営層、総務部門、人事部門、調達部門などもありますが、単純化のため省略します。

事業・業務部門とは、たとえば、企画部門・製造部門・営業部門などです。ちなみに、これら事業・業務部門をLOB部門(Line Of Business)と呼ぶことがあります。LOBといっても、データベースのラージ・オブジェクト型のことではありません。デカくて扱いづらいのは同じです。

ユーザー企業の利益の源泉は、業務部門のオペレーションになります。企画部門がビジネスモデルを練り上げ、製造部門が商品を作り、営業部門が商品を売りさばいているからこそ企業が成り立っています。このような利益をあげる組織のことを「プロフィットセンター」と呼びます。売れない商品を作っている製造部門は例外です。

プロフィットセンターの業務プロセスを効果的にまわすためには仕組みが必要になります。企画部門が市場分析をするためには売上傾向を調べる仕組みが必要ですし、製造部門が商品を作るためには物流管理の仕組みが必要ですし、営業部門が商品を売るためには顧客情報を知る仕組みが必要になります。

これら仕組みを担うシステムを構築しているのが、社内システム部門になります。また、社内システム部門で仕事をしている方々を、通称、社内SEと呼びます。

基本的に、社内システム部門が利益を生むことはありません。むしろ仕事をすればするほどコストが増え、利益を圧迫することになります。このような利益をさげる組織のことを「コストセンター」と呼びます。邪魔だけど必要、そんな存在でしょうか。

コストセンターは立場が低い

では、ユーザー企業では、どういった力学が働くのでしょうか。

まあ簡単です。社内の立場が、

LOB(プロフィットセンター) >>> 社内システム部門(コストセンター)

となります。

つまり、

「お前らの食い扶持を支えているのは俺らだ」
「システム部門ごときが、なに文句を垂れてるんだ?」

ということですね。天は人の上に人を造らず人の下に人を造らずと言いますが、企業は稼いでなんぼなわけなので、当然のことながら、コストセンターの立場は低いです。CIO(Chief Information Officer : 最高情報責任者)から、CEO(Chief Executive Officer : 最高経営責任者)になった方は明らかに少ないと思います。

相対的に立場が低い社内システム部門ですが、困ったことに彼らには技術力がないので、システム構築を外注(丸投げ)することになります。なぜ技術力が無いかについては、「なぜシステム開発を丸投げするのか?」を参照いただければと思います。

SIerおよび下請け会社の組織構造

次に、社内システム部門からの丸投げ先。システム・インテグレーター、通称「SIer」の構造を考えてみます。

丸投げ先であるSIerは、システム構築で利益を上げている企業ですので、技術部署がプロフィットセンターとなります。したがって、もちろん、世界有数の、誰もが理想とする、半端じゃない技術力があるわけです。代表的な企業として、〇〇データとか、〇BMとか、〇士通などの大企業があります。

そんなスゴいSIerですが、実はSIerが自分自身でシステムを開発することは稀です。技術力があるのに開発しないのはなぜなんだろう?と疑問に思うかもしれません。

なぜ自分自身で開発しないかといえば、案件の受注量が一定ではないからです。

例えば、

  • 2010年分の開発案件には、500人必要だった
  • 2013年分の開発案件には、300人必要だった

とすると、2010年には社員を500人以上雇わなければなりません。しかし、2013年には200人が余ることになります。企業としては200人をクビにしたいところですが、日本は解雇規制が強いので、簡単にはクビにできません。もちろん仕事がなかったとしても給与を払わなければならないので、経営が立ち行かなくなります。

そこでどうするかといえば、案件の受注量に応じて子会社に協力をお願いするわけです。そうすると、

  • 2010年は、SIer 10人 + 下請け会社 490人 (計500人)
  • 2013年は、SIer 10人 + 下請け会社 290人 (計300人)

となり、SIer自身は案件の受注量に関わらず、社員をクビにしなくて済みます。

実務的には、少人数で行った方が効率が良い「要件定義、設計、プロジェクト・マネジメント」などをSIerが実施し、大人数で行った方が効率が良い「コーディング、テスト」などを子会社が担うことになります。これら実務を全て子会社が行って、SIerはピンハネするだけのこともあります。

なるほど、うまいことを考えるな。と思いますが物事はもう少し複雑です。

子会社に任せれば余剰人員を抱えるリスクを負わなくていいというのは、なにもSIerだけではなく子会社も同様です。子会社であっても当然のことながら簡単には社員をクビにすることはできません。

するとどうなるかといえば、子会社は孫会社に対して協力を依頼する、孫会社はひ孫会社に協力をお願いする、そしてひ孫会社は、、、と、どんどん多重でピンハネが進んでいくことになります。

つまり、日本独特の「職能型採用」によりユーザ企業は開発を丸投げし、丸投げされたSIerは日本独特の「解雇規制」によりさらなる下請け企業に丸投げする。その結果、多重請負構造が生まれます。

多重請負構造の問題点は多数あります。たとえば、

  • 多重になればなるほど、コミュニケーションロスが大きくなる
  • 多重になればなるほど、マネジメントの手間が増える
  • 多重になればなるほど、ピンハネが大きくなり下請けの給与が安くなる

など。色々問題があるなら無くせばいいじゃん、とは思いますが、根本原因が「職能型採用」と「解雇規制」ですので、どうしようもないです。SES契約というやり方もあるのですが、このあたりはまた別途考えたいと思います。

社内システム部門とSIerとの力学

IT業界の全体構造が見えたところで、この構造からどういった力学が働いているのか、を考えてみようと思います。

LOBは本業が忙しいので協力しない

ユーザー企業の中でシステム企画が立ち上がると、「〇〇システム導入プロジェクト」が立ち上がります。プロジェクト開始時点で基本的に次のことが決まっています。

  • 導入目的 : ○○という課題があり、解決のために○○を導入する
  • 実現イメージ : 導入後の絵
  • 検討体制 : 関連LOB部門と社内システム部門
  • スケジュール : なぜかローンチ時期が決まっている

何を作るかわからないのにローンチ時期が決まっているのも奇妙な感じですが、これは深い話になるので別エントリでお話したいと思います。まずはこの時点ですでにローンチ時期が決まっているものだと思っていただければと思います。

その後、LOB部門と社内システム部門でざっくりとしたイメージを固め、予算を取り、発注に向かうのですが、ここでユーザー企業の力学が働きます。

「プロフィットセンターである俺は本業が忙しい」
「システム導入はコストセンターである社内システム部門の仕事だ」

この背景にはどうしても業務を変えたくないというLOB側の都合もあるのですが、システム開発と名前がついた以上、社内システム部署の仕事の扱いになるわけです。

社内システム部門は失敗しなければ良いと考える

その後、社内システム部門がメインとなってシステム導入を進めていくなかで、ある問題がでてきます。それは、社内システム部門は、プロジェクトの成功を望んでいるのではなく、システム開発で成功すれば良いと考えていることです。

プロジェクトの成功とシステム開発の成功は異なります。

  • プロジェクトの成功 = 目的の達成、○○課題の解決
  • システム開発の成功 = QCDの達成
QCDとは、製品を作るときに重視される、Quality : 品質、Cost : コスト、Delivery : 納期の頭文字を取ったものです。

これはよく混同されることがあるのですが、たとえば、500メートル先のコンビニに行くことを効率化したいが課題だったのに、世界最高速のF1マシンを作っても仕方がありません。自転車で十分です。

この混同は、実際のシステム開発でもよくあります。LOBの要求をすべて盛り込んだゴージャスなシステムを開発するものの、実際には利用されてないなんてことは日常茶飯事です。

なぜこんなことになるのかというと、僕は社内システム部門のインセンティブが、加点方式ではなく、減点方式であるためだと考えています。

プロフィットセンターは効率化すればするほど給与が上がりますが、コストセンターは効率化しても給与は上がりません。コストセンターはQCDを満足すること、すなわち、不具合がなく・予算内で・納期通りにF1マシンを作ると給与が上がります。

SIerも失敗しなければ良いと考える

SIerも社内SEと同じですね。ユーザー企業が儲かっても給与は上がりませんが、QCDを満足するシステムを作れば給与が上がります。それがコンビニにいくために使うF1マシンかどうかは関係ありません。

社内システム部門と大きく違うところは、社内システム部門は基本的に1つですが、SIerは複数社あるということです。ユーザー企業の伝家の宝刀、「じゃあ他のところにお願いしますね」を食らってしまったら、昇給どころの話ではなく、良くて現状維持になるでしょう。

F1マシンではなく自転車を作ろう

本来なら同じゴールを持って、楽しい仕事ができればいいのだと思うのですが、多重請負構造の中では、さまざまな立場の方がさまざまな意図で動いています。この業界構造や力学を押さえておくと、F1マシンではなく、自転車を作るだけで良くなるかもしれません。

おわり。