こんにちは！メインフレームの底知れぬ安定性と、PL/Iというちょっぴり古風で奥深い言語の世界へようこそ。
普段はJavaやC#、あるいはWeb系のモダンな言語でバリバリコードを書いている方にとって、レガシーシステムの移行案件は、まるで「異世界に放り出されたような不安」がありますよね。「なんだこの見慣れない記号は…」「変数の宣言方法が独特すぎる…」と、冷や汗をかいている方もいらっしゃるのではないでしょうか。
大丈夫です、怖くありませんよ。一つずつ紐解いていけば、PL/IもJavaも、やろうとしている本質（データを正確に計算して出力する）は同じです。
今回は、そんなレガシー移行の現場で「1円のズレも許されない経理・金融系バッチの移行」において、必ずと言っていいほどエンジニアの頭を悩ませる最大の難所、PL/Iの `FIXED DECIMAL`（パック10進数）を Javaの `BigDecimal` へリプレイスする際の罠と解決策について、じっくりお話ししていきますね。
—
1. なぜPL/Iの「数字」はJavaと違うのか？
私たちが普段Javaで扱う数値（`int` や `long`、あるいは `double`）は、コンピュータが一番大好きな「2進数（バイナリ）」で世界を認識しています。
しかし、IBMメインフレームの世界は違います。お金を扱う基幹システムにおいて、2進数で小数を計算させると、あの忌々しい「浮動小数点誤差（0.1を足したつもりが 0.30000000000000004 になっちゃう現象）」が起きてしまいますよね。金融機関で1円でも誤差が出たら、システム担当者は即座に青ざめてお詫行脚です。
そのため、PL/Iをはじめとするメインフレーム言語では、「10進数（人間が普段使う数字）」のままメモリやストレージにガッチリとデータを格納する仕組みが使われてきました。これが `FIXED DECIMAL`（通称：パック10進数 / COMP-3） です。
PL/Iのデータ宣言を覗いてみよう
PL/Iでは、変数の名前や属性を次のように宣言します。
1
/ ========================================================= /
/ 顧客の売上金額を定義するPL/Iのコード例 /
/ ========================================================= /
DCL W-URAIAGE-AMT FIXED DECIMAL(9, 2) INIT(0);
この `FIXED DECIMAL(9, 2)` という見慣れない記述、初見だと少しビビりますよね。でも意味はとってもシンプルです。
- 全体で 9桁 の数字が入りますよ（精度 / Precision）
- そのうち 小数点が 2桁 ありますよ（スケール / Scale）
つまり、整数部が7桁、小数部が2桁で、最大 `9999999.99` までを誤差なく完璧に保持できる最強の箱なんです。PL/IにはJavaのような厳格な「予約語による型縛り」が少ない（文脈によってキーワードの意味が変わる）ため、こうした自由度と厳密さが同居しているのが特徴です。
—
2. Javaの `BigDecimal` へリプレイスする際の「2大落とし穴」
さて、このPL/Iの `FIXED DECIMAL(9, 2)` を、Javaの現代的な `BigDecimal` に書き換えるとき、多くのプログラマが以下の2つの罠にハマります。
落とし穴その1：精度（Scale）の自動調整による予期せぬ桁落ち
Javaで何も考えずに `new BigDecimal(“12345.678”)` のような値を受け渡したり、割り算を行ったりすると、スケール（小数点以下の桁数）が勝手に変動したり、溢れたりします。
PL/Iでは、あらかじめ決められた枠（`9, 2` なら強制的に小数点以下2桁に丸められる、あるいはパディングされる）にピタッと収まるようハードウェアレベルで制御されていますが、Javaの `BigDecimal` はデフォルトでは「計算結果に合わせて勝手にスケールが変わる」気まぐれ屋さんです。
落とし穴その2：丸めモード（Rounding Mode）の文化の違い
ここが一番の肝です。
PL/I（およびメインフレームの演算回路）が標準で行う四捨五入（正確にはJIS丸めや代数切り捨てなど、コンパイラオプションや代入時の挙動に依存します）と、Javaの `BigDecimal` が持つデフォルトの丸めモード（`RoundingMode.UNNECESSARY` で例外が出たり、`HALF_EVEN` ＝銀行家ズミだったり）が一致していないのです。
移行テストの最中に、「あれっ、PL/Iだと『100.05』になるはずの計算結果が、Javaだと『100.06』になるんだけど……！？」という怪現象に直面し、夜な夜な首を傾げる羽目になります。
—
3. 怖くない！Java側でPL/Iの挙動を完全再現する処方箋
では、この差異をどうやって埋めればよいのでしょうか？
答えは簡単です。「Java側で、PL/Iの箱の大きさとルールを厳格にエミュレートしてあげる」のです。
実務でそのまま使える、Javaのユーティリティ的なコード片を見てみましょう。
import java.math.BigDecimal;
import java.math.RoundingMode;
public class PliDecimalEmulator {
/
- PL/Iの FIXED DECIMAL (9, 2) の振る舞いをJavaのBigDecimalで完全に再現するメソッド
- @変換元のBigDecimal
- @return PL/I仕様に丸められ、かつ桁数が保証されたBigDecimal
/
public static BigDecimal convertToPliFixedDecimal9_2(BigDecimal input) {
if (input == null) {
return BigDecimal.ZERO;
}
// 1. 整数部7桁、小数部2桁（合計9桁）の制約をかける
// PL/Iの FIXED DECIMAL(9, 2) が保持できる最大値・最小値の範囲チェックもここで行うと安全です。
// 2. 小数点以下2桁に丸める（ここではPL/Iの標準的な算術四捨五入を採用する場合の例）
// ※プロジェクトのPL/Iコンパイラオプション（TRUNCなど）に合わせて RoundingMode は調整してください
BigDecimal scaledValue = input.setScale(2, RoundingMode.HALF_UP);
// 3. 整数部がオーバーフローしていないかチェック（全体で9桁以内か）
// FIXED DECIMAL(9,2) の場合、整数部は最大 9999999 まで
if (scaledValue.precision() – scaledValue.scale() > 7) {
throw new ArithmeticException(“PL/Iデータ定義(9,2)の許容桁数をöverflowしました！”);
}
return scaledValue;
}
}
このように、Java側であっても「何桁の箱に入れ、どのタイミングでどの丸めモードで丸めるか」を明示的にコードとして書いてあげることで、メインフレームが何十年も守り抜いてきた計算の正当性を、モダンなJava環境でも完全に再現することができます。
—
4. まとめ：レガシー移行は「歴史の翻訳作業」
レガシーシステムのモダナイゼーション（Javaリプレイス）は、単なるプログラミング言語の置き換えではありません。それは、「先人たちがメインフレームのハードウェア特性を前提に積み上げてきた、暗黙の業務ルールやデータ制約を、現代の言語に正しく翻訳し直す作業」です。
「PL/Iのデータ定義って、なんだか呪文みたいで怖いな……」と思っていた方も、その背景にある「なぜその形をしているのか（＝誤差を出さないため、限られたメモリを効率よく使うため）」という理由を知ってしまえば、もう怖くありませんよね。
移行作業で躓いたときは、いつでもこの記事を思い出してください。
あなたのスムーズなリプレイス作業と、エラーのないバッチ稼働を、心から応援しています！
