ITシステム開発の外注についてよく知らない一般の人々に分かるように、日本のSIer業界の構造について解説します。
きちんと説明している記事は意外に少ないので、自分で書こうと思ったわけです。
SIer業界の人々の中には、これを説明すると怒る人々がいますが、この記事では事実のみ解説しますので、私の意見は書きません。
事実を批判したいのなら、事実の現場に行って批判なされば良いと思います。
業務システム開発とは何か
SIerとは、IT企業ではない普通の企業から、業務用のITシステム開発の発注を受けて、ITシステムの開発を請け負い、納品するIT企業の事です。
つまり、ITシステムの受託開発業者のことです。
ITコンサルの機能も持ちますが、SIerではITコンサルを営業目的で無償提供することが多く、ITコンサル業として商売が成立していないので、ITコンサルタントとは別の物と考えた方が良いと思います。
発注社の「普通の企業」の事を、業界内では「ユーザー企業」と呼びます。納品したITシステムを使う会社ですので、ユーザー企業なのです。
ユーザー企業もSIer企業も、大きな会社から小さな会社まで、様々な会社があり、一枚岩ではありません。
ただ、SIer業界には、他のIT企業とは異なる特徴があり、この記事ではそのSIer企業特有の特徴を解説します。細かいレベルでは個々の企業には当てはまらないケースもあります。あくまで一般的な話だけをします。
業務用ITシステムは、ユーザー企業の業務をITシステムで自動化したり省力化したり効率化したものです。
当然、そのITシステムにはユーザーの業務知識が反映されています。
もし、ユーザーの業務知識が反映されていなければ、そのITシステムはユーザーの役には立ちません。
そして、SIer企業は通常、ITの専門家であり、ユーザーの業務の専門家ではありません。
例外的に特定業務の専門知識を持つ、特定ユーザー業界に特化したSIerも存在しますが、こういうのは稀少な存在です。
通常は、ユーザー企業業務は素人の、IT専門家がユーザーに業務知識を教わりながらITシステムを設計します。
ユーザー企業がユーザー業務の専門家である事は当たり前ですし、ユーザー企業の従業員ではないSIer企業のIT技術者がユーザー業務の素人である事も、同様に当たり前の話だと思います。
そのため、業務ITシステムの開発は、ユーザー企業の業務の専門家と、SIerのIT技術者が、互いに協力し合ってITシステムを設計します。
この協力関係が成立していないと、十中八九でITシステム開発は炎上し失敗します。
そして多くの場合、ITシステム開発は、この協力関係が成立しないことで失敗しているのが実状です。
ウォーターフォールモデルが採用される
ソフトウェアの開発手法には、いくつか種類があり、その全ての開発手法の基礎的概念になっているのが、ウォーターフォールモデルです。
ソフトウェア開発手法は、一般的に「ソフトウェア開発工程」「情報システム開発工程」とか「ソフトウェア開発プロセスモデル」とか「ソフトウェア開発方法論」とも呼ばれますが、ざっくりとだいたい同じようなものと理解してください。
ソフトウェア開発プロセスモデルにはいくつも種類がありますが、全てのプロセスモデルの基礎になっているのが、ウォーターフォールモデルです。
他のプロセスモデルは、全てウォーターフォールモデルを改良したものです。
だからプロセスモデルを理解する為には、その基礎としてウォーターフォールモデルを理解する必要があります。
ソフトウェア開発プロセスモデルについては、別記事で解説しています。
SIer企業ではプロセスモデルにウォーターフォールモデルを採用する事が多いです。ほとんどウォーターフォールモデルで受託開発していると言っても過言ではないです。
以前紹介したMicrosoftの牛尾剛さんの著書でも「マイクロソフト社でウォーターフォールを採用しているプロジェクトを見たことがない」との事です。
他の情報を見ても米国のソフトウェア開発では、ウォーターフォールモデルは採用されていないようです。
日本のSIer業界がウォーターフォール開発を採用しがちな理由としては、模範解答として以下のよう説明ができます。
1. 従来の開発慣習への慣性
SIer業界では長年ウォーターフォール開発が主流だったため、その慣習や体制に組織文化として慣れ親しんでいます。新しい手法に移行するコストや抵抗感があります。
2. 大規模システム開発への不安
アジャイル開発は比較的小規模な開発に向いているとの認識があり、大規模システム開発に不安があります。要件の大幅な変更には不安があります。
3. 製品開発とサービス開発の違い
SIerの主な業務はユーザー企業に合わせたカスタマイズであり、製品開発のようなスピーディーな開発スタイルとはマッチしにくい側面があります。
4. 顧客との契約スタイル
顧客との契約がウォーターフォールを前提としていることが多く、アジャイルに合わせた契約スタイルの変更が難しいことがあります。
5. 開発者のスキルセット
ウォーターフォール開発のスキルは組織に蓄積されていますが、アジャイルに必要なスキルがまだ不足している側面があります。
6. マネジメント層の理解不足
経営層や上級管理職の間で、アジャイルに対する理解が十分でない場合があり、導入が進みにくい側面があります。
このように、組織文化や慣習、契約、人材育成などの理由から、SIer業界ではアジャイルへの移行が容易ではない状況があると考えられます。ただし最近では一部でアジャイルへのシフトが始まっています。
以上は、「なぜウォーターフォールモデルが採用されるのか」の一般的模範解答としての説明ですが、私は一部納得していません。
「2. 大規模システム開発への不安」については、Microsoft社ほど大規模なソフトウェアを開発している企業が他にあるでしょうか。
そのMicrosoft社ですらウォーターフォールモデルを採用していないのですから、大規模ソフトウェア開発だからと言って、ウォーターフォールモデルを採用しなければならないという理屈は成立しないと思います。
また、「3. 製品開発とサービス開発の違い」についても、Microsoft社の存在がその正当性を否定していると思います。
ウォーターフォールモデルは原則として「仕様変更しない」事が前提の開発プロセスモデルです。
しかし、現実の業務システム開発では、仕様変更しないことは不可能であり、システム開発の現場では、「仕様変更してはいけないウォーターフォールモデル」で、「仕様変更とリスケを繰り返している」のが現実です。
ウォーターフォールモデルは仕様変更しなければ生産効率の良いプロセスモデルですが、仕様変更すると逆に生産効率が悪くなる欠点があります。
つまり、現在のSIerとユーザー企業は、最も生産効率の悪いやり方で、ITシステムを作っていることになります。
ソフトウェア開発プロセスモデルの解説を読めば分かりますが、仕様変更に対応したプロセスモデルは、アジャイルモデルやプロトタイプモデル、スパイラルモデルなど多数あります。
どうしても仕様変更を必要とするなら、アジャイルなど仕様変更に対応したプロセスモデルを採用すれば良いのですが、なぜかSIerでは頑なにウォーターフォールモデルで仕様変更を繰り返して、炎上と失敗を何十年も繰り返しているのが実状です。
SIer業界の中で精神疾患に陥るITエンジニアが絶えない理由も、ウォーターフォールモデルで仕様変更を繰り返し、開発が炎上して連日の超過労働に陥るからです。
この責任はSIer企業だけでなく、ウォーターフォールモデルを前提にした発注契約に拘りながら、仕様変更を繰り返すユーザー企業にもあります。
ウォーターフォールモデルと多重請負体制の密接な関係
昔のSIer企業は、ユーザー企業からの発注を受けて、自社でITシステムを開発していました。
NTTなど例外はありますが、昔は現在のように多重下請け体制にはなっていませんでした。
しかし、ソフトウェアが発達し開発プロジェクトの規模が大きくなると、SIer単独では対応が難しくなるため、下請けの企業に一部の作業を外注することが多くなります。
下請けの仕事が多くなると、この下請け企業が更に下請け企業に仕事の一部を外注するようになり、階層構造となる「多重請負体制」が生じます。
初期は、開発力や人員の不足を埋める為に、下請けに外注して、開発の主導権は元請けSIerが有していたのですが、やがてコスト削減のため、プログラミングを安価な下請けに発注するようになりました。
このコストダウン方式は、そのままエスカレートして、やがてシステム設計も下請けに外注し、企画や提案までも下請けが担うようになりました。
会社にもよりますが、現在ではユーザー企業からの受注、要件定義とベンダーマネジメントだけを担うのが元請けSIerの主な仕事になっていると言われ、ITシステムの開発は全て下請けが担う状態になっています。
さらに、その下請けも同じコストダウン方式を採用しており、設計を担った二次下請けが、開発を三次下請けに外注するという慣習が蔓延していきます。
三次下請け企業は、二次請けからの受注状況が不安定で、ITエンジニアを直接安定雇用する事ができないため、派遣エンジニアやフリーランスを多方面から集めてきて、開発チームを編成するという、非常に不安定な雇用体制が形成されています。
このように、現在のSIer業界の開発体制は、非常に不安定な雇用環境の元で、ITシステムが開発されている事が分かると思います。
「忠誠心」とか「計画的人材育成」とか「よく知る同僚との信頼関係」のような物は、SIer業界の下請け階層では無縁のものです。
また、派遣エンジニア会社やフリーランスの仲介業者は、SESと呼ばれ、多重派遣や偽装請負などの違法労働の温床になっています。
SESというのは、元々派遣では無いのですが、現在では違法な派遣労働の温床になっています。本来のSESとは似ても似つかないものになっています。
このようにSIer業界では、ウォーターフォールモデルの各開発工程である、企画・要件定義・基本設計・詳細設計・開発という工程ごとに異なる下請けIT企業が役割を担う体制が構築されています。
つまり、ウォーターフォールモデルというプロセスモデルに合わせて、多重請負階層が構築されており、SIerの多重請負構造とウォーターフォールモデルは、切っても切れない密接な関係になっています。
要件定義や設計を担当する会社は、要件定義や設計だけを行い、開発を担う会社は他社が設計したITシステムのプログラミングだけを行うという体制です。
これは前工程を担う会社にとっては、非常に美味しい立場となります。
前工程は、人月単価のマージンを取れる上に、仕様変更による手戻り負担や納期の不足による超過労働などの負担は、下請けに任せられます。
発注元の無理な仕様変更や説明不足・開発期間不足などの理不尽な要求も、受託社が自分で開発していれば、発注元と交渉したり抵抗したりして是正されますが、多重請負では発注元から下請けに、そのまま無抵抗に流されてしまうので、末端の下請け企業の負担は際限なく大きくなります。
末端の下請けの負担がどんなに大きくなっても、元請けや二次請けは痛くも痒くも無いからです。
前工程だけを担っていた会社は、この多重請負体制を失いたくないでしょう。
日本のSIer業界が頑なにウォーターフォールモデルに拘る理由の一つは、この前工程利権を失いたくないからだと思います。
SIer業界で精神疾患の発症率が高いのは、この多重請負体制の後工程を担うプログラマーが、前工程の無理な仕様変更やミスによる手戻り作業の負担を、押しつけられて理不尽な超過労働になり健康を害する事が多いからです。
(よく、上流工程・下流工程という呼び方がありますが、本来上流工程とは業務側の企画などの事であり、要件定義や設計などは前工程と呼ぶのが相応しい呼称です。プログラミングは後工程と呼ぶべきでしょう)
ウォーターフォールモデルへの批判的意見に対して、誹謗中傷にも近い激しい反発の声が上がりやすいのは、この前工程利権を失いたくない人々が、多数存在するからだと思います。
現場の後工程を担うプログラマーが、ウォーターフォールモデルを望んでいるとは考えにくいですし、実際に現在の人手不足経済の中では、SIer業界から後工程を担うプログラマーが他の業界へ流失しています。
また、この多重請負構造を維持したまま、アジャイル開発などの導入は不可能だと思います。
アジャイルでは1週間から1ヶ月程度で、前工程から後工程を何度も反復開発するからです。一つの会社・一つのチームの中で反復しなければ、非常に効率が悪くなってしまいます。
仕様の柔軟な変更に対応できるアジャイル開発の導入には、ウォーターフォール型・多重請負構造の破棄が必要です。
精神疾患の発症率が突出しているIT業界
厚生労働省は2016年、IT業界での精神障害の発症状況に関する調査結果を公表しました。その中で、IT業界の精神障害の発症率が他産業に比べて高い水準にあることが指摘されていました。
具体的には、IT業界の精神障害による休職者の割合が5.9%と、全産業平均の2.8%を大きく上回っていたことが分かりました。特に、長時間労働や納期のストレス、頻繁な残業が精神疾患の一因となっている可能性が指摘されていました。
また、この調査結果を受けて、厚生労働省は「情報通信業における労働者の精神障害の予防のための指針」を策定し、企業に以下のような取り組みを求めています。
– 長時間労働の是正
– 休日・休暇の確保
– メンタルヘルス対策の強化
– 上長によるケアの徹底
– 相談窓口の設置
このように、IT業界における過重労働やストレスが、精神疾患のリスクを高めていることが指摘され、予防対策の強化が求められています。
報告は、2016年ですが、その後改善されたという報告は聞いていません。
SNSなどを観察していると、今でもSIer業界の労働で精神疾患になり静養しているITエンジニアの嘆きを何度も見かけます。
先に説明したように、問題の根源は、ウォーターフォールモデル型・多重請負構造にあるので、ここが改善しない限り、IT業界における精神疾患リスクは改善しないでしょう。
健康保険料の資金は広く国民から徴収した資金を分配しているのですから、IT業界だけ突出して健康保険歳出を浪費しているのなら、IT業界だけ健康保険料の負担を増やすことも、検討した方が良いかも知れません。
経済産業省は2018年から問題を指摘している
SIer業界のウォーターフォールモデルと多重請負構造の問題は、以前から経済産業省は把握していて、2018年9月に「DXレポート~IT システム『 2025年の課題と将来指針』」という報告書を国民に公開しています。
このレポートの中で、SIer業界の改革案が提案されています。
主な内容は以下のようになっています。
【日本のIT業界の現状と課題】
– 多重下請け構造による品質・生産性の低下
– 優秀な人材の確保が困難
– ユーザー企業とのコミュニケーション不足
– 旧態依然とした開発手法の慣習化
– クラウドやAI等の新技術への対応の遅れ
【2025年に向けた将来指針】
– アジャイル手法の活用による高品質・高生産性の実現
– 常に最新の技術を取り入れられる環境整備
– ユーザー企業と密なコミュニケーションを重視
– 多能工化された高度IT人材の育成・確保
– セキュリティ対策の強化
– オープンイノベーションの推進
このレポートは、日本のIT業界が抱える構造的な課題を分析し、DX(デジタルトランスフォーメーション)の実現に向けて大胆な改革を求めたものとなっています。特に多重下請け構造の是正やアジャイル開発の浸透、最新技術への対応力強化などが重要視されました。
このDXレポートの中で、経産省は「ユーザー企業によるITシステムの内製」を推奨しています。
日本のITシステム外注比率は7割に達しており、ITの進んでいる欧米は5割程度であることから、欧米並みに内製率を5割程度に抑制する事で、多重請負体制の是正とITシステム開発の効率化を進めたいようです。
また、受託開発を担ってきたITベンダーに対しては、得意な技術をマイクロサービスのような形で提供し、ユーザーの内製にプロフィットシェア契約での技術提供を推奨しています。
これは、SIerの受託契約では、ITシステムの開発完了がゴールになってしまい、ITシステムがユーザー企業の利益に貢献する事に、ITシステム開発者が責任を持たない体制になっている事を解消しようとしたための提案です。
行政は以前から多重請負体制を問題視している
以上のように、日本SIer業界のウォーターフォールモデル依存型の多重請負構造は、以前から厚生労働省と経済産業省から問題視されています。
また、日本のIT業界における多重派遣や偽装請負の問題は、行政からも問題視する報告がなされています。
具体的には、以下のような報告があげられます。
1. 厚生労働省「情報サービス業における現状と課題」(2008年)
多重派遣や偽装請負が横行し、雇用が不安定で賃金水準が低い実態を指摘。違法派遣の是正を求めた。
2. 総務省「情報サービス業における労働者派遣事業適正化対策」(2011年)
IT人材の6割近くが派遣労働者で、多重派遣が蔓延する実態を示し、法令順守を求めた。
3. 公正取引委員会「情報サービス業における取引実態調査」(2017年)
下請け業者へのしわ寄せや不当な価格圧迫など、取引環境の問題を指摘。公正な取引の確保を促した。
このように、多重派遣や偽装請負、下請けへの搾取など、IT業界における労働環境や取引の歪みが長年にわたり指摘されてきました。しかし、業界の構造的な問題が根付いているため、抜本的な改革には至っていないのが実情です。
行政からは法令順守や公正な取引を求める声が繰り返し上がっていますが、実効性のある是正には至っておらず、依然として課題が残されているのが現状と言えます。
多重請負構造に参加しないSIer
ごく少数ながら、自社の従業員だけでソフトウェア開発を行い、多重請負体制に参加しないSIerも一部存在します。
ただし、そうしたSIerは大手に比べると規模が小さく、プロジェクトの規模にも限界があるのが実情です。
主な特徴としては以下の点が挙げられます。
・中小SIerが中心
大手SIerは規模の大きいプロジェクトが多く、自社リソースだけでは対応が困難なため、下請けを活用する傾向が強い。中小SIerのほうが自社開発体制を維持しやすい。
・自社の技術者が携わる
外注やベンダーコントロールを行わず、自社の従業員が直接設計〜実装を担当する。
・特定の業界や業種に特化
特定分野の深い知見を持ち、そのニッチな領域でサービスを提供することが多い。
・アジャイル開発の採用が比較的進んでいる
小規模だが機動力があり、アジャイル手法の導入がしやすい。
ただし、こうしたSIerでも、ごく大規模なプロジェクトの場合は外注を利用せざるを得ないケースもあります。
完全に自社開発体制を維持できるのは、比較的小規模なプロジェクトに限定される傾向にあります。
大手と比べると少数派ですが、自社の技術力とノウハウを最大限に生かせる強みがある一方、規模の制約があるのが実情です。
最後に
この記事は、実はClaudeという生成AIを使用して書きました。
生成AIは、報道や行政の報告などを要約してレポートに纏める使い方に非常に適しています。
事実に基づくレポートですから、細かい部分で、自分の意図と異なるレポートも書きますが、不足部分は自分で書き足しました。
生成AIのClaudeが学習している情報は、最新で2023年8月までの情報ですが、このテーマなら問題無いと思います。
もし貴方がSIerの実状について、自分で確認したければ、同様に生成AIに質問してみるのが良いと思います。
仮に私の説明に納得がいかないならば、自分で生成AIに質問すれば、その話が本当かどうか、確かめられます。
ぜひ、ご自分で生成AIにより、確認してみてください。
今回、生成AIで記事を書いてみて、生成AIはジャーナリズムのあり方を変えてしまう可能性があると感じました。
もし、マスメディアが虚偽の報道をしたとしても、個人が生成AIに質問して事実確認すれば、真実が簡単に確認できるということです。
世間で嘘が吹聴されていても、各個人が生成AIで事実を確認すれば、嘘は通用しなくなります。
この報道における生成AIの役割は、社会に大きな影響を与えるでしょう。
欠点としては生成AIが学習したデータが半年ほど古いという点でしょう。最新情報には対応できません。
今回は、SIer業界の多重請負構造についての解説でした。
多重請負構造とウォーターフォールモデルとの強い結びつきは、日本のユーザー企業にとっても問題だと思います。
ユーザー企業の方々は、ウォーターフォールモデル型・多重請負SIerへの発注が、自社の利益に叶うか、よく検討してみるべきでしょう。
繰り返しになりますが、事実関係の確認は、ご自分で生成AIに 質問して確認してください。
お勧め書籍
ITエンジニアではない、一般のユーザー向けに、ソフトウェア開発プロセスモデルの解説をしている書籍は、非常に少ないです。
私は、もっとたくさんあった方が良いと思いますが、一般ユーザーの開発プロセスモデルに対する認識と意識が低いので、その重要さが世間一般に伝わっていないのでしょう。
数少ないユーザー向けの開発プロセスモデルの解説本の中では、
私は「スクラム － 仕事が4倍速くなる世界標準のチーム戦術」を強くお勧めします。
スクラムとは、アジャイル開発の一つの手法で、トヨタ生産方式の方法論を米国人がソフトウェア開発に導入することで生まれました。
今では、米国のソフトウェア開発は、ほとんどこのスクラムと、もう一つのアジャイル開発手法である、XP(エクストリームプログラミング)で開発されているようです。
この本では、米国でスクラムが生まれた経緯、スクラムで生産性が4倍にもなること、スクラム的なマネジメントの応用事例について解説しています。
アジャイル開発とはどのようなものか、一般ユーザーが理解するには最適の一冊だと思います。
日本の多重請負問題とは別に、マネジメント論として、なぜウォーターフォールモデル開発がダメなのかを上手く解説しています。
お勧めです。
