レガシーシステム / レガシー連携

「レガシーシステム / レガシー連携」

データ活用やDX成功に必要な考え方を、各種キーワードの解説で理解できる用語解説集です。
今回は、現実的なIT利活用で避けられない要素である「レガシーシステム」や「レガシー連携」について考えてみましょう。

レガシーシステムとは

レガシーシステム（Legacy system）とは、古くから使われているITシステムや、最新技術ではない技術を使っているITシステムのことを指す言葉です。新しい技術を採用したITシステムへの置き換えができていない状況を、良くない状況として話題にする時に使われることが多い言葉です。
IT利活用において、以前からあるIT資産との共存は現実的に避けられないことでもあります。レガシーシステムとどのようにかかわるかは、現実的なIT利活用を考えるにあたって避けられないテーマでもあります。

レガシーシステムとは具体的にどういうものか

世間的にレガシーシステムとして話題になりやすいのは、今でもなおメインフレームで稼働しているITシステムのイメージではないかと思います。AS/400などのIBM iシステム上で稼働し、COBOLなど当時の技術で開発されているような業務システムが代表的なイメージかもしれません。

メインフレーム以外にもレガシーシステムとして語られる状況があります。例えば、20世紀末に多く開発されたWindowsを用いたクライアントサーバ型のシステムや、古いUNIXで開発されたシステム、さらには古いバージョンのPHPで開発されてそのまま稼動しているシステムもレガシーシステムと呼ばれることがあります。Excelで開発されて業務で活用されているツールが、Excelレガシーと呼ばれていることもあります。

これらは、古くからある技術により開発され使われているシステムであり、昔に導入したハードウェアで今でもまだ使われている例であり、あるいは今はサポート切れしている基盤や技術を用いているシステムでもあります。このような、新しいITにしないんですか？と言われることもありそうな状況が「レガシー」と呼ばれる傾向があるように思います。

レガシーシステムはなぜ良くないと言われているか

ではなぜ、レガシーシステムは問題であるとする意見があるのでしょう。

まず、新しい時代のニーズへの対応がうまくできず、IT活用が成果を上げることを妨げてしまうことがあります。例えば、営業が出先から業務システムを使えれば業務効率もお客さんへのレスポンスも大きく改善すると考え、業務システムをスマホ対応させたいと思ったとします。しかし業務システムがメインフレームで動いているなら、このようなニーズへの対応が困難になってしまうことがあります。

古いハードウェアは維持コストそのものが高くなる傾向もあります。例えば、メインフレームはハードウェアの維持費が高くなってしまう傾向があります。高信頼性であることなどコスト以外の属性と併せて考える必要もありますが、新しいITと比べると性能面でもコスト面でも大きく見劣りすることがあります。

また、レガシーシステムにはサポート切れの問題もあります。例えば、Windows98を使ったクラサバがまだ使われている状況や、Windows2000を使った制御システムが工場で稼働しているなど、開発当時のソフトウェアがそのまま使われていてとっくにサポート切れになっていることがあります。セキュリティ上の問題が発生しやすくなります。

古い技術が用いられているとエンジニアの確保が難しいこともあります。例えば今になって、Windows98の時代に開発されてそのまま使われているクラサバ（クライアントサーバシステム）のシステムを改修しよう思ったとして、当時使われていたプログラミング言語（Visual Basic 6やDelphiなど）で、きちんとした開発ができるエンジニアを確保することは容易ではありません。

よくあるレガシーシステム対策と失敗

もちろん古いシステムだからといってただちに問題であるわけではありません。システムに古さはあるものの、日々の業務で特に問題なく使い続けられていることもあります。しかし、ここまでで説明したような問題や不便が生じているならば、新しいシステムへの刷新が望まれることになります。

レガシーシステムを今の時代に即した新しいITにする取り組みは「レガシーマイグレーション」と呼ばれます。しかしながらレガシーマイグレーション、取り組んでみたもののうまくいかず失敗してしまうことがよくあります。

システムの書き直しが難しいことがある

例えば、COBOLで開発されたレガシーシステムをJavaなどの新しい技術で作り直そうとするような状況では、旧システムはブラックボックス状態になっており現行のシステム仕様がわからなくなっていることが珍しくありません。

何とか苦労をして現状の仕様を解読したとして、Javaで実装しなおすのにはコストがかかりますし、調査できなかった仕様が実装から漏れてしまい、新システムが業務で問題を起こしてしまうこともあります。しかも苦労してJavaに書き換えても、新システムに新しい機能が付くわけではなく、コストをかけるメリットが理解しづらいこともあります。

自動変換はうまく機能しないことが多い

COBOLをJavaに自動変換するような方法で、レガシーシステムの移行が取り組まれることがあります。しかし、そのような方法での移行はメンテナンス不能状態を作り出すことがあります。

Javaへの自動変換ツールは、COBOLのソースコードから設計意図を解読してJavaとして自然な形で再設計しなおして出力するわけではないため、出力されるのは「COBOLのようなJavaのソースコード」という厄介なものか、あるいは単に人には読解困難なソースコードになります。そうなるとCOBOLエンジニアにはJavaだから読めず、JavaエンジニアにもJavaとしては不自然なので読めない、と誰にもメンテナンスできないものになってしまうことがあります。

パッケージ製品などへの移行は困難を伴うことが多い

パッケージソフトウェアが導入されて社の業務システムを一新しようとすることもあります。あるいは最新のクラウドサービスへの移行で問題を一掃しようとすることがあります。しかしこの取り組みも大失敗しやすいことで知られます。

レガシーシステムには現状の自社の業務の事情がしっかり作りこまれていることがよくあります。パッケージ製品やクラウドサービスには、そのような自社への高度な配慮はありませんから、導入後に業務が回らなくなってしまうことがよく起こります。

あるいは汎用の製品を自社業務で使えるようにするため、大量のカスタマイズが必要になってしまうこともあります。結果、果敢に新システムに移行したはずが、業務がまわらなくなってしまい、旧システムに戻さざるを得なくなることがあります。

理由も無しに古いシステムが使われているわけではない

レガシーマイグレーションが特に難しいことではないのなら、世の中のITシステムは「問題がある」とか「新しいITにしたい」と判断され次第、新しいITに移行してそれで済んでいるはずです。

古いITをレガシーと呼んでダメだと言い、新しいITを称賛するだけならば簡単な話です。「問題はあるけれども、移行に取り組んでも失敗しやすい」ような判断が難しい状況こそが「レガシーシステム」という言葉が使われている本当の事情です。

「レガシー」は悪い意味だけではない

IT方面では悪い意味で使われることが目立つ「レガシー」という言葉ですが、言葉そのものには本来そのような意味はありません。レガシー（Legacy）は「遺産」という意味で、過去から未来にうけつがれてきたものくらいの意味しかありません。

例えば、2020年開催の東京オリンピックにおいて「オリンピックレガシー」という言葉がよく使われていましたが、「未来に厄介ごとを残そう」という話では当然ありません。オリンピック開催のために整備した施設などを、「オリンピックが遺した資産（レガシー）として未来の人たちに役立ててもらいたい」ということで、使われていた言葉でした。

長く使われているITシステムは、長い間きちんと役に立ってきたからこそ使われ続けています。古いシステムが純粋にマイナスの存在であるだけなら、単にすぐ廃止すればいいだけです。

レガシー連携：新旧システムを組み合わせればよい

むしろ、旧システムがきちんと役に立っている現実があるからこそ、レガシーシステム問題が起こっていると考えられます。廃止しても特に支障のないレガシーシステムであれば廃止すればよいだけで問題になどなりません。

さてそこで考えたいのが、旧システムの恩恵、本当に切り捨てるしかないのか、ということです。良いものを良い形で残せるなら健全な意味でのレガシーにもなりうるはずです。

無理をして新システムに移行せず、旧システムの良いところは残す形でITのモダナイズを行う方法があります。新旧システムの良いところを組み合わせる選択肢です。具体的には、新システムとレガシーシステムを「連携」させて活用する取り組み方です。

旧システムをスリムアップする

レガシーシステムには良い部分と悪い部分、移行が容易な部分と困難な部分があります。これらを整理して「良い部分」や「業務に必須だが移行が現実的ではない」だけを整理してコンパクトにし、スリムな形で残すことを考えます。

新しいITを導入する

クラウドサービスの活用など、今の時代にあわせたITを導入します。そちらで済む業務などは新システム側に業務を移行し、新しいシステムならではのIT活用（モバイルの活用など）にも取り組みます。しかし新システムには旧システムのプラスのレガシー、過去から積み上げてきたエッセンスに欠いていることがあります。

新旧システムを「連携する」

良いところだけ残してスリムにしたレガシーシステムと、新システムと「連携」させます。それにより両システムのデータや機能を組み合わせて利用します。新システムに一気に移行するコストや苦痛を引き受けることなく、新旧システムの良いところを合わせて活用できるようになります。

新旧システムの組み合わせでのミラクルな例

新旧システムを組み合わせる考え方は、仕方がない状況での妥協案や折衷案的に思えるかもしれませんが、状況によっては素晴らしい効果を生むことがあります。

「新旧システムを組み合わせる」考え方は、仕方がない状況での妥協案や折衷案的に思えるかもしれませんが、状況によってはむしろ「素晴らしい結果を生むきっかけになる」ことすらあります。

例えば、今でもメインフレーム（AS/400やIBM iなど）があってCOBOLで書かれたシステムが長年使われており、社内技術者もCOBOLエンジニアしかいないとします。実際のところ、そのような状況は今でも珍しくありません。「古いITは廃止すべきで、新しいITへの全面移行をしなければいけない」という思い込みで考えると、問題解決が困難な難しい状況に思えるかもしれません。

しかし、考えてみてください。本当にそれ以外の選択肢は悪い選択肢なのでしょうか？上手にレガシーを残して「新しいITとは連携すればよい」と考えると新しい可能性が広がってきます。

例えば、kintoneとメインフレームを連携させることで、一足飛びにkintoneを業務で使いこなしている先進的なIT活用に足を踏み入れることができます。Salesforceを連携させることで、営業活動と生産活動を高度に組み合わせた取り組みが一気に実現できるかもしれません。しかも、業務を盤石に支えているメインフレームの安定稼働の強みや安心感と組み合わせてです。

このような、「一足飛びに最新のものを導入して成功する」取り組み方は、「発展途上国で固定電話回線や電力の整備すらおぼつかない状況から、一気にスマホや4G通信などが一気に普及した」現象でもみられるもので、このような「大逆転を実現する取り組み方」には「リープフロッグ現象」という名前もついています。

⇒リープフロッグ現象（leapfrogging）｜用語集

「新旧システムを組み合わせる」考え方には、苦労することが多い人員確保の面でもメリットがあります。

クラウドサービスなら自社でのシステム運用も不要ですし、上記で例として挙げたような現場ユーザが利用するタイプのクラウドなら「レガシーシステムを担当しているエンジニア」や「社内情シス」でも十分に使いこなせることが多く、新しい人員の確保すら必要ないことがあります。最終的にレガシーシステムをなくしたいのだとしても、このような中間段階を経てから段階的に廃止する取り組みのほうが現実的なことは多いと思います。

レガシー連携を自在に実現する、「つなぐ」技術

新旧システムの連携による「レガシー連携」がレガシーシステム対策において、大変な切り札であることはわかった。しかし、どうやって連携処理を実現するのか？エンジニアも確保できていないのに、本格的なプログラミングを必要とする連携処理の開発など自社には無理なのではないか？と思われたかもしれません。

しかし、このような各種の「連携処理」を、「GUIだけ」で効率的に開発できる手段が存在します。「EAI」や「ETL」、「iPaaS」と呼ばれる、「DataSpider」や「HULFT Square」などの「つなぐ」技術です。これらを活用することで、新旧システムをスムーズかつ効率的に連携させることができます。

GUIだけで利用できる

通常のプログラミングのようにコードを書く必要がありません。GUI上でアイコンを配置し設定をすることで、多種多様なシステムやデータ、クラウドサービスへの連携処理を実現できます。

「GUIで開発できる」ことは長所でもある

GUIだけでのノーコード開発は、本格的なプログラミングに対して簡易で妥協的な印象を受けるかもしれません。しかしながら、GUIだけで開発できることは「業務の現場の担当者が自分たち自身で主体的にクラウド連携に取り組む」ことを可能にします。

ビジネスのことを一番良くわかっているのは現場の担当者です。その「一番わかっている人たち」が自分たち自身で、クラウドの導入や活用、データ活用や業務の自動化について、実現が必要なことをどんどん作りこめるのは、何かあるたびにエンジニアに説明してお願いしないと開発できない状況よりも、優れているとも言えます。

本格的処理を実装できる

「GUIだけで開発できる」ことを謳っている製品は沢山ありますが、そういう製品に簡易で悪い印象を持っている人もおられるかもしれません。

確かに、「簡単に作れるが簡易なことしかできない」「本格的処理を実行しようとしたら処理できずに落ちてしまった」「業務を支えられるだけの高い信頼性や安定稼働能力がなくて大変なことになってしまった」ようなことは起こりがちです。

「DataSpider」や「HULFT Square」は、簡単に使うこともできますが本格的プログラミングと同等のレベルの処理の作りこみもできます。内部的にJavaに変換されて実行されるなど本格的プログラミングと同様の高い処理能力があり、長年にわたって企業ITを支えてきた実績もあります。「GUIだけ」の良さと、本格的能力の両方を兼ね備えています。

iPaaSなので自社運用不要

DataSpiderなら自社管理下のシステムでしっかりと運用できます。クラウドサービス（iPaaS）のHULFT Squareなら、このような「つなぐ」技術そのもの自体もクラウドサービスとして自社運用不要で利用でき、自社での導入やシステム運用の手間がなく利用できます。

関係するキーワード（さらに理解するために）

EAI
- システム間をデータ連携して「つなぐ」考え方で、様々なデータやシステムを自在につなぐ手段です。IT利活用をうまく進める考え方として、クラウド時代になるずっと前から、活躍してきた考え方です。
ETL
- 昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
iPaaS
- 様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。

「iPaaS」や「つなぐ」技術に興味がありますか？

オンプレミスにあるITシステムからクラウドサービスまで、様々なデータやシステムを自在に連携し、IT利活用をうまく成功させる製品を実際に試してみてください。

「つなぐ」ツールの決定版、データ連携ソフトウェア「DataSpider<」および、データ連携プラットフォーム「HULFT Square」

当社で開発販売しているデータ連携ツール「DataSpider」は長年の実績がある「つなぐ」ツールです。データ連携プラットフォーム「HULFT Square」はDataSpiderの技術を用いて開発された「つなぐ」クラウドサービスです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発できるので、自社のビジネスをよく理解している業務の現場が自ら活用に取り組めることも特徴です。

DataSpider / HULFT Squareの「つなぐ」技術を試してみてください：

簡易な連携ツールならば世の中に多くありますが、GUIだけで利用でき、プログラマではなくても十分に使える使いやすさをもちつつ、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」を備えています。

IT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。無料体験版や、無償で実際使ってみることができるハンズオンも定期開催しておりますので、ぜひ一度お試しいただけますと幸いです。

無料製品紹介セミナーはこちら

「HULFT Square」で貴社のビジネスが変えられるか「PoC」をしてみませんか：

貴社のビジネスで「つなぐ」がどう活用できるのか、データ連携を用いた課題解決の実現可能性や得られる効果検証を行ってみませんか？

SaaSとのデータ連携を自動化したいが、その実現可能性を確認したい
データ利活用に向けて進めたいがシステム連携に課題がある
DXの実現に向けてデータ連携基盤の検討をしたい

PoCプログラム | HULFT Square | セゾンテクノロジー