IT業界の仕事が辛い理由「多重請負構造」

Tweet

Pocket

請負構造の問題がエンジニアを苦しめる

システム開発の受注は、二次請け三次請けにまで及ぶ多重請負構造になっていることが多いものです。そして、この構造が末端のエンジニア達の仕事を辛いものにします。IT業界の仕事がキツイと思われる理由はいくつかありますが、請負構造のどこの位置に属するかで仕事のキツさが異なってくるでしょう。

多重請負は難易度の高い伝言ゲーム

クライアントと元請け企業は、システム開発の受注にあたって具体的な話を直接行いますよね。だからこそお互いの意思疎通がしっかりとできているわけで、途中で仕様変更の必要が生じたとしても、クライアントに直接確認をすれば認識の誤差は出にくいはずです。
ところが、これが二次請け三次請けとなると、エンドユーザーから直接話を聞く機会はほとんどなく、受注内容は伝言ゲームのように伝えられます。設計書を見れば最後まで問題なくプログラムを組めることなどまずなく、不明点や疑問点などをその都度確認しなければなりません。わからないことを直接エンドユーザーから聞ければ一番いいのですが、二次受けなら一次受け、一次受けなら元請けに確認を取ることになるため、質問に答える側が質問されたことの意図をしっかりと理解していないと、的外れな回答になりかねません。単語をやりとりする伝言ゲームなら簡単なことですが、システム開発についての複雑な内容を伝言ゲームで正しく伝えるのは至難の技。最悪の場合、間違った情報のままで開発が進んでしまい、完成してからトラブルに発展してしまう可能性もあるのです。

中間業者に専門知識がないとさらに困った事態に

多重請負構造の場合、最終的にプログラムを組むのは最後の業者です。そのため、中間業者はやろうと思えば案件の丸投げもできますし、実際にやっているところもあります。中間業者の担当者が専門知識を持っていない場合、下請け業者は仕様に関する正確な情報が入りにくいというリスクを背負うことになるかもしれません。中間業者は下請けに仕事を流すだけでマージンが発生し、実際に作業をする下請け業者の苦労が多くて取り分は少なくなるというのは理不尽な感じがしますが、これこそが多重請負構造なのです。

末端業者は苦しい立場

IT業界だけに限った話ではありませんが、多重請負構造の末端にいる業者の立場は弱くて苦しいものです。元請けをはじめとする先端のほうは、仕様やスケジュールを急に変更することがよくあります。それだけならまだしも、伝達がしっかりできず末端が振り回されてしまうなら、肝心の成果に大きく響いてしまいます。いいものをしっかり作りたいと考えているエンジニアは、多重請負構造のどこに位置する企業なのかどうかも見極める必要があるかもしれませんね。