このエントリーをはてなブックマークに追加LINEで送る

2.3. 中間搾取でボロもうけ

ハッピィ・エンジニアリング表紙

 ハイテク産業という言葉の後に「IT産業」なる横文字まで出てきた。コラム「業界のレベルダウンを検証する」に記述したように、ITビジネスというのは、インターネットや電話などの通信の仕組みを利用したコンテンツビジネスと、企業買収により収益を生むビジネスモデルをさしているようである。

 

 残念ながら、システム業界は土木や建築の職人に似た仕事であって、ハイテクでもなければ日本で一般にIT産業と呼ばれるものとは実態が異なる。土木や建築の職人との相違点は、肉体を駆使しないゆえに、直接的に肉体的な危険を伴う可能性が低いというだけのことである。しかし、過度な残業や精神的負担により、肉体・精神に支障をきたす人は多い。例として土木や建築を挙げたが、それらの業界に代表されるような搾取構造もシステム業界がしっかりと継承しているところが興味深い。

 

 通常、大手企業は発注先の会社を固定するのが普通であり、今までに取引のなかった会社が新規に取引を開始するのは、業務によほどの特殊性を持たない限りは非常に大変なことである。特に元請けとなるような大手SIベンダや大手メーカーでは、親会社の名前を社名に冠するような子会社が発注先となるケースが多い。そのほかに多いのが中堅の開発会社や大手の人材派遣会社である。

 

 仕事には波がある。システムの運用開始を年始や年度初めに置くような場合が多いので、夏から春先までは人の動きが少なくなり自社のエンジニアすべての仕事が埋まっているケースがある。時折発生する大規模プロジェクトに全員を投入してしまうと資金繰りの面で問題が起きるケースもある。このような、自社のメンバだけで開発を受注できない場合に、プロジェクトのメンバとしての業務を協力会社に委託することになる。

 

 あるいは、専門性と難易度が高い仕事の場合、最初から専門の業者に委託したいこともある。このようなときも発注元となる元請け企業は、発注先として決められているどこかの会社を通して発注する場合が多い。

 

 上述したような協力会社を使うまともなケースを考えれば、せいぜい二次下請けあたりで止まるのが普通に見えるが、システム開発業界では、最初からピンハネ目的で、下請け構造はネズミ講のごとく連鎖を繰り返すのである。「人件費商売」は、それほどたくさんの元手を必要とせずに起業できるため、零細企業はゴマンとあり、下請けを集めるのはそれほど苦労しない。それと同時に、連鎖する下請け構造から逃れるために安易に会社規模の拡大に走るのが、下請け企業の一般的な姿である。

 

 ユーザ企業が元請けに発注する金額は千差万別である。元請けは、その会社の予算や体質を見て、「取れる金額で」受注するからである。見積金額の提示の仕方はケース・バイ・ケースであり、すべてを人件費として組み込んでいないケースが多いが、エンジニア1名に支払われる金額の2〜3倍が提示されていることが多い。

 

 元請けは、だいたい周辺の価格と合わせて相場で一次下請けに仕事を依頼する。現在注10は少々金額が下落しているが、コンサルタントで160万〜200万円、SEで100万〜140万円、プログラマで70万〜90万円程度が無難な相場であろう。ただし、これも受注金額からすでにほかのプロジェクトの赤字分を埋め合わせているような場合には、さらに上乗せした金額となるケースもないとはいえない。

 

 ここから先が大きなピンハネ構造の始まりである。下請けに、下請けにと伝票が連鎖する間に、それぞれの間で、また企業間の力関係により10〜30%程度が搾取されていく。表向きは開発会社のようで、実質は案件の取り次ぎだけをしているブローカも多数存在する。このような連鎖により、支払いサイトが徐々に長くなり、最悪のケースではSE単価が50万円(その上、サービス残業となり下請けには50万円以上支払われない場合がある)、支払いサイトが90〜120日という状況にまで下回るのである。

 

 四次下請けが受注した場合、一次下請けから三次下請けまでは発注書類が流れただけで数万〜十数万円が何もせずに懐に入るということになる。それでも、一次下請けが開発に関して責任を持つだけのプライドを持ってさえいれば、開発チームのリーダをアサインしてプロジェクトを率いることになる。しかし、一次下請けのメンバが一人もおらず、二次下請け以下のメンバのみが在籍するプロジェクトはあまりにも多い。

 

 それ以前の問題として、発注側自体がこの下請けの連鎖に疑問を持たなくなってきている。元請けの力のなさは十二分に理解しているが、それでも名の通った大手に発注する。

 

 そこにはユーザ企業の発注担当者の「最後には、なんとかシステムを動かしてくれるだろう」という甘えがある。事実、火のついたプロジェクトには元請けが企業としてのプライドをかけて内部・外部の腕の立つメンバを集中投入することは珍しくない。資本とコネクションがある会社のみが可能な芸当である。

 

 元請けにすら納品物の整理以外に何もしていないプロジェクトが時として存在することを思えば、一次下請けがプロジェクトに参加していないことなど、大した問題ではないのだろう。結局、ここにも元請けと一次下請けの甘えと癒着の構造が存在するのである。

 

運命からの脱却

 本節の問題も、本質は甘えと癒着の構造である。ユーザ企業と元請け、元請けと一次下請け、さらに一次下請けと二次下請け……。このように甘えと癒着の構造が連鎖していく。

 

 ユーザ企業が調達の立場として、延々と続く搾取の連鎖構造に問題を感じるのであれば、ユーザ企業のシステム担当者は、この連鎖の構造を許容せず、甘える姿勢を取らないことが必要である。さらに、開発会社の力量を客観的に評価する基準を持たなければならない。

 

 下請けの開発会社は、プロジェクトを完遂できる能力を磨くだけのことである。最初に手がけなければならないことは、QCD(高い品質:Quality、低いコスト:Cost、早い納期:Delivery)の向上であろう。QCD向上のために行うべきこととして、以下が考えられる。

 

  1. 作業プロセスの確立
  2. 作業プロセスを徹底するための教育体系の整理
  3. 教育の実施
  4. プロジェクトの事後検証
  5. 作業プロセスの改善

 

 QCDはそれぞれが相反する要素だと考えられているが、実はおのおのの関連性は非常に強いものである。各工程での成果物品質を高く保った状態にしておくことで手戻りがなくなり、結果的に生産性が向上する。そのため、人件費がコストに大きく影響するシステム開発においては、最終的なコストを抑えることができるのである。

 

 手戻りをなくすには、システムへの要求が明確になっていることのほかに、技術者のプロジェクトにおける役割を明確にし、各作業にスムーズに入っていくことが重要である。すなわち、作業プロセスの確立が必要なのである。

 

 しかし、作業プロセスを確立しただけでは不十分である。プロジェクトには、さまざまな役割を持ち、バックグラウンドの違うプロジェクトメンバが参加することになる。そのため、作業プロセスに対する正しい認識を持ち、作業プロセス自体をプロジェクトの共通言語としなければならない。それには、作業プロセスを徹底するための教育体系が必要になる。

 

 そのうえで、プロジェクトメンバに作業プロセスを徹底するには、教育が必要となってくる。メンバそれぞれが作業プロセスに対する十分な理解を持って作業にあたらなければ、その効果は期待できない。

 

 作業プロセスをさらに効果的なものとするには、プロジェクトの事後検証が必要である。問題が発生せずに終了するプロジェクトはない。なんらかの問題が発生した場合においては、個人的なスキルや注意力に責任を帰着させてしまうプロジェクトは多い。だが、単に技術者のスキルの問題にとどめず、作業プロセスの改善によってチェック機能を持つことができなかったのか、ほかに優れた解決策がなかったのかを検証し、将来のプロジェクトではより優れた作業プロセスとするための改善活動が必要となる。

 

 このほかにも、今までと同様にさまざまなアーキテクチャや言語への適用能力が必要なことは言うまでもない。さらに、開発・運用・保守の観点から設計の妥当性を監査する眼力も必要となる。ユーザ企業の立場を理解したうえで、しっかりとしたシステムを開発するという、下請け仕事から脱却した視野が必要である。

 

 客観的に評価されたとき、自社が他社より一歩先を行くためには、今までのやり方を改善し、顧客からの要求にフィットする方法論への転換が求められる。搾取構造を断ち切ることは現状よりも楽な道ではない。

 

 

コラム:下請けの規模拡大

 

 下請けの規模拡大は稼働率によるところもある。零細企業では雇用している技術者の稼働率がシビアに会社の業績に響く。規模が大きくなるにつれて稼働率の問題は徐々に緩やかになってくるという側面がある。

 

 例えば、プログラマやSEを4人雇用したとして、4人分の仕事であれば問題ないが、3人分の仕事でも5人分の仕事でも状況は厳しくなる。お得意先から「5人欲しい」と言われて4人しか出せなければご機嫌を損なうから、必死で人探しをする。零細の開発会社でこうした経験を持つ経営者は少なくなかろう。ところが、プログラマが100人いれば、スケジュールのはざまで数人が遊ぶことになってしまっても、ほかのプログラマの売り上げで十二分にカバーできる。

 

 また、一般的な契約では工程ごとに検収・支払いを受けるケースが多い。下請けの開発会社は、大手の余剰資金によって毎月検収を受けることができればこそ、事業の継続が可能だという側面もある。よほどの資金的余裕がないと、少しばかり下請けのランクを上げられるだけで、とても元請けになることはできない。

 

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

2.3. 中間搾取でボロもうけ ハッピィ・エンジニアリング関連ページ

2.1. 丸投げ文化
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.2. 価格破壊+やらされ仕事=低い満足度
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.4. 人手余って人材足らず
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
2.5. 根性、根性、ド根性
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング