第4回　レガシー移行

2020年2月

はじめに

前回はIT戦略の特に中核のテーマとなる「ITインフラの見直し」についてご紹介しました。ITインフラ見直しは、経営・事業戦略とITインフラで解決すべき改革テーマの整合を図っていく事がそのポイントとなりますが、今回もまた同様に企業のこれまでのビジネス活動を支え続けてきた基幹業務システムの移行への取り組みについて、モデル事例を交えてご紹介したいと思います。

崖に落ちて突然死？（昨年末の“とある”セミナーより）

本コラムにご関心をお持ちの読者の方で、ここで紹介するセミナーに参加された方もいらっしゃるかと思いますが、DXやレガシー移行をテーマにしたセミナーで講演者の強烈なメッセージが耳に残りました。その内容は「既存のアプリケーションを変更しない＝ビジネスプロセスを見直ししないという事と同じだ」「バックエンドプロセスを変更しない＝ビジネスを変更しないと同じだ」「クラウド移行だけでは中味が変わっていない」「器だけ変わっていても（＝重要ではあるが技術が優秀なので簡単にリホスト出来てしまう、先送りするテクノロジーでは）企業は勝ち残れない」というものでした。

これらのメッセージを整理すると“既存のビジネスモデルを移行しても意味がない”“システムを使ってどうビジネスを変革するかが重要”“手段であって目的ではない”“あくまでビジネスの設計があってこそ”などの視点が、レガシー移行の本質（2025年の崖に落ちて突然死しないために）であるとの理解を促す内容であったと受け止めています。

レガシー移行に向けての現状システムの見える化

さて、これまでのレガシー移行に関する執筆記事や論考などを調べてみると、メインフレーム上などで稼働する基幹系情報システムを「レガシーシステム」として、クラウド化などの移行技術やその手法を論説するものや、ビジネスニーズに対応できなくなった情報システムを「レガシー（遺産）」「技術的負債」と称して国際カンファレンス等で本質的な問題点を議論するものなど多岐にわたっています。

昨今、企業の情報システム上で稼働しているソフトウェアやハードウェアなどを稼働中の資産を活かしながら最新の製品や再設計で置き換えていくことを“モダナイゼーション”として広く紹介されています。その応用として、オンプレミスで運用している情報システムをクラウド化する考えを調査会社であるガートナー社が、アーキテクチャーパターンとして定義し各パターンの頭文字を取り“7つのR”などと呼ばれています。当社に限らずSIer（システムインテグレーター）は、このパターンを参考にユーザー企業のクラウド化をさまざまな適用手法、応用技術で支援しています。

当社では基幹業務システムのさまざまな移行を進めるにあたって、特にその上流にあたる“現状システムの見える化とシステム企画”に注視した活動を行っています。

そもそも、“レガシー移行＝長年にわたって稼働している基幹業務システムの刷新”における課題は、一般的にその利用技術が老朽化している、機能的な拡張を繰り返しているためシステムそのものが複雑になり肥大化している、システムの構造が長年の保守を経てブラックボックス化してきているなどがあげられています。この点がビジネスニーズの急速な変化、対応を困難にしているとされます。レガシー移行の検討（企画）にあたっては、現状システムの見える化を行ない必要とされるビジネスの抜本的強化に向けた課題への対応を導き出す必要があります。

現状システムの見える化とシステム企画の進め方

レガシー移行を検討するには、第一にその実施の目的を明確にすることであり、当然ならがシステム対象範囲を明確にすることが重要となります。投資対効果を明確にして実施後の効果測定ができるよう数値目標を立てることも必要となります。

実施内容を組織内で合意、その実施可否を判断する。それをもとに具体的計画（移行、改修、再構築、システム調達など）を進める事になります。その結果として実施計画の成功確率を上げることにつながります。

業務システムの刷新に関する基本方針としては、経営課題解決、業務改善、事業拡大を目標に、事業環境の変化にITを用いてどのように対応していくのかであり、そして何よりも重要な視点としては、ビジネスモデルの見直しに関して全社最適の視点であることなどがあげられます。また事業の形態によっては、グローバルシステム化を前提とする必要もあります。

基幹業務システムの移行パターン検討（モデル事例）

ここでは、基幹業務システムの移行パターンを、モデル事例を使って整理したいと思います。

現状システムは、基幹業務の中でも特に事業遂行における中核を担う業務機能（販売管理、生産／設備管理、購買／調達など）はメインフレームを導入し、主にCOBOLベースで個別開発を行なっていました。また財務会計と人事・給与などのシステムは、パッケージソフトをオンプレミスで導入し運用しています。

このケースをベースにして、移行パターンA案、B案、C案として挙げています。

（A案）ERPパッケージを導入して業務システムをリビルド、リプレースするパターン

ERPパッケージに搭載されているビジネスモデルを使ってこれまでの業務を変える、パッケージを使った業務標準化を図るものです。企業の基幹事業とビジネス、業務プロセスを長年にわたって支えてきたシステムであるのため、その導入に関しては全社的な視点での判断と経営側からのコンセンサスが必要で、パッケージの選定、業務適合性などの検討も重要となります。

（B案）既存のビジネスモデルとERPパッケージ導入によるハイブリッドパターン

アプローチ的にはリバイス、リビルドの両方が考えられますが、ここではリビルドを想定していて、これまでのビジネスで培ったIT資産（ビジネスモデル）を強みとして活かしながら業務の効率化を図るものです。ここでの例としては販売管理を挙げていますが、その意図としては一般的に販売管理に企業の特徴、強みがある場合が多く、ITとしてその特性を継続させたいと言われているからです。パッケージのビジネスモデルに業務を適合させたりした場合、これまで積み上げた自社の強みを消したりパッケージ機能へのアドオン等で過大なコストがかかるようなケースが多くの企業で発生しています。

レガシー移行を検討する際のアプローチとしては、ここでのB案が段階的推進イメージとして、また現実的なものとしてとらえられる反面、多くの考慮すべき点もあげられます。

（C案）基本的には業務を変えないで既存の資産（ビジネスモデル）を活かすコンバージョン、リホストパターン

仮想サーバやIaaS※1などのサービス基盤に移行を行いながら、必要に応じてアプリケーションの最適化を行っていきます。この場合、既存システム（販売、生産、設備、購買、調達）全体のコンバージョン作業としてAPマイグレーションを主体としたリバイス、リビルドを実施することになります。

特に、採用する技術方式や適用サービス（PaaS※2、CaaS※3、FaaS※4など）の選択が必要となり、またコンバージョンにおける開発工数が発生します。さらに、技術リソースの面でも異なるスキルセットがそれぞれ求められるために、これまでの要員では対応できない場合も想定されます。

• ※1　IaaS：Infrastructure as a Service
  インターネット上に仮想サーバやネットワークの利用環境を提供するサービス。
• ※2　PaaS：Platform as a Service
  アプリケーションをインターネット上で運用するためのハードウェアやOS、ミドルウェアや関連するフレームワークなどの環境を提供するサービス。
• ※3　CaaS：Container as a Service
  アプリケーションをコンテナ化したものを実行させるプラットフォームを指し、Kubernetes（クバネティス）がその代表格として有名。Google Kubernetes Engine、Azure Kubernetes Service、Amazon Elastic Container Service for Kubernetes、IBM Cloud Kubernetes Serviceなどの仮想サービス環境が提供されている。
• ※4　FaaS：Function as a Service
  PaaSにフレームワークを加えたサービスであり、サーバレスアーキテクチャ―の実現方式のひとつ。関数レベルでの実行サービスであり、従来のサービスよりも小さい機能単位であるマイクロサービスを提供する基盤である。

移行パターンA案、B案、C案に示した、ERPパッケージの導入、ハイブリッド化、コンバージョン・リホストなどのシステムサイト構成に関しては、それぞれクラウドへの全体的な移行、オンプレミスとクラウドの組み合わせなどのパターンが考えられますが、具体的構成については運用面を含めた詳細な検討が必要となります。

各移行案ともに一長一短があり、企業の事業展開（事業の根本的な強化）に向けてどの案が最も経営課題解決、業務改善、事業拡大そしてIT活用によるビジネスチェンジのゴールに向けて、実施上の最適解であるかの周到な検討と判断が必要となります。

移行パターン例

参考情報

IPA（独立行政法人情報処理推進機構）ホームページ
「システム再構築を成功に導くユーザガイド　第2版」を発行
～「業務継続性」を軸にシステム開発における上流工程の課題解決を整理～

まとめ

今回は、IT中計策定における4つの重要課題の第3点目の課題で掲げた「レガシー移行」について、最近の動向、注視すべき事項（上流工程）や事例ケースを使っての検討ポイントを整理しました。

少々以前の話になりますが、オープン技術と呼ばれる技術要素群が大きく台頭していた2000年台初頭に、実は今回のメインフレーム資産の移行と同様の、オフィスコンピュータ（オフコン）のレガシー移行が問題になった時期がありました。課題も現在と同様、当時の最新技術と比較して利用技術が老朽化している、機能的な拡張を繰り返しているためシステムが複雑になり、肥大化、ブラックボックス化してきているなどでした。そこで当社でも2002年にこのレガシー移行への技術的な取り組みとして、オフコンシステム等で構築された基幹システムのオープンシステムへの移行を実現するためのフレームワークを製品化していました。

約20年を経て当時の課題がまた新たにITシステム“2025年の崖”問題として、私たちに突き付けられている事になります。

前回ご紹介した「ITインフラ見直し」と同様に、経営・事業戦略と基幹業務システムとして解決すべき改革テーマの整合を図っていく事がその重要なポイントとなります。

現状システムの見える化を行いその課題を明らかにすることで、より一層の企業（お客様）自社のあるべき姿、目指す姿を明らかにする事が出来ます 。「レガシー移行」は、来るDXに 向けた最重要テーマとして各企業にその取り組みが求められています。

次回は、重要課題の第4点目として掲げた「データ活用」とその取り組みについて、ご紹介します。