メニュー

公開日:
9 min read
技術文化史

失われた品質基準:技術国家敗戦の記録 第3部 - 2000年代エンジニアリング空洞化の始まり

失われた品質基準:技術国家敗戦の記録 第3部 - 2000年代エンジニアリング空洞化の始まりのイメージ

よくある質問 (FAQ)

2000年代に日本が選んだ道は何でしたか?

SIerが「ソリューションビジネス」へ転換し、インド・中国へのオフショア開発が本格化しました。PMBOKが流行して管理者SE、ブリッジSEの大量生産が行われ、市場要求が「品質」から「納期短縮」へと変化しました。

SIerのソリューションビジネス転換とはどのようなものでしたか?

システム開発の技術者は「ITコンサルタント」や「ソリューションアーキテクト」と呼ばれるようになりましたが、実態は技術的な深度を犠牲にした表面的な提案力重視でした。自社開発から既存パッケージの組み合わせとカスタマイズに軸足を移し、根本的な技術力よりも「調整力」が重視されるようになりました。

オフショア開発本格化による影響は何でしたか?

人件費削減を目的としたインド・中国への大量発注が急速に進み、当初は単純な実装業務から始まったが徐々に設計業務まで委託されるようになりました。ブリッジSEという新職種が誕生しましたが、技術的理解よりもコミュニケーション能力が優先されました。距離と言語の壁により従来の日本的品質管理手法が機能しなくなり、詳細な仕様書作成が求められるようになったが逆に現場の技術力低下を招きました。

筆者が現場で目撃した設計力の低下とは?

画面遷移図さえまともに書けない設計書が増え、基本的なシステム設計ができない技術者が急増しました。過去のプロジェクトの設計書をコピーして表面的に変更するだけの「設計書」が横行し、システムの整合性や拡張性は完全に無視されました。

技術者の役割はどのように変化しましたか?

「SE」と名乗りながら実際はガントチャートの管理と会議の調整しかできない人材が大量に生産されました。技術的な判断はできず、問題が発生すると「仕様です」で逃げるのが常態化しました。PMBOKが導入されましたが、現場では形式的な書類作成に終始し、本来の目的である「プロジェクトの成功」ではなく「書類の完成」が目標になってしまいました。

技術継承の断絶とは具体的に何を指しますか?

システム設計の原理原則(なぜそのような設計にするのか、どのような考慮事項があるのかという基本的な思考プロセス)が継承されなくなりました。品質管理の実践的ノウハウは形式的な書類作成に置き換えられ、トレードオフを理解し状況に応じて最適な技術選択をする技術的判断力が育成されなくなりました。

筆者が選択した道とその結果は?

インドオフショアのマネジメント業務、炎上確定の劣悪な設計書案件、エンジニアリングを捨てて管理者になる道を断りました。技術者として一貫した選択をした結果、大口顧客を失い、リーマンショックや東日本大震災もあって会社を清算することになりました。しかし、この経験がのちに経営コンサルタントとして生きることになったと述べています。

第2部「90年代後半の品質文化空洞化」では、バブル崩壊と外部環境の激変により、日本IT企業の品質文化が複合的要因で空洞化していく過程を記録した。

第3部では、2000年代に入って始まったエンジニアリング空洞化の実態と、現場で目撃した技術継承の断絶を述べる。

2000年:エンジニアリング空洞化の始まり

2000年から何が起きたか。 私は現場で目撃した。

日本が選んだ道

  • SIerが「ソリューションビジネス」へ転換
  • インド・中国へのオフショア開発が本格化
  • PMBOKが流行:管理者SE、ブリッジSEの大量生産
  • 市場要求が「品質」から「納期短縮」へ

SIerのソリューションビジネス転換

2000年代初頭、大手SIerは一斉に「ソリューションビジネス」へと舵を切った。

技術者からコンサルタントへの転換: システム開発の技術者は「ITコンサルタント」や「ソリューションアーキテクト」と呼ばれるようになった。 しかし実態は、技術的な深度を犠牲にした表面的な提案力重視だった。

パッケージソフト中心のビジネスモデル: 自社開発から既存パッケージの組み合わせとカスタマイズに軸足を移した。 これにより、根本的な技術力よりも「調整力」が重視されるようになった。

オフショア開発の本格化

インド・中国への大量発注: 人件費削減を目的とした海外への開発業務移管が急速に進んだ。 当初は単純な実装業務から始まったが、徐々に設計業務まで委託されるようになった。

ブリッジSEという新職種の誕生: 日本と海外開発チームの橋渡し役として「ブリッジSE」が重要視された。 しかし、多くの場合は技術的理解よりもコミュニケーション能力が優先された。

品質管理の困難: 距離と言語の壁により、従来の日本的品質管理手法が機能しなくなった。 その結果、より詳細な仕様書作成が求められるようになったが、逆に現場の技術力低下を招いた。

私が見た崩壊の現場

この時期、私は複数の現場で信じられない光景を目撃した:

設計力の著しい低下

画面遷移図さえまともに書けない設計書: 基本的なシステム設計ができない技術者が急増した。 画面の遷移関係すら整理できず、データベース設計に至っては破綻している案件が頻発した。

コピー&ペーストによる設計書量産: 過去のプロジェクトの設計書をコピーして、表面的に変更するだけの「設計書」が横行した。 システムの整合性や拡張性は完全に無視された。

技術者の役割変化

エンジニアなのにスケジュール管理しかできない人材の増加: 「SE」と名乗りながら、実際はガントチャートの管理と会議の調整しかできない人材が大量に生産された。 技術的な判断はできず、問題が発生すると「仕様です」で逃げるのが常態化した。

PMBOKの盲信: プロジェクトマネジメントの体系的手法として導入されたPMBOKが、現場では形式的な書類作成に終始した。 本来の目的である「プロジェクトの成功」ではなく、「書類の完成」が目標になってしまった。

エンジニアリングの欠如

フリーランスにも一般化したエンジニアリング軽視: 正社員だけでなく、本来技術力で勝負すべきフリーランスエンジニアにも、エンジニアリングを軽視する風潮が広がった。 「動けばいい」「仕様通りであればいい」という考えが蔓延した。

技術的負債の概念の欠如: 将来の保守性や拡張性を考慮しない、その場しのぎの実装が当たり前になった。 技術的負債という概念すら知らない技術者が増加した。

技術継承の断絶

私は若くして同世代では担当できない業務をいくつも担当できたので、技術的にはラッキーだった。 しかし、その結果として痛感したのは、今のオフショア人材にエンジニアリングを伝授できる人材が、ほとんどいないという現実だった。

継承されなかった技術

システム設計の原理原則: なぜそのような設計にするのか、どのような考慮事項があるのかという基本的な思考プロセスが継承されなくなった。

品質管理の実践的ノウハウ: 第1部で記録したような厳格な品質管理手法は、形式的な書類作成に置き換えられ、実践的なノウハウは失われた。

技術的判断力: トレードオフを理解し、状況に応じて最適な技術選択をする能力が育成されなくなった。

実際、フリーランスの多くもエンジニアリングを知らないし分かっていない。

私の選択と代償

この流れの中で、私は以下を断った:

断った案件

  • インドオフショアのマネジメント業務
  • 炎上確定の劣悪な設計書案件
  • エンジニアリングを捨てて管理者になる道

その結果

技術者として一貫した選択をしたことは、今でも正しかったと思っている。 別に後悔はしていない。

結果として大口顧客を失い、代替となる売上は見つかったかのように思えたが、騙されたり裏切られたりして、リーマンショックや東日本大震災もあって、会社を清算した。

そもそも私は経営者に向いていなかった。 エンジニアとしての矜持を捨て、売上のためにエンジニアリングを軽視する道を選ぶのが、経営者たるものだろう。 ところが、2010年代は資金繰りに追われて、エンジニアリングなど考える余裕がなくなった。 この経験が、のちに経営コンサルタントとして生きることになったのは、皮肉なことである。

第4部への橋渡し

2000年代のエンジニアリング空洞化により、日本のIT業界は技術的基盤を失った。

その結果が、2025年現在の絶望的な状況として現れている。 データが示す業界の崩壊、構造的な三重苦、そして記録を残す責任について、第4部で述べる。