画面プログラムは「読む順番」で8割わかる
✅ はじめに：なぜ今、RPGⅢの“読み方”を書こうと思ったのか
この連載を書こうと思った理由は、シンプルです。
いま私が関わっている現場で、「これは放置すると本当に危ない」と感じる出来事が続いたからです。
IBM i（AS/400）で動いているシステムは、今でも多くの会社の“心臓部”です。
売上、仕入、在庫、請求、支払、製造――止まったら業務が止まる。
そして多くの場合、止められないまま何十年も動き続けています。
ところが現場では、こんな状況が珍しくありません。
- ソースはあるのに、読める人が限られている
- 改修したいのに、影響範囲が分からず、怖くて触れない
- 何かあった時に頼れる“ベテラン”が、もう社内にいない／少ない
- 結果として、運用でカバーするしかない状態が積み上がる
⚠️ 残酷な一言（でも現実）
残酷に聞こえるかもしれませんが、「読める人がいる」ことと「将来も改修できる」ことは、もう同義ではありません。
🔀 いま現場で起きている「分断」
現場ではいま、はっきり分断が起きています。
RPGⅢで支えてきた知見は今も価値が高い一方で、Free-Form化やSQL中心の改修には、別のスキルと作業の型が必要になります。
「ベテランが弱い」のではありません。
長年の運用で最適化されたやり方が、そのままでは通用しにくくなった――それが現実だと感じています。
そしてDX化するなら、現状を踏まえて、次の一歩が避けられません。
- 📌 まず、現状を読める形に整理する（棚卸し／見える化）
- 📌 次に、小さく安全に直す（段階移行）
- 📌 その上で、Free-Form RPG化（必要ならSQL化）へ進める
いきなり全面刷新ではなく、
まず読める状態にする → 見える化する → 小さく安全に直す
これが、現場で回るやり方です。
🎯 この連載でやりたいこと（手助けになれば幸いです）
この連載は、RPGⅢを「懐かしむ」ためではありません。
現場のシステムを止めずに、次の世代へ繋ぐための“読み方”を整理するのが目的です。
- 🧭 若手の方が、RPGⅢのソースに立ち向かうときの“地図”になる
- 🧠 ベテランの方が、頭の中の暗黙知を言語化するきっかけになる
- 🏢 企業が、属人化から抜け出す第一歩になる
そんな手助けの一環となれば、幸いです。
では第1回として、画面プログラムの読み方を「読む順番」から整理します。
🧩 1. 結論：画面プログラムはこの順番で読む
RPGⅢの画面プログラムは、基本的にこの順番で読むと理解が速いです。
- 🗂️ F仕様（ファイル定義）：何を入出力しているか
- 🧾 I仕様（画面項目・サブファイル）：何を表示・入力するか
- ⚙️ C仕様（主処理の流れ）：表示 → 入力 → チェック → DB更新
- 🧯 エラーメッセージ系：どこで弾くのか
- 🔗 CALL先 / 参照するLF・PF：裏で何を呼んでいるか
✅「C仕様から読む」のは初心者ほど迷子になります。
まずは “材料（F/I）” を把握してから “料理（C）” を見るのが最短です。
🗂️ 2. F仕様：最初に見るべきは「更新か？参照か？」
F仕様で見るべきポイントは、細かい書式よりも以下です。
- 🖥️ **画面ファイル（WORKSTN）**があるか
- 🧱 DBファイルがあるか
- ✍️ DBファイルが 更新（Update） なのか、👀 参照（Input） なのか
ここが分かるだけで、ざっくり処理の骨格が見えてきます。
- 画面を出す
- DBから読んで表示する
- 入力された内容をチェック
- OKならDBを更新する（または別プログラムをCALLする）
🧾 3. I仕様：画面は「入力項目」と「キー項目」だけ拾う
I仕様は情報量が多く、全部追うと疲れます。
第1回は割り切って、次だけ拾えばOKです。
- 🔑 キー（検索条件）：何を入力したら、何を引けるのか
- 📝 更新項目：どの項目を入力して、DBに書くのか
- 📋 サブファイル（あれば）：一覧表示＋選択があるか
✅「この画面は何をキーにして、何を更新する画面か？」
ここが掴めると、C仕様の読みが急に楽になります。
⚙️ 4. C仕様：読むのは「処理の塊」だけ（行単位で追わない）
C仕様は、行単位で追うと迷子になりがちです。
おすすめは、C仕様を次の4ブロックに分けて読むことです。
🧊 ブロックA：初期表示（画面に出す前）
- 初期値セット
- 画面項目の初期化
- 初回表示フラグ
📥 ブロックB：表示用データ取得（DB参照）
- キーでPF/LFを読む
- 画面項目にMOVEする
- サブファイルを作る（あれば）
⌨️ ブロックC：入力受付（ユーザー入力）
- 画面入力を受け取る
- Fキーや終了条件の判定
✅ ブロックD：チェック → 更新（DB更新 or CALL）
- 入力値チェック
- エラーならメッセージ表示して戻す
- OKならUPDATE / WRITE / CALL
🧨 5. よくある落とし穴（初心者がハマる場所）
🧯 落とし穴1：画面初期化が散らばっている
初期値設定が複数箇所にあると、表示が崩れたりします。
→ ✅ 初期化の場所を一か所に集める意識が重要です。
🧯 落とし穴2：DB参照がLF依存で、順番が“暗黙”
LFのキー順に依存して処理しているケースがあります。
→ ✅ SQL化するときは、並び順・抽出条件を明示しないと結果が変わることがあります。
🧯 落とし穴3：エラー処理が「画面戻し」前提
エラー時に「表示状態を戻す」前提の実装が多いです。
→ ✅ どのタイミングでメッセージを出しているかを必ず追います。
🚀 6. DX視点の一言：読解＝移行設計の入口
画面プログラムを読めるようになると、DXの話が現実になります。
- 🧩 どの画面が、どのPF/LFを触っているか
- 🧩 どこが“運用で吸収している仕様”か
- 🧩 どこから切り出せば安全に段階移行できるか
つまり、**読解は「モダナイズの設計作業そのもの」**です。
