「Cloud Service for オフコン」のサービス終了に伴う移行方式について――第1回：リホスト／マイグレーション時の注意点

はじめに

富士通の「Cloud Service for オフコン」が、2031年3月末をもってサービス終了となることが発表されました。このサービスは、オフコンシステムを富士通データセンター上で安全かつ安定的に運用するためのクラウドサービスとして、多くの企業に利用されてきました。

しかしながら、富士通のオフコン事業の戦略転換に伴い、サービスを終了する運びとなりました。サービスの終了に伴い、オフコンシステムを利用している企業はオープンシステムなどへの移行を迫られることになります。

この記事では、IT部門の責任者・管理者向けにオフコンシステムを移行する際の技術的な注意点やリスクを極力押さえたマイグレーションのやり方を解説します。

▼この記事でわかること・ポイント

• オフコンシステム移行で推奨される方式：既存資産のロジックを活かし、コスト・期間・リスクを最小化する「リホスト（マイグレーション）」
• オフコンシステム移行の主な課題：文字コード（JEF）、拡張言語（COBOL-G）、独自DB（ISAM）などオフコン特有のアーキテクチャ変換
• オフコンシステム移行成功のカギ：周辺装置（専用帳票等）やバッチ運用（CL）を含めた包括的な資産棚卸しの実施

なぜ「Cloud Service for オフコン」移行は早めに着手すべきなのか

「サービス終了はまだ先だからまだ大丈夫……」と思っている方もいらっしゃるかもしれません。しかし、オフコンシステムのような基幹系システムの移行は3年程度の長い期間と多くの準備が必要な大規模プロジェクトです。

特に長年運用してきたオフコンシステムは、現状の棚卸しから新システムへの要件整理、移行方法の選定、そして新たな業務フローの策定など、検討すべきポイントが数多く存在します。

移行にかかる期間を逆算し、余裕を持って早めに移行プロジェクトを開始すれば、不測のトラブルやシステム停止期間のリスクも最小限に抑えることができます。

したがって、致命的なトラブルやシステム停止のリスクを回避するためにも、余裕のあるロードマップを描き、準備を進めることが求められます。

「Cloud Service for オフコン」の移行をスムーズに進めるための4ステップ

スムーズかつ安全な移行を進めるためには、以下の観点をしっかり抑えておきましょう。

現行システムの可視化
どのシステムや業務が現行オフコン環境で動いているのか、またそれぞれに必要な要件は何かをしっかりと棚卸ししましょう。これを機に、不要な資産の整理やスリム化を図ることは、今後の運用負担軽減につながります。可視化は、移行プロジェクトの第一歩です。

移行方法の検討
一口にオープンシステムへの移行と言っても移行には、様々な選択肢があります。

・リホスト（マイグレーション）：現行アプリケーションを極力変更せずに、新しいハードウェアやOS上に移行する方法
・リライト（改修）：現行のソースコードを新しい技術や言語に書き換えて移行する方法
・リプレース：パッケージソフトウェアやSaaSなど、全く新しいシステムに置き換える方法

自社の事情に合った方法を慎重に検討しましょう。信頼できるベンダーとの協力がスムーズな移行に繋がります。

移行計画の策定
移行期間、費用、ダウンタイムやリスクを十分に考慮しつつ、現実的で無理のない計画を立てることが大切です。

実績のある移行ツール・パートナーの活用
作業効率化やエラー低減のため、実績のある移行ツールの活用も検討をおすすめします。専門企業に相談するのも一つの手です。

「Cloud Service for オフコン」からリホスト（マイグレーション）する際に考慮すべき技術的観点

弊社（システムズ）では、移行コスト、スケジュール、業務への影響、移行後の安定性を総合的に考慮し、現行アプリケーションの業務ロジックを極力活用する「リホスト／マイグレーション」を有力な選択肢として推奨しています。

オフコンシステムは、長年の運用によって独自の業務ルールや例外処理が組み込まれていることが多く、リライトやリプレースでは、要件の再整理、再開発、データ移行、利用者教育、総合テストなどの範囲が広くなります。その結果、コストや移行期間が増大し、業務停止や移行後の不具合といったリスクも高まる可能性があります。

一方、リホストであれば、既存の業務ロジックや運用方法をできる限り維持しながら、稼働基盤を新しい環境へ移行できます。これにより、変更箇所と検証範囲を抑え、移行に伴うコスト・期間・業務影響を低減しやすくなります。特に、2031年3月末というサービス終了期限までに確実な移行を実現する必要がある場合、リホストは現実的でリスクを抑えやすい方式といえます。

富士通オフコン（ASPシリーズ）をリホスト／マイグレーションする場合、単なるハードウェアの置き換えではなく、アーキテクチャや言語、周辺装置、運用形態の違いを把握・考慮することが重要です。

具体的には、以下の観点で検討・対応を進める必要があります。

文字コードの違い（富士通オフコンはEBCDIC＋JEFコード）
富士通オフコンでは、一般的なWindowsやLinux環境で利用される文字コードとは異なり、主にEBCDIC系の文字コードとJEFコードが使用されています。そのため、オフコン上のプログラム、データ、帳票、外部連携ファイルなどをオープン系環境へ移行する際には、SJISやUTF-8など、移行先の環境に適した文字コードへ変換する必要があります。

ただし、文字コード変換は単純に「EBCDICをUTF-8へ変換すれば完了」というものではありません。文字の種類、外字の有無、データ連携先、帳票出力、検索・並び順などを確認しなければ、移行後に文字化けやデータ不整合が発生する可能性があります。したがって、文字コードの移行では、まずどの文字を、どのシステムで、どのように利用しているのかを整理し、そのうえで変換方式を決定することが重要です。

COBOL-Gなど専用言語資産
富士通オフコンのASP COBOL-Gには、標準COBOLには含まれない富士通独自の拡張文法や、オフコン環境に依存した入出力処理、ファイルアクセス、帳票制御などが含まれている場合があります。そのため、単純にソースコードを標準COBOLや他社COBOLの実行環境へ移すだけでは、コンパイルできない、実行時に正しく動作しない、あるいは既存システムと処理結果が一致しないといった問題が発生する可能性があります。

特に、長年にわたって改修を重ねてきたオフコンシステムでは、当初の設計書に記載されていない独自処理や、特定の運用を前提としたプログラムが含まれているケースも少なくありません。そのため、言語仕様だけでなく、プログラムが利用しているファイル、帳票、ジョブ、外部システムとの連携まで含めて確認する必要があります。

データアクセス（ISAM / G-ISAM）
オフコンシステムでは、ISAMやG-ISAMなどの索引順ファイルを利用して、業務データの登録・検索・更新を行っているケースがあります。これらのファイルは、単なるデータ保存先ではありません。プログラム内のアクセス処理、キー項目、レコード構成、排他制御、エラー処理、バックアップ運用などと密接に関係しています。

そのため、オフコンからオープン系システムへ移行する際に、ISAMファイルを単純にRDBへ変換すれば完了するわけではありません。データ構造だけでなく、現行プログラムがどのような方法でデータを読み書きしているのか、複数の処理が同時にデータへアクセスした場合にどのような制御を行っているのかまで確認する必要があります。

そのうえでオフコン独自の索引順ファイル（ISAMファイル）をRDB（Oracle, SQL Server等）へ置き換えるのか、もしくはISAM互換ミドルウェアを利用するのか検討しましょう。データ移行における性能差や排他制御、運用面の違いにも十分注意してください。

帳票出力（プリンタ制御）
オフコンシステムでは、ラインプリンタやドットプリンタ、複写式伝票などを利用し、独自の帳票レイアウトに基づいて請求書、納品書、仕入伝票、作業指示書などを出力しているケースがあります。これらの帳票は、単に画面上のデータを印刷しているだけではありません。用紙サイズ、印字位置、改ページ、明細行数、固定文字、バーコード、印影、複写枚数、プリンタ制御コードなど、業務や機器に依存したさまざまな設定によって構成されています。

そのため、オフコンから新しい環境へ移行する際は、帳票をPDFやレーザープリンタへ出力できるようにするだけでなく、現行帳票が担っている業務上の役割や、出力後の運用方法まで含めて見直す必要があります。

ジョブ制御・バッチ処理
オフコンシステムでは、ASP独自のジョブ制御言語（CL）を使って、日次・月次処理やデータ連携、帳票出力、バックアップなどを自動化しています。CLには、処理の実行順序や条件分岐、エラー時の再実行、外部システムとの連携、通知・ログ取得などの運用ルールも組み込まれています。そのため、移行時には単にバッチファイルやシェルスクリプトへ変換するだけでなく、実行条件や異常時の対応、復旧手順まで含めて再現する必要があります。

CLを、バッチファイルやシェルスクリプトへ変換し、さらに運用スケジューラがある場合にはWindows/Linux系の運用管理ツール（JP1、Systemwalker等）へ移行する手順を検討しましょう。

移行先のインフラ・運用基盤で考慮すべき技術的観点

アプリケーションやデータ資産に加え、それらを稼働させるインフラ構成や運用体制も移行プロジェクトでは大事になってきます。
特に、以下の2点はじっくりと検討して要件を固めるようにしましょう。

OS、オンプレミス、クラウド環境の選択
リホスト先の環境として、Windows ServerやLinux Serverのどちらを選択するか、またクラウド／オンプレミスの運用形態についても十分な検討が必要です。

バックアップ、復元方式
バックアップソフトや実行スケジュール、媒体（HDD、SSD、TAPEなど）、および復元手順やBCP（事業継続計画）についても、従来との違いを意識しつつ新たに策定することが重要です。

「Cloud Service for オフコン」の移行を成功させ、将来にわたる安定運用を実現しよう

「Cloud Service for オフコン」の終了は、利用企業にとって大きな転換期です。しかし、早めに準備を始めることで、移行リスクを減らし、将来的なIT基盤の最適化や業務効率の向上を実現することができます。

オフコンのリホスト／マイグレーションは多岐にわたる検討・対応事項があるため、詳細な現状分析と計画立案が成功のカギとなります。まずは現行システムの調査から始め、移行の方向性を見定めましょう。

移行支援に実績のあるパートナー企業のサポートも活用しながら、2031年3月末までの円滑な移行を目指しましょう。早めの準備が、将来の安定運用につながります。