FBI BLOG

ブログ記事

最終更新日: 2025.03.13

3社連動記事 第3章 RPGⅢからFFRPGへの道程

【前章】

この記事の狙い

RPG技術者不足が深刻化する中、IBM iユーザーが直面する課題は旧式RPG(特にRPGⅢ)に依存したシステムの保守性や拡張性の限界です。この課題を解決する鍵が「FFRPG」です。

なぜFFRPGなのか?

RPGⅢは固定書式の制約があり、可読性が低く、改修に手間がかかるため、技術者の負担が大きいという問題があります。一方、FFRPGは自由形式の構文を採用しており、現代的な開発手法に適応しやすく、学習コストも低いため、技術者の確保と育成がしやすくなります。

また、RPGⅢでは新機能の追加や他システムとの連携が難しく、拡張性の面でも大きな課題があります。しかしFFRPGならモジュール化が容易で、新しいビジネス要件にも柔軟に対応できるため、IBM iを将来のIT基盤として活用し続けることが可能になります。

弊社は過去にFFRPGに関する多数の記事を執筆し、iEvo2024のセッション「RPGだけどRPGじゃない~採用事例が拡がるFF RPG」でも、RPGⅢからの移行方法について解説しました。特に段階的な移行や支援ツールを活用することで、スムーズな移行が可能であることをお伝えしました。

本記事では、具体的な移行事例を紹介しながら、IBM iの未来を見据えたシステム運用のヒントをお届けします。

RPGⅢからFFRPGへコンバージョンプロジェクトの概要

第2章:RPGソースをFFRPGに変換するツールARCAD Transformer RPGのご紹介」で三和コムテック様よりFFRPGへのコンバージョンツールである「ARCAD Transformer RPG」について説明がありました。

弊社はARCAD Transformer RPGを使ったRPGⅢからFFRPGへのコンバージョンプロジェクトに参画した経緯があり、今回はそのプロジェクトの内容に触れながらFFRPG化のプロセスをご紹介していきたいと思います。

そのお客様(以下A社)は、特に機能面に不満はなく、構築して数年間大きなトラブルもない安定したシステム稼働を実現していましたが、長く保守を担当していた会社から将来的に保守契約解除の話が上がり、どのようにIBM iを継続利用するかが課題となりました。

対象となるRPGⅢの本数は約2500本。そこでIBM iを継続利用するか、他システム(オープン系)へリプレイスするか検討を開始しました。

<検討内容のまとめ>

IBM iの継続利用

  • FFRPGはオープン系言語に近いため、保守担当者や技術者の確保が容易
  • RPGⅢからFFRPGへの変換は、高い変換率を誇るツールが既に用意されている
  • 言語変換のみでシステムの機能はそのまま利用可能なため、新規システムを構築するよりもスケジュール・コスト・リスクを大幅に削減できる
  • IBM iの信頼性や安定性を維持したまま、継続利用が可能


オープン系に移行した場合

  • 移行にはFit&Gapの分析や業務改善など、多くの検討が必要
  • システムに業務を合わせる必要があり、運用面での課題が多数発生
  • データ移行では完全移行が困難なケースもあり、補完作業が不可避
  • スケジュール・コスト・リスクを総合的に検討した結果、FFRPG化に比べて移行コストが一時
    的に約10倍に膨らむだけでなく、アプリケーションの資産継承が困難になる。結果として、長
    期的な保守・維持の負担やコストもさらに増大する

以上の結果からA社はFFRPGへの変換を選択し、プロジェクトがスタートしました。

FFRPG化プロジェクトのスケジュール

FRPG化プロジェクトで実際に使用されたマスタースケジュールです。ここでFFRPG化プロジェクトのスケジュール図をご覧ください。

FF化プロジェクトのスケジュール

ここで重要なポイントは以下の3つです。

  • 変換が完了しても、プロジェクトは終わりではない
  • ツールを使っても、手作業が必要な部分が残る
  • テストは慎重に行い、十分な時間を確保することが重要

それぞれ詳しく説明していきます。

変換が完了しても、プロジェクトは終わりではない

作業項目を見ていただくとわかるように、スケジュールは長期間にわたっています。対象本数が2,500本であることは前節で説明しましたが、作業内容を見れば、「ある作業」を経験したことがある方には馴染みのある工程だと感じるかもしれません。

このようなスケジュールを組むのは、「桁数拡張」などのプロジェクトに似ています。確かに、変換作業自体は前章で紹介した「ARCAD Transformer RPG」のようなツールを使えば短期間で完了します。しかし、その前にクリアすべき課題がいくつかあります。

<クリアすべき課題>
①対象プログラムの最終的な洗い出し
②開発環境の構築

  • コンパイル環境の準備
  • ライブラリリストの関連性チェック
    • 同じ名前のFILEが複数のLIBに存在し、データ内容が異なるケースの整理
  • 文字コードの問題
    • 「ARCAD Transformer RPG」の推奨文字コードは5035だが、古いシステムでは65535で作成されていることがある。その場合、まず5035への変換が必要になるため、事前調査を行い対象本数とともに整理しておくことが重要。

これらの課題を事前に解決することで、変換作業をスムーズに進めることができます。

ツールを使っても、手作業が必要な部分が残る

変換作業が完了しても、そこで終わりではありません。変換後も多くの作業が残っています。特に、コンバート後にはエラーが発生することがあり、ここでは実際のプロジェクトでよく見られたエラーの例をいくつか紹介します。

FF化プロジェクトで頻出のエラー例

①「6.コンバート失敗」
DO命令の繰り返しがなくなったコーディングなどについては変換エラーとなります。
例)DO命令の項目2に指定がない場合
①forへの変換が行われずにC仕様書のままで残る
②doに対応するenddoがendforに変換されてしまう。このような場合は、元のコードを修正した上で、再度変換を実行する必要があります

②「2.数値あふれ」
RPGⅢではよくあることですが、MOVE(L)命令を使って文字項目から数値項目へデータを転送し、タイプ変換を行うケースがあります。特に、最後の数桁を意図的に切り捨てる目的で使用されることも多いでしょう。しかしFFRPGでは数値項目への転送時に桁あふれが発生すると、実行エラーとなります。

「ARCAD Transformer RPG」は、転送元の桁数が転送先より大きい場合、桁あふれを考慮したコードを生成しますが、二進数項目の場合は桁あふれ対策が適用されないため、注意が必要です。

③「4.文字数字変換」
RPGⅢでは、MOVE(L)命令を使用して文字項目から数値項目への転送時にタイプ変換を行うことができました。しかし、FFRPGではMOVE(L)が廃止されたため、転送処理は%DEC関数を使ったコードに変換されます。

テストは慎重に行い、十分な時間を確保することが重要

前章では変換後のエラーについて説明しましたが、では変換が完了した後はどうなるのでしょうか?単純な言語変換でロジック自体は変更していないため、そのままシステムとして使えると考える方もいるかもしれません。しかし、実際にはそう簡単にはいきません。

なぜなら、変換作業の過程で少なくとも6つの項目に何らかの修正を加えており、結果的に開発と同じ作業を行ったため、必ずテストが必要になるからです。本プロジェクトでは、マスタースケジュールに沿って変換作業期間よりも長いテスト期間を確保し、テスト工程を3つの段階に分けて実施しました。

<テストの3段階 >
①ロジック確認と実行時エラーチェック

  • FOR命令で桁あふれが発生するなど、実行時のエラーを確認し、修正を行いました

②スルーテストとプログラム切り替えテスト

  • 修正が完了したプログラムを再度スルーテストし、現在稼働中のオブジェクトとの入れ替え作業を想定したテストを実施
  • 実際の切り替え時間を計測しながら検証を行いました

③最終テスト

  • ②のテスト結果をもとに問題点を洗い出し、本番移行と同じ手順でテストを実施
  • 稼働判定会議で最終確認を行い、計画通り本番環境へ移行しました

テスト中にいくつかの修正が発生したものの、変換作業はスムーズに進み、事前に想定されていた問題にも迅速に対応できたため、円滑にスケジュール通りの移行を実現することができました。

ここまで、既存システムをFFRPG化する実際のプロジェクト事例を紹介しました。想像以上に期間が長く、作業も多岐にわたると感じたかもしれません。しかし、こうした移行プロセスの多くはRPGⅢ特有の仕様に起因しており、FFRPG化を通じてオープン系との互換性を高めるために必要な作業です。

適切なスケジュールを確保し、事前準備・変換・テストを段階的に進めることでスムーズな移行が可能になります。

まとめ|コンバートプロジェクトを通じて得た知見

  • ARCAD Transformer RPGの変換精度は高い
  • 変換時の問題は、RPGⅢのコーディング方法に大きく影響を受ける
  • 事前対応をしっかり行うことで、問題の発生を抑えられる
  • ソースの修正作業には、IBM iやFFRPGの専門知識がなくても参加できる
  • テスト仕様書の作成には、システムを熟知したメンバーが必要
  • テスト作業は、保守チームやシステム部門と分担することが重要
  • 現行システムと新システムの比較テストで、数値の相違は発生しなかった
  • テスト環境と本番環境の設定を揃えておかないと、細かな差異が発生する
    ※OSバージョンの違いによるパラメータ初期値の差異やCHGCMDDFTなどユーザーがカスタマイズした設定の影響

現行システムと新システムの比較テストで、数値の相違は発生しなかった。テスト環境と本番環境の設定を揃えておかないと、細かな差異が発生する。続く第4章では一連の文書のまとめとして、短期・長期の両面から、どのようにしてFFRPGを活用してゆけば良いのかベル・データ株式会社による次章に委ねたいと思います。

【次章】
ベル・データ株式会社「第4章:FF RPGで描く基幹システムの未来」に続く

【前章】

関連ブログ

そんなご質問・ご相談でも大歓迎です!

ITの力で企業の未来を支える

お気軽にお問い合わせください。
お客様のご要望に合わせて、最適なシステムをご提案いたします。

お問い合わせ