マイグレーションとは？意味とサービス工程、ツール、テストを詳しく解説！

システムのマイグレーションについて、以下の内容を解説していきます。

Contents 1 マイグレーションとは？意味を解説 1.1 マイグレーションとリプレースの違い 1.2 マイグレーションをするメリット 1.3 マイグレーションサービスという業務 1.4 マイグレーションサービスの費用見積もり方法 1.5 追加費用がかかることも 2 マイグレーションの工程【４ステップ】 2.1 ①【資産調査工程】 2.2 ②【設計工程】 2.3 ③【変換工程】 2.4 ④【テスト工程】 2.4.1 マイグレーションのテストは効率化が重要 3 代表的なマイグレーションツール 4 マイグレーションする資産の具体例 4.1 マイグレーション資産例①「ファイル」 4.2 マイグレーション資産例②「COBOL」 4.3 マイグレーション資産例③「 DB（データベース）」 5 マイグレーションの失敗事例 6 まとめ

マイグレーションとは？意味を解説

IT分野でのマイグレーションの意味とは、おおむね次のとおりです。

すっごく簡単に言うと、だいたいこんな感じです。

銀行などで稼働している基幹業務システムは、多くの場合かなり古いホストコンピューターなどを今でも使用しているケースがあります。

ホストコンピュータ上ではCOBOLが開発言語として使用されているケースがほとんどだと思います。僕もマイグレーション時代に結構な確率でCOBOLと出会いました。

この古くなった資産を新しい環境でも稼働するように移行していくのが、マイグレーションなのです。

マイグレーションとリプレースの違い

リプレイスというのは、古くなって低スペックとなった機器を入れ替えることを指します。

対して、マイグレーションは、上でご説明しましたとおり、OSやシステムを新しいプラットフォームでも稼働するよう移行する事を指します。

マイグレーションをするメリット

マイグレーションをすることのメリットですが、次のような点が挙げられます。

古くなったシステムの中には、資産が整理されていなかったり、重複資産があったりと資産の肥大化が起こることも多々あります。そして、それらの運用管理にはコスト（ランニングコスト）が多大にかかることもしばしば。

マイグレーションサービスを利用することで、これらの肥大化した管理の行き届いていない資産を整理し、最適化することでランニングコストを大きく抑えることが可能となります。

さらにマイグレーションでは基本的に既存の資産を活用しつつ移行をします。まったく新規に作り直すわけではありません。そのため新規開発に比べて大きくコストを抑えることも可能です。

管理できる人がいないことも･･･

システムが古くなり、仕様書などが紛失している場合もあります。その場合、管理できる人材がいないという問題も起こり得ます。

基本的に誰でも管理できるシステムが望ましいですよね。特定の人物しか運用管理できないとなると、かなり不安定です。

そのため、マイグレーションして誰でも管理できるオープンな環境に移行するのは大きなメリットとなります。

マイグレーションサービスという業務

マイグレーションサービスを業務として請け負う企業もいくつか存在します。自社システムのマイグレーションを考えるなら、まずはそのような企業に問い合わせてみることから始まるでしょう。

規模が大きくて実績のある企業となると、日立や富士通あたりでしょうか。ネットで調べてみると色々見つかると思います。

まずは複数の企業に見積もってもらい、一番安心できる（希望が実現できる）企業に依頼することをお勧めします。安くても希望通りにマイグレーションしてくれない場合もあるので。

マイグレーションサービスの費用見積もり方法

基本的にマイグレーションサービスの費用は次の要素から見積もられることが多いです。

機能というのは、例えば入力機能、出力機能、印刷機能、通信機能など、そのシステムを構成する機能のことです。機能が多ければ移行する機能数が多いということなので、当然費用がかかります。

さらにマイグレーションするのは機能だけではなく、ユーザーが操作する画面も含まれますよね。たとえば入力画面、印刷画面など色々あると思います。

画面数が多くなれば、やはり費用もかさんでいくことになります。

追加費用がかかることも

契約段階でピックアップされていなかった機能や画面が新規に発見された場合には、当然追加の費用がかかることもあります。

たとえば、当初は移行が不要と判断していたけど、やっぱりこの機能も移行するべきだった･･･なんてケースです。

他にも、ある程度マイグレーションが進んでいく中で初めて発見されるような非互換（エラーや不具合など）があったりします。そのような場合にも、改めて費用見積もりが行われることもあります。

マイグレーションの工程【４ステップ】

マイグレーションサービスの工程は大きく次のように分かれます。

それぞれの工程について、くわしく解説していきます。

①【資産調査工程】

資産調査工程では、お客様の運用されるシステムの資産をすべて調査していきます。何を調査するのかというと、マイグレーションするにあたり、どの資産のどの部分に移行（変換）が必要なのかを洗い出します。

マイグレーションするということは、古いプラットフォームで動いていた資産を、新しいプラットフォームで動くようにするわけです。

ということは、新しい環境では互換性がなく（非互換といいます）動かなくなる恐れが結構な確率で起こります。

その非互換をくまなく探していき、非互換となる箇所をマイグレーションしていくことになります。非互換のない資産についてはそのまま使用します。

この資産調査工程が実はかなり肝心だったりします。ここで調査漏れがあったりすると、後々の全工程に悪影響を及ぼします。

最悪の場合、マイグレーションが完了してテスト工程まで行った段階で調査漏れが発見されることも起こります。これが手戻りというやつです。かなりの時間とお金がかかってしまうこともあります。

②【設計工程】

設計工程では、資産調査工程で洗い出した非互換を基に、マイグレーションの設計書を作成していきます。つまり、次のような内容を設計書に残していきます。

マイグレーションに限ったことではないですが、必ず設計書は必要です。これを基にして、以降の変換ツール作成を行っていきます。

③【変換工程】

変換工程では、設計工程で作成した設計書（仕様書）を基に、変換ツールを作成し、実際に資産に変換をかけていきます。

基幹業務システムの資産は当然ですが膨大な量があります。そのすべてに変換が必要なケースもあったりします。これを人が手作業で変換していくのは不可能です。というか無謀です。

なので、変換ツールを作成して、一気に資産に変換をかけていくことになるのです。

変換に使うツールは基本的に一から作成します。一度作成してしまえば、他のマイグレーション案件でもそれを使い回すことになります。

変換工程の小話･･･

実際に僕が経験したマイグレーションの辛かった？小話をお話しします。

上記のとおりマイグレーションの変換工程は基本的にツールで自動化して行うのですが、ケースによってはそれができない場合もあります。

それは、複雑な変換を要するケースです。単純にツールだけでは判断できず、人が目視で確認してその都度判断しながら変換する必要があるソース箇所があったりします。

こんな場合、ツールは使用できず、マンパワーで膨大な資産をひたすら手修正していくことになります。こうなるとかなりの人件費とコストがかかります。

お客様に相談して、しっかり理由を述べてお金を出してもらうこともありますが、それが実現されないケースもあります。

そうなると、つら～いサービス残業が待っていたり、変換期間が伸長されず毎日会社に泊まったりというケースが出てくるわけです。

以上、変換工程の小話でした。

④【テスト工程】

お客様資産の変換が一通り完了したら、いよいよテスト工程に入ります。テスト工程では、変換した新しい資産を用いて、新しい環境でテストを行います。

具体的には次のようなことをテストします。

上記の項目をすべてチェックしていき、不具合はないか、新しい非互換は発見されないか、くまなくテストしていきます。

テストする際には、以下の点も考慮する必要があります。

せっかくマイグレーションするのに、変換前より変換後の方が品質が落ちていたらダメです。これはマイグレーション失敗ということになります。

当然そのまま放置はできないので、改めて仕様を作り直して、品質改善に努めていくことになります。

処理速度も重要です

また、複数の処理をまとめて実行するバッチ機能や、画面操作をするオンライン機能などの処理で、マイグレする前よりも実行速度が落ちてしまうケースがときどきあります。

現行環境ではバッチAを実行すると１時間程度で終わったのに、新規環境だと２時間かかってしまう･･･なんてことは多く発生します。当然そのままにはしておけません。

よって、どうすれば処理の高速化が図れるか、念入りにチェックしていくことになります。高速化するために、設計段階まで手戻りすることもあります。

マイグレーションのテストは効率化が重要

テスト工程は多くの時間を要するとても重要な工程です。基本的にテストは１回ですんなり終了することは少なく、たいていは同じテストをやり直したりするものです。

その場合、同じインプットデータを再度用意したり、データベースの状態をテスト前の状態に戻したりと、付帯作業が必要だったりします。

なので、１つのテストをするだけでもかなりの時間と労力を要することも多々あります。

結論として、テスト工程では効率化が必要不可欠となります。具体的には次のような点を工夫してみます。

ざっくりですが、このような感じです。

考えなしでテストを始めてしまうと、何度も同じテストを繰り返すことになったり、その都度入力データを準備したりと、なかなか先に進まないことがあります。

なので、できる限り効率化を図り、テスト工程でつまづかないようにすることが大切です。

代表的なマイグレーションツール

僕が会社で実際に使用していたマイグレーションツールは、次に示すプログラミング言語で開発されていました。

会社によっては他にも色々使うと思いますが、僕のいた場所では上に示すような言語を使っていました。最後のはプログラミング言語ではないですが。

変換工程で使用するツールとは、基本的に次のような処理を行います。

つまり、正規表現が扱えるような言語なら何でも良いわけです。その意味で、Perlはかなり重宝しました。

マイグレーションする資産の具体例

最後にマイグレーションする資産の具体例を少しご紹介します。

マイグレーション資産例①「ファイル」

銀行などでは、ホスト環境で使っていた古い形式のデータファイルを新しい環境でも読み込めるようにマイグレーションすることがあります。

たとえばCOBOLのファイルなら、順ファイルとか索引ファイルとかあります。

また、レコードの長さによって、固定長レコード、可変長レコードなどもあります。現行の可変長レコードを、マイグレによってすべて固定長に変換するということもあります。

マイグレーション資産例②「COBOL」

銀行などの基幹業務システムでは、COBOL言語が使われていることが多々あります。この場合、変換対象となる資産は主にCOBOLということになります。

基幹業務システムにCOBOLが使われている会社は今でもある程度残っているのではないでしょうか。

マイグレーション資産例③「 DB（データベース）」

古いデータベースをリレーショナルデータベースにマイグレーションすることもよくあります。現行はローカルのファイルで管理していた資産を、移行後はデータベース上で管理するということもあります。

移行後はオラクル（Oracle）のRDBにするという案件もけっこうあります。

マイグレーションの失敗事例

僕の務めていた会社ではマイグレーションサービスをいくつも扱っていましたが、失敗事例というものは聞いたことがありません。

当然ですが、品質、処理速度、運用、すべてにおいて現行と同様、またはそれ以上を目指すまで終わりません。というか終われません。

その意味で、マイグレーションをやって失敗ということは起こりにくいかもしれません。運用で問題があれば、マイグレスタッフがサポート、保守することも一般的です。

まとめ

マイグレーションサービスとは何か、どのような工程からなり、どのようなメリットがあるのか、経験談からご紹介してきました。

老朽化したシステムは資産の管理不備による肥大化が起こりやすく、ランニングコストも多くかかる傾向があります。マイグレーションして悪い、ということはまずないでしょう。