記事の内容
IT業界がオワコンと言われるのには、２つの明確な理由があります。
一つは「多重下請け構造」で、もう一つは「中抜き体質」です。
でも、IT業界でもWeb業界はオワコンではありません。
オワコンなのはSier（エスアイアー）業界だけです。
目次
Web業界とSier業界の違い
IT業界には大別してWeb業界とSier業界があります。
ちなみに、Sierとは、System Integrator（システム インテグレーター）の略称です。
業界の違いは、大まかには以下のようになります。
Web業務とSier業界
- Web業界は、自分達でサービスを作っている業界
- Sier業界は、IT以外の業界でITが使われる仕事を手伝っている業界。
例えば、Sierの会社は銀行のATMシステムを作ったりします。
142億円の開発費をかけて、セブンペイのシステムを作ったのはSierです。
IT業界の職種に関する詳細を知りたい方は、「IT業界を分類して職種を紹介します」を読んでみて下さい。
多重下請け構造について
オワコンと呼ばれるSier業界における、多重下請け構造でのプロジェクトの始め方を見ていきましょう。
ここに書かれている数字は、あくまでも例です。
みずぽ銀行のATMを作りたいんだけど？
予算は100億円で頼むわ。
[ボスSier]わかりました。
エンジニアを500人集めます。
↓（下請けの数社に声をかける）
[ボスSier]
みずぽ銀行がATMを作りたいらしい。
各社、エンジニアを100人づつ集めて欲しい。
予算は80億円で頼むわ。
[下請けSier 1]
わかりました。
エンジニアを100人集めます
↓（下請けの数社に声をかける）
[下請けSier 1]
どっかの銀行がATMを作りたいらしい。
各社、エンジニアを10人づつ集めて欲しい。
予算は6億円で頼むわ。
[下請けSier 2]
わかりました。
エンジニアを10人集めます
↓（エンジニアに声をかける）
[下請け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の開発手法
Sierの特徴
- エンジニアを集めるのに時間がかかる。（数ヶ月はかかります）
- エンジニアに払われている給料が安いので、エンジニアのモチベーションが上がらない
- エンジニアは、銀行（受注元）から言われたことしかやらないので、サービスが洗練されない
- エンジニアからの主体的な提案がない
- エンジニアの流動性が激しいので、システムに熟知している人が少ない
- エンジニアの銀行（受注元）に対する忠誠度は低い
- エンジニアは、システム開発に責任を持たない
Web系の開発手法（GoogleやAmazonがやっている開発手法）
Web系の特徴
- エンジニアを自社で雇っているので、新規機能の追加が早い
- 直接雇用なので、給料が高めで、エンジニアのモチベーションも高い
- エンジニアがサービス運営に関わっているので、エンジニア側からも積極的に意見が出てくる
- エンジニアの流動性はあるものの、そのシステムを熟知しているエンジニアが多い
- エンジニアの企業に対する忠誠度は高い
この差が、Sierがセブンペイというシステム開発に失敗した理由です。
たとえ142億円の開発費をかけたとしても、現場のエンジニアのモチベーションが低く、エンジニアが責任を持たなければ、いいシステムができるはずもありません。
2020年には、コロナ禍対策の接触確認アプリ「COCOA」でも同じ問題が起こりました。
そこでも、多重下請け構造が明確に批判されています。
現在のCOCOAの開発はパーソルプロセス&テクノロジーが元請けとして工程管理を引き受け、同社が日本マイクロソフト、FIXER、エムティーアイに再委託。
さらにエムティーアイがディザイアードとイー・ガーディアンに再々委託をしている。
この多重下請け構造が、COCOAの不具合の原因把握や修正の遅れにつながっているとの批判がある。
平井大臣も「そもそも発注自体に問題があったと言わざるを得ない」と2月の会見で指摘していた。
まとめ
SierとWeb系を比べてみて、Web系の開発方式がよいのは一目瞭然です。
それでも、2010年ぐらいまでは、Sierのやり方が一般的でした。
なぜならば、それまでは世の中のビジネスのスピードがそこまで早くはなかったからです。
つまり、追加開発をする機会はあまり多くありませんでした。
その場合は、エンジニアを自社で雇用する必要のないSierのやり方が好まれていました。
ところが2010年以降ぐらいから、ビジネスのスピードがあがってきました。
様々なWeb系の会社が、毎日、創意工夫をして、常に追加開発をしています。
これを我々はアジャイル開発と呼んでいます。
こうしてWeb系が躍進して、Sierは没落しているのが今の時代です。
それでも長年のやり方は、なかなか止められないので、Sier中心の開発は続いていきそうです。
それは日本のIT業界が、引き続き停滞し続けることも意味しています。
一方で、自社でエンジニアを雇って、システムの内製化に切り替えている会社も増えつつあります。
そうしたSierからの脱却の流れが加速すれば、日本企業の復活も早まるかもしれません。
内製化の話の詳細を知りたい人は、この本を読んでみて下さい。
Sierの新しいビジネスモデルを考えている人には、この本をオススメしています。
▼ エンジニアの組織論に興味がある人には、この記事がおすすめです
-
-
エンジニア組織を作る時におすすめの本【2022年最新】
Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス Googleのエンジニア達が培ってきたノウハウが、600ページ以上にわたって書かれた本です。 Googleの現役ソフトウェアエンジニアたちが ...
▼ アジャイル開発に興味がある人には、この記事がおすすめです
-
-
アジャイル開発とスクラム開発でおすすめの本と動画（Udemy）【2022年最新】
初心者向け アジャイルサムライ−達人開発者への道 アジャイル開発の定番本です。 アジャイル開発の心構えや実務のコツを啓蒙してくれる良書です。 いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法 フトウェア開発の現場で ...
▼ 今後のIT業界の方向性を知りたい人には、この記事がおすすめです
-
-
Sierは必要なくなり、企業でITの内製化が進んでいきます【社員はSierから逃げるべき】
Sierの利益は、事業会社の非効率から生まれます Sierの利益は、どのようにして生まれるのでしょうか？ Sierの利益は、「事業会社に派遣するエンジニアの数 × 単価 × 月」で決まります。 「あれ？エンジニアのスキルや業務の効率化は関係 ...
▼ 何歳までエンジニアとして働くか迷っている人には、この記事がおすすめです
-
-
2030年にはエンジニアは何歳まで働いているのか？【生涯現役！】
昔は、「プログラマー35歳定年説」というものがあり、35歳でコードを書くことを引退していたと聞きました。 でも、最近は35歳を過ぎてもコードを書き続ける人もいるという話も聞いています。 10年後の2030年には、日本人は何歳までコードを書き ...
▼ みずほ銀行の障害レポートを読みたい人は、ここをクリックして読んで下さい。
▼ ブログの内容を復習をしたい人は、動画を見て下さい
