情報システム部門・IT部門が強くなるためのプラットフォーム

攻めの情シス研究所

情シスにノウハウを。
情シスが会社を強くします。

DXの前になぜレガシーシステム整備なのか?

2022

6/14

DXの前になぜレガシーシステム整備なのか?

DXというバズワード

「DXやりたいんです」

ある企業の経営企画部の方から相談がきました。どうやら、社長号令で「待ったなし」のようです。

そもそも「DX」で何がやりたいのかを聞いてみました。

「AI、ビッグデータ、IoT、VR、MR、ロボットなどいろいろあるじゃないですか」

とキラキラとした空気が流れます。

しかし、この企業の状況を聞けば聞くほど、不安が大きくなっていきます。なぜなら「COBOL」というキーワードが出てきたからです。

そうです。この企業は典型的な「レガシーシステム」を抱えていました。

「先に基幹システムを整備しませんか?」と切り出してみましたが、

「確かにやらないといけないのは承知しています。いずれはやるでしょう。でも、今はDXをやらないといけないんです」

と、抵抗されます。背後で指示を出している社長の姿が、うっすらと見えてきました(苦笑)

レガシーシステムの大きすぎる問題

COBOLなどの古い言語で開発され、メインフレーム(汎用コンピュータ)を利用して構築したシステムのことを「レガシーシステム」と呼びます。

このレガシーシステムには、どのような問題があるのでしょうか?
 

(問題点1)品質と保守性の低下

レガシーシステムは10年、20年と使い続けているため「つぎはぎ」だらけで、プログラムはスパゲッティのように絡み合っています。

そのため、調査するだけで時間がかかり、修正するにはさらに時間がかかります。

すると、徐々にシステム本体の修正をあきらめて、「外付け」でシステムを作っていくようになります。

その結果、いくつもの「サブシステム」が乱立し、全体として構成が複雑になっていきます。巨大な「ブラックボックス」ができあがるのです。

こうなると、ちょっとした修正なのにリリース後に思わぬところで障害が発生したりします。サブシステム同士が「密結合」しているため、結局は全サブシステムに影響が発生するからです。

ベンダーは再発防止策を求められ、慎重に調査するようになります。

そのため、ちょっとした調査や修正をベンダーにお願いしても「全サブシステム」を調査することになり、時間がかかり、費用も高くつくようになるのです。
 

(問題点2)保守費用のたれ流しによるIT予算不足

レガシーシステムは「運用・保守」をするだけで、大きな費用がかかります。

定期的なデータのメンテナンス、機能の改修や追加、トラブル対応などで、かなりの予算を「毎年」確保しなければなりません。

ベンダーの工数あたりの単価を計算してみると、大したことをやっていないのに、べらぼうに高かったりします。

システムの保守性が悪いというのもあるのですが、ベンダー営業にも殺し文句があります。

「基幹システムだから何かあってからでは遅いですよね」

これでユーザー企業は、思考停止に陥ります。保守タスクが正当化され、延々と費用がたれ流しになっていきます。

保守費用の垂れ流しは、さらに大きな問題を呼び込みます。

「IT予算」を根こそぎ取られてしまうのです。

そのため「守りのIT」で費用を捻出するのが手いっぱいとなり、「攻めのIT」への予算がまったく捻出できなくなります。

その結果、DXが一向に進まないのです。
 

(問題点3)エクセル問題

ちょっとしたシステム修正でも時間と費用がかかる状態になると、現場のユーザーはどう考えるのでしょうか?

「自分たちで、エクセルでやった方が早い」

現行システムに見切りをつけて、各ユーザーがエクセルを使いだします。エクセルでデータを加工したり、管理したりするようになっていきます。

すると、業務フローのいたるところにエクセルマクロが組み込まれ、業務が「属人化」していきます。

そのため、いつも特定のメンバーだけに負荷が集中し、暇な人もいるのに、まったく「平準化」できなくなってしまうのです。

また、AIやビッグデータも活用できなくなります。

重要な「業務データ」がデータベースではなく、エクセルに散在してしまっているからです。つまり「最新技術」とも接続できないのです。

さらに、エクセルの氾濫は、企業の「セキュリティリスク」も高くなります。

エクセルは、個人のPCに格納され、ローカルで動かせるからです。

顧客リストなど企業にとっての重要なデータが、個人のPCに入ったままだとどうなるのでしょうか?

紛失した場合の情報流出や、そのまま退職して持ちだされることもあるかもしれません。

個人情報の流出は、企業にとって大きなペナルティを払うことになります。
 

(問題点4)事業継続リスク

近年さらに、レガシーシステムの問題を大きくしているのが「人材不足」です。

COBOLなど古い言語で保守できる要員が定年を迎え、どんどん退職しているからです。

かろうじて、現在は定年後の「再雇用」でつなぎとめていますが、数年後は本当に人がいなくなります。

ベンダーとしても、保守案件があるのはうれしいことですが、メンバーをアサインできません。そのため、苦渋の決断をせまられます。

実際に「保守できないので撤退します」とベンダーが去ってしまったケースが起きています。

システムの保守ができなくなれば、法改正等でシステム改修が必要なときに対応できません。ハードウェアが故障しても、ベンダーに助けてもらえなくなります。

それ以前に、日々のトラブルや調査にすら対応できなくなってしまいます。

基幹システムであるがゆえに、システムのトラブルはそのまま業務トラブルに発展します。

つまり企業にとっての「事業継続リスク」が非常に高いということです。
 

(問題点5)最新技術の無力化

重要なデータがレガシーシステムという「ブラックボックス」に格納されていたり、エクセル等に散在している状況では、最新技術の接続が困難になります。

専用の接続APIを作成することは可能ですが、それなりの費用と保守が発生します。

そもそも、IT予算をレガシーシステムの保守にとられているため、中途半端な工数しか確保できません。

さらに、既存の情シスメンバーもレガシーシステムの調査や保守対応に追われているため、なかなか最新技術をキャッチアップする余裕もありません。
 

***

このように、レガシーシステムは「問題だらけ」といえます。

存在しているだけでリスクが大きいのです。ここを見ないフリをして、最新技術だけを追うのは「穴の開いたバケツに水を入れる」ようなものです。

いくらインタフェースだけを最新にしても、データは溜まらず、投資したお金もすり抜けていくだけです。

DXをやるためには、まず「レガシーシステムのリプレイス」なのです。

DXは順番が大事

冒頭の経営企画部の方は、現状のままではDXがうまくいかないことを理解しました。

そして持ち帰って、社長に相談してみるとのこと。

後日、その方から連絡がありました。

「レガシーシステムの見直しも含めてDXだろ!」

と言われたそうです。全くもってその通りなのですが、あれ?最初と話しが違うような(苦笑)

COBOLは使っていない企業でも、5年後、10年後には、現行システムはレガシーシステムになっているかもしれません。

基幹システムが「全体最適化」されていなければ、それはレガシーの始まりです。

貴社の情シス、情報システム部門、IT部門は、レガシーシステムに対応できていますでしょうか?

関連コラム

御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか

情シスコンサルタント
田村 昇平

情シス(IT部門、情報システム部門)を支援するコンサルタント。

支援した情シスは20社以上、プロジェクト数は60以上に及ぶ。ITベンダー側で10年、ユーザー企業側で13年のITプロジェクト経験を経て、情シスコンサルティング株式会社を設立。

多くの現場経験をもとに、プロジェクトの全工程を網羅した業界初のユーザー企業側ノウハウ集『システム発注から導入までを成功させる90の鉄則』を上梓、好評を得る。同書は多くの情シスで研修教材にもなっている。

また、プロジェクトの膨大な課題を悶絶しながらさばいていくうちに、失敗する原因は「上流工程」にあるとの結論にたどり着く。そのため、ベンダー選定までの上流工程のノウハウを編み出し『御社のシステム発注は、なぜ「ベンダー選び」で失敗するのか』を上梓し、情シスにインストールするようになる。

「情シスが会社を強くする」という信念のもと、情シスの現場を日々奔走している。

著書の詳細は、こちらをご覧ください。