「基幹に持たせよう」という一言は善意で出る。ただし、判断基準が利用者数でも設計の美しさでもないとすれば、何なのか。

答えは一点だけだ。「他システムがそのデータを取り込んで書き足す共有物に育ったかどうか」——これがSoR（System of Record：組織のデータ管理における権威的ソース）への昇格の唯一の引き金だ。この一軸で判断できれば、会議での問いに根拠を持って返せる。

受益者の有無が唯一の判断軸

SoRという概念の産業界定義は、Geoffrey MooreとAIIMが2011年に策定した白書が原典だ。「組織の重要マスターデータを管理するトランザクション処理の権威的ソース」——核心条件は、他システムがそのデータを取り込んで書き足す「共有物になっているかどうか」だ。

利用者数・設計の美しさ・担当者の熱意は、この定義に入らない。「月1,000人が参照する」と「他システムから書き込まれる」は別の概念だ。前者はアクセス頻度、後者はデータ所有権の問題だ。

Microsoftの公式参照アーキテクチャ「Synchronize data across Dataverse environments」（2024年）も「一方をプライマリ（権威的ソース）と定め、他はセカンダリ（コピー）として設計する」と明示している。SoRを定めることは自然に決まるものではなく、明示的な意思決定だ。

データ設計の判断とは、受益者を先に確認する作業だ。

2つの取り違えを潰す

会議でよく起きる取り違えは2つある。

利用者が多い ＝ 共有物

「多くの部門が参照している」は昇格の引き金でない。読み取り専用の利用がいくら増えても、他システムからの書き込みが発生しなければSoRの条件を満たさない。

コピーを基幹に流す ＝ 正本が基幹に移った

「基幹DBにデータをコピーして同期している」と「基幹が正本（SoR）になった」は別の意思決定だ。どちらが権威的ソースかを明示的に決めなければ、障害時・更新競合時に「どちらが正しいか」の判断がつかなくなる。

Microsoft公式ドキュメント「Data ownership models for synchronization」（2024年、DataverseとBusiness Centralの統合設計）はこう規定している——「どちらかをSoR（正本）と定め、他はコピーとして扱う」。写しがいくら出回っても、正本は動いていない。

昇格に付く4つの恒久コスト

昇格を選んだ瞬間から、以下4つのコストが恒久的に積み上がる。

コスト内容
同期コスト2システム間のデータを常に一致させるための配管メンテナンス
維持コストスキーマ変更・バージョンアップのたびに統合コードを更新する工数
責任分界障害時・更新競合時に「どちらが正しいか」の所管整理（担当部門間の調整）
部門間調整マスタ変更・スキーマ変更の影響範囲を関係部門と合意し続けるコスト

IPAが示す業界慣行では、システム保守費用は初期開発費の15〜20%が目安だ。Fivetranの調査（参考値・商業調査機関）によれば、エンジニア時間の53%がデータパイプライン・統合のメンテナンスに費やされるという。Ampersandの調査（参考値・商業調査機関）では、統合1件あたりの年間保守コストは構築コストの2倍以上に達するとされている。

昇格した日から始まる構造的なコストだ。

受益者がいなければ、コストだけが積み上がる

他システムが書き足す受益者がいない状態で昇格すると、便益はゼロのままこれらのコストが恒久的に積み上がる。

経産省のDXレポート（2018年）は「既存システムの集約が必ずしもサイロ化を解消するわけではなく、新たな統合コストを生む」と指摘している。「あった方がいい」という根拠だけで昇格する場合、この指摘は直接当てはまる。

受益者の有無という一軸で判断できれば、「昇格しておけば将来使えるかもしれない」という根拠のない期待を機械的に排除できる。

データ種別で答えが変わる

SoR定義（Geoffrey Moore/AIIM 2011）から整理すると、判断が異なるデータ種別が2つある。この判断フレームが主な対象とするのはフロント入力データ（ユーザー入力・業務記録・申請フォームへの回答等）だ。

参照データ（コード表・マスタ等）は、通常すでにSoRが存在している。問いは「どこのSoRから取るか」になる。フロント入力データは「そもそも昇格すべきか」から判断が必要だ。

Microsoftも「バーチャルテーブル（参照のみ）とデータ同期（コピーを持つ）の選択肢」を公式に並べており、どちらが適切かは状況に依存すると示している。この種別の区別を持っておくと、「なぜ基幹に集約しないのか」という問いに対して、まずデータ種別から答えを絞り込める。

→ M365 Developer Tenant でのローカル検証環境構築：顧客テナントに時間を吸わせる構造へ、資産を渡すな

まとめ

フロント入力データをSoRに昇格させるかどうかは、他システムが書き足す受益者がいるかどうかだけで決まる。受益者がいなければ、昇格は4つの恒久コストを無償で積む選択だ。

次の一歩：会議で「基幹に持たせよう」と言われたら、まず「そのデータを書き足す他システムが今あるか、3ヶ月以内に現れるか」を確認する。Yesなら昇格を検討する。Noならコピー運用の設計を選ぶ。ただしコピー運用には写しのライフサイクル管理と参照タイムラグの許容範囲の合意が別途必要になる。

関連記事