なぜ日本企業でシステム障害が相次いでしまうのか。システム開発・運用基盤「LaKeel DX」で企業のDXを支援するラキールの久保努社長は「既存システムの存続にこだわり、対症療法的なシステム改修を繰り返してきた結果、システム全体の整合性が崩れ、予期しない障害やトラブルが発生するリスクが高まっている」という――。

※本稿は、久保努『サステナブルソフトウェア時代 IT産業のニュースタンダードになるもの』（クロスメディア・パブリッシング）の一部を再編集したものです。

HELPの旗を掲げてラップトップで頭を隠すサラリーマン
写真＝iStock.com／BrianAJackson
※写真はイメージです
全ての画像を見る（4枚）

「業務に合わせたシステム」の盲点

大企業が抱えるレガシーシステムの多くは、基本的にゼロからオリジナルのシステムを開発するスクラッチ開発で構築されています。

実はそれこそが、技術的負債の始まりとなるものです。

たとえばアメリカなどでは、市販のパッケージシステムを主軸にして業務を行い、それが古くなれば新たなパッケージを購入して、システムを一気に刷新します。そうして「業務を都度、システムに合わせる」というのが一般化し、現在も変わりません。

一方の日本では、「業務に合わせたシステムを作る」という考え方が基本でした。そうすると必然的に、パッケージシステムでは補えない独自の機能が数多く求められることになります。それなら、自社専用のシステムをゼロから開発したほうがいい。そんな経営判断によって、スクラッチ開発を選択する大企業がほとんどでした。

スクラッチ開発なら、確かにかゆいところに手が届くようなシステムが完成するかもしれませんが、その一方で開発には相応の時間とコストがかかります。

15億円かけてもすぐに「時代遅れ」に

開発に3年を要し、15億円のコストをかけ、こだわりぬいた基幹システムを作り上げたとします。減価償却を考えるなら、せめて10年以上は使いたいところです。しかしITの世界は技術の消費期限が早く、過去の常識を塗り替えるような技術が次々と誕生しています。それらを取り入れねば、技術の進歩についていけません。

仮に基幹システムにパッケージを採用しているなら、初期コストもスクラッチ開発ほど大きくはかかりません。アップデートも頻繁に行われますし、数年使ったら新たなシステムに刷新するというアメリカ式のやり方で、十分元が取れます。

しかしスクラッチ開発したこだわりの基幹システムの場合、そう簡単に捨てるわけにはいきません。システムと調和している現行業務も、できる限り変えたくありません。

ですから基幹システムには基本的に手を付けず、新たな機能の部分だけを追加で開発したり、システムの一部のみを更新したりと、いわばつぎはぎをするように機能性を拡張していくという対症療法的なやり方が主流となってきました。

これを長い間続けてきた結果、技術的負債という形で表面化しつつあるのが、現在地です。