リライトマイグレーションにおける帳票アーキテクチャの開発の進め方

皆さん、はじめまして。
TIS株式会社で「Xenlon～神龍　モダナイゼーションサービス」のデリバリを担当している来嶋と申します。

今までのコラムでは、弊社のリライトマイグレーションサービスの特徴やリライトマイグレーションプロジェクトを成功に導くポイントを多くご紹介してきました。
今回は、リライトマイグレーションプロジェクトにおける開発にフォーカスをあてて、企業の業務に身近な「帳票」をテーマにお話ししたいと思います。

帳票は、業務を円滑に進めるために必要な存在で、従来は、帳簿や伝票など、お金の流れや取引に関する書類を指します。また、作業指示書、点検表のような書類・リストも帳票と称して扱われことから、帳票は、様々な場面で活用されています。システムで管理している帳票数としては、1つの基幹システムで数百種類におよぶことも珍しくありません。

マイグレーションにおいて、帳票の移行は、主に以下３つの観点で検討します。

1. 帳票アーキテクチャの移行
   業務データを帳票に必要な形式に編集するプログラムや帳票を視覚的なイメージとして出力する帳票製品など、帳票を作り出すためのアプリケーションの移行。
2. 帳票そのものの移行
   帳票製品で保持している帳票データやPDFなどの電子ファイル形式の帳票など、現行システム内で保管されている帳票の移行。
3. 帳票を使ったユーザ業務・運用業務の移行
   帳票を利用した業務、帳票の印刷や配送などの運用業務の移行。

本コラムでは、このうち「１．帳票アーキテクチャの移行」についてご紹介します。

帳票アーキテクチャの移行について

リライトマイグレーションでは、新システムで作成される帳票が、現行の帳票と同等の見た目や印字結果となるよう開発を進めます。

まずは、現行システムの帳票アーキテクチャを解明することが必要です。そして、新システムの帳票アーキテクチャを構成する各要素において、どこで何を実装すれば現行の帳票と同等の見た目や印字結果にできるのかを考えることが重要です。つまり、帳票製品だけではなく、帳票データを作り出しているアプリケーションを含めて、帳票アーキテクチャ全体でFit&Gap分析を行い、マイグレーションを進めます。

企業によってシステム構成は様々であり、プログラム言語や帳票製品をはじめとしたソフトウェアも異なります。
帳票アーキテクチャを大きく４つの要素に分け、リライトマイグレーションにおける開発の進め方について、考慮すべき点に触れながらご説明したいと思います。

【図１：帳票アーキテクチャ構成の概要イメージ】

①　帳票データを作成する業務プログラム
②　帳票をイメージ化する帳票製品とのインターフェースプログラム
③　帳票をイメージ化・保管する帳票製品
④　帳票をイメージ化するために必要な定義資産

①帳票データを作成する業務プログラム

帳票データを作成する業務プログラムは、帳票の数に比例して存在していることが多く、帳票アーキテクチャの移行において、開発のボリュームゾーンとなります。
リライトマイグレーションにおいては、弊社サービス「Xenlon～神龍Migrator」などのマイグレーションツールを活用してレガシーなプログラム資産（COBOL、PL/Iなど）をJavaプログラムへ自動変換します。これにより、現行のプログラム資産を活かしながら帳票アーキテクチャの移行における開発ボリュームを抑えることができ、同時に、帳票データも現行と同様のレイアウトを再現します。

ただし、帳票データを作成する業務プログラムでは、帳票の印字に関わる制御を担っている場合もあり、帳票アーキテクチャの移行を考慮したリライトが必要です。
例えば、メインフレームでは、帳票データがラインデータ（行データ）形式で、オーバーレイ（罫線、枠、固定文字などのフォーマット）と組み合わせることで、帳票を実現している場合があります。この場合、業務プログラムが、改行、改ページ、フォントサイズ指定などの制御コードを帳票データに対して付与しており、オーバーレイで定義した罫線や枠内に帳票データが収まるように印字位置を制御するための役割を担っています。
これら制御コードは、メインフレームの文字コードや帳票製品に依存した値であるため、オープン系システムで採用する文字コードや帳票製品を踏まえた値に置き換えるように業務プログラムをリライトすることが必要になります。
制御コード以外にも帳票製品に依存した実装が含まれる場合もあるため、帳票アーキテクチャに関わる業務プログラムを特定・分析して、新システムに適した置き換えを考慮してリライトすることが不可欠です。

②帳票をイメージ化する帳票製品とのインターフェースプログラム

帳票製品のAPI（Application Programming Interface）です。帳票製品によって、受け付ける帳票データのレイアウトや連携方式の仕様が異なるため、リビルド手法で開発します。また、インターフェースプログラムには、現行と新の帳票アーキテクチャの仕様差異を吸収する役割も持たせます。この役割を持たせることで、前述した「①帳票データを作成する業務プログラム」はリライト手法で移行できるため、リライトの適用範囲を最大化に寄与することになります。リライトの適用範囲の最大化は、リライトマイグレーションを成功させる重要なポイントの一つです。
インターフェースプログラムに何を実装すべきかは、帳票アーキテクチャのFit&Gap分析を踏まえて検討します。

③帳票をイメージ化・保管する帳票製品

帳票製品は、帳票をシステム内に保管・管理することや、帳票データを用いてPDF形式などの電子帳票を作成、帳票印刷する役割を持っています。そのため、用紙のサイズや片面・両面印刷などの印刷設定、帳票保管期間や帳票印刷時の仕分け・配布先の情報などをマスタ情報として保持しています。一方、これらの情報は、オーバーレイで設定している場合や業務プログラムで帳票データに付与している場合もあります。新システムの帳票アーキテクチャにおいて、これらをどこに・どのように設定すれば現行の帳票を再現できるかを踏まえて、新システムの帳票製品のマスタ情報に設定すべき値を検討します 。
新システムに導入する帳票製品の選定についても少し触れておきます。
リライトマイグレーションとしては、現行の帳票製品と同等機能が備わっているかを基本として選定しますが、長期保管や新たな帳票の増加など、大量の帳票を管理する必要があることも踏まえて検討します。
特に、メインフレームからオープン系システムへのマイグレーションにおいては、現行システムで導入している製品の後継がない場合もあります。一方で、オープン系システムの帳票製品自体は数多く存在し、多機能・多様化しているため、マイグレーションを機にマイグレーション以外の要件も含めた選定をすると良いでしょう。

• 従来の紙印刷を廃止し、PDF形式で保管・業務利用できるようペーパレス化したい
• 新たな全社標準の帳票統合管基盤を作りたい
• データ活用を想定してBIツールなどとの連携も容易に追加可能な製品を導入したい

など

④帳票をイメージ化するために必要な定義資産

帳票の見た目をつかさどる資産として、罫線・枠・固定文字列などをあらかじめフォーマットとして定義しているオーバーレイや、帳票データの各項目の配置位置・表示形式を定義した帳票定義体などがあります。帳票をイメージ化する帳票製品やプリンタ機種などによっても様々な形式で存在しており、定義できる項目も様々です。
これらの資産も、帳票単位に必要となるケースが多く、開発ボリュームが大きい要素です。
弊社では、現行システムのオーバーレイや帳票定義体を解析し、新システム用の定義資産に自動変換するためのツールを開発します。自動変換ツールを用いることで、帳票の定義資産の開発ボリュームを抑えることができます。
また、帳票の見た目を検証する手法として、もし、現行システムおよび新システムの帳票が共にPDF形式で出力可能な場合であれば、帳票の罫線や枠線の印字、帳票データの印字内容・位置が一致していることを自社開発ツールで自動比較することが可能です。従来、目視で検証をしていた工数や検証漏れなどの品質リスクの低減を図ることができます。
リライトマイグレーションのプロジェクトにおいても最終的な帳票の品質は、運用テストなどユーザ様にて検証いただく工程を設けますが、これら自動変換ツールや自動比較ツールを活用することにより、マイグレーションプロジェクトの早い段階から現行の帳票の再現度を高めた開発を進めることが可能です。

おわりに

帳票アーキテクチャは、帳票製品と業務アプリケーションが密接に連携して構築されています。「現行帳票はそのまま移行できるのだろうか？」といった漠然とした不安をお持ちの方にも、リライトマイグレーションでの開発のイメージを少しでもつかんでいただければ幸いです。

「Xenlon～神龍　モダナイゼーションサービス」製品ラインナップ

「Xenlon～神龍　モダナイゼーションサービス」シリーズはTIS独自のリライト手法によるマイグレーションを中心としたモダナイゼーションサービスで企業のDX推進をご支援します。