前回、「古くて新しいレガシーマイグレーション」では、レガシーマイグレーションの概要について紹介した。今回は、昨今多く選択されるリライト手法によるレガシーマイグレーションプロジェクトを前提とし、勘所（ポイント）を紹介する。
プロジェクトとしての難しさ
多くのユーザにとって、レガシーマイグレーションプロジェクトは他の開発プロジェクトとは異なる難しさが2つある。
- 難しさその１：マイグレーションプロジェクト推進のノウハウ不足 ユーザにとってマイグレーション自体が数十年に一度、経験するかしないか の頻度であり、マイグレーション特有の工程（現状調査、変換設計やテストな ど）での進め方に慣れていない点があげられる。
- 難しさその２：レガシーとオープンの両技術を保有する人材不足 現在まで保守運用してきたレガシーについては詳しいが、オープン側のスキルも兼ね備えた人材となるとユーザ側では不足しているケースが多い。これは、後述する技術面での検討を進める際に、両技術を理解している事が重要となる。
技術面でのポイント
リライト先としての採用技術については、各ポイントでいくつかの選択肢があるが、ユーザサイドで最も考慮すべき点は保守運用性が確保できるか否かである。ここでは、技術面において主要となる5つのポイントについて述べていく。
- 1.開発言語 リライト先の開発言語の選択肢は主に次の2つである。すなわち、手続き型言語であるオープンCOBOLか、オブジェクト指向型言語であるC#/Java等である。現行のレガシーでは、手続き型言語が採用されているため、リライト先にオープンCOBOLを選択した場合は、同型言語変換のため失敗リスクが低いことや、既存技術者のスキルシフトが容易なことがメリットにあげられる。但し、オブジェクト指向型言語への変換ツールも成熟してきており、同型言語変換が大きなアドバンテージとはならないケースもある。 一方、将来的な技術者確保となると、オブジェクト指向型言語のスキル保有者の方が多いため、オープンCOBOLの採用を見送るユーザも少なくない。
- 2.会話型処理 レガシー系で特徴的な技術の一つに会話型処理がある。この中には、画面間での情報連携、および処理の中断/再開コントロールという2つの要素が存在する。画面間の情報連携は、サーバサイドでのセッションオブジェクトによる連携や、HTMLメタ情報での連携などで対応することになる。 一方、処理の中断/再開コントロールの変換については、マルチスレッドでのコントロール、もしくはプログラム分割による対応となる。これら会話型処理は、単純にツールでの機械的な変換が困難な部分であることを認識しておきたい。
- 3.トランザクション処理 トランザクション処理は、プログラム側、DB側でコントロールされている。リライト先でも、プログラム/DBのみで対応するのか、もしくはTPモニタなどのトランザクション制御ソフトウェアで対応するのかの選択肢になる。特にトランザクション処理を多く利用している場合は、システムの拡張性とプログラムの保守運用性を確保する意味でも、TPモニタを導入し、プログラム内からトランザクション制御コードを外出しにすることを推奨する。
- 4.命令語 レガシー側言語特有の命令語で、リライト先言語に同じ動作をする命令語が無い場合、同じ動作をするclassを作成するか、もしくはロジック変更対応となる。
- 5.DBアクセス レガシー側のDB構造に依存するが、オープン化した際に構造変更が必須となる場合がある。その際、プログラム側でのDBアクセスロジックについて現行踏襲する場合は、DB構造変更の差異を吸収するDAO（Data Access Object）を作り込む必要があるが、後の保守開発における改修範囲によっては、改修量と複雑度が大きくなる可能性があることに留意したい。
以上、5点のポイントをあげたが、ツールでの変換が困難な実装方法を選択する（手組み部分が多くなる）場合は、構築金額の上振れや、稼働が遅延するリスクの増大に繋がってしまう。しかしながら、リライト後に数年～数十年の間、稼働するシステムであることを考えれば、保守運用性が許容できる範囲であることを優先すべきである。
最後に
これまであげた勘所は、何が最善の方法かはユーザ状況によって様々ではあるが、プロジェクト計画時やベンダ選定時に理解をしていれば、マイグレーションプロジェクトの成功にぐっと近づくことができると考えている。是非、参考にして頂きたい。