デジタル化を推進する際のボトルネックになるのが、老朽化した情報システム。つまりレガシーシステムである。今、企業はレガシーシステムの解体を迫られている。レガシーシステムの作り直し方や延命方法、クラウド移行などのノウハウを徹底解説する。

 ビジネスや業務のデジタル化に取り組む企業が増えるなか、従来のレガシーシステムの課題が健在化してきた。モノリシック(一枚岩)に作られたレガシーシステムでは、ちょっとした変更にも大きな手間がかかり、デジタル化で求められるスピードが出せないのだ。

 レガシーシステムをうまく解体し、既存のデータやロジックなどを生かすための「解体シナリオ」は様々ある。レガシーの利用目的に合わせて選ばなければ、手間とコストばかりがかさむ。まずは現行システムに手を入れるかどうか判断が必要だ。そのうえで、レガシーに手を入れない場合は既存の機能をそのまま使うかどうか、手を入れる場合はビジネスロジックをそのまま使うかどうかを検討し、解体シナリオを見極める。

レガシーの活用手法を選ぶ
[画像のクリックで拡大表示]

 モダナイズなどでシステム全体を作り直す場合、システムの規模や改修度合いによるが、億円単位の大掛かりなプロジェクトになる。

 一方、既存の業務ロジックをAPI経由で流用したり、データを連携したりするだけなら、既存システムへの影響は少ない。連携の仕組みを既存システムの外側に作れば済むし、「z/OS Connectを使えば、IBMメインフレームで稼働するミドルウエアなどを簡単にAPI連携できる」(日本IBM グローバル・ビジネス・サービス事業本部の二上哲也CTO)というように、連携ツールも使える。

 既存システムを作り直す手法は、リライトやリビルドが代表的だ。前者は業務ロジックはそのままにソースコードを書き換える。後者は業務やロジックなどを見直して再構築するので、要件定義などの難易度が高い。レガシーマイグレーションを手掛けるシステムズ ソリューション開発グループの中本周志氏は「開発した人がいなくなって、どうしてこういう作り方をしたか分からないという状況でも、現行と同じ機能を担保した新システムが作れる」とリライトのメリットを話す。

 ここでは、作り直しの現実解といえるリライト手法を見ていこう。

「新旧一致」を目指すリライト

 リライトの一般的な作業工程を以下に示した。まずは資産を棚卸しし、不要な機能は捨て、移行対象を絞り込む。移行性検証から移行設計にかけて、ソースコードについてはCOBOLなどで書かれた現行システムのパターン分析などを通じ、Javaなどへの変換方法を検討。VSAM(Virtual Storage Access Method)ファイルやネットワーク型DBといった現行システムのデータストアは、RDBMSに移行するためのテーブル設計を行う。

リライトによる作り直し工程
[画像のクリックで拡大表示]

 パイロット移行で問題なしと判断したら、ソースコードの変換を行う。この作業は、ツールによる自動変換を中心に、人手で補足しながら進める。テストでは、現行システムと新システムで処理結果が同じになる「新旧一致」を目指す。

 実際にリライトを活用し、メインフレームからWebシステムに移行したユニチカの事例で、注意点を見よう。

この先は有料会員の登録が必要です。有料会員(月額プラン)は申し込み初月無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら