COLMUN

コラム / IT化経営羅針盤

  1. TOP
  2. コラム / IT化経営羅針盤
  3. IT化経営羅針盤147 買う側も注意が必須! IT業界の多重下請構造

IT化経営羅針盤147 買う側も注意が必須! IT業界の多重下請構造

2022.06.27

買う側も注意が必須! IT業界の多重下請構造

USBメモリーを紛失した事件が世間を騒がせています。少し複雑な報道がなされているため「なんだかよくわからない」という声が身近なところで聞こえてきましたので、なるべく難しくならないように経緯と原因、実施すべき対応を説明してみます。

まず登場人物が多いのでいったん名前を定義します。

A:データを使った運用を委託する側、つまり客です。

B:Aから作業を一括受託した会社とします。(今回は謝罪会見した大手IT企業です)

C:Bから作業の一部を再委託された会社とします。(今回は全く報道されていません)

D:Cから作業の一部を再委託された会社とします。(Bは「社名を言うと人名まで特定できるので公開しないと言っています)

D1さん:今回メモリーを紛失したD社の社員です。

経緯ですが、D1さんがBの担当者の指示に基づいてUSBメモリーにAが管理するデータを保存し、それを管理状態なく単独で持ち出して屋外で紛失したことがことの発端です。警察も一緒になってメモリーを探し、結局発見できたのでいったんはよかったとは思います。メモリーの中のデータを誰も見ていないか検証する作業が残っていると思いますが、物理的には見つかったので、少し安心です。

さて、この事件になぜこんなに登場人物が多いのか?という疑問を持たれる方が多いと思います。今回の例では、BからCへ、CからDへ、と2回再受託契約がなされており、「B=元請け」とすると「C=下請け」、「D=孫請け」という呼び方になるでしょう。ITの仕事の場合、今回の様にAが大きな会社や組織だった場合はBはたいてい規模の大きなIT企業になります。入札やコンペを経て、様々な実績を加味された上で委託企業が決まりますので、実績のないスタートアップ企業などにはほぼ獲得チャンスがありません。ところが契約を獲得できたBは、とにかくコスト圧縮対策に走りますので・・・

仕様通りに単純なプログラムを作る

仕様通りにデータを加工する

仕様通りにデータを使って事務処理をする

など、あらかじめ作業の仕様を決めることができる単純作業については、安い単価で下請けに出すことを考えます。今回のケースもデータを使った事務作業との報道ですので、CはBから仕様通りの単純作業を下請けしたのだと思います。その仕事を得たCもBから散々コストをたたかれていますので、単純作業はさらに下請けに出したい。そこでDを孫請けとして仕事を再々委託したと思われます。

孫請けまで登場するということは、末端のDはBに比べるとはるかに低い作業単価で仕事をしなければなりません。ITの仕事では、再々委託の孫請けに出される仕事は本当に単価が低い、もしかすると地域の最低賃金レベルの単価で作業提供しないといけない場合が結構多いものです。非正規社員が多用される状況でもあります。いわば、「作業時間に対して付加価値をつけることができない業務領域」を担っているのがDの様な孫請けであり、そのような契約構造を作ってしまうのが「日本のIT業界の闇」と言われる問題です。この「闇」についてはいずれ別のコラムで解説することもあろうかと思いますが、本事件はDがきちんと管理状態を作ることができず、もしくは、管理方法を知らされていないままデータを持ち出してしまったことが一次的な原因です。本来であれば、Aは厳格で明確なルールをBに守らせ、BはCに対しそのルールを徹底し、CはDにそれと同等のルールを徹底し、ということを多重的に実施しなければならなかったのに、そもそもAがBに対してあまり厳格でないあいまいなルールを示してしまったがために、Dまでたどり着く間に管理方法が曖昧になってしまったのでしょう。

この事件については詳細が調査されている最中ですので、これ以上の推察は控えますが、これを「IT作業を委託するAの教訓」としてどのように理解すればよいか考えましょう。

まずAは、BだけでなくCやDの存在をきちんと把握するべきです。今回どのように把握していたか公開されていませんので断定はできませんが、AとBの間の契約では「再委託は原則禁止」すべきです。Bがどうしても再委託したくなる場合もあるでしょう。その場合には「再委託する場合は再委託する業務と作業内容を明確に定義したうえで、事前にAの承認を得る。再委託先がさらに再委託する場合にも同様の手続きを経てAの承認を得るもの」と契約で定めます。これによって、多重下請け構造が発生した場合もどの会社がどのように関係しているのかAは把握することが可能となります。

次に、CやDの作業をBが監督し、Aもそれを監督できるように、B~Dの機密情報を使うすべての作業を計画化させ、Bから提出させます。それをAは作業監督できるようにし、Bにもそれに対応するように計画段階で指示します。「作業担当はD1さん、その監督はDの誰、Cの誰、Bの誰、Aの誰」という形で担当者名を管理状態におけるように計画します。このように言うのは簡単ですが、Bから見るとこれは非常に煩雑で自分達にも現場で監督する負担が発生しますので割高になってしまいます。Bにとってはとても嫌なことですが、それぐらいでちょうどよいのです。Bから安易に再委託されないよう、牽制する効果も高いはずですし、何よりも作業の管理監督体制を明確化することで責任の所在も明確になります。今回のような事件も防止できたことでしょう。

このような対策はAにとっても煩雑で、委託単価が上がってしまう要因にもなり得ます。それを防止するため「機密事項とは?それを使う作業とは?」を明確化し、そうでない作業と分類して切り分けることでコストアップ要因もある程度は避けることができます。Aの立場の会社にとって、Bのような会社に「丸投げ」するのは楽だと思いますが、その現場構造を放置したままではどうしても曖昧な状態が発生し、管理体制もきちんとできないものです。今回の事件はAに対する大きな課題を示したと思いますし、ご紹介したような多重下請け構造を緩い管理で使うととんでもないことが発生するのだ、ということを如実に示す教訓だったと思います。

無料メール講座登録

経営者様向けのIT化ヒントが詰まった無料メール講座や代表コラム「IT化経営羅針盤」、各種ご案内をお届けします。

お名前
Mail

資料請求

パンフレット、コンサルに関する資料のご請求は下記フォームからお願いします。

資料請求フォーム

CONTACT

お問い合わせ

お問い合わせフォーム

(TEL: 050-8892-1040)

Page Top