データ基盤を作ると、社内の様々な人がデータを見るようになる。便利になる一方で、「この数字の定義は何か」「誰がこのデータを見てよいのか」が曖昧なまま使われると、混乱が生まれる。ある会議では「売上」が税込で語られ、別の会議では税抜で語られる。本来は限られた人しか見られないはずの個人情報に、誰でもアクセスできてしまう。こうしたほころびは、基盤が広く使われるほど大きな問題になる。
本記事は、データ基盤を安全に育てるためのガバナンスを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当である。ガバナンスというと堅苦しく聞こえるが、発注者として「数字の定義を揃える」「誰が何を見てよいかを決める」「個人情報を区別する」の三つを意識できれば十分である。仕組みづくりは開発会社と一緒に進められる。
結論：定義・権限・個人情報を最初に決めておく
データガバナンスは、後から付け足すと作り直しが増える。基盤を作る段階で土台を決めておくのが効率的である。GXOがガバナンスで重視するのは、次の3点である。
- 主要な指標の定義と項目の命名を統一し、数字の解釈をそろえる
- 誰がどのデータを見られるかを、役割に応じて設計する
- 個人情報など機微なデータを区別し、扱いを特に慎重にする
ガバナンスの目的は、利用を縛ることではない。安心して使えるようにすることである。定義と権限が整っていれば、現場は数字を疑わずに判断に使える。
なぜガバナンスが必要か
データ基盤は、人が増えるほど解釈や運用がばらつく。ガバナンスがないと、次のような問題が起きる。
- 同じ言葉が違う意味で使われる：「売上」「新規顧客」の定義が部門で違い、会議で数字が食い違う。
- 見るべきでない人がデータを見られる：権限設計が甘く、機密や個人情報に誰でも触れられる。
- 責任の所在が曖昧になる：数字が間違っていたとき、誰がそのデータの正しさに責任を持つのか分からない。
ガバナンスは、データを「信用できる状態」に保つための約束事である。これがないと、せっかく作った基盤も「数字が当てにならない」と言われ、使われなくなる。データの品質を保つ取り組みは社内データ活用・データ基盤の始め方｜データ品質の確保とも密接に関わる。
指標の定義と命名を統一する
数字が信用されるには、その数字が何を指すのかが一意に決まっている必要がある。定義と命名の統一は、ガバナンスの最初の一歩である。
| 揃えるもの | 例 | 揃えないと起きること |
|---|---|---|
| 指標の定義 | 売上は税込か税抜か、いつ計上するか | 会議ごとに数字が食い違う |
| 集計の単位 | 新規顧客は月単位か年単位か | 同じ言葉で別の数を語る |
| 項目の命名 | 顧客名・取引先名の呼び方 | データをつなぐとき混乱する |
| 区分の基準 | どこから「大口」と呼ぶか | 部門ごとに線引きが違う |
これらは、誰がどの定義を正とするかを決め、文書として残しておくことが大切である。定義が口頭の暗黙知のままだと、担当が変わったときに失われる。主要な指標から順に、定義の一覧を整えておきたい。
定義を一度に全部揃えようとする必要はない。会議でよく使われ、解釈が割れて困りやすい指標から手をつけると、効果が早く出る。売上、顧客数、新規と既存の区別といった、判断に直結する数字を先に固めておくと、その後の議論が噛み合うようになる。定義は決めたら終わりではなく、業務の変化に合わせて見直す前提で持っておくとよい。
アクセス権限を役割に応じて設計する
データ基盤には、見せてよいデータと、限られた人にしか見せられないデータが混在する。誰が何を見られるかを、役割に応じて設計する。
- 役割で区切る：経営層、部門責任者、現場担当など、役割ごとに見られる範囲を決める。
- 部門で区切る：自部門のデータは見られるが、他部門の詳細は見られないようにする。
- 機微なデータは別扱い：個人情報や人事情報は、見られる人を特に絞る。
- 変更の記録を残す：誰がいつ権限を変えたかを記録し、後から追えるようにする。
権限は「広く渡してから絞る」より「狭く始めて広げる」ほうが安全である。最初から全員に全データを開放すると、後から絞るのは難しい。いったん見えていたものを見えなくするのは、現場の反発も招きやすい。だからこそ、必要な範囲から開き、足りなければ広げる順序が無理がない。既存の業務システムにすでに権限設定があれば、それと整合させると運用しやすい。基盤だけ特別に広い権限を持つ状態は避けたい。
個人情報の取り扱いを区別する
データの中でも、個人情報は特に慎重に扱う必要がある。顧客の氏名、連絡先、購買履歴などは、漏れたときの影響が大きい。
| 取り扱い | 内容 | ねらい |
|---|---|---|
| アクセスを絞る | 見られる担当を最小限にする | 触れる人を限定 |
| 記録を残す | 誰がいつ見たかを残す | 後の説明責任 |
| 分析時は識別を避ける | 集計や分析では個人を特定しない形にする | 不要な露出を防ぐ |
| 保管期間を決める | いつまで保持するかを定める | ため込みすぎを防ぐ |
個人情報を分析に使うときは、個人を特定する必要があるのか、集計だけで足りるのかを見極めたい。多くの分析は、個人を特定しなくても集計だけで成り立つ。識別が不要なら、最初から特定できない形で扱うほうが安全である。顧客データの扱いはCDP（顧客データ基盤）導入ガイドも参考になる。
ガバナンスを運用に乗せる
ガバナンスは、ルールを決めて終わりではない。決めた定義や権限を、運用の中で維持していく必要がある。
- 定義の管理者を決める：指標の定義を誰が管理し、変更時に誰が承認するかを決める。
- 権限を定期的に見直す：異動や退職に合わせて、不要になった権限を整理する。
- 新しいデータにもルールを適用する：基盤に新しいデータを足すとき、定義と権限を決めてから入れる。
これらを担う社内の体制が必要になる。専任でなくてよいが、責任を持つ担当は決めておきたい。運用体制とデータ人材については社内データ活用・データ基盤の始め方｜運用体制とデータ人材で扱う。
導入前チェックリスト
- 主要な指標について、定義をそろえる対象を洗い出したか
- 売上・顧客など、解釈が割れそうな言葉を特定したか
- 誰がどのデータを見てよいか、役割で整理したか
- 個人情報や機微なデータを、別扱いにする方針を決めたか
- 権限の変更を記録する仕組みを想定したか
- 定義や権限を管理する社内の担当を決めたか
- 異動・退職時に権限を見直す運用を想定したか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 指標の定義を一元管理できますか | 定義の統一 |
| 役割や部門ごとにアクセスを絞れますか | 権限設計の粒度 |
| 個人情報を別扱いにできますか | 機微データの保護 |
| 誰がデータを見たか記録できますか | アクセスの追跡 |
| 権限の変更履歴は残せますか | 監査への対応 |
| 後から定義や権限を変えやすいですか | 運用での見直し |
「権限はあとで設定すれば大丈夫」という説明には注意したい。後から付けるより、最初の設計に織り込むほうが、作り直しを避けられる。
相談前に整理しておくとよい情報
- 数字の解釈が割れて困った経験（売上、顧客数など）
- 見せてよいデータと、限られた人だけが見るべきデータ
- 扱う個人情報の種類（顧客の連絡先、購買履歴など）
- 既存システムにすでにある権限設定
- 定義や権限を管理できそうな社内の担当
これらが整理されていなくても相談は可能である。困った経験と、機微なデータの心当たりが見えていれば、ガバナンスの土台を一緒に設計できる。
関連記事
よくある質問
Q1. 中小企業でもデータガバナンスは必要ですか
必要である。むしろ担当者が少ない分、定義や権限が暗黙知になりやすい。最初に主要な指標の定義と権限を決めておくだけでも、後の混乱を大きく減らせる。
Q2. ガバナンスを厳しくすると、現場が使いにくくなりませんか
縛りすぎると使いにくくなるが、ねらいは利用を妨げることではなく、安心して使えるようにすることである。見られる範囲を役割に応じて適切に開けば、現場は迷わずに使える。
Q3. 個人情報は分析に使ってはいけないのですか
使えないわけではない。多くの分析は集計だけで成り立つため、個人を特定しない形にできる。識別が本当に必要かを見極め、不要なら特定できない形で扱うのが安全である。
データ基盤を安心して使える状態にしませんか
GXOでは、データ基盤を作る前に、指標の定義や命名の統一、アクセス権限の設計、個人情報の取り扱いを一緒に整理します。後からの作り直しを避けるため、ガバナンスの土台を初期の設計に織り込んでご支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。