日鉄ドラム株式会社様 | ソルパックコーポレート

500本のRPGプログラムで構成された生産管理システムをJavaに変換し、大幅なUIの向上とシステムのサステナビリティを実現

システムのサステナビリティを考え
RPGをJavaへコンバートして維持・運用性を向上
コンバージョンツール「Florida」を利用して、真にJavaライクなアプリケーションを生成

このままではシステムのサステナビリティを実現できない

日鉄ドラムはAS/400時代から約30年にわたり、IBMi上で基幹システムを運用してきた。
RPGで開発された販売管理、生産管理、出荷かんり、鋼材・副資材管理、原価管理の各システムは、約20年前に大幅な機能改善の実施をした以外、ほぼ当時の機能・構成のまま稼働している。また、給与・会計システムは、「iSeries Site」を一部カスタマイズして運用していた。
日本製鉄のシステム担当部長であった金澤典一氏が日鉄ドラムへ転籍し、管理本部システム部長に着任したのは2017年4月のことである。このとき金澤氏には、「このままIBMiを使い続けても大丈夫か」という命題を証明する、つまりこの難しい問いに対して、明確な答えと解決策をもたらすという重要なミッションが与えられていた。
長年にわたるIBM iの運用で顕在化していた課題は2つある。1つはドキュメントが残されておらず、RPGスキルを備えた人材が不足し、現行アプリケーションの維持・運用が難しくなっていたこと。もう1つはスクロールやプルダウンなどの一般的な画面操作が行えず、機能の改善や高度化へ対応するのが困難なシステム構造であったことだ。
システム部では、外部ベンダーから派遣された常駐のベテラン技術者1名がアプリケーション保守に対応する一方、長年運用に携わり、RPGやシステム構造を熟知したシステム部の担当者がまもなく定年を迎えるタイミングであった。着任以来、数か月にわたる調査を実施した結果、金澤氏は次のような結論を出すに至ったという。
「このまま使い続けた場合、要員は枯渇し、システムは塩漬けになり、近い将来にはシステムを抜本的に作り直す道しか選べなくなる。システムのサステナビリティ（持続可能性）を考えるなら、IBM iをこのままの状態で使い続けるべきではない。やるなら、今。ベテラン担当者が在籍し、知識やノウハウを継承しつつ、先に踏み出せる今のタイミングしかないと判断しました」

「Florida」を使用してRPGプログラムをJavaへ変換

金澤氏が次に検討したのは、「それではIBM iをどのように変えていくべきか」という青写真である。
選択肢は2つあった。1つはIBM i以外のサーバーへ移行し、ゼロからシステムを作り直すこと。もう1つは現行のRPGで開発したビジネスロジックを活かしつつ、そのプログラムをJavaへコンバートして維持・運用性を高めることである。
ただし、全社の案は早々に見送ることになった。理由はコストとマンパワーである。「全面的な再構築は相当のコストが予想されるうえ、基幹システムの全面再構築を担える十分な人員を充当することは難しいと考えました」（金澤氏）
そこで現行システムのRPGプログラムをJavaへコンバージョンすることを前提に、その手法を検討し始めた。

システム構成ー従来・現行・将来
システム構成-従来・現行・将来

「操作性の改善や機能追加などは必要であるものの、基幹システムは現行の基本的な業務要件を満たしており、ビジネスロジックそのものに問題はありません。検討すべきはRPGという開発言語であり、これがシステムのサステナビリティを阻害していると考えざるを得ませんでした。そこで一般的な言語、つまり若い世代が誰でも知っていて、かつ存分に使用できるJavaという言語に変換していくことを選んだわけです」
ここでは2つのコンバート手法が検討された。1つは海外製ツールを使用して、RPGプログラムをストレートコンバージョンする手法。もう1つは同じくJavaへのコンバージョンツールである「Florida」（フロリダ）を使って、Javaの個性を活かしたアプリケーションとしてコンバージョンする手法である。
後者の案はソルパックからの提案であったが、結論として、同社が選択したのはこちらの手法、すなわちFloridaによるJavaへのコンバージョンであった。
一般にRPGプログラムをJavaへストレートコンバージョンした場合、言語特性の違いから、データベースアクセス時にパフォーマンスが劣化したり、RPGのプログラム構造をそのままJavaに反映するため、Javaの特性や開発生産性のよさを欠いたアプリケーションが完成するケースがしばしば見られる。
しかしFloridaの場合は、取り込んだPRGソースを中間言語（Miami）に変換し、エディター機能で、ロジックの修正や使用の追加が可能。PRGの読み込み処理をJavaに変換する独自のチューニング技術により、パフォーマンスの劣化を防ぐ。またCLプログラムなどは自動変換ではなく、手作業で変換するため、全体的にJavaの特性を生かしたアプリケーションとして作成できるのが特徴だ。
「最大のテーマは今後の維持・運用性でした。そこで2つの手法で変換されたJavaプログラムを、今後のアプリケーション開発・保守を委託する日鉄ソリューションズのJava開発者に比較・検討してもらいました。その結果、Floridaで変換したプログラムのほうが、維持・運用性に優れるという結論を得て、採用を決めました」
変換されたJavaアプリケーションはオープン系のLinuxサーバーで稼働させ、データベースはDb2 for iとしてIBM i側で運用する。つまりIBM iはデータベースサーバーとして残すわけである。
「データベースもOracleやSQL Serverなどへ移行してLinuxサーバーで運用し、IBM iから完全撤退する案も検討しました。しかしDb2 for iは優れたデータベース構造を備え、テーブルもよく正規化されていたので、必ずしも今オープン系へ移行する必要はないと判断しました。Power SystemsとIBM iというマシンの優秀さはよく理解していたし、データベースサーバーとして残す案を選択したわけです」（金澤氏）

6年計画の「システムマスタープラン」を策定

これらの結果を受け、2018年7月には、6年計画で2024年の完了を目指した「システムマスタープラン」を作成し、経営側の承認を得た。
このプランでは、（1）システム基盤の再整備、（2）生産・販売・出荷管理システムでの機能拡充や操作性の改善、（3）一般事務・管理業務へのパッケージソフトの導入という3つの柱に据えた。
システム部の人員構成は、金澤氏を含む3名で、上流工程を担当する。また企画支援、開発・保守をになうのは日鉄ソリューションズ。プロジェクトチームにはこの2社に加え、コンバージョン作業を手掛けるソルパックとフロリダが参加した。
システムマスタープランの第1弾として、2019年5月にまず、それまでシステム化していなかった「勤怠管理システム」「設備管理システム（代表拠点）」をオープン系のパッケージソフトで実現した。
さらに第2弾として、当初は2021年度末までの完成を目指し、生産管理、完売管理、出荷管理の各システムのコンバージョンに着手した（コロナ禍によりプロジェクト進捗に遅れが生じ、実質的に約半年～1年遅れでの本稼働となっている）。
最初の対象システムは生産管理システムで、400～500本のRPGプログラムで構成されていた。不具合発生時の原因究明を明確にするため、変換作業は2段階に分けられている。第1フェーズで、Javaへの自動変換および項目の見直しや整理を含むマスターの変更を実施。第2フェーズとして、新規機能を追加を実施した。
アセスメントに約2か月、変換作業に約5か月、サンプル受け入れテストに約2か月を経てコンバージョンの妥当性評価・確認を行った。その後、本格的なコンバージョンと並行して進めていたマスター関連の改善機能を含めて総合テストを実施し、第1フェーズは2020年7月、第2フェーズは2021年9月に本稼働している。
完成したシステムは、チェックボックスやボタンなどの操作が可能になっているが、画面デザインはRPG時代のイメージを踏襲しており、ユーザーに混乱が生じないように配慮されている。
また次の販売管理システムは、RPGプログラムで300～400本。2022年3月に第1フェーズが本稼働した。今年秋には第2フェーズが稼働する予定である。
今回のWebベースの新システムは、「大納言」（DINAGON=nittetsuDrum INtegrated and Advanced system for General Operation and Next-stage）と呼ばれている。
生産管理・販売管理という大きな山を越え、プロジェクトは順調に後半戦へと向かっているようだ。

COMPANY PROFILE