技術発表会：2025年2月21日開催レポート

今回は技術発表会の場を借りて、今年度参加させていただきました日本IBM様主催によるIBM i RiSINGの成果報告を行いました。

本イベントにて、私は入社2年目の若手だったのですがリーダーという大役に任命していただき、約半年間活動しました。

活動内容としては、チームでの研究活動とその内容をまとめての最終発表の２つとなり、私が所属していたチームは【初心者による初心者に向けた「RPG Ⅲ」と「RPG Ⅳ」】というテーマを掲げ、若手RPG技術者のための知識を得ることができる環境構築が必要であるという問題に対して研究活動を行いました。

リーダーとしては、普段の業務でまだ経験のないチーム活動のスケジューリングや普段のミーティングでのファシリテーターといった仕事を行わせていただき、とても大きな経験をさせていただきました。

今回の技術発表会では、研究活動の成果発表となった最終発表の資料を基に研究を行った内容についてと、追加でIBM i RiSINGの中で関わらせていただいたメーカーの方やベンダーの方といった様々な環境で普段仕事をされている方との交流で学んだ知識を盛り込み発表を行わせていただきました。

　今回の発表では、前回発表したテスト自動化を仕様書の読み込みのみで実装を行うというものでした。前回のおさらいをすると、生成AIでの業務効率化に限度があることから、Pythonの自動化ライブラリに目をつけて、実業務で扱うテストでどれほどの時間短縮（効率化）が実現できたかというものでした。今回の概要は、Excelで作成した仕様書を、VBAや関数を使って自動化の動きを選択できるようにしたため、感覚的にコードを生成できるツールとなっています。

　また、前回課題に挙げていた仕様書の読み込みで自動化を実現すること、Exe化によってPytohn環境のない方でも実行できること、Wikiにて知見共有すること、生成AIを活かすことを達成できているかどうかのチェックを行いました。Exe化に関しては、話し合いののち、仕様書ツールを第三者に使用していただきフィードバックをもらうという目標に変更致しました。

　今後の課題として、PHP以外のブラウザ環境ツールにも適用できる汎用性を持たせること、仕様書のUIを改善すること（見やすく、わかりやすくする）が挙げられます。いかに使っていただく方が感覚的に操作しやすいかを追究したUI画面に改良を行っていく予定です。

　今後もPythonや生成AIに関する技術を高めていき、機会があれば技術発表会のような場で成果をご報告できるように励んで参ります。

第2サービス事業部 第3サービス部では、主にLinux・UNIX基盤の構築～保守サポートの業務にあたっています。
OSSであるLinuxは、日々新たなサービスやツールが更新されていきます。
今回取り上げた「Ansible」は、Red Hat Enterprise Linuxに同梱されたパッケージで無料で使用することができ、構築や保守作業の効率化に非常に有用なツールです。多種多様な実行モジュール、様々なクライアントに対応したコネクションモジュールを備えており、これまで手作業で行っていた作業のほとんどをそのまま置き換えることができるほどの柔軟性を持っています。

zLinuxサーバーの構築現場では、これまで手作業やスクリプトで行っていた構築手順をAnsiblePlaybook で置き換え、合計100台を超える仮想サーバーの構築作業を効率的に行うことができました。
実際に使用してみてAnsibleを最大限に活用するには、準備段階で統一化したルール（追加変更にどのように対処するか、ネットワーク環境変化への対応など）や、マクロなどの再現性の高いツールを作成することが不可欠だと感じました。

また、構築では一度切りの実行も多く、Ansibleの特徴である「冪等性」を十分に発揮できたとは思えません。今後は、運用保守における様々なクライアントの処理をAnsibleに統合することや、Ansibleを使用することによる運用ステップの削減などクライアントに合わせたAnsibleの活用ポイントを社内で検討していこうと考えています。

Create!Formは、システム開発の帳票設計において早くて簡単にデザインすることができ、PDFやHTML生成など、運用業務に合わせたフォーマットで出力する帳票作成ツールです。
また、IBMiでのCreate!Formを活用することによって、PDFのプレビュー印刷する場合は指定したプリンターでのページ指定印刷が可能です。(事前設定が必要)
以上のことから、ペーパーレス化やコスト削減などの業務改善効果が得られます。

LANSAで作成した基幹システムから、Create!Formで作成した帳票を出力する仕組みを実装した際の導入事例をご紹介します。
画面上の流れは以下の通りです。

1. 画面上の帳票発行ボタンをクリック
2. プレビュー画面が表示
3. プレビュー画面上の発行ボタンをクリックすると、近くのプリンターに帳票が出力される

IBMiのQNTCという技術を利用し、LANSAから発行したcsvとCreate!Formで作成したPDFのサーバー間のやり取りを可能にし、また同じくIBMiのADDLINKという機能を利用して、別サーバーに格納されているPDFへのアクセスを可能にしました。

近年DX化およびローコード開発の機運が高まる中、SLJがMendixなるローコード開発ツールを用いたプロジェクトに携わり始めてからおよそ1年半ほど経過いたしました。まだまだSLJ内部で"Mendix"というワードは浸透しておらず、知らない方も多いと思われます。

故に、今回は技術発表会という場で、Mendixの説明および事例紹介をさせていただきました。

Mendixは、オランダに本拠地を持つSiemens社が提供するローコード開発ツールであり、いわゆるアジャイル開発でのプロジェクトが推奨されるスクラップ＆ビルドなツールです。
Mendixではスクラムと呼ばれるアジャイル形式が推奨されていて、これはPMが不在となる代わりに人員をオーナー、スクラムマスター、開発者の3つに分けて実施します。このメンバーでどのタスクをいつまでに実施するかの"スプリント"を作成し、約2~4週間ほどで1サイクルを回します。
メンバーは互いに協力して近い距離感で一丸となって作業に取り組む（＝スクラムを組む）のが大きな特徴です。
Mendixツールの特徴として、作成した画面の実機確認までが早いことと、DBが内部実装されているため外部DBに頼らずともデータを入力し動作させられる点が挙げられます。このため、実際に作成してから動作確認までのステップが早く進み、円滑な開発に繋がります。Mendixでモック画面を作成して実現可能性を検討してから、次のステップへ進むといった使い方も可能であり、ユーザの使い方次第で様々に応用して扱うこともできるのが長所です。
上記機能を使えるまでに必要な期間は、簡単な画面作成までなら1~2週間ほどとなり、比較的低コストで操作可能となります。このためプログラム経験の無い人でも短期間で使い方を学び、自分の求める機能に対してアプローチをすることも実現できます。

SLJ活用例ではMendixを使ってT社様のレガシーによる基幹システムを再構築するプロジェクトに携わりました。他会社様がMendixでの再構築を選んだ縁でSLJもMendixへ関わることとなり、基幹システムのローコード開発ツールによる構築には困難な道程もありましたが、まずは本稼働まで漕ぎつけつつあります。実際に業務場面でMendixを利用してみると便利な側面だけでなく、適さない状況や、むやみに使いすぎてはいけない機能の知見も多く得られて、ローコード開発の良い面・悪い面のどちらも吸収しながら進めていくことができました。

今回の技術発表会を通じて、Mendixの紹介とSLJで実際にどのような利用をされたかを説明させていただきました。まだまだSLJでは未成熟なツールであるため、今後興味を持ってくれる人が増えていき、さらなる業務への活用をできる事を祈って結びとさせていただきます。

SLJでは、WebAPIの仕組みを使って基幹システムとデータ連携するようなシステム開発を過去に何度か経験したことがありましたが、WebAPIとRPGの両方に知識があるエンジニアでないと対応が難しい場面が多くありました。

RPG技術者がWebAPIを用いてデータ連携を行えるようになると、お客様からの要望にも応えやすくなるのと同時に、RPG技術者の対応領域を広げることができます。
今回、私たちのチームではIBM i で利用できるWebAPI連携ツールを2つ用いて次の2つの観点で調査・検証を行いました。

• 「RPG技術者がWebAPI開発を行う時に使いやすいツールはどちらか」
• 「技術的な観点において、良いツールはどちらか」

今回の検証では、有償ツールとIBM i OS標準機能として使用できる
「統合Webサービスサーバー（以下：IWSサーバー）」の2つを用いることにしました。

実際の作業においては、次の点を前提に開発と検証を実施しました。

• IBM i はWebAPIのサーバーとして構成する（検証環境の統一）
• ビジネスロジックはRPG言語にて、単一DBに対するCRUD処理を実装する（再利用性の検証）
• どちらのツールからも同じRPGプログラムを実行する（ツールパフォーマンス検証）

検証作業を終えて、次のような結果が得られました。
全ての内容は記載しませんが、概要としては次の通りです。

（RPG技術者の評価）
・WebAPIを知らない中で実施したが、簡単な事前知識の習得でAPI設定を行う事ができた
・開発したRPGプログラムは普段開発しているプログラムと変わらなかった
・APIサーバーの設定については、IWSより有償ツールのほうが直感的でわかりやすい

（技術的観点での評価）
・IWSサーバーは2025年現在、無償で利用可能でAPI実行パフォーマンスが非常に高い
　RPGデータタイプのサポートも豊富、APIパラメーター定義が自動化されている
　一方で、設定画面UIがわかりにくく初心者には難しい
・有償ツールは、API実行時のCPU使用率が高くなりやすくIWSと比べるとパフォーマンスが高くない
　画面UIが整理されていて初心者でも扱いやすい
　設定画面からAPIプログラムのテスト実行が可能
　APIパラメーター定義を手動で行う必要がある

今回の条件での作業を通して、IBM i がWebAPIサーバーとして構成した場合はパフォーマンス、無償利用可能、RPGデータタイプサポートの豊富さなどから総合的に考えてIWSサーバーが優れているのではないかという評価を行いました。

今後の展望としては、IBM i (RPG) がWebAPIを実行するクライアントとなった時（RPGからパブリックAPIを実行した場合を想定）どのような結果になるのか、来期以降検証が行えたら良いなと考えています。