3-4.データ不整合を排除する「SSOT」のDB設計。受注から売上を「削り出す」アーキテクチャ

今回は、シリーズで最も技術寄りの、しかし最も本質的な話をする。データベースの設計思想だ。画面や機能は後から直せる。だがデータの構造はシステムの背骨であり、後から変えるのは外科手術になる。第4回は、データ不整合を構造的に排除するSSOT(Single Source of Truth:信頼できる唯一の情報源)の設計と、その中核「受注からの売上の削り出し」を書く。

あえて強調したい。AIで「作る」がコモディティになる時代に、最後まで差を生むのはデータ構造だ。コードはAIが書ける。SQLもAIが書ける。だが「自社の事実をどんな構造で持つか」——これだけは、業務の本質を理解した人間にしか決められない。データモデルは、安く速く量産できる「手段」の対極にある、自社固有の資産だ。本シリーズの中核を、この回でいちばん深く彫り込む。

Before:同じ事実が、複数の場所で食い違う

旧環境のデータ問題の本質を一言で言えば、同じ事実が複数の場所に別々に記録され、食い違うことだ。受注の情報と、生産指示の情報と、売上の情報が、それぞれ別に入力され、別に存在する。転記のたびにズレが生まれ、どれが正しいか誰にも分からない。月末になると人間が突き合わせて辻褄を合わせる。この「突き合わせ業務」こそ、データ設計の失敗が生む人的コストの象徴だった。

After:SSOTという原則

次期システムの設計原則は、一つの事実は、一つの場所にだけ記録する。これがSSOTだ。受注という事実は受注マスターにだけ存在する。他のすべて——生産指示も、出荷も、売上も——は受注マスターを参照するか、そこから派生する。コピーは作らない。コピーが無ければ食い違いは構造的に起こり得ない。言葉にすると当たり前だが、これを業務の複雑さの中で貫くには相応の設計が要る。その中心が次の「受注と売上の関係」だ。

受注と売上を「1:N」で切り離す

旧来の発想では受注と売上は1:1だ。シンプルだが、現実の商売はそうなっていない。一つの受注の中で、テーブルは今月納品・チェアは来月納品という分納が起き、納品後にチェア1脚だけ一部返品が来て、使い込んだ家具の修理引取が発生する。1:1では、これらのたびにデータを無理やり加工し、そこから不整合が生まれる。

次期システムでは受注と売上を1:Nで設計した。一つの受注から複数の売上が生まれ、実際に納品された分だけが、納品のたびに売上として記録される。私たちはこれを「売上の削り出し」と呼んでいる。受注マスターという原木から、納品という事実が確定するたびに、その分だけを売上として削り出す。受注は常に全体像を保持し、売上は確定した事実だけを刻む。原木と部材の関係だから、合計が合わないことは構造上あり得ない。この「1:Nで切り離す」という発想こそ、自社の商売の現実を見つめて初めて出てくる本質的な判断であり、汎用テンプレートを当てはめるだけでは決して辿り着けない。

「受注残数」の動的管理

このアーキテクチャの鍵が受注残数だ。受注数量から削り出された売上数量を引いた残りが受注残。分納すれば残が減り、一部返品があれば残が戻り、修理引取のような特殊な流れも残数の動きとして表現できる。受注残は静的な数字ではなく、事実が起きるたびに動的に計算される値として設計した。これが効くのは、「この受注、あとどれだけ残っている?」という業務の最頻出の問いに、システムが常に正確に答えられること。旧来は複数帳票を突き合わせて人間が計算していた。前シリーズの数値目標「納期回答時間-70%」も、この受注残の正確さの上に建つ。

将来のための「器」を先に掘っておく

DB設計でもう一つ重視したのが拡張性だ。今回は実装しない機能——BOM(部品表)による部品展開、製造現場のかんばん運用の高度化——が次期フェーズの構想にある。将来追加するときにデータ構造の作り直しが必要になったら、それは今回の設計の敗北だ。だから、今は使わなくても将来の機能が乗るためのDBの器(ハコ)を先に設計に織り込んだ。器を掘っておくコストは小さいが、後から掘り直すコストは巨大だ。ここにはShopify内製化の教訓が生きている。標準から外れた実装が後でShopify POSとの衝突を生んだ——あの「将来を閉ざす設計」の痛みを、DB設計で繰り返さない。

データ設計は、業務の哲学である

SSOTも、1:Nの削り出しも、技術の話に見えて実は業務の哲学の話だ。「事実は一箇所にだけ記録する」「確定した事実だけを刻む」「将来を閉ざさない」——これらはデータベースの設計原則であると同時に、信頼できる業務運営の原則そのものだ。データモデリングとは、自社の業務の本質を構造として彫り出す作業なのだと、この設計を通じて実感した。だからこそ繰り返す。実装はAIに任せられても、何をどう構造化するかという判断だけは、自社が握り続けなければならない。ここを手放した瞬間、システムは「誰でも作れるが、自社の役には立たないもの」になる。

次回は、この受注データが生産現場へ流れていく——生産手配・実績管理の設計だ。

評決ではなく、レンズを。

コードはAIが書けても、自社の事実をどんなデータ構造で持つかは自社にしか決められません。手段がコモディティ化するほど、このデータ基盤の設計こそが差を生みます。

AIで「作る」はコモディティになります。手段が横並びになるほど、散らばった知識の“点と点”をつなぎ、自社の本質——何を、どの基準で選び、どう活かすか——を見極める力が問われます。私はアトムビットとして、その見極めを特定ベンダーに肩入れしないフラットな評価軸でお渡しします。売るのは「どれが一番か」という評決ではなく、「あなたの制約でどう選ぶか」というレンズです。最終選定と結果責任は発注者にあります。

選定とAIDDレディネスの要点を1枚にした無料の「評価軸チェックシート」を配布中です。

▶ 無料で受け取る:https://atomb.it/lens?utm_source=note&utm_medium=article&utm_campaign=s3