こんにちは！メインフレームの深い森へようこそ。
普段はJavaやCOBOLをバリバリ書いていらっしゃる開発者の方にとって、突如として目の前に現れるPL/I（ピーエルアイ）のソースコードは、まるで古代文字のようにおっそろしく見えるかもしれませんよね。
「なんだこの暗号みたいな宣言は……！」
「数値なのに文字列みたいにピクチャが指定されているぞ……！？」
そんな風に冷や汗をかいているあなた、どうぞご安心ください。怖がる必要はまったくありません。今回は、レガシーなPL/Iの世界から、モダンなJavaの世界へシステムを移行する（マイグレーション）際に誰もが必ずハマる「データ型マッピングの深い罠」について、現場の知見をたっぷり詰め込んで優しく紐解いていきますよ。
—
1. なぜPL/Iのデータ型はJavaとこれほど相性が悪いのか？
Javaの世界では、金額や数量を扱うときは `BigDecimal`、フラグやコードは `String` や `boolean`、整数は `int` や `long` と、綺麗に住み分けがされていますよね。
しかし、PL/Iのデータ定義は、IBMメインフレームという「1バイトでもメモリやストレージを削り、CPUの演算効率を極限まで高めたい」という鉄の意志で作られた世界に生きています。そのため、Javaの常識で直訳（単純な型変換）しようとすると、必ず足元をすくわれるのです。
特に、移行プロジェクトで頻発する「精度の欠落」と「フォーマットの不整合」という2大トラップについて、具体的なコードを見ながら見ていきましょう。
—
2. トラップその1：`FIXED DECIMAL` と Java `BigDecimal` の密かなすれ違い
PL/Iで最もよく使われる数値型の代表格が `FIXED DECIMAL`（パック十進数、あるいはゾーン十進数）です。
例えば、PL/Iでは次のように変数を宣言します。
1
/ 契約金額（全体で9桁、そのうち小数点が下2桁）の定義 /
DCL WK-CONTRACT-AMT FIXED DECIMAL(9,2);
この `FIXED DECIMAL(9,2)` という見慣れない記述、一体どういう意味でしょうか？
これは、「符号を含めて全体で9桁入るうち、下2桁が小数ですよ」という意味です。メモリ上では、これは浮動小数点数ではなく、人間が手計算する筆算と同じ10進数として正確に保持されます。金融計算で誤差が出ては困るので、メインフレームではこれが大活躍するわけです。
さて、これをJavaへマイグレーションする際、多くアーキテクトはこう考えます。
「10進数の正確な計算だから、Javaの `java.math.BigDecimal` がぴったりだよね！」と。
ここに潜む罠：演算の丸めモード（Rounding Mode）の罠
Javaの `BigDecimal` を使う場合、割り算や桁数合わせを行う際に「丸めモード（切り捨て、四捨五入など）」を明示的に指定しないと、デフォルトでは `ArithmeticException` が発生するか、予期せぬ丸め方をしてしまいます。
一方、PL/Iはコンパイルオプションや代入時の暗黙のルールに従って、猛烈にシビアな桁あふれ（Overflow）や切り捨てをハードウェアレベルに近い挙動で処理します。
Java側で何も考えずに `new BigDecimal(“1234567.89”)` などと受け渡しをしていると、PL/I時代には許容されていた（あるいは切り捨てられていた）微小な端数の扱いがズレてしまい、決算バッチの総額が1円合わない……！という、生きた心地がしないトラブルを引き起こすのです。
—
3. トラップその2：ピクチャ型（編集型）という名の魔王
PL/Iの真骨頂であり、Javaプログラマーが最も頭を抱えるのが「ピクチャ型（PICTURE）」です。
COBOLにも編集句がありますが、PL/Iのピクチャは変数宣言とフォーマット定義が一体化していて、かつ自由度が高すぎて時に凶器になります。
次のPL/Iコードを見てみてください。
1
/ 画面や帳票に出力するための編集済み売上金額 /
DCL PRT-SALES-AMT PICTURE ‘$,$$$,$$9.99CR’;
ひゃあ、なんだか記号だらけで呪文みたいですね……！
これは、「数値データを保持しつつ、メモリ上ですでに『カンマ編集』『ドルマーク付加』『マイナスなら末尾にCRをつける』という見た目の形（文字列）に整形して保持しなさい」という強烈な命令です。
これをJavaに移行する際、うっかり「見た目が文字列だから、Javaの `String` 型にマップしよう！」とやってしまうと、大惨事になります。
ここに潜む罠：Java側で計算ができなくなる
`String` 型にしてしまうと、その変数に対して「消費税を掛け合わせる」といった数値演算が一切できなくなります。もし計算したい場合は、わざわざJava側で `String` からカンマやドルマークを取り除くパース処理（正規表現など）を書き、計算したあとに再び `DecimalFormat` などでフォーマットし直す必要があります。
「じゃあ、数値として扱いたいからJavaでは `BigDecimal` にしよう」とすると、今度は元のPL/Iが持っていた `CR`（Credit：マイナス値の表現）や、ゼロサプレス（不要な先行ゼロを空白やカンマにする）のニュアンスが綺麗に落ちてしまい、出力される帳票のレイアウトが盛大に崩れることになります。
—
4. 実務で役立つ！安全なデータ型マッピングの指針
では、私たちはこのレガシーな魔物たちとどう向き合い、安全にJavaへ橋渡しをすればよいのでしょうか。
現場で使える実践的なマッピングの指針をまとめました。
1. 計算に使う `FIXED DECIMAL(p, q)` は、必ず Java の `BigDecimal` へ。ただし「スケール（小数桁数）」と「丸め規則」をチーム内で統一する。
- 移行先のJavaコード全体で、端数処理をどう行うか（例：切り捨てなのか、四捨五入なのか）の共通ユーティリティクラスを必ず用意しましょう。
2. 見た目を定義する `PICTURE` 型は、データ項目の「性格」を見極めて分離する。
- 内部でまだ計算に使う場合： ピクチャを剥ぎ取った純粋な数値項目（`FIXED BINARY` や `FIXED DECIMAL`）としてJavaの `BigDecimal` または `long` にマッピングし、表示の直前にJava側で `DecimalFormat` を適用します。
- 単なる出力用・コード表の場合： Javaの `String` 型として扱い、レガシー固有のパディング（左側ゼロ埋めなど）をJavaの `String.format` や専用メソッドで丁寧に再現します。
—
おわりに
いかがでしたでしょうか？
PL/Iのデータ型やピクチャ制御は、一見すると難解で気まぐれなものに思えるかもしれませんが、その裏には「データを正確に、かつ美しく効率よく扱う」というメインフレーム時代のエンジニアたちの知恵と工夫がぎっしり詰まっています。
「なぜこの宣言になっているのか」を一つずつ紐解いていけば、Javaへの移行も決して怖くありません。
レガシーシステムの海原へ漕ぎ出すあなたの航海が、安全で実りあるものになるよう、これからもそっとサポートしていきますね。それでは、また次の技術でお会いしましょう！
