テクノロジーレガシーなITシステムを再生する

マイグレーション戦略

ITシステムにおける「レガシー」とは、前時 代的なシステムのことを指し、汎用性や拡張性に課題があることが少なくありません。その一方で、長きにわたって使い続けてきたレガシーシステムには、企業が蓄積してきたノウハウが 凝 縮されており、簡単に手放せない側面もあります。
「 レガシー」問題をスムーズに解決し、IoT、インダストリー4 .0、フィンテック、人 工知能（A I）といった新しいテクノロジーの現代のシステムといかに整 合させるか。今、経 営戦略が問われています。

レガシーシステムにはどのようものがあるか？
「レガシーシステム」「 レガシー資産」というと、どのようなシステムを思い浮かべるでしょうか。代表的なものとしては、メインフレームと呼ばれるバッチシステムやタイムシェアシステムに特 化した大型コンピューター、そして、事務用ソフトウェアの開発言語としてスタンダードだったCOBOLのアプリケーションが挙げられます。オフコン・ミニコンといった古いハードウェアで構成されたシステムもその部類に入るでしょう。
これらのシステムでは、OSの設計が古いため、インターネットに接続できないケースがあることはもちろん、ハードウェアやデータに互換性がなく、近年の汎用的なサーバーやパソコンと接続が困難なこともしばしばあります。さらに、記憶メディアが、古い仕様のテープやディスクカートリッジであるばかりか、そもそも文字コードさえAS CI IやUnicode（ ユニコード）でないことも珍しくはありません。またハードウェア、ソフトウェアのいずれも老朽化が進み、稼働を維持するためのメンテナンス費用が高額になるなど、さまざまな問題を引き起こしているケースもあるでしょう。
レガシーシステムは業務には欠かせない存在でありながら、経 営の足枷になってしまう一面を持っています。この問題は最近になって顕在化したものではありません。インターネットの発展とワークステーション、I Aサーバーの普及にともない、Webをベースとしたオープンアーキテクチャー、オープンシステムが一般的になった10 年以上前から指摘されている問題です。
近年、クラウドやモバイルデバイスが企業活動に浸 透するなど、ITやネットワークの発展は目覚しく、ビジネスには従来以上にスピードや柔軟性が求められています。そのため、再びレガシーシステムの動向に注目が集まっているのです。

1/4

Copyright (c) NTT COMWARE CORPORATIONテクノロジー
レガシーなITシステムを再生するマイグレーション戦 略

レガシーシステムをあえて使い続ける意味
レガシーシステムは、システムを一からプログラミングして作り上げる、いわゆる「フルスクラッチ」で構築されたものがほとんどです。企業や部門ごとの業務フロー、商材やサービスの特 性にあわせて、効率的に業務が進むように構築されるなど、レガシーシステムには企業のさまざまなノウハウが 凝 縮されています。
そのノウハウが同業他社との競争において有利に働いている限り、レガシーシステムを使い続けたいと考える企業は少なからず存在するでしょう。仮に新しいパッケージやソリューションに乗り換えた場合、競合企業も同じ製品を使っていたらそこに優位性を失い、差別化を図ることが 難しくなる可能性があるからです。
つまり、現在もレガシーシステムに依存する企業は、「 変えられないから、仕方なく使っている」とは限らず、「 あえて使っている」場合があるのです。なかには社内にCOBOLのエンジニアを抱えて、社会状況やビジネスの変化に合わせて、今も改善を加えながら運用している企業も存在します。
その一方で消極的な理由でレガシー資産を残してきた企業もあるでしょう。例えばコストの問題。ある業務に特 化した複雑なレガシーシステムを作り直すことは容易ではなく、思った以上に開発コストがかさむ可能性があるということです。たとえ部分的なリプレースを行うとしても、全体に及ぼ す影 響を予測することは困難であり、システムの数が多ければそれだけ改修コストは膨らむ恐れがあります。

レガシーシステムのリスクを意 識し、対 策の検 討へレガシーシステムにこだわり、消極的に使わざるを得ない場合も、システムの老朽化による影 響が必ずあります。実際、前世代のIT資産を使い続けることのデメリットやリスクはどこにあるのでしょうか。
優先して検 討すべきは「コスト」です。当時としては合理化にひと役買ったシステムかもしれませんが、10 年、2 0 年が経過した現在、必ずしも同様の効果を生んでいるとは限りません。むしろ無駄を生んでいる可能性もあります。新しいシステムであれば、業務の効率化が実現可能かもしれません。
さらにメンテナンスや運用の要員確保に加え、ハードウェア本体や周辺機器が、メーカーの保証期間を過ぎてしまえば、さらに維持・管理コストが上昇します。当然、メンテナンスコストは割高になるでしょうし、メーカーで製 造が終了した補修 部品、消耗品を自前で確保、管理する必要が出てくるかもしれません。
関連して、環境 基 準やコンプライアンス、製品関連の規制によって法的に適合しなくなる（違法状 態となる）こともあります。レガシー資産は社会の理 解を得られない、といった問題も考えられるのです。

2/4

Copyright (c) NTT COMWARE CORPORATION

テクノロジー
レガシーなITシステムを再生するマイグレーション戦 略
くわえてサイバー攻撃の脅威が年々高まっています。ITシステムの場合、セキュリティーの問題を常に検 討しておかなければなりません。レガシーシステムは、脆弱性の存在に気が 付いていなかったり、脆弱性を把握していても、メンテナンスそのものが 難しく、そのまま放置されてしまう恐れもあります。
メインフレームなどインターネットに直接 接続できないものや、フォーマットやOSが特殊である場合、不特定多数を狙ったマルウェアの脅威にさらされるリスクはそれほど大きくないでしょう。
しかしながら、レガシーシステムに有益な情報が保存されており、それを窃取することで大きな利益を得ることができた
り、システムの破壊など、脅迫の道具に使えると分かれば、サイバー犯罪者から執拗な攻撃を受けるリスクもあります。そのため脆弱性を放置することはできません。たとえインターネットに直接 接続されていないシステムであっても、組 織内部の端末が踏み台にされたり、記 録メディア経由で攻撃が行われたりすることもあるのです。
脅威が拡大する今日、マイグレーションはレガシーシステムの機能を移 行すれば済む問題ではなく、企業の情報資産を守るため、セキュリティーの確保も視野に入れて対策を検 討しなくてはなりません。

マイグレーションの選 択 肢 ― リライト、リプレース、リホスト、リビルド
レガシーシステムのリスクを意識し、その上で使い続けることを選択した場合、レガシー資産活用の選択 肢はいくつかあります。例えば、メインフレームなどのレガシーシステムを、WindowsやU N I X、クラウドなどのオープン環境に移 行すること等を指す「マイグレーション」もその一つです。マイグレーションを含む、レガシーシステムの対処方法を整理してみましょう。

ソフトウェアを最 近の言 語で書き換える（リライト）
COBOLなど開発言語で作成された既存のソフトウェアを、Javaや. N E Tなどの新しい開発言語で書き直す手法です。新しいOSへの対応、システムの効率アップ、セキュリティーの向上などが期待できます。これは、ユーザビリティーの変化など影 響も小さく済むメリットがある一方、新しいビジネスモデルやプラットフォームとの連携などを行うことはできません。
改修コストが発生するものの、収 益構造に大きな改善をもたらすとはいいにくいでしょう。

既 存パッケージ 製品への置き換える（リプレース）
リプレースは、独自開発したレガシーシステムを、既存で同様の機能を持つパッケージやソリューションなどに置き換えるものです。パッケージを用いる分、スピード感を持ってシステムを移 行できます。一方で同じ製品を利用する競合他社との差別化ができなくなる恐れもあります。
リプレースを円滑に進めるには、自社のビジネスに則したパッケージを選定することがポイントとなります。もし、パッケージに用意されていない機能を利用したければ、カスタマイズが必須です。しかし大幅なカスタマイズが必要となれば、コストが上昇し、導入までの期間が長くなるため注意が必要です。

3/4

Copyright (c) NTT COMWARE CORPORATION

テクノロジー
レガシーなITシステムを再生するマイグレーション戦 略
オープンなプラットフォームでシステムを動かす（リホスト）
メインフレーム上で動いていたソフトウェアを、Windowsサーバー、U N I Xサーバー、クラウドなどのオープンなプラットフォーム上で動かす手法です。特に「レガシーシステムが企業の競争力となっているため、乗り換えに躊躇していた」という企業には有効な解決策といえます。
さらにオープンなプラットフォームに移 行することで、クラウドサービスなどとの連携も可能になるなどのメリットも少なくはありません。リホストのためのソリューションを使えば、比較的短 期間で移 行が 可能になります。

システム全 体の再 構築する（リビルド）
レガシー資産のあらゆる問題を解決する手段として、すべて一から作り直すという「リビルド」の選択 肢は、コストさえ気にしなければ 理想的といえるでしょう。業務システム全体を見直し、新しい市場、ビジネスに適合しやすいようなシステムを作り直すためです。
メインフレームからサーバークライアントシステムへと中途半端に置き換えるのではなく、クラウド、IoT、モバイルを前提とした業務システムを再設計します。とはいえ、リビルドを選択する場合は、設計や開発の工数は多くなり、初期投資も大きくなります。新たなシステムがもたらす投資効果を見極めなければなりません。
レガシーシステムにおいて企業競争力にプラスとして働いていた点、マイナスとなっていた点をリストアップし、将来に向けた企業ビジョンを踏まえて目的を明確にした上でリビルドを進めます。あいまいに進めると、「 レガシーシステムのほうがよかった」ともなりかねません。
このようにマイグレーションと言ってもさまざまな選択 肢があります。これから先のビジネス展望や企業ビジョン、新しいビジネスモデルなど経 営的な視点を踏まえ、業務システム全体のライフサイクルを検 討した上で、戦略的なマイグレーション手法を選択する必要があります。

WEB 掲載：2016.12
URL：http://www.nttcom.co.jp/

4/4

Copyright (c) NTT COMWARE CORPORATION