ローコード開発コラム
経済産業省の「DX(デジタルトランスフォーメーション)レポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」によれば、
レガシーシステムを刷新できないことやIT人材不足など、2025年付近に集中するさまざまな課題を解決できなかった場合、
2025年以降、毎年最大12兆円規模の経済損失が生じると指摘されています。「2025年の崖」と呼ばれる問題です。
すでにレガシーシステムの刷新を済ませた企業様もあるでしょうが、
ブラックボックス化して内部構造がわからなかったり、
コストがネックになったりして、依然、手が出せないままという企業様もあるでしょう。
ただ、レガシーシステムにかかるリスクやコストは、放置する間にどんどん大きくなります。
このページでは、レガシーシステムが抱える課題を振り返り、置き換えの方法をご紹介いたします。
レガシーシステムとは何を指すのでしょうか?
レガシー(legacy)は「遺産、遺物」などの意味を持ち、特に悪いニュアンスのある言葉ではありません。ただ、コンピューター用語として使われる場合は、古びて時代に合わなくなったというマイナスイメージを伴います。
レガシーシステムとは、新たな技術の登場により古くなってしまったコンピューターシステムのことです。
新技術の比較で使われるため、導入から具体的に何年経ったら「レガシーシステム」になるといった明確な基準はありません。
技術進歩の目覚ましいITは、人間の18倍の速度で成長するネズミになぞらえた「マウスイヤー」という言葉があるほどです。現在は、最新のデジタルテクノロジーであっても、数年もすれば代替技術が登場して陳腐化してしまいます。
ITがどんどん進化していく一方、利用する側の組織では、商習慣や業務が変化するスピードはもっと遅く、新たな技術が登場するたびにシステムを入れ替えるというところはほとんどありません。
入れ替えには金銭コストや手間もかかります。
特に、入れ替えに伴う想定外の不具合への対処や、社内問い合わせへの対応は、情報システム部門に大きな負担を与えています。多くの人が、システムの使い勝手が変わることを嫌う傾向にあることも一因でしょう。
このような理由から、古いシステムが長年、組織に根付き、レガシー化していきます。
レガシー化したシステムでありながら、上のような理由から長期間使い続けてしまうことで、次のような問題が生まれます。
レガシーシステムを使用する中で、ビジネス環境や業務フローの変化などに合わせて、新たな機能をつぎはぎで追加してきたケースが多く見られます。システム変更に関するドキュメントを整備せずに機能追加などが進められ、長い年月を経て社内の担当者やベンダー側の担当者が変わってしまった結果、内部構造を把握できている人が誰もいないブラックボックス状態になってしまっているシステムが多いのです。
レガシーシステムは、当時ポピュラーだった「COBOL(コボル)」という開発言語を用いて構築されているもの特徴の一つです。構築当時のシステムについて詳しく、さらにCOBOLも扱える人材が定年退職などにより、社内からいなくなってきています。COBOLエンジニアの年齢層は上がっており、若年層のエンジニアは先端分野で活用されているJavaやPythonを習得する傾向があります。
前項でお伝えしたようにブラックボックス化が進んでいることに加え、レガシーシステムに必要な知見を持つエンジニアがいなくなっていることから、新たなシステムへの置き換えが難しくなっているのが実情です。
基幹システムなどに使用されているレガシーシステムは、新しいシステムへの置き換えが必要ですが、上記のようにハードルが高いものです。ただ、レガシーシステムを刷新しなくても、追加で新たな業務システムやデジタルツールを導入すれば、新しい技術の恩恵を受けることは可能です。 ただ、新たな業務システムなどを利用する際に重要なのが、レガシーシステム内に蓄積してきたデータとの連携です。ただし、レガシーシステムから新たなシステムへのデータ移行には、それぞれのシステムを熟知していなくてはなりません。前項でお伝えしたように、そうした人材はすでに退職していることが多いため、データ移行作業は煩雑になってしまいます。 このほか、正規のメーカーサポートが終了してしまい、メンテナンス費用が高くついたり故障のリスクが上がるといった問題もあります。 冒頭でご紹介した「DX(デジタルトランスフォーメーション)レポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」では、上記のような理由からレガシーシステムを刷新できないことに加え、INSネットとディジタル通信モードのサービス提供終了、IT人材不足の拡大などが重なり、DX(デジタル・トランスフォーメーション)を実現できなかった場合、2025年以降、毎年最大12兆円規模の経済損失が生じると指摘されています(2025年の崖)。
レガシーシステムの置き換えが難易度の高いものであることは何度も触れましたが、それでも刷新しないままでいるリスクを放置するわけにはいきません。 では、具体的にどのような方法があるのでしょうか? 「マイグレーション」と「モダナイゼーション」の二つの方法があります。
マイグレーション(migration)とは、IT資産であるハードウェアやソフトウェア、データなどを新しい環境に乗せ換えることをいいます。レガシーシステムからの移行を特に「レガシーマイグレーション」と呼びます。
マイグレーションには大きく「アプリケーションの移行」「ストレージの移行」「データベースの移行」「BPM(ビジネスプロセス管理)の移行」の4種類があります。
アプリケーションの移行とは、従来のアプリケーションと同等の機能を持つアプリケーションへの移行で、現行のプログラムを新しい環境下でリコンパイルする「ストレートコンバージョン」、現行のプログラムを新しい環境下に適した言語・ソフトウェアに書き換える「リライト」があります。新たに、一からスクラッチ開発を行うこともあります。
レガシーマイグレーションの多くが、アプリケーションの移行に該当します。
上記の「アプリケーションの移行」では、データベースの移行が発生します。データベースソフトを移行する場合またはアプリケーション内のデータを移行する場合のいずれかになります。
いずれの場合も、既存のアプリケーションで利用していたデータ形式の変換を伴うケースがあります。
ストレージ(データが格納されているハードウェア)を新しいものに移行します。ストレージの移行は、レガシーマイグレーションでなくとも、オンプレミス環境の場合は3~5年周期で行う必要があるため、経験のある担当者も多いでしょう。
データの消失を避け、可能な限りサービス停止時間を短く実施しなければならなりません。ストレージの移行と同時にアプリケーションやソフトウェアの移行も行う場合は、データやファイルの単純な移行では済まないため、スケジュールや容量・接続性などの十分な確認が必要です。
BPMとは、Business Process
Management(ビジネスプロセス管理)の頭文字を取ったもので、組織における業務プロセスを整理・分析したり、業務の効率化を推進する方法を検討し、行動していくことです。
BPMを移行するタイミングは、組織変更などがあった際、もっと大きな変化としては、買収・合併があったり、新マーケットへ参入した際などが挙げられます。
こうした変化に伴い、ビジネスプロセスが変更された時にBPMの移行が必要になります。
BPMの移行に伴い、業務で活用してきたデータやデータベースの移行も必要になるため、上記の「アプリケーションの移行」「ストレージの移行」「データベースの移行」の2つ以上の移行が必要になります。
【関連記事】
BPMツールとは?業務改善に効果を発揮するBPMツールを比較
モダナイゼーション(modernization)とは、古くなったIT資産を最新の製品や設計に置き換えることです。
モダナイゼーションには大きく「リプレース」「リライト」「リホスト」の3種類があります。
リプレースとは、既存のシステムやパッケージソフトウェアから新たなパッケージソフトへ移行することです。
業務プロセスにも手を加えることが多いため、業務効率化につながるメリットがあります。
抜本的な変更となるため、大掛かりになり、金銭コストや手間暇がかかります。現場からの反発が出る恐れもあります。
リライトとは、現行のプログラムを新しい環境下に適した言語・ソフトウェアに書き換えることです。
コード変換ソフトなどを活用し、セキュリティや稼働スピードの向上などを目的として、既存システムのプログラミング言語を新しいものへと移行します。
機能や仕様には特に変更を加えません。
リホストとは、サーバやOS、ミドルウェアなどを新しい環境に構築して、アプリケーションやデータなどを移行することです。
クラウド化も含まれます。
古いIT資産(ソフトウェア)をそのまま利用することになるため、業務効率化の効果は限定的になりますが、スピーディーに実施できます。
前章では、レガシーシステムを置き換える方法をご紹介しました。 その具体的な手段としては、「ローコード開発」をおすすめします。 ローコード開発とは、開発の大部分を、「GUI(Graphical User Interface/グラフィカルユーザインタフェース)」とよばれる、視覚的に理解しやすく直感的に操作できる画面を用いて開発する手法のことで、ソースコードの記述は必要最小限で済むため、非エンジニアであるユーザー部門の担当者の手で現場に合ったアプリケーションを開発できるのが特長です。 ローコード開発がレガシーシステムの置き換えにおすすめな理由は、次の3点です。
ローコード開発では、あらかじめ用意されたコンポーネントと呼ばれる機能単位を組み合わせることで開発の大部分が行えます。このため、一からプログラミングを行って開発するのに比べ、開発期間を大きく短縮できます。開発期間が短くなれば、その分、開発コストも削減できます。
そのため、レガシーシステムの置き換えにローコード開発を用いることで、開発期間や開発コストを圧縮できます。
新たなシステムを一から開発する場合もローコード開発を活用する場合も、情報セキュリティ対策については要件定義を行う必要があります。スクラッチ開発を採用した場合、自社のセキュリティポリシーに沿ったシステムを実現できますが、セキュリティポリシーに変更があった場合は、開発ベンダーに依頼して、システムも変更する必要が出てきます。
また、たとえば、システムの運用を開始した後でグローバル展開するようになった場合などに、NISTやGDPR、PCI-DSSといった海外のコンプライアンス基準に対応したシステムへと更改しなければなりません。
ローコード開発の場合、提供されるプラットフォーム側でセキュリティ対策やコンプライアンス基準への対応がなされているため、プログラミングを行った部分のみ対応すれば済みます。自社のセキュリティポリシーや、求めるコンプライアンス基準に合ったローコード開発プラットフォームを選びましょう。
せっかく費用や時間、手間暇をかけてレガシーシステムを新たな技術で置き換えたとしても、時間が経てばいずれはまた陳腐化してしまいます。 ローコード開発ツールを活用すれば、ビジネス環境の変化に伴う業務の変化に合わせ、現場の担当者の手で素早くアプリケーションの機能などを変更することが可能です。 特に、クラウドタイプのローコード開発ツールであれば、提供者側で新機能や新技術の搭載を行ってくれ、利用しているだけで自動的にアップデートされるため、アプリケーションをレガシー化させずに済みます。
レガシーシステムが抱える課題と置き換えの手段、ローコード開発を活用するメリットをご紹介しました。
経済産業省は、「DX(デジタルトランスフォーメーション)レポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~」を発表した2018年から、レガシーシステムを使い続けるリスクを指摘しています。同レポートで言及されている2025年まであと3年。
現在もレガシーシステムを抱えている組織は、刷新に向けて動き出すリミットが迫っています。
レガシーシステムの置き換えには、マイグレーションとモダナイゼーションがあり、ローコード開発がおすすめです。
ローコード開発を活用することで、開発期間とコストを低減でき、セキュリティやコンプライアンス基準に簡単に対応でき、現場の担当者の手で業務変化に合わせた柔軟なシステム変更が可能になります。置き換えた後のシステムをレガシー化させないためにも、ぜひローコード開発による刷新を検討してみてください。