レガシーシステム再構築の選択肢の一つ『マイグレーション』に関するセミナーや展示会などシステムズのイベントをご案内。

システム再構築を成功させるマイグレーションセミナー

〜クラウドやOSSを活用した最新移行事例と現場のプロによる移行検討の勘所を解説〜

システムズは9月12日（金）、東京・品川区の本社セミナールームで「システム再構築を成功させるマイグレーションセミナー」を開催しました。まだまだ日中は暑さが続く中、多数の方々にご来場いただきましたことを御礼申し上げます。

メインフレームを中心としたレガシー環境で稼働する業務システムを、オープン系システムへ移行するレガシーマイグレーションに、多くの企業が取り組んでいます。しかし、長年にわたる運用の中では、機能追加や改修の繰り返し、技術者の異動・退職などが発生し、システムを所有している企業自身がその中身を把握できない“ブラックボックス化”を招いているケースが少なくありません。マイグレーションの必要性は理解しているもののどこから手を付ければいいのかわからない、あるいは、マイグレーションに取り組んだものの移行しきれず旧ホストが継続稼働している、といった声もよく聞かれます。

システムズは、マイグレーションサービスの専門ベンダーとして多数のお客様の移行プロジェクトをお手伝いしてまいりました。今回のセミナーでは、当社がこれまで手がけてきたマイグレーションの事例を交えながら、クラウドやオープンソースソフトウェア（OSS）の活用なども含むシステム再構築の最新動向をご説明しました。

マイグレーション事業本部
担当部長 中本周志

第1部は、当社マイグレーション事業本部担当部長の中本周志から、マイグレーションに用いられるさまざまな手法や、当社のサービスの特徴、複数の技術を組み合わせたシステム再構築の実例などをご紹介しました。

当社は、4GL（第四世代言語）やベンダー独自仕様のCOBOLで書かれたレガシープログラムを、WindowsやLinux上でサポート可能なオープン系COBOL、Javaなどに書き換える「リライト」型のマイグレーションを得意としていますが、システム再構築の手法としては、エミュレータを活用して現行プログラムをそのままオープン系OS上で動作させる「リホスト」や、スクラッチで新システムを再開発するやり方も考えられます。当社にご相談をいただくお客様も、多くは最初からリライト型マイグレーションを実施する意向を持たれているわけではなく、さまざまな手法がある中でどれを採用すべきか決めかねているというケースがほとんどです。

そこで当社では、実際のマイグレーション作業に入る前段階として、既存IT資産の“棚卸し”プロセスを重視しています。ブラックボックス化したシステムの中身を精査し、プログラム／JCLの使用状況等をドキュメント化。使われていないプログラムや重複したプログラムを排除し、新環境へ本当に移行すべき資産は何かを可視化した上で、最適なマイグレーション手法をご案内します。

セミナーでは、課題に応じて特徴的な手法を採用した事例として、製造業のお客様がERPパッケージを導入する際、「部分マイグレーション」でアドオン開発費用を削減できたケースをご紹介しました。受発注管理では得意先ごとの独自仕様が要求されるためERPパッケージをカスタマイズすることを検討していましたが、その部分のみ既存ホストで使用していたプログラムをオープン系COBOLへ変換しERPパッケージと連携させることで、ERPのカスタマイズに比べ移行費用を4分の1に抑えることができました。

ERPパッケージを「部分マイグレーション」により補完することで、パッケージのカスタマイズに比べ1／4の費用で独自仕様に対応

また、旧ホスト上の人事システムをクラウド基盤上へ再構築するにあたり、COBOLとJavaを共存させた構成例もご紹介しました。システム開発においてJavaが主流となっていることから、マイグレーションというとまず「レガシープログラムのJava化」を想像されることも多いですが、Webインタフェース部分や頻繁に改修が入る機能ではJavaの使い勝手が活きる一方で、長期間変更がないロジックはJavaに書き換えるよりも、COBOLのまま移行したほうが性能や変換トラブル予防といった点で有利な場合もあります。COBOL／Java連携型の構成を採ることで、限られたコストや納期の中でレガシー資産のクラウド化が実現しました。

このほか、セミナー第1部では、OSSを活用してオンプレミスからクラウドへの移行を実現した例や、移行方式やコスト・技術的リスクを検討する際に行う「PoC」（Proof of Concept：コンセプト実証）、コードをパターン分析しプログラムの変換効率を向上させる当社独自技術に加え、社内教育やステークホルダー間での調整といった技術面以外で発生する課題についてもご説明し、レガシーシステム再構築の全体像をお伝えしました。

開発事業本部
マイグレーショングループ
プロジェクトマネージャー 大島理史

続く第2部は、当社開発事業本部マイグレーショングループでプロジェクトマネージャーを務める大島理史から、マイグレーションプロジェクトの現場ではどのような課題が発生しているか、またプロジェクト成功のためどのようなポイントを押さえておくべきか、最新の事例をもとにより具体的にご説明しました。

このセッションでは、当社が最近手がけたマイグレーション事例を5つ採り上げ、その中で直面したさまざまな課題とその対応策を紹介。スケジュール通りプロジェクトを進めるためお客様側でどのような体制をご用意いただくか、また既存システムの運用とマイグレーション作業を並行して進めるための調整や工夫など、実際にさまざまなプロジェクトに携わってきたプロマネの立場からシステム再構築の勘所をお伝えしました。

さらに、マイグレーション作業の中でトラブルにつながりやすい技術的な課題についても詳細な解説を行いました。例えば、プログラムの変換と同様に重要となるのがデータの移行です。文字コードひとつとっても、メインフレームではEBCDICコードやベンダー独自の漢字コードが使用されていますが、Linux環境で標準的なのはUTF-8です。しかし、UTF-8は日本語1文字が2バイトに収まらないため、プログラムの大規模な改修が必要となってしまいます。これを防ぐため移行先がLinuxの場合でも文字コードは一般にShift-JISが用いられますが、システム上にUTF-8・Shift-JISが混在する問題をミドルウェアで解決する必要があります。また、EBCDICとShift-JISではソート順に違いが発生することもあります。

また、コンパイラによって小数点以下の桁数の扱いが異なるため、中間処理によっては最終的な計算結果に違いが発生するといったトラブルも考えられます。このようなバグは、入力する値によっては表面化しないことも多いため見つけにくいという問題があります。

プロジェクト中で最も多くの人手が必要となるのがテスト工程ですが、お客様からは「ロジックに変更はないので疎通テストのみでよい」とのお声をいただくこともあります。しかし前述の通り、プログラムの変換が正しくても他の要因で問題が発生することは少なくなく、テストのレベルを落としたためにかえってトータルの工数が増えてしまった事例もありました。

当社ではマイグレーションの品質を確保するため、新旧システムにデータを流して実行結果の一致を確認する「比較検証テスト」を原則実施しており、この日のセミナーでもテストの重要性を強調しました。テスト実施に際してはお客様にも作業のご負担をいただくことになりますが、作業内容や分担についてはプロジェクトの最初の段階で詳しくご説明し、着手後においても十分なサポート体制を整えておりますのでご安心ください。

以上の2セッション終了後、セミナー会場ではマイグレーションを熟知したプロジェクトマネージャーや技術者との相談会も実施し、この日の内容に関する質問だけでなく、システム再構築に関する幅広いご相談をお受けしました。

新規開発や機能改修とは異なり、マイグレーションはベテランのシステム担当者でも任期中に1度経験するかしないかの特殊な作業です。企業の内部にはノウハウが蓄積されにくい分野ですので、レガシー資産に関する悩みをお持ちの場合はまずシステムズに声をおかけください。プログラムの変換技術にはもちろん自信を持っておりますが、“変換ありき”ではなく、お客様ごとの課題に応じたベストアプローチをご提案させていただきます。