読者です 読者をやめる 読者になる 読者になる

エンジニアの「学び方」「働き方」 ときどきクラウド♪

■FACEBOOKもやってます! https://www.facebook.com/masahito.tomimoto

SI業界の多重下請構造は問題なの? ①

ITインフラ業界

 

SI業界は、ことあるごとに「多重下請構造」を批判的に論じられていますが、一体何が問題で、どうあるべきなのか?について自分なりの意見を纏めてみました。

最初に今の構造の問題点を洗い出し、その後にその原因について考察してみたいと思います。

 

■問題点

仮に日本にいる全てのエンジニアが200人だとし、大手2社に50人ずつ、その他10社に10人ずつ所属する【下請け構造】をモデルに考えてみます。


 

【下請構造】
[大手A
社]-50人
 ┗[下請けA社]ー10人
   ┗[孫請けA社]ー10人
  ・
  ・

[大手B社]-50人

 ┗[下請けB社]ー10人
   ┗[孫請けB社]ー10人
  ・
  ・

 

①健康保護の問題
通常、所属会社の違うエンジニアが集ってプロジェクトチームが出来ます。その状態では往々にして会社を跨いだ指示命令系統が出来る。つまり、[大手A社]のPMが、[下請けA社]のエンジニアに直接指示命令するケースがあるが、これは法令違反です。(労働基準法

エンジニアの健康保護の責任はその所属会社にあるので、勤務時間と切っては切り離せない指示命令は所属会社の上司がするものです。
しかしながらプロジェクトの現場では実質不可能に近い。

つまり、労働者の健康保護を目的とした機能が不完全になることがあるということです。

 

②間接業務の増幅
単純に会社数が増えれば、間接要素(オフィス、税務・会計、システム、エンジニア以外の人件費...)も増える。会社の数が少なければ少ないほど統合メリットが出て効率は良いと言えると思う。

③不当な利益
通常、報酬(売上)は価値に見合っているべきだと思いますが、例えば、[大手A社]の仕事を[下請けA社]が受注し[孫請けA社]のエンジニアが作業するようなケースがある。
この場合
[下請けA社]が問題となる。ただ、[下請けA社]は価値を生み出していないというのは言い過ぎで、[孫請けA社]より営業工数を掛けて営業しているから[孫請けA社]には取れない仕事が受注できたともいえると思う。また[下請けA社]は契約上のリスクも負っている。しかし直接的な業務といえば伝票を起こしているだけに過ぎない。この位置の会社がマージン取り過ぎということが往々にして起こっているように感じる。

 

④人材マネジメント不全
例えば[孫請けB社]のエンジニアが、現場で困っているとしよう、現場で相談出来るよ内容であれば問題ないのですが、中には[大手B社]のプロマネからのパワハラ、不明確な指示など直接言えない内容で困ることも多くある。通常は所属会社の営業が問題の種を早期発見し未然に沈静化する。しかし下請け構造が多重で複雑になると、時間がかかったり、話しの要旨が伝わらなかったりでコミュニケーション不全に陥り問題が悪化することがある。突然「やってられませーん!」と言って離反するメンバーが出ることも。。

 

⑤価格から抱く期待とのズレ
[ユーザー企業]→[大手B社]→[下請けB社]→[孫請けB社]→[ひ孫請けB社]のような多重構造を想像してほしい。それぞれの会社が20%の粗利をとると[ひ孫請けB社]へは50万しか入ってこない。もちろん[ひ孫請けB社]も粗利をとるため全額エンジニアには渡らない。[ユーザー企業]は100万の価値を期待する。しかし実際には[孫請けB社]は50万そこそこの価値しか提供できない。といった構図が出来あがりしばしば顧客不満足につながることがある。

 

 私が感じる問題点は以上となります。

次は、「何故こんな構造になっているのか?」について考察してみたいと思います(^^)/


※何かお気付きの点やご意見など御座いましたらコメント頂けると幸いです。
(メールでも結構です! masahito.tomimoto@gmail.com)

 

また、宣伝になっちゃいますが、
2014年6月よりIT系無料勉強会を開催しております。
開催した勉強会は、無料動画として配信し「時間」「場所」に制限されず学べるようにしたいと思っています。

 

以下のページの「申し込む」ボタンから、当Communityのイベント案内メールが配信されるようになります。

~ITエンジニア勉強会~ engineer'sLearning・Vesper | Doorkeeper

是非、ご登録を(^^)/

 

 

 

 

 

にほんブログ村 IT技術ブログ ネットワーク・SEへ
にほんブログ村