業務システムは、整合性を"維持しやすい"設計が命だと思っている

取引は"結果"だけだと説明できなくなる

整合性が崩れる典型的なパターンがある。取引を「結果だけ」残してしまうことだ。

販売を例に考えてみる。販売テーブルに「販売金額：1,500円」とだけ記録されているとする。後日、こんな質問が来たとき、答えられるだろうか。

• 定価はいくらだったのか？
• 値引きは何円だったのか？
• なぜその価格になったのか？
• 特売対応だったのか、それとも端数調整か？

「1,500円」という数字しかなければ、答えられない。「結果だけを残す設計」は、後から何も説明できない設計だ。

根拠データを残すことの重要性

取引には必ず「背景と構成要素」がある。それを丸ごと記録しておくことが、整合性を維持するための基本だ。

先ほどの販売の例なら、記録すべきは次のようなデータだ。

項目	値
定価	2,000円
値引額	500円
値引区分	特売
販売金額	1,500円

こうしておくと、「特売による値引き総額」「定価販売と特売販売の比率」「商品ごとの値引き傾向」など、後からさまざまな視点で集計できるようになる。

根拠を残さないと、数字の説明ができないだけでなく、誤りに気づきにくくなる。整合性を保つための検証も難しくなる。

縦に積んで集計できる設計

もう一つ重要なのが、「更新型」ではなく「追記型」の設計だ。

例えば在庫管理を「現在の在庫数」だけ保持する設計にした場合、「いつ・何が・どのくらい入出庫したか」の履歴が残らない。月次集計や棚卸差異の分析が、後からできなくなってしまう。

これに対して、入出庫トランザクションを1件1件縦に積んでいく設計なら、どの時点の在庫状況でも再現できる。「在庫が合わない」という問題が発生したとき、履歴をたどって原因を特定できる。

追記型設計の利点

• 任意の時点での集計が可能
• 誤りが発生したとき、取り消しレコードを追加するだけで訂正できる
• 「なぜこうなったのか」の説明責任を果たせる
• 監査や第三者チェックに耐えられるデータ構造になる

可読性とコード化のバランス

整合性を保つためには、コード値と名称の扱いにも気を配る必要がある。

よくある失敗が、取引テーブルに「値引き区分名称：特売」とそのまま文字列で保存してしまうことだ。名称が変わったとき（例：「特売」→「タイムセール」）、過去データとの整合が取れなくなる。

コード値（例：「01」）を記録しておき、名称マスタで管理する設計にすれば、名称が変わっても過去データの意味は変わらない。ただしコードだけでは可読性が下がるため、マスタの変更履歴を保持する設計もあわせて検討したい。

設計の視点：「後から集計できるか」を問い続ける

テーブル設計の段階で「このデータから、後で何を集計したいか」を問い続けることが大切だ。

機能要件だけを満たすことに集中していると、「取引を記録できた」で終わってしまう。しかしシステムの価値は、データが蓄積されるにつれて出てくる。集計・分析・検証・説明——これらをすべて支えられる設計が、本当の意味での業務システムの設計だと私は思っている。