第10回となる今回は、ユーザー2社、ベンダー1社のZ世代のIBM i担当者に集まっていただいた。
IBM iシステム資産の「継承者」でもある参加者たちは、プログラム資産の状況やレガシーのRPG技術、IBM iをめぐる現状を「問題あり」と受け止め、その解決策を実践する一方で、RPG・IBM iの価値を高く評価し、今後への期待も抱いている。
（写真左から）
加藤 巧騎氏
岡谷システム株式会社
岡谷事業本部 企画開発部
サヒ サキブ アリ氏
濃飛倉庫運輸株式会社
システム開発部
松井 良倫氏
株式会社東郷製作所
デジタル推進部 システム課
担当は自社システムの保守・開発、
顧客システムの基幹再構築、保守・開発
i Magazine（以下、i Mag） 最初に自己紹介をお願いします。
松井 株式会社東郷製作所の松井です。2011年の入社で、入社に際して機械設備の仕事を志望していたこともあり、製造現場で1年間実習をしました。そして1年後に配属されたのがシステム部門で、それ以来変わらずシステム部門の所属です。
i Mag システム部門への配属を告げられたときは驚いたのではないですか。
松井 高校は溶接などを学ぶ機械科で入社してからも製造現場だったので、意外な感じは受けました。しかし入社したら何でも経験してみようと考えていたので、戸惑うことはなかったですね。
加藤 岡谷システム株式会社の加藤です。私は入社5年目で、入社以来、親会社（岡谷鋼機）のシステムを担当しています。大学ではマーケティングを勉強しましたが、マーケティングとシステムは企画・設計の進め方がよく似ていると思い興味があったのと、将来性のある分野で働きたいという気持ちもあり、当社に入社しました。現在、基幹システムの再構築プロジェクトに入っていて、チームにおける私の主な担当はRPGからJavaへのプログラムの書き換えです。
アリ 濃飛倉庫運輸株式会社のアリです。2024年の入社で、現在はシステム開発部に所属し、お客様ごとに構築する物流・倉庫システムの保守・開発を担当しています。
故郷のパキスタンでは大学でIT全般とシステム開発、Web開発などを学び、卒業後は岐阜にある大学院へ進学し、経営学と情報学がクロスする領域の研究をしました。日本へは来日して7年目になります。
RPG・IBM iの習得法は
OJT、自習、ベテランへの質問
i Mag 皆さんはRPGやIBM iをどのように習得したのですか。
松井 私はほぼOJTで、ベテランの先輩社員に一からRPGとIBM iを教えてもらい、覚えていきました。当時はグリーン画面でしたが、私にはゲームの画面のように思え、抵抗感もなくスムーズに習得できたように思います。
加藤 私は約1年間の新入社員研修でJavaを習いました。RPGとIBM iに本格的に触れたのは、今から3年前に基幹再構築のプロジェクトに加わってからです。グリーン画面を最初に見たときは、松井さんとは違って、かなり違和感がありました。しかし時間が経つにつれて慣れていき、今ではIBM iのよさや価値は理解しています。現在はRPGを読むことはできますが、プログラムを書くことはしていません。
アリ 当社のシステムは大半がRPGLEなので、私はRPGLE を解説した英語の書籍を教科書にして勉強しました。そして教科書でわからないことが出てくると、ベテランの方々に尋ねるという方法で覚えました。
RPGはできることが他の言語と比べてそれほど多くないので、簡単と言えば簡単です。しかし学生時代にJavaScriptやC、C++などで関数やクラスを使ってプログラムを書くことに慣れていたので、最初はRPG独特の作法にかなり戸惑い、苦労しました。
たとえばJavaはオブジェクト指向なので、プログラムを書いていけばプログラムの構造がわかるようになっています。ところがRPGでは同じ処理を繰り返し書く必要があるので、慣れるまではとても難しく思えました。
フリーフォームへの移行は
システム資産の継承でも便利
i Mag 皆さんは、先輩方が構築し運用してきたシステムを継承していくポジションにあるか思います。システム資産の継承という観点で、こういう環境が整っているとよいということは何かありますか。
松井 システム資産の継承という観点では、まずは仕様書だと思います。仕様書がきちんと揃っていれば保守や改修の際にどこをどう直せばよいか迷うことはありませんが、仕様書がないと、そのシステムをよく知るベテランに尋ねるかプログラムを読むしかありません。手間も時間もかかり、保守や改修がスムーズに進まない原因となります。
アリ そう思います。仕様書があるとないのでは大違いで、保守や改修、追加開発の工数に大きく影響してきます。未知のプログラムを目で追って理解するのは大変な労力がかかりますから、仕様書の存在はとても重要です。
それとRPGでは、固定フォームからフリーフォームへの変換が進んでいると、システム資産の継承という点では便利だろうと思います。フリーフォームであればオープン系のエンジニアにも理解しやすく、彼らをRPGプログラムの保守・改修の戦力とすることも可能です。またフリーフォームを経験しておけば、他の言語も習得しやすいのではないかと思います。
加藤 それは同感です。Javaをやっていると、フリーフォームは固定フォームとは違ってわかりやすく、プログラムの把握が容易です。
また、固定フォームのRPGはソースが追いづらいという難点があります。ソースのどこで何を書いているのか判然としないことが多く、プログラムを理解するのに時間と工数がかかります。たとえば、その変数はどこから来ている変数なのか明示されるようになっていると、作業効率はもっと上がるだろうと思います。
アリ その点はフリーフォームにすれば少し楽になりますね。RPG以外の言語だと、行の要素はソースの中に明示されているのでわかりやすいですが、そういう機能が備わっているとRPGはもっと使いやすくなるはずです。若い人たちも受け入れやすいだろうと思います。
松井 そのプログラムのわかりやすさという点では、プログラムは作る人の癖や作法がどうしても出てしまうので、ソースのポイントとなるところに注釈を残しておいてもらえると便利です。ソースのこの部分はこの役割を果たしているといったコメントです。それがあると、そのシステムに初めて触れる人も助かるはずです。
もう1つ思うのは、プログラムは後でほかのエンジニアが直すこともあるので、他人が触ることを前提にコーディングすべきですね。開発やプログラムの書き方の標準があっても留意すべき点だろうと思います。
加藤 そのことに加えると、プログラムが対象としている業務内容についても詳しい情報が残されていると非常に便利です。開発に携わった方でも時間が経つと忘れてしまうことがあるでしょうから。
生成AIの活用に大きな関心
確認・検証すべきことも多い
i Mag RPGやIBM iの利用を進めるにあたって、どういう環境が整っていると便利ですか。
加藤 IBM iを自習しているときに感じたのは、情報の絶対量が少ないということでした。求めている情報に行き当たらない、探し出せないということがよくありました。基本的な情報が、サンプルコードやユースケースも含めて手軽にアクセスできるところに揃っていると便利だろうと思います。
松井 それと、IBM iやRPGを解説したページは英語が圧倒的に多いですね。そのため正確に理解しようとすると時間がかかり、調べづらいという気持ちになります。それでつい先輩たちに先に聞いてしまうということなりがちです。自分で調べようとするときに、日本語の情報が豊富にあるとよいと感じます。
i Mag 生成AIについてはどのような取り組みを進めていますか。
松井 弊社ではシステム部門に生成AIツールを導入していろいろな検証を続けています。今のところは、開発者が自分の手であれこれ調べていたのを生成AIに代行させるナレッジ系が多い印象です。
この先は、プログラムの解析やコードの生成、テストコードの生成など開発者の伴走者のような使い方ができるのではないかと考えています。先ほどの変数の出どころの話なども生成AIを使えば簡単に確認できると思います。弊社では現在、IBM Bobの導入も検討中です。
加藤 生成AIは、使う人次第という側面がありますね。生成AIの特徴を踏まえて使わないと大きな問題になったり危険なことも起こり得ます。正しく使うということが大前提です。
それと松井さんが言うように、ユーザーは生成AIに対してあれこれ指示をする立場に立てるので、開発の補助役として使えるだろうと思います。
もう1つは、生成AIはソースコードも生成できるので、手始めにアウトラインのようなコードを生成させて、そこから詳細を詰めていくという開発方法も実現しそうです。ただし、生成AIは間違ったことをさも正しいかのように答えを返してくるので、真偽を見分ける知見やスキルが必要だろうと感じています。
アリ 私の会社でもいろいろ試していますが、既存プログラムの解析の話になると、対象とするプログラムやデータをクラウドに上げ
る必要が出てくるので、その会社のガバナンスやセキュリティのコードに引っ掛かることもありそうです。生成AIに関しては、まだ検証すべきことがたくさんあると感じています。
撮影：SAMIYA
［i Magazine 2026 Spring掲載］
