業務システムは、UIよりも"構造"が命だと思っている

UIと構造、それぞれの役割

UIは「使いやすさ」を担う。入力のしやすさ、画面の見やすさ、操作の直感性——これらはユーザー体験に直結し、日々の業務効率に影響する。

一方、構造（テーブル設計）は「データの器」を担う。どの情報を・どんな形で・どこに保持するか。この設計が、システムの長期的な保守性と拡張性を決定する。

両者の優先順位を間違えると、「使いやすいが後々動かせないシステム」が生まれる。

なぜ構造を先に固めるべきか

業務システムの寿命は長い。10年・15年と使われることも珍しくない。その間に、業務フローは変わり、法改正があり、組織も変わる。

UIはそのたびに改修できる。画面のレイアウトを変えたり、入力項目を追加したりするのは、比較的小さな工数でできる。

しかしテーブル構造が変わると話は別だ。テーブルの変更はデータ移行を伴い、既存の集計ロジックの修正を伴い、場合によっては過去データの整合性を崩しかねない。運用開始後のテーブル変更は、想像以上に重い作業になる。

だからこそ、設計の初期段階でテーブル構造をしっかり考え抜くことが重要なのだ。

構造が悪いと、運用で苦しむ

テーブル設計の失敗が積み重なると、運用開始後にこういった問題が起きやすくなる。

集計できない

「先月の商品カテゴリ別の売上を出してほしい」という依頼に答えられない。カテゴリ情報が取引テーブルに記録されていないか、後から集計できる形で設計されていないためだ。

説明できない

「なぜこの在庫数になっているのか」を追跡できない。更新型の設計で履歴が残っておらず、現在値しかわからない状態になっている。

修正できない

入力ミスが発覚したとき、修正するにはいくつものテーブルを手動で直す必要がある。正規化が不十分で、同じ情報が複数の場所に分散しているためだ。

小売・業務システムで構造が特に重要な理由

小売業の業務システムでは、特にテーブル設計が重要になる場面がある。

• 商品マスタ：バーコードの変更・廃番・新規登録が頻繁に起きる
• 価格管理：特売・通常価格・会員価格など複数の価格体系を扱う
• 在庫管理：入出庫・棚卸・ロス・移動など、多様なトランザクションが発生する
• 販売管理：値引き・クーポン・ポイント還元など、取引構成が複雑

これらを「結果だけ残す」設計にしてしまうと、後から何も説明できない状態になる。現場が困るのはもちろん、経営判断に使えるデータが蓄積されないという致命的な問題にもなる。

UIは構造の上に乗る

UIはあくまで、しっかりした構造の上に乗るものだ。構造が整っていれば、UIは後から改善できる。要望に合わせて画面を変えることも、新しい集計レポートを追加することも、比較的容易にできる。

しかし構造が崩れていると、どれだけUIを磨いても限界がある。「見た目はきれいだが、実は何も集計できない」システムになってしまう。

業務システムの本当の価値は、日々蓄積されるデータにある。そのデータを活かせる構造をつくることが、設計者の最初の仕事だと私は思っている。