私は現在、基幹システムの移行プロジェクトを進めています。
その中で「バッチ処理」の保守運用において、従来の設計手法は「必要経費」を抱えているという気づきを得ました。
従来の「バッチ処理」とその課題
長年運用されてきた（COBOL時代の）システムにおいて、バッチ処理は中核的な役割を担っています。
その責務は、一日の取引データから様々な区分ごとの判定処理を行い、判定結果を集計し、在庫数や請求額といった最終的な「状態（State）」を算出して、データベースを更新することです。
当時の計算資源や言語仕様の制約下では、計算結果である「状態」のみを正しく保持することが最も効率的かつ合理的な設計判断でした。
しかし、この「状態」中心のアーキテクチャは、システム運用、特に保守において構造的な課題を抱えていました。
「結果」はあっても「経緯」がない
「この請求額はなぜこうなっているのか？」
保守担当者の日常は、このような問い合わせが入ります。
システムには、インプットである取引伝票（元データ）と、アウトプットである請求額（状態）は存在します。
しかし、その両者を結びつける計算の「経緯（プロセス）」が、システムの記録として一切残らない設計になっています。
失われた経緯
この失われた「経緯」には、以下のような、伝票区分や取引条件によって複雑に分岐する業務ロジックの適用結果が含まれます。
- どの伝票が「通常売上」として加算されたのか
- どの取引に「特別値引」ルールが適用され、金額が調整されたのか
- どの伝票が「サンプル出荷」などの理由で、請求対象から除外されたのか
これらのステップはバッチ処理の実行中にメモリ上で行われるだけで、その「適用結果」が記録されることはありません。
保守担当者が「正当性」を証明する
業務システムは、上記のような複雑なロジックを内包しているため、最終的な結果を予測するのは困難です。
保守担当者は、システムのソースコードを精読し、過去の入力データを元に手作業で処理を再現・追跡することで、「経緯」や「適用結果」を洗い出し、その正当性を証明してきました。
必要経費と属人化
この調査・証明にかかる工数は、システムの信頼性を担保するための、いわば一種の「必要経費」でした。
さらに、この作業はシステムの内部を熟知した特定の熟練者の経験と勘に依存し、業務は極めて属人化していました。
2. 解決策：「状態の更新」から「事実の記録」へ
この課題を根本から解決する鍵は、バッチ処理の設計パラダイムを「状態の管理」から「事実の記録」へと転換することです。
具体的な手法
例えば、とある顧客への請求額「¥8,500」が「状態」です。
対して、事実の記録（適用結果）は以下のイメージです。
| 発生日時 | 事実（イベント） | 適用された業務ルール（純粋でない操作） | 金額への影響 |
|---|---|---|---|
| 10/05 10:20 | 商品Aが出荷された (元伝票: #101) | 通常売上 として計上 | + ¥10,000 |
| 10/05 10:20 | 伝票#101に対し割引を適用 | 長期顧客向け特別割引 ルールを適用 | - ¥1,500 |
| 10/18 11:30 | 商品Cが出荷された (元伝票: #103) | サンプル出荷 のため請求対象外として除外 | ± ¥0 |
| 最終合計 = | ¥8,500 |
つまり「請求額」といった「状態」に対する、自身の経緯（適用結果）を内包した、透明性の高い「要約（サマリー）」を持つのです。
余談：パフォーマンスが求められる場合、集計結果（請求額）を別途Read Modelとして保存します。
結果
この設計により「状態が正しいことを説明する作業」は、人間がソースコードを読んで再現する作業ではなくなります。
「特定の状態は、どのイベント（事実）の積み重ねによって構成されているか」を、システム自身が、記録から提示するのです。
これは、説明のシステム化です。
3.効果
保守運用でコストが発生している部分に、このアプローチを導入することで、期待できる効果は以下のものです。
保守・運用コストの構造的削減
これまで保守担当者が「必要経費」として費やしてきた、調査・証明のための工数が削減できます。
そして創出されたエンジニアのリソースは、障害対応のような受動的な業務から、新機能開発やビジネス価値向上といった未来への投資へと振り向けます。
追跡可能性（トレーサビリティ）の獲得
これは「バッチ処理」が、システム内で発生した全てのビジネスイベントを記録し、完全なトレーサビリティが確保できる設計に繋がります
これにより、システム利用者や顧客からの問い合わせにも、事実ベースで即座に回答でき、信頼性を向上させます。
ドメイン駆動設計
イベントストーミング、ドメインイベントといった設計を採用することで、「バッチ処理そのものを不要にする」といった設計も可能です。
✳︎先の例のような事実の記録を「Single Source of Truth（唯一の信頼できる情報源）」として請求額を算出するイメージです。
事実の永続化
もし「分散システムは過剰な投資だ」といった場合でも、計算結果の「状態」だけでなく、計算経緯や適用結果といった「事実」を永続化する設計であれば、上記のメリットを得ることができます。
必要経費
このように過去の設計には、保守運用面で「必要経費」を抱えていました。
これは、当時の計算資源や言語仕様を考慮すると設計として適切な判断でした。
しかし現代では、メモリや記憶装置のコストが安価になり、設計面でもドメイン駆動設計など手法が確立しているなど、環境が異なります。
返済
そのため、この「必要経費」を払い続けることは「負債を抱えた」状態と考えられます。
つまり今回の移行プロジェクトにおいては「返済」が１つのテーマであると言えます。