なぜ日本企業のシステムは"欠陥"だらけなのか…｢多重下請け･その場しのぎ｣の改修を続けてきた重い代償
2025年4月11日（金）8時15分 プレジデント社
※写真はイメージです - 写真＝iStock.com／BrianAJackson
※本稿は、久保努『サステナブルソフトウェア時代 IT産業のニュースタンダードになるもの』（クロスメディア・パブリッシング）の一部を再編集したものです。
写真＝iStock.com／BrianAJackson
※写真はイメージです - 写真＝iStock.com／BrianAJackson
■「業務に合わせたシステム」の盲点
大企業が抱えるレガシーシステムの多くは、基本的にゼロからオリジナルのシステムを開発するスクラッチ開発で構築されています。
実はそれこそが、技術的負債の始まりとなるものです。
たとえばアメリカなどでは、市販のパッケージシステムを主軸にして業務を行い、それが古くなれば新たなパッケージを購入して、システムを一気に刷新します。そうして「業務を都度、システムに合わせる」というのが一般化し、現在も変わりません。
一方の日本では、「業務に合わせたシステムを作る」という考え方が基本でした。そうすると必然的に、パッケージシステムでは補えない独自の機能が数多く求められることになります。それなら、自社専用のシステムをゼロから開発したほうがいい。そんな経営判断によって、スクラッチ開発を選択する大企業がほとんどでした。
スクラッチ開発なら、確かにかゆいところに手が届くようなシステムが完成するかもしれませんが、その一方で開発には相応の時間とコストがかかります。
■15億円かけてもすぐに「時代遅れ」に
開発に3年を要し、15億円のコストをかけ、こだわりぬいた基幹システムを作り上げたとします。減価償却を考えるなら、せめて10年以上は使いたいところです。しかしITの世界は技術の消費期限が早く、過去の常識を塗り替えるような技術が次々と誕生しています。それらを取り入れねば、技術の進歩についていけません。
仮に基幹システムにパッケージを採用しているなら、初期コストもスクラッチ開発ほど大きくはかかりません。アップデートも頻繁に行われますし、数年使ったら新たなシステムに刷新するというアメリカ式のやり方で、十分元が取れます。
しかしスクラッチ開発したこだわりの基幹システムの場合、そう簡単に捨てるわけにはいきません。システムと調和している現行業務も、できる限り変えたくありません。
ですから基幹システムには基本的に手を付けず、新たな機能の部分だけを追加で開発したり、システムの一部のみを更新したりと、いわばつぎはぎをするように機能性を拡張していくという対症療法的なやり方が主流となってきました。
これを長い間続けてきた結果、技術的負債という形で表面化しつつあるのが、現在地です。
■対症療法だけではいつか限界を迎える
長年にわたるシステムの改修と拡張は、複雑化を引き起こします。新しい機能を追加するたびに、既存のコードやデータ構造が変更され、全体の整合性が徐々に崩れていきます。システムの保守や運用がますます困難となり、新たな変更やアップグレードを施すたびに、予期しない障害やトラブルが発生するリスクが高まります。
近年は、新たなパッケージを導入してレガシーシステムと共生させるという選択をする企業も多くありますが、その際もあくまで既存システムをベースに据え、それに合わせて動くようパッケージをカスタマイズするケースが目立ちます。
パッケージは基本的にバージョンアップを繰り返しながら進歩していくものですが、独自にカスタマイズした機能はそうはいかず、何もしなければそのまま取り残されます。
本来なら自社の強みともなる独自機能こそ、頻繁にアップデートをして磨いていくべきですが、それもままならず、いずれメンテナンスすら難しくなっていきます。この独自機能もまた、レガシー化しやすい部分です。
このように既存システムの存続にこだわり、対症療法を繰り返すだけでは、システムはいつか限界をむかえます。
そこで既存システムの全面的な刷新という決断を下したとしても、以前と同じようにスクラッチ開発を選択すれば、再び膨大な時間とコストがかかり、しかも行き着く先は同じです。
こうしたサイクルは、レガシーシステムを抱える日本企業の負の呪縛といえ、DXの推進にも大きな障壁となるものです。
出所＝『サステナブルソフトウェア時代』（クロスメディア・パブリッシング）
■システムトラブルが多い納得の理由
経済産業省のレポートによれば、2018年の時点で約8割の企業がレガシーシステムを抱え、また7割の企業ではそれがDXの足かせになっていると感じているといいます。
このような特性を持つ企業のシステムでは、新たな開発にあたってもトラブルが起きやすくなります。
複雑化したレガシーシステムと新たなシステムを連携し、新技術を取り入れて機能を拡張するのは、そう簡単ではありません。
特に大規模なプロジェクトや高度なシステムの追加構築の際には、計画通りに進むのは稀で、予期せぬ不具合が頻発したり、納期や予算が大幅に超過したりといった問題がよく発生してきました。
■多重下請け構造が足を引っ張っている
レガシーシステムの存在以外にも、システム開発がうまく進まない理由と考えられることはいくつかあります。
日本の企業は、組織間に壁があることが多く、経営層と現場、マーケティング部門とIT部門などでコミュニケーションが不足しているケースがよく見られます。この壁のせいで、要件定義から業務プロセスやニーズが十分に共有されず、開発がある程度進んだ段階で「こんなシステムを求めていたわけではない」といった意見の相違が生まれるなど、トラブルが起きます。
また、システムを使う企業と、それを実際に作る開発会社の間でも、コミュニケーションが不足しがちです。日本のシステム開発は、大手システム開発会社が受注した案件をいくつかの中堅会社に振り、その中堅会社がさらに小さな会社に開発を依頼し……という、いわゆる多重下請け構造のもとで行われてきました。
その中にあって、顧客と実際に話し、要望を聞くのは大手システム開発会社ですが、その詳細な内容が実際に開発を担う会社まで下りてくることはほとんどなく、「この機能がなぜ必要か」が設計書を通じてしか想定できないケースもよくあります。
そうしてクライアントの背景やニーズをはっきり掴めぬまま、「おそらくこうだろう」という見立てでシステム開発を進めていけば、当然ながら出来上がるシステムもクライアントの想定とは違ったものになりがちです。
こうした組織の壁や多重下請け構造に起因するコミュニケーション不足こそが、システム開発がうまく進まぬ最たる理由の一つです。
■納期遅れは企業にとってデメリットだらけ
また、新たな技術や開発手法の導入に慎重な姿勢を示し、あくまで従来の手法にこだわり変化を好まない風土を持つ企業も多く存在します。そういった企業では最新の技術や手法が承認されるまでに時間がかかってしまい、開発が停滞し、納期が遅れることもあります。
システム開発でトラブルが多発すれば、企業の経営にも大きな影響が出ます。
開発期間の延長は追加コストにつながりますし、長期にわたり社内のリソースがトラブル対応に偏れば、そのしわ寄せは他のプロジェクトにも及びます。
納期の遅れはビジネスチャンスの損失にもつながり、企業としての競争力を低下させる要因ともなります。企業内外のステークホルダーからの信頼も揺らぎ、ブランドイメージにも傷がつきかねません。
システム開発におけるトラブルをできる限り減らすには、システムの在り方や開発手法から根本的に見直す必要があるのではないかと、私は考えています。
出所＝『サステナブルソフトウェア時代』（クロスメディア・パブリッシング）
■「ブラックボックス化」が大きな壁に
新しい機能の追加やシステムの改修を行う際の障壁となるのが、度重なる拡張を行ってきた既存システムの中で、ブラックボックス化している部分があることです。
何十年も前に開発されたレガシーシステムは、使われている技術やアーキテクチャが、現在のシステムとまったく違います。
バッチ処理一つをとっても、以前はメインコンピューターで大量のデータをさばくのに適したコンピューター言語を使ってプログラムを動かしていました。しかし現在は、クラウド技術を活用するのに適した言語によってプログラムを動かすのが一般的です。仮にレガシーシステムをクラウド上で動かそうとするなら、言語をそれに合ったものに置き換えねばなりません。
それが可能な場合もありますが、たとえば古くから使われているCOBOLという言語をJAVAに置き換えようとすると、それまで3000ステップで済んでいた処理が一気に数倍に膨れ上がり、処理速度がかなり遅くなります。
このようなクラウドに適した言語への置き換えを実施し、実用に耐えうるようにするには膨大なコストと時間がかかるため、レガシーシステムに大幅に手を入れようとする企業はほぼないのです。
■「古い言語」を扱える人材は減っている
そこで既存システムはそのまま使い続けながら、時代に合わせて新たなシステムを導入するという対症療法が行われることになります。
先ほどの例でいうなら、既存システムは依然としてCOBOLで動き続けるわけですが、すでに誕生から70年近く経つCOBOLを書けるプログラマーの数は減ってきており、メンテナンスができるような人材の多くはすでに退職しているはずです。
企業内のシステム部門や担当者も次々と交代する中で、システムの内部構造や設計思想はいつしか曖昧となり、なんとか引き継がれてきた断片的な知識で運用を行うしかありません。改修にあたっても、すでにブラックボックス化している部分には手を付けることができませんから、大きな変更を加えるのは難しくなります。
この構図は、システムの開発から運用まで一貫して外部ベンダーに任せてきた企業にも当てはまるものです。
■「外注すればいい」がもたらすリスク
システムの内部構造や設計思想について外部ベンダーや企業の一部の社員のみしか理解していない状態では、当然ながらシステムをどのように改修すればよいかがわかりませんから、引き続き外部ベンダーに発注することになります。
しかし、外部ベンダーにおいても古いシステムについて知る人間はどんどん減っています。いずれ保守ができなくなる日が必ずやってくるのです。
それもまた、レガシーシステムの運用における大きな課題の一つです。
外部との関係という観点からいうと、企業の多くは外部のベンダーや情報システム系子会社に、システムの運用や保守を任せていると思います。
「餅は餅屋」の格言通り、専門家に任せること自体は間違いではありませんが、結果として社内にIT技術者がほとんどいなくなってしまうと、問題が起きる可能性があります。
■システムを内製化できた企業は一握り
バブル崩壊やリーマンショックといった過去の不況においては、厳しい経営環境を生き残るため、当時は非中核的な部門とみなされていた情報システム部門のリソースを縮小し、アウトソーシングを加速する動きがありました。
この過程で、情報システム部門が果たす役割もまた変化していきます。社内業務の効率化やデジタル戦略の推進を担う部署から、外部ベンダーが提供するソリューションの調整や監督を行う管理者としての業務を行う部署となったのです。
久保努『サステナブルソフトウェア時代 IT産業のニュースタンダードになるもの』（クロスメディア・パブリッシング）
管理者の役割を担うのに、システムをゼロから作るほどの技術も知識も必要ありません。結果としてIT技術者の能力も役割も低下しているというのが現状でしょう。
情報システム部門の開発力が落ちてくると、新たなシステム開発をアウトソーシングする際にも、技術的な議論がどうしても薄くなり、外部からの提案や判断に依存せざるを得なくなります。それもまた、発注側にとってのブラックボックスが増える要因といえます。
このような課題を踏まえ、一部のDX先進企業はすでにシステムの内製化に舵を切っていますが、そのハードルはなかなか高いようです。
----------
久保 努（くぼ・つとむ）
ラキール社長
1964年生まれ。1988年、株式会社エイ・エス・ティ入社。1999年に株式会社イーシー・ワンで開発部門の責任者に就任。2005年6月に株式会社レジェンド・アプリケーションズを設立。その後株式会社ワークス・アプリケーションズの傘下に入り、取締役に就任。2017年10月、MBOにより独立。2019年に社名を株式会社ラキールに変更し、現職。2021年7月16日、東京証券取引所マザーズ（現·東京証券取引所グロース市場）に新規上場。ソフトウェアをブロックのように組み立てる「部品化」の構想が話題を呼んでいる。
----------
（ラキール社長 久保 努）
関連記事（外部サイト）
