マイグレーションとは？種類や手法、リプレースとの違いを徹底解説

情報システムにおけるマイグレーションとは、既存のシステムを新しい環境に移行することを表します。近年、情報システムのクラウド化などもあり、多くのシステムでマイグレーションが行われています。

こちらでは、マイグレーションとは何か、似ているけれども意味が違う用語であるリプレースやコンバージョンとの違いについても解説します。マイグレーションってよく聞くけど何のことだろう、と思っていた方にとって新たな知識となり、今後の業務に活かせることでしょう。

マイグレーション（migration）とは、一般的には「移住」、「移動」、「移転」という意味をもった言葉です。

情報システムにおけるマイグレーションとは、OSやアプリケーションなど既存のシステムを新しい環境に移行することを表す言葉です。具体的には、メインフレーム系で稼働していたシステムをオープン系のシステムへ移行するなどが該当します。近年はクラウド化の進展に伴い、オンプレミスのシステム環境からクラウド環境へのマイグレーションの事例が多くなっています。

＞＞マイグレーション支援のページへ
＞＞お問い合わせページへ

マイグレーションと混同されやすい用語として、リプレース（replace）があります。リプレースとは、既存のOSやアプリケーションを互換性のあるハードウェアに入れ替えることを意味します。例えば、サーバーの老朽化に伴い、同じ機器を購入して入れ替えることがあげられます。この場合、ハードウェアは新しくなりますが、システムは何も変わりません。

一方、マイグレーションとは、既存のシステムが古いオペレーティングシステムやプラットフォームから新しい環境に移行することを指します。システムの仕様自体は基本的に変わりません。例えば、対象システムをオンプレミスからクラウドへ移行することに伴い、ハードウェア環境を変える場合はマイグレーション、対象システムが稼働しているサーバーを入れ替える場合はリプレースとなります。

リプレースと同じくマイグレーションと混同されやすい用語に、コンバージョン（conversion）があります。コンバージョンとは、ソース・データ・ファイルなどの資産を機械的に新しい環境に合わせて変換する作業を表す言葉です。具体的には、COBOLで書かれているプログラムをソース変換ツールによってJavaプログラムに変換する作業が該当します。

マイグレーションのパターンとして、レガシーなプログラミング言語から、技術者の多い言語に変えたいという要求が出ることがあります。言語が変わると言語の仕様以外にも関数やライブラリの仕様が異なるので、プログラム構造を含めた大きな見直しになります。

プログラムはすべて書き換えになりますが、これをすべて手作業で行うのは工数がかかるため、コンバージョンを取り入れることを検討することになります。

具体的に、マイグレーションは次のような状況や課題を抱えた際に必要となります。

・ハードウェアの老朽化や保守期限の到来による、ハードウェア故障リスクの回避
・OSやミドルウェアなど、バージョンのサポート終了による運用コスト増大、システム脆弱化の回避
・システム利用者数や取り扱うデータ件数の増加による性能低下の改善
・古くなったシステムを運用できるスキルを有するエンジニアの継続確保が困難
・ランニングコストの削減

現行のシステムをそのまま動かすよりも、将来的にコスト・技術・人材の観点からプラスになると判断できる場合にマイグレーションを行います。

マイグレーションのよくあるパターンとして、レガシーマイグレーションがあります。レガシーマイグレーションとは、古い設計思想や製品に基づいて作られた、いわゆる「レガシーシステム」を新しい技術や製品に置き換えることを指します。特に、メインフレームやオフコンなどで稼働しているシステムを、WindowsやUNIX系OSをベースとした最新のシステムに移行することを表すケースが多く見られます。

大企業や官公庁を始めとする大きな組織では、未だにレガシーシステムが稼働している環境も多く残っている傾向があります。機器本体や部品の生産停止、保守期限切れといったハードウェアとしての側面、最新の技術に対応できないというソフトウェアとしての側面、どちらの側面もレガシーシステムは年々移行を迫られていると言えるでしょう。

レガシーマイグレーションでは、稼働させるハードウェアを新しい機器に、ソフトウェアをWindowsやUNIX系OSにし、これらの環境で稼働するように変換したのちに移行します。具体的には、メインフレームで稼働していた生産管理システムを、Windowsサーバーに移行するような場合です。

このような場合には、利用している言語も技術者の少ない古い言語であることが多く、現在の主流となっている言語で作り替えられることもあります。

現在、クラウドやデータアナリティクス、モバイル、ソーシャルといったプラットフォーム、また、AIやIoTの本格的な活用を背景にIT投資も変化を求められ、売上・付加価値を向上させるフロントエンドへの投資が拡大しています。しかし、いくらフロントエンドに投資したとしても、バックエンドのシステムがビジネスの変化に対応していなければシステムが機能しません。そのため、既存システムの整理・見直しを行い、フロントエンドとの連携を強化したりするためにマイグレーションに踏み切る例が出てきています。

売上・付加価値の向上、そして企業の成長に向け、既存システムの刷新や整理のために戦略的にマイグレーションを実施することが求められています。

マイグレーションでは対応する範囲によりさまざまなパターンがあり、規模に応じたコストがかかります。新システムへのマイグレーションの手法として以下3つがあげられます。

・リホスト：インフラ刷新
・リライト：プログラム言語の変更
・リビルド：システムの再構築

以下では、これら3つについて説明していきます。

リホストとは、アプリケーションの修正を最低限に抑え、クラウド環境などの別のプラットフォームに移行する手法です。

アプリケーションの修正を最低限に抑えて新しい環境に移行するため、コストも低く移行期間も短くできることがメリットとしてあげられます。しかし、アプリケーションの修正を最低限に抑えて利用するため、最新の技術や新しいビジネスモデルに対応できないなど、業務面で遅れをとってしまう可能性もあります。

リライトとは、システムの仕様はそのままに、別のプログラミング言語で記述し直すことです。

例えば、メインフレームやオフコンで使われていたプログラム言語では、Webシステムや新しいOSではアプリケーション開発や改修ができない事態が発生する可能性もあります。また、メインフレームやオフコンに対応できる技術者の確保が年々難しくなっています。これらのことから、新しいプラットフォームに対応するため、または技術者確保のために新しいプログラム言語に変更する場合があります。

なお、リライトの方法として手動で新しいプログラム言語に変更する以外にも、ツールを用いて機械的に変換（コンバージョン）する方法もあります。

リビルドとは、既存システムを一から再構築することで、システムの仕様は基本的にそのままで新しい環境、新しいシステム構成で構築する手法です。

メリットとして、新しい環境に新しい技術やシステム構成で構築するため、新しい技術を取り込むだけでなく、拡張性が高くなる効果が見込めます。一方で、一から構築するために構築期間だけでなくコスト面においても負担が大きくなる可能性があります。

既存システムの老朽化や、将来的な拡張性が見込めない状況の場合に、この手法にてマイグレーションを行うと良いでしょう。

マイグレーションでは、既存のシステムで行っていた業務が同じようにできることが期待されています。とはいえ、マイグレーションを行うにはさまざまな課題があり、簡単なことではありません。ここではマイグレーションの代表的な課題を3つ紹介します。

1つ目の課題は、「開発に関わった人がいない」ことです。

既存のシステムをマイグレーションする場合、既存システムを理解する必要があります。しかし、マイグレーションの対象となるシステムが10年以上長い年月を経ていることも珍しくありません。そして、長い年月が経った既存システムに存在する機能の開発経緯を確認しようにも、システム開発時に関わった社員やエンジニアは退職しており、話が聞けない状態となっている可能性もあるのです。

このため、マイグレーションを行うためには既存システムのプログラム解析はもちろん、存在する機能がどのような業務やビジネスで使用されているのかなど、ビジネスに関する知識も持ち合わせたエンジニアの存在がカギとなります。

2つ目の課題は、「ドキュメントが残っていない」ことです。

マイグレーションを行う場合、既存システムの機能を把握する必要があります。しかし、長い期間を経過したシステムの場合、設計書をはじめとしたドキュメントが存在しないことも珍しくありません。仮にドキュメントが存在していたとしても、昭和時代に開発されたメインフレームやオフコンのシステムのドキュメントはほとんどが手書きであるため、文字が読めないこともあります。また、機能追加や機能改修時にドキュメントの更新を行っていたため、ドキュメントに記載されている内容と実際に動作している機能の内容に乖離があることも珍しくありません。

このように、ドキュメントがない、もしくはドキュメントの内容と乖離があるために、既存システムの内容の把握に苦労することがあります。

3つ目の課題は、「テストにコストがかかる」ことです。

既存システムのマイグレーションを行うとき、多くの場合は「既存システムの機能が新システムに引き継がれている」ということを前提にします。この前提のとき、テストとして用いられるのが「現新比較テスト」です。これは既存システムと新システムで同じデータで同じオペレーションを行い、同じ結果となるかどうかを確認するテストになります。そして、マイグレーションを行う際の「現新比較テスト」のテスト対象範囲は全機能です。

全機能の現新比較テストを行う場合、一般的にはテスト項目が膨大になるとともに、テストに要する手間やコストも膨大になります。

マイグレーションを行うにあたって、先に記載した課題に対応しながら作業を進めることが必要です。では、マイグレーションの実施にあたって考えなければならないこととして何があるのでしょうか。以下で3つご紹介します。

1つ目は、「調査～マイグレーション実施～運用保守を一貫して考える」ことです。

事前に先のことを見据え、きちんと計画を立てることが重要です。「単純に既存システムを新しいプラットフォームに移行すればよい」と何も考えずにマイグレーションを実施すると、マイグレーションの実施段階、あるいは運用保守の段階で問題が発生しかねません。

特に、最初の段階で行う調査は、既存システムの把握に時間がかかることが予想されるため、期間を長めにとっておくことが必要です。

2つ目は、「業務の流れに基づき、業務知見も取り入れてテストを行う」ことです。

マイグレーションということで、「既存システムと新システムの現新システムのテストを行えば十分ではないか」と考えている人も多いのではないでしょうか？しかし、実際にはシステム的な観点のテストだけでは不十分です。なぜなら、業務を知らない開発メンバーがマイグレーションを行った場合、マイグレーション後の機能が必ずしも業務的に正解であるとは限らないからです。このため、マイグレーション後の機能が業務的に正解であることを確認するためにも、業務の流れを踏まえて業務知見を取り入れたテストを行う必要があります。

3つ目は、「適切な自動化の導入で、マイクロマネジメントを行う」ことです。

マイグレーションをすべて手作業で行った場合、期間やコストが膨大にかかる可能性があります。また、人的なテストのみでは、エンジニアが疲弊し、プロジェクトが回らない可能性も考えられます。このため、コストを抑えるために、ソースプログラムをはじめとした資産を新しいプラットフォームに合わせて自動変換するマイグレーションツール、テスト工数を削減するためのテスト自動化ツールなどを上手く活用することも必要です。

ビジネスの変化に対応していかなければ生き残れないこの時代、過去のシステムが足かせとなり、新しいビジネスに対応できないといったことがあってはなりません。特に近年は、DX推進によるデジタル化が進んでおり、レガシーシステムの見直しや刷新がカギを握っています。このため、戦略的マイグレーションを検討してみてはいかがでしょうか？

「短期間かつ低コストで新しい環境を手に入れたい」など、戦略的マイグレーションに関するご相談は、SHIFTにお気軽にお問い合わせください。

＞＞マイグレーション支援のページへ
＞＞お問い合わせページへ

大手IT会社にて、17年間ソフトウェア製品の開発に従事し、ソフトウェアエンジニアリングを深耕。SE支援部門に移り、システム開発の標準化を担当し、IPAのITスペシャリスト委員として活動。また100を超えるお客様の現場の支援を通して、品質向上活動の様々な側面を経験。その後、人材育成に従事し、4年に渡り開発者を技術とマインドの両面から指導。2019年、ヒンシツ大学の講師としてSHIFTに参画。

担当講座