IT業界が終わっていると言われる理由【Sierはヤバイです】

Web業界とSier業界の違い

IT業界には大別してWeb業界とSier業界があります。
ちなみに、Sierとは、System Integrator（システム インテグレーター）の略称です。
業界の違いは、大まかには以下のようになります。

IT業界の職種に関する詳細を知りたい方は、「IT業界を分類して職種を紹介します」を読んでみて下さい。

多重下請け構造について

オワコンと呼ばれるSier業界における、多重下請け構造でのプロジェクトの始め方を見ていきましょう。
ここに書かれている数字は、あくまでも例です。

銀行

みずぽ銀行のATMを作りたいんだけど？
予算は100億円で頼むわ。

Sier

[ボスSier]わかりました。
エンジニアを500人集めます。

↓（下請けの数社に声をかける）

Sier

[ボスSier]
みずぽ銀行がATMを作りたいらしい。
各社、エンジニアを100人づつ集めて欲しい。
予算は80億円で頼むわ。

Sier

[下請けSier 1]
わかりました。
エンジニアを100人集めます

↓（下請けの数社に声をかける）

Sier

[下請けSier 1]
どっかの銀行がATMを作りたいらしい。
各社、エンジニアを10人づつ集めて欲しい。
予算は6億円で頼むわ。

Sier

[下請けSier 2]
わかりました。
エンジニアを10人集めます

↓（エンジニアに声をかける）

Sier

[下請けSier 2]
どこかの銀行がATMを作りたいらしい。
発注元は現場にいってから確認してくれ。
みんな頑張ってほしい。

はい、わかりました。

このように、発注元から仕事を受けて、下請けに仕事をまわしていくのがSierのやり方です。
日本の企業では、従業員の解雇は認められていません。
そのため、Sierは普段から多くの正社員を雇用するわけにはいきません。
その変わりに、エンジニアが必要になったら、このように下請けに声をかけていきます。
これをSier業界のピラミッド構造と呼んでいます。
もしくは、多重下請け構造と呼ぶこともあります。

下請けの会社には、なるべく入社しないようにしましょう。
もし間違って入社した場合は、少し経験を積んだところでサッと転職すべきです。

Sier業界の中抜き体質

上の会話を読んでいると、下にいくほど予算が減っていくことがわかります。
これは間に入っている会社が、多くの中間マージンを抜いていくからです。
そのため、銀行が出した予算が100万/月だとしても、エンジニアの手元に入ってくる金額は50万/月以下になります。
そして、ほとんど何もしていない営業の人が残りの50 万円を貰います。
これをSier業界の中抜き体質と呼んでいます。

2020年の6月に「雇用調整助成金のオンライン申請システム」は、中抜体質そのものです。
富士通が設計業務だけで7,701万円を抜いて、残りを下請けに任せたようですね。
トラブルだらけのシステムになるのも納得ですw

富士通；1億円で受注

富士通マーケティング；854万円
インフォテック；440万円
ペガジャパン；1,005万円

厚労省によると富士通が約一億円で受注しシステム設計の統括を担っていた。
再委託先と受注額はそれぞれ、富士通マーケティングが八百五十四万円、インフォテックが四百四十万円、ペガジャパンが千五万円。

プロジェクト体制

多重下請け構造によって出来上がったチームは、同じ会社の社員でもなんでもありません。
むしろ、こんな感じの寄せ集めチームです。
A社；10人、B社；10人
C社；10人、D社；10人

そのため、プロジェクト開始時はコミュニケーションすら、ままなりません。
このような会話はよくある話です。
「オタクは何次受け？」
「5次受けって聞きましたけど、よくわかりません。」
こうして、まずはチーム作りとお互いのスキルを知ることからプロジェクトが始まります。

このしたプロジェクト体制では、精神的に病む人も出てきます。
今のIT業界のエンジニア不足の一因は、こういったプロジェクト体制のためです。
私は、このやり方が本当に嫌いです。

みずほ銀行が事件を障害を起こした原因にも、こういったプロジェクト体制が挙げられています。

1、委託先である MHRTやMHRT の再委託先である外部ベン ダーにおける当該案件の設計・開発工程の各段階における設計ミスの見逃し、MHBK におけるチェックの不備
2、MHRT の外部委託先管理の不十分性、当該設計ミスを検知するに足り る体制の不備などがあった。

プロジェクトが終わったあと

仮に2年かけてプロジェクトが完成したとします。
そうすると現場にいた100人は、ほとんどやることがなくなります。
そのため10人ぐらいのエンジニアをのこして、残りの90人は現場から撤収します。

みずほ銀行が事件を障害を起こした原因にも、こういったSierの体制について説明されています。

障害の発生及びシステム復旧遅延に通じる原因として、システム保守運用管理体制が脆弱であった点がある。
MINORIを構築し、運用に移行する段階で実施した MINORI に詳しい人材の再配置に当たり、最も重要な「安定稼働の定着」になお比重を置く意識が足りなかったことが、そのようなシステム保守運用管理体制の脆弱化を招いた可能性がある。

プロジェクトの追加開発をやる時

数年後に、追加開発の作業をやる必要がでてきたとします。
その時に残った10人で作業ができれば、問題はありません。
でも、その10人では間に合わない場合は、改めて人を呼ぶところからやり直します。

そして、集められるエンジニアは、前回、開発を手掛けたエンジニアではありません。
なぜならば、その時に銀行で働いていたエンジニアは、すでに別の現場で働いているからです。
そうして、新たに派遣されてきたエンジニアは、残されたドキュメントとソースコードを手掛かりにして、追加開発を始めます。
彼らは、既存の仕様やコードを理解していないので、開発効率が悪いのは言うまでもありません。

Sier方式がオワコンである理由

Sierの仕事を見ながら、改めてWeb系との仕事のやり方を比べてみましょう。

Sierの開発手法

Web系の開発手法（GoogleやAmazonがやっている開発手法）

この差が、Sierがセブンペイというシステム開発に失敗した理由です。
たとえ142億円の開発費をかけたとしても、現場のエンジニアのモチベーションが低く、エンジニアが責任を持たなければ、いいシステムができるはずもありません。

2020年には、コロナ禍対策の接触確認アプリ「COCOA」でも同じ問題が起こりました。
そこでも、多重下請け構造が明確に批判されています。

現在のCOCOAの開発はパーソルプロセス&テクノロジーが元請けとして工程管理を引き受け、同社が日本マイクロソフト、FIXER、エムティーアイに再委託。
さらにエムティーアイがディザイアードとイー・ガーディアンに再々委託をしている。
この多重下請け構造が、COCOAの不具合の原因把握や修正の遅れにつながっているとの批判がある。
平井大臣も「そもそも発注自体に問題があったと言わざるを得ない」と2月の会見で指摘していた。

まとめ

SierとWeb系を比べてみて、Web系の開発方式がよいのは一目瞭然です。
それでも、2010年ぐらいまでは、Sierのやり方が一般的でした。
なぜならば、それまでは世の中のビジネスのスピードがそこまで早くはなかったからです。
つまり、追加開発をする機会はあまり多くありませんでした。
その場合は、エンジニアを自社で雇用する必要のないSierのやり方が好まれていました。

ところが2010年以降ぐらいから、ビジネスのスピードがあがってきました。
様々なWeb系の会社が、毎日、創意工夫をして、常に追加開発をしています。
これを我々はアジャイル開発と呼んでいます。

こうしてWeb系が躍進して、Sierは没落しているのが今の時代です。
それでも長年のやり方は、なかなか止められないので、Sier中心の開発は続いていきそうです。
それは日本のIT業界が、引き続き停滞し続けることも意味しています。
一方で、自社でエンジニアを雇って、システムの内製化に切り替えている会社も増えつつあります。
そうしたSierからの脱却の流れが加速すれば、日本企業の復活も早まるかもしれません。

内製化の話の詳細を知りたい人は、この本を読んでみて下さい。

Sierの新しいビジネスモデルを考えている人には、この本をオススメしています。

▼ エンジニアの組織論に興味がある人には、この記事がおすすめです

▼ アジャイル開発に興味がある人には、この記事がおすすめです

▼ 今後のIT業界の方向性を知りたい人には、この記事がおすすめです

▼ 何歳までエンジニアとして働くか迷っている人には、この記事がおすすめです

▼ みずほ銀行の障害レポートを読みたい人は、ここをクリックして読んで下さい。