SIerの仕事

【SIerの闇】IT業界の多重下請け構造のリアル

いわゆる一次請けのSIerで10年働いてきました。

日本で最も大きな悪名高きSIerの中で、IT業界の多重下請け構造の頂点に立ちながら、業界の問題を見つめてきました。

さて、新型コロナ接触確認アプリ「COCOA」の不具合が4ヶ月以上も放置されていた問題に端を発し、IT業界の多重下請け構造がちょっとだけ話題になっています。

COCOA以前からもIT業界の多重下請け中抜き構造はたびたび話題に上がりますが、一向に是正される気配はありません。

というのも、業界構造的に変えられないからです。
一次請けのSIerは「これだけの工数が必要なので○○億円ください」と顧客に請求し、単価の安い二次請け、三次請けに仕事をさせることで「自分たちの単価との差額」の利益を得ます。

単価が安い外の人間にやらせればやらせるほど、利益が出るのです。

その上、長年丸投げし続けたせいで、一次請けのSIerの人間にはシステムを作る技術はありません。

ツイッターとかで「SIer勤務」をアピールする意識の高いSIerの人間は、「俺はシステムを理解している。いざとなったら一次請けのメンバーでシステムを作ることができるんだ」とかいうアホもいますが、できません。

中身は何もわかっておらず、「設計書」と呼ばれるプログラムをなぞっただけのおもちゃをレビューしてわかったつもりになっているのが一次請けのSIerの現実だからです。

SIerはオリンピックで批判されたパソナと同じ、中抜き業者なのです。

中で働いていて、「これ、一次請けのSIerいらねえな」と思ったのは一度や二度ではありません。

仕事を流して調整するだけ。

中には「顧客と対面するのが重要だ」「責任を取るから俺たちは素晴らしいんだ!」「仕事をやり遂げるのは誰にでもできることではない」などと自負する連中もいますが、大したことやってないですよ。

一次請けのSIerは何をしているのか?

「一次請け」とは、お客さんから直接「こんなITシステムを作ってくれよー」と受注する立場の会社を指します。

具体的にはNTTデータや大塚商会、NECなどの大きな会社です。

外から見た普通の感覚の人であれば、

「一次請けで受注した会社がシステム開発をして、お客さんに『言われた通りのシステムができましたよ』と納品するんだろう」

と思うでしょう?

実際はそんなんじゃないんですね。

受注した一次請けSIerは何をするかというと、「プロジェクトマネジメント」です。

このシステムを作るには工数(何人がかりで何ヶ月かかるか)を見積もり、どの工程をどれくらいの期間で行っていくかの計画を立てます。

大きなプロジェクトであれば、この計画作りに3ヶ月から半年以上かけます。

パワーポイントで「XX計画書 0.1版」を作り、「XX計画書 1.0版」になるまで何度も社内の偉い人のレビューを受けます。

こうしてプロジェクト計画書ができあがり、次にシステム化計画書、○○計画書、〇〇設計書、…etcみたいな、たくさんのワード、パワポ、エクセルの資料が作られます。

これらもまた、たくさんの人にレビューを受けます。

ここまでで一行もソースコードは書きません。

ひたすらに書類の執筆です。

そして、一通りの書類のレビューが終わり、計画書にGOサインが出たら、プロジェクトが始まります。

プロジェクトが始まったタイミングで大量の「協力会社」と呼ばれる下請け企業の人達が雇われます。

SIerの社員が行うのは、

「計画を立てて、下請けに投げて、下請けを管理すること」

なのです。

これを「上流工程」と呼びます。

大雑把な計画を定義して、後の作業は下請け企業に投げます。

2次請け、3次請けの企業は何をしているのか

1次請けの企業からすると、二次請けの企業しか見えませんが、実は影には三次請け、四次請けの会社がいます。

「NTTデータ」から「パソナ」という企業に下流工程の仕事を投げたとします。

「NTTデータ」から見ると「パソナ」が作業しているように見えますが、「パソナ」の下にさらに「中国のオフショア企業」であったり、「国内の下請け企業」であったり、「低賃金のSES」みたいな人たちがいるのです。

こうやって、伝言ゲームで作業を投げていく仕組みをIT業界の多重下請け構造といいます。

お客さんがお金を出して、そこからマージンを取って下請けに投げるので、下にいけばいくほど利幅が小さくなります。

お客さんは大金を出しているにも関わらず、下請けの末端の社員の年収は300万円になったりするのです。

二次請けの人たちが三次請けの人たちに指示を出して、三次請けの人たちが実際の開発業務を行います。

この人達にとってはプログラミングは単純作業です。

設計書と呼ばれる処理の順番を書いたエクセルの内容をソースコードに落としていく作業を行います。

創造性の欠片もない「単純作業」なので、

「ソースコードを綺麗にしよう」

「あとでメンテナンスしやすくなるように、保守性の高いコードを書こう」

みたいなモチベーションは沸きません。

余計な作業をしてしまうと、今度は面倒でつまらない「テスト」をやらされるので、どうしても「指示された作業以外はやりたくない」という負のインセンティブが働いてしまうのです。

こうして大手SIerが抱えるプロジェクトには「技術的負債」が溜まっていきます。

2021年現在、既に溜まりに溜まった技術的負債は返済不可能なレベルになっており、たくさんの人柱たちが負債の返済を迫られています。

上の記事はブラックなSIerを脱出するヒントが詰まった漫画の紹介です。

SIerの技術的負債は解消できるのか?

断言してもいいですが、SIerに溜まった技術的負債は絶対に解消できません。

まず、技術的負債を解消させるよう旗を振ることができるのは一次請けのSIer社員だけなのですが、彼らにはプログラミングの知識もスキルもありません。

なので、問題が起こっていることを認識はできても、解決策が考えられないのです。

たとえば、私の隣のチームでは「古くてどうしようもないプロジェクトを刷新しよう!」というプロジェクトが進められていたのですが、彼らが何をやっていたのかというと、

「COBOLのソースコードを解析して、Excelにクラス図を書いていく」

という作業でした。

そんな作業を3ヶ月以上、ずっとやっていました。

それも多重下請け構造の中で、下請けにクラス図を書かせ、一次請けの人たちが「レビューする」という作業ゲーをずっと続けていたのです。

プロジェクト計画のようなものが作られていたので眺めてみましたが、

「COBOLをJavaに書き換えること」

が「刷新」とされていて、リファクタリングのために「テストを書く」だとか、「設計を見直す」みたいな内容はありませんでした。

誰もそんな発想に至らないのです。

エンジニア的な常識で考えるならば、テストを書かずにリファクタリングするのは自殺行為であって、刷新するならまずはテストから書くものと思いますが、大手SIerの社員はテスト駆動開発を全く知らないですし、経験がないので、テストを書くという発想になりません。

ひたすらにExcelに書かれた「単体テスト」の項目を目視で確認する罰ゲームを繰り返し、現場の人たちが疲弊していくのです。

ちなみにExcelのテストケースは

「ケースのレビュー」

と、

「証跡のレビュー」

という不毛な作業も含まれます。

無駄な作業で延々と時間と労力を無駄にして、何一つ問題が解決しないのがSIerの下の多重下請け構造の現実です。

問題の根本は一次請けSIer社員の無知

一次請けのSIer社員はネットでディスられがちですが、彼らは元々はかなり優秀な人たちです。

高学歴で、吸収力があり、仕事にも一生懸命です。

毎日真面目に残業もしています。

決して馬鹿ではないのです。

馬鹿ではない人たちが、馬鹿みたいな作業を一生懸命やった結果、ゴミだらけになってしまっているのです。

元々頭の良い彼らがなんでこんなに馬鹿みたいな単純作業を是としているかというと、SIerにいる40代以降の管理職が馬鹿だからです。

多重下請け構造のピラミッドのごとく、SIer内の意思決定もトップダウンで行われます。

不勉強な40代、50代の人間にレビューを受け、承認されないとプロジェクトは進められません。

新しいことを提案しようとすると、リスクの説明を求められ、前例にないものは認められません。

認められるにしても、多大なる労力をかけた「偉い人の説得」が必要になるので、この説得、誰得?となり、わざわざ余計なことをするインセンティブがわきません。

そうして20代、30代の社員は学習的無力感を抱きます。

SIerに染まっていきます。

まともな開発がしたい人は、「こんな環境にいても無駄ぽよ」と確信し、会社を去っていきます。

残るのはSIerに染まりきった人だけになります。

こうしてダメな方向に新陳代謝が行われ、存在が「技術的負債」になる人たちばかりが残った結果、今のSIerの惨状があります。

非効率な開発で、永遠に苦しみ続けます。

中にいる人達は大真面目なのです。

超真剣に、真面目に開発しているのです。

誰もサボっているとは思っていません。

自動化すれば1分で終わることを100時間かけてやってます。
みんな真面目です。

こうして、エンジニアリングからかけ離れた、技術を何も知らない人が偉くなって、多重下請け構造のピラミッドの上の方で偉そうにしています。

プロジェクトの意思決定はプロジェクトマネージャー次第で、プロジェクトマネージャーは自分の知らないことを認めようとはしません。

こうして、伝統的に非効率なSI開発が繰り返され、現場は疲弊し、低スキルな人しか残らなくなっていきます。

今後10年は、大手SIerの多重下請け構造や、非効率な開発スタイルが変わることはないでしょう。

中にいる人間が変われないからです。

組織を変えるよりも、見限って出ていった方がずっと早いし、楽です。

沈んでいくタイタニック号にしがみつくより、さっさと小さな船に飛び移って、海大きな海を渡るスキルを身に付けましょう。