データレイクから、根拠を説明できる意思決定へ。
Medallion アーキテクチャは原データ、共通の業務エンティティ、業務データプロダクトを段階的に整理します。次は、それらを責任の明確な判断につなぐことです。
行動を最適化する前に、根拠を整える
Bronze は原記録と履歴、Silver は検証・照合された共通エンティティ、Gold は業務目的別のデータセットを扱います。これは論理的な役割で、サーバーを三台用意する意味ではありません。統制された Silver データも ML に使えます。すべての記録を全層へ複製するより、利用者の要件から設計します。
共通の定義は、業務上の合意
二つのシステムが正しくても、営業の受注数量と倉庫の引当後在庫は一致しないことがあります。使えるデータプロダクトは粒度、定義、更新期限、責任者を明示します。取消、返品、遅延更新の扱いを合意し、鮮度の警告を対応できる人へ届けます。解決までの間、下流の判断をどう扱うかも定めます。
意思決定への接続を、明確な契約として扱う
整ったデータだけでは、急ぎの受注を引き受けるかは決まりません。収益の前提、能力の限界、サービスの約束、変更を承認する権限が必要です。使った入力スナップショットと候補案を保存し、承認計画と実績を比較します。既存業務と並行して提案を審査するシャドー運用から始め、合意した範囲内で自動化を広げます。
具体例で考える
以下は検討用の仮定であり、顧客事例や成果の主張ではありません。
ERP の在庫は 120 個、WMS の引当後利用可能数は 90 個、検討中の急ぎ注文は 40 個とします。Bronze は両ソースのスナップショットと時刻を保持。Silver は SKU と在庫定義を合わせ、引当済み 30 個を識別します。Gold は利用可能数 90 個と更新時刻を公開。意思決定エンジンはさらに材料使用、能力、既存の約束を確認します。WMS の情報が合意した期限を超えた場合、90 個を現在値とみなさず提案を保留し、人の審査へ回せます。
試行前に確認すること
最初のデータプロダクトはどの業務判断を支えるのか。定義の衝突や古いソースを誰が解決するのか。データとモデルの版から提案を再現できるか。品質基準、復旧訓練、入力不足時の対応を合意します。一つの業務を評価してから基盤を広げます。データの量が価値を持つには、用途と責任が明確であることが必要です。