TOP>レガシーシステムとは - IT部門が知っておくべき3つのポイント

レガシーシステムとは - IT部門が知っておくべき3つのポイント

レガシーシステムとは - IT部門が知っておくべき3つのポイント

デジタルトランスフォーメーション(DX)に欠かせないのは
モダナイゼーションとデータ連携

レガシーシステムは企業のビジネスを長らく支えてきていますが、経済産業省が2018年9月に発表した『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』 (※) を契機に、モダナイゼーションを検討する企業が増えています。

メインフレームなどレガシーシステムを有する企業は多くあり、そのうち半数以上が構築から20年以上経過する基幹系システムです。DXレポートでは、レガシーシステムが企業の足枷となり、2025年以降には年間で最大12兆円の経済損失を生じさせてしまう可能性が報告されています。さらに2027年には多くの企業が導入している「SAP ERP」の標準サポート終了が発表されています。これらの対応が必要となる現在から2025-2027年は、企業が保持するシステムにとって大きな節目となるのではないでしょうか。

本サイトでは、既存のビジネスにデジタル技術やIT技術を融合させ新しいビジネス価値を実際に生み出すこと、つまりデジタルトランスフォーメーション(DX)を実現することの第一歩となるモダナイゼーションをはじめに、クラウド・ファースト時代のシステムを最大活用する鍵となる「データ連携」について解説します。


レガシーシステム とは

レガシーシステムとは

メインフレーム(汎用機)やオフコンをはじめとする 肥大化・複雑化・ブラックボックス化
などの課題を抱えた、柔軟性や機動性に欠けた最新技術を適用しにくいシステムのことです。


メインフレーム(汎用機)やオフコンをはじめと記載しているのは、オープン系のUNIXやLinux、Windowsベースで構築されているシステムであっても、採用した技術や時間の経過によりレガシーシステム化が発生し得るためです。

例えば下記のようなケースがあります。

 ・プログラムはCOBOLのまま移行したため、
  COBOL技術者への属人化が課題となってしまっている
 ・プログラムをコンバージョンツールでJavaに変換しただけのため、
  プログラムの可読性が低くメンテナンスに課題が生じている

このように近年に構築したシステムでも担当者に依存していたり設計詳細がブラックボックスであったりするシステムは、レガシーシステムと言えます。そのため、既存の資産を活かしながら新しい技術や設計でレガシーシステムを刷新する「レガシーモダナイゼーション」が注目されています。


レガシーシステムの問題点(2025年の崖)

以前からレガシーシステムをモダナイゼーションする動きはありましたが、メインフレーム技術者の定年退職による人材不足を示唆するに留まっていた感があります。しかし今、レガシーシステムへの対応に伴う今後のビジネス影響は大きく変化しています。

レガシーシステムはDXの足かせとなる可能性を指摘され、基幹業務など重要な役割を担うレガシーシステムへの対応次第では市場の変化に柔軟・迅速に対応できず、デジタル競争の敗者になる恐れがあると言われています。つまり、レガシーシステムをモダナイゼーションするかどうかは「生存の問題」になりつつあるということです。

先のDXレポートでは、レガシーシステムへの対応を誤るとDXの実現の妨げになるばかりではなく、2025年以降において最大12兆円/年の経済損失が生じる可能性があると報告されています。これがレガシーシステムへの対応に伴い2025年を乗り越えられるかどうか?という点において「2025年の崖」と言われています。

[ 具体的な問題点 ]

上記のような問題点が自社システムに当てはまる際には、そのシステムは技術的負債となっている可能性があります。企業活動の要となっているシステムを刷新することは多大な労力やコストを要しますが、技術的負債に対し適切に向かい合い、対応をはじめることをおすすめいたします。


レガシーモダナイゼーションにおけるポイント

「レガシーシステム刷新時のポイント」と「新システムの効果を引き出すためのポイント」となることはどんなことでしょう? ここでは、3つのポイントを解説します。

ポイント1 現行機能・性能を担保したモダナイゼーション

現行機能・性能を担保したモダナイゼーション

レガシーシステムのモダナイゼーションには、大きくわけて下記3つの方式があります。

● アプリケーションやミドルウェアなどの設定はそのままでインフラのみを刷新する「リホスト」
● 業務の流れや使い方などゼロベースで再構築する「リビルド」
● 既存のアプリケーションを新しい開発言語/ツールに書き換える「リライト」

リライトは、リホストのように古い言語などの技術的負債を残さず、リビルドのように過剰に新たな要件が発生するリスクが少ないため、安全かつ短期間にシステムをモダナイズできる手法となっており、実際に採用されることの多い手法です。

リライトでモダナイゼーションする際、既存のソースコードを新しい開発言語/ツールで置き換え、想定の出力結果を作成することが先行しがちで、処理性能という観点が後回しになってしまうことがあります。しかし、メインフレームで顕著なのは、基幹業務として重要なバッチ処理が多く稼働している点です。バッチ処理は、メインフレームといったパワフルなマシンでさえ大量のリソースを消費する傾向にあるため、プロジェクト終盤の本番データ量を想定したテストや運用開始後に性能問題が顕在化するケースがあります。

そのため、新しい開発言語/ツールで機能要件を満たすことに加え、(特にバッチ処理の)性能の担保が忘れてはならないポイントとなります。


ポイント2 モダナイゼーションにおけるデータ移行

モダナイゼーションにおけるデータ移行

システム刷新に伴い必要となる作業がデータ移行です。データ移行の際は新旧双方のシステムを理解し、移行すべきデータを確定することからはじめます。移行データを確定させた後は、データ移行用の処理プログラムを開発します。

新システムに合わせたデータ加工・変換を行う場合、正しいデータが作成できているかどうか、突き合わせなどにより確認作業が必要になります。大まかな手順だけではそれほど大変な作業でないように写りますが、対象データの本数が1,000~10,000と膨大であったり、データ容量が大きかったりすると、データ移行の工数は非常に多くの工数を要し、システム刷新のプロジェクト総工数の約40%がデータ移行に関連するとも言われています。

2027年で標準サポート終了が決定しているSAP ERPを移行する際も、データ移行手法の検討はついてまわります。SAP社ツールであるABAPでデータ移行プログラムを開発することはできますが、スキルを持つ要員の不足によりアサインが困難なことや、一概に生産性が高いとは言えないこと、システムの移行に伴うダウンタイムをどう許容し最小化するかなど課題は多々あります。

そのため、データ移行のためのアプリケーション開発工数を最小限に抑え、最低限の移行時間で済む手法を検討することは大いに重要なポイントとなります。


ポイント3 システム最大活用のためのデータ連携

システム最大活用のためのデータ連携

「クラウド・ファースト」というキーワードが使われ、クラウドサービスの積極的な利用が加速する背景から、刷新後のシステムをクラウドへ移行する企業が増えています。またSaaSを中核としたクラウドネイティブなシステムデザインにチャレンジする企業もあります。その際、オンプレミスにその他の既存システムが存在している場合もあるでしょう。

つまり、企業システムにはオンプレミスとクラウドの両方にシステムが存在する形となります。さらにクラウドにおいては、IaaSやSaaSなどシステムの形態が多様化しています。

このように多様なシステムが散在した場合、データ連携せずにシステムを孤立させてしまうと、サイロ化に陥ります。サイロ化した場合、そもそも必要なデータが足りていなかったり、システムごと個別にデータを揃えるのに工数がかかったりする状況が発生し、せっかくのモダナイゼーションした新システムを最大活用できません。そのため、データ連携の検討はデジタルトランスフォーメーション(DX)に欠かせない重要なポイントです。

データ連携のプログラムは、連携するクラウドサービスやアプリケーションごとにスクラッチで開発することもできます。しかし、スクラッチ開発はクラウドサービスごとに適切なAPIの特性を習得しなければならず、開発/運用コストが増えてしまう可能性があります。また、その部分が属人化してしまえば、ブラックボックス化へ逆戻りしてしまう可能性もあります。

そんなデータ連携の柔軟性の乏しさを解消するため、スクラッチではなくツールによりデータ連携を実装する企業が増えています。


レガシーモダナイゼーションを実現した3社の成功事例

アシストでは上記で挙げたポイント1の「バッチ処理」ポイント2の「データ移行」ポイント3の「データ連携」において、長年に渡ってお客様をご支援しています。
多数ある事例の中から、代表的なお客様事例を3つご紹介します。

レガシーシステムのオープン化では、バッチ処理性能が鍵となる

拡張性が乏しく、業務の要求に迅速に対応できないホストをモダナイゼーションするプロジェクトを発足。膨大な件数のバッチ処理をPL/SQLで開発したものの、期待した性能が出ないことが発覚しました。

基幹業務が停止すると約2兆円に相当する商品が安定供給されないという危機的状況で、バッチ処理時間を1/4以下に短縮し、遅延の許されない基幹システムの安定運用を実現した手法とは?

達成困難と思われた大量データの超高速処理を実現。商品の安定供給を支える基幹システムの運用を強力にサポートした事例

SAP2027年問題を乗り切る術とは

2027年には、「SAP ERP」のメインストリームサポートが終了します。
この機会にクラウドやAIなどの技術を取り込むポストモダンERPを目指し、S/4 HANAや他ERPへの変更を検討される企業が出てくるでしょう。

その際、必ず発生するのは「SAP ERP」からのデータ移行です。
ダウンタイムは短く、コストは低くデータ移行する手法とは?

SAP技術者のリソース不足解消とシステム移行効率化に貢献、SAP S/4HANA導入を成功に導いた事例

クラウドサービスとデータ連携するためのWebAPIはもう学ばなくていい

DX実現のために戦略的なIT活用が求められている中、クラウドサービスと既存のシステムを有機的に素早くつなぐ仕組みが求められています。そんなとき強い力を発揮するのがWebAPIです。

WebAPIにはRESTやSOAPなどがありますが、これを駆使できる技術者をデータ連携処理が必要なたびにアサインできるかというと、現実は厳しいものです。人員不足でもスピード感を持って、クラウドサービスとのデータ連携処理をつくる手法とは?

データ連携を中核としたファストシステムでデータの利活用を促進し、グループの生産性向上を実現した事例


モダナイゼーション、データ連携おすすめ記事
2025年の崖とバッチ処理との関係 SAP 2027年問題、S/4HANAへの移行方法について考察 いまさら聞けない!?「WebAPIとは?」から、利用方法までご紹介します
2025年の崖と
バッチ処理との関係
SAP 2027年問題、S/4HANAへの移行方法について考察 いまさら聞けない
「WebAPIとは?」
-基礎・利用方法・API連携-
バッチ処理のかたまりともいえるレガシーシステムを性能を担保しながらマイグレーションするにはどうしたらよいでしょう?
SAP 2027年問題に向けて、SAP ERPからS/4HANAへの効率的なデータ移行の方法について解説します
「WebAPIって一体なに?」「RESTとSOAPの違いはなに?」「活用方法は?」などをわかりやすく解説します
 
システム間のデータ移行時によくある課題と解決策 データ連携処理を構築するベストプラクティスとは? バッチ処理の基礎-リアルタイム処理との違いにも迫る!
システム間のデータ移行時に
よくある課題と解決策
データ連携処理を構築する
ベストプラクティスとは?
バッチ処理の基礎-
リアルタイム処理との
違いにも迫る!
異なるプラットフォームやデータベース間でのデータ移行、移行時にデータモデルが変更するケースなど、データ移行時によくある課題とその解決策とは?
データ連携処理を開発する際の選択肢を挙げてそれぞれ比較しながら、データ連携処理構築時のベストプラクティスを探ります
バッチ処理の基礎からリアルタイム処理との違いまで、わかりやすく解説しています


データ連携に関する自社要件を整理できる資料&ワークシートをプレゼント!

クラウドやオンプレミスなどシステム間のデータ連携や多種多様なデータの扱いなど、データ処理に伴う要件は複雑化しています。 システムにおけるデータ処理をどのような手法で実装しますか?

実装方式としては、プログラム言語によるスクラッチ開発やETLやEAIツールでの対応が考えられ、検討の際には一律に機能比較を行なうケースがよく見受けられます。しかし、機能だけを比較しても、それが自社の要件を満たすものなのか?がわかりません。


データ連携ツール初めての検討

◆ ツールの特性把握
◆ 適合性を測るための要件整理
◆ ツール選定における比較/評価軸
など、ツールでのアプローチを検討する上で参考となるポイントをまとめた資料&ワークシート(Excel)です。

自社がデータ連携を実装する本来の目的、例えば各工程での属人化排除や生産性向上などを踏まえながら、自社にとって大事な要件となることはどんなことか?本資料を使ってぜひ整理してみてください。

資料をダウンロード




データ連携に関するご相談はアシストにおまかせください!


ページの先頭へ戻る