バッチ処理と「正当性の証明」という名の職人芸
先日、以下のスライドを作成しました
『バッチ処理を「状態の記録」から「事実の記録」へ』
この記事は、スライドで提示した思想をさらに深掘りするものです。
（この視点を共有は難しく、これまで関係部署や協力会社への依頼が響かない場面もありました。この記事をまとめることで、皆様と視点の共有ができれば、それは私にとってのメリットとなります。）
以下、長文となります。
まずはスライドの振り返り、その後、実装イメージを説明します。
「正当性の証明」という保守業務
多くの基幹システムに存在するバッチ処理。
処理後、保守担当者は「この結果は本当に正しいのか？」という「正当性の証明」という役割を担っています。
本記事では、この「正当性の証明」という保守業務そのものを一つの独立したビジネスドメインとして捉えます。そして、システム自身がその正当性を語る、自己説明能力を持つシステムを提案します。
(本記事で用いる「ゴールド会員」といった具体的な事例は、コンセプトを分かりやすく伝えるためにAIとの対話を通じて生成したものです。実在の案件とは関係ありません。)
「判断プロセスの永続化」へ
従来の「バッチ処理」では「なぜその結果に至ったのか」というプロセスは破棄されがちです。
今回提案するアプローチでは、このプロセスを重視します。
具体的には、業務ルールの適用、計算、判断といった、個々の「事実（ファクト）」をドメインイベントとして永続化します。
導入効果
この設計により、システム利用者は「なぜこの数字になったのか？」という疑問に対し、IT部門を介さずに、システムが提示する「事実（ファクト）」を「根拠（エビデンス）」として直接参照できるようになります。
(もちろん、これにより保守担当者の業務が完全になくなるわけではありません。実行時エラーへの対応や、サーバー、データベースの確認といった技術レイヤーの保守運用は依然として重要です。)
実装イメージ：DDDパターンによる設計
このコンセプトをドメイン駆動設計（DDD）のパターンで表現すると、以下のような設計が考えられます。
判断ルールをカプセル化
- 「ゴールド会員は10%割引」
- 「初回購入者は送料無料」
といった業務ルールを、それぞれ独立した「仕様」オブジェクトとしてカプセル化します。
「判断の事実」を記録する
全ての判断は、ドメインイベントとして表現できます。
- 基本料金が確定した (BaseFeeDetermined)
- 割引が適用された (DiscountApplied)
- 送料が加算された (ShippingFeeAdded)
- 最終金額が確定した (FinalAmountCalculated)
例えば、DiscountAppliedイベントでは
- 「どの割引ルールが」
- 「なぜ適用され」
- 「いくら変動したか」
といった情報を扱います。
イベントの連なりで計算結果という「状態」を表現する
計算結果という「状態」を直接データベースに保存するのではなく
発生したドメインイベントのリストを、時系列でイベントストアに追記（Append）します。
ある顧客の最終請求額は、その顧客に関するイベントを最初からすべて再生して復元します。
(パフォーマンス要件によっては、最新の状態をスナップショットとして記録する選択も視野に入ります。その場合でも、ドメインイベントのリストが主役であり、信頼できる唯一の情報源（Single Source of Truth）です)
利用者のための「判断プロセス」の提示
利用者が直接参照するためのリードモデルを構築します。
リードモデルのテーブル例: calculation_process_details
| closing_id | step | rule_name | reason | change_amount | subtotal |
|---|---|---|---|---|---|
| C123-202510 | 1 | 基本料金 | 商品マスタ参照 | +5000 | 5000 |
| C123-202510 | 2 | ゴールド会員割引 | 顧客ランクがGold | -500 | 4500 |
| C123-202510 | 3 | 送料無料ルール | 金額基準未達 | +500 | 5000 |
このリードモデルを画面に表示するだけで、システム利用者（営業、経理担当者など）は、（詳細なレシートを見るように）、計算のプロセスを理解できます。
保守担当者がもつドメイン知識
ここまでの例は計算ルールが中心でしたが、元スライドのような「取引伝票の集計」では、どの情報を「事実」として残すべきかが重要になります。元データのすべてを記録するのは冗長です。
ここで保守担当者の持つドメイン知識が活用できます。
保守担当者がこれまで実施してきた「正当性の証明」という業務そのものです。
彼らが結果を検証するために、どのデータに着目し、何を比較していたのか。
その手順や思考プロセスこそが「正当性の証明」を適切に表現するための情報源になります。
この設計がもたらす価値（関心事）
システム利用者への権限移譲
システムが社内向けの場合は、顧客→社内担当者→IT部門といった経路をたどります。
しかし今後は、社内利用者はIT部門に問い合わせることなく、自らの手でデータの正当性を確認できます。
その結果、顧客への回答時間は短縮され、組織全体の信頼性が向上します。
保守担当者の役割を建設的に
「なぜ？」に答えるだけの保守業務から解放された担当者は、ビジネス部門と共に新機能に着手したり、保守プロセス全体の健全性を監視したりするなど、より創造的で高付加価値な役割をこなせます。
自己説明能力を持つシステム
システムは、自身の振る舞いをデータによって完全に説明できるようになります。
これは、内部統制や監査対応の観点からも有用です。
まとめ：運用コストの踏襲から、価値創造への転換
基幹システム移行を単なる「現行踏襲」とすることは、「運用コスト」も踏襲することです。
バッチ処理の保守業務を「判断プロセスの永続化」という視点で見つめ直すことは、保守の負担を低減し、システムの信頼性と透明性を向上させます。これは、組織のデータ活用能力を引き上げる価値創造への投資です。
追記
この設計を適用した結果、他にも便利な面がありました。
以下の記事にまとめました。