データガバナンスの設計思想と運用¶

2026-10-28 更新約7分で読めます

作成: 2026-09-30 特定製品に依存しない実務ノート。以下は設計・運用の一例であり、全社共通の必須規則ではない。

30秒で復習¶

業務の困りごとから始め、責任と判断基準を決め、普段の仕事に確認・修正の流れを組み込む。

規程を作って終わりにせず、問題を見つけて直し、再発を減らすところまで設計する。

こんな場面で出会う¶

「データガバナンスを進めて」と言われたが、何から始めればよいか分からない
規程は作ったのに、現場で守られていない・誰が直すのか決まっていない

1. 設計で大切にしたい考え方¶

考え方	設計への反映	避けたい状態
業務目的から始める	「品目の重複で集計に時間がかかる」を解決する	ツール導入そのものが目的になる
責任と決定権をセットにする	誰が定義・変更・例外を承認するか決める	責任者はいるが判断できない
共通基準と現場の知識を両立する	全社でコード・機密区分を統一し、各部門が内容を管理する	全てをIT部門へ丸投げする
品質を用途に合わせる	経営集計と設備監視で必要な鮮度を分ける	全データに同じ厳しさを求める
入力・変更時に防ぐ	必須項目、形式チェック、承認を組み込む	集計のたびに手作業で直す
正式な情報源を明確にする	項目・用途ごとに正本と更新経路を決める	複数のコピーを別々に更新する
小さく始め、効果を見て広げる	品目マスターなど一つの対象で試す	最初から全社の全データを整える

「正式な情報源を決める」は、全データを一つのデータベースに移すという意味ではない。例えば取引先の住所は販売管理、支払条件は会計を正式な情報源にする設計もある。項目ごとの責任と連携ルールが必要。

2. 管理体制をどう設計するか¶

役割	主な責任	製造業の割り当て例
経営・部門横断の会議体	優先順位、予算、部門間の対立を判断する	管理職と関係部門の定例会
データオーナー	定義、品質目標、利用条件、重要変更を承認する	品目マスターの業務責任者
データスチュワード	定義の整理、品質確認、問い合わせ・修正の調整	マスター管理担当者
社内SE・システム管理者	権限、入力制御、連携、ログなどを実装・運用する	システム担当
利用者	利用ルールを守り、不具合を報告する	営業、生産、購買担当

小さな組織では兼務できる。人数よりも「最終判断者」「日常の窓口」「技術担当」が分かることを重視する。

3. 最初に作る管理台帳¶

まずは表で管理できる。製品選定は、その後に不足する機能から考える。

項目	記載例：品目マスター
業務目的	売上・生産・在庫を品目コードで関連付ける
対象・範囲	現行品目。廃止品は履歴として区別
正式な情報源・場所	生産管理システムの品目マスター
オーナー／日常窓口	生産管理責任者／マスター担当者
定義・単位	品目コードの体系、名称、個・kg等の単位
品質基準	コード重複ゼロ、必要項目の欠落を検出
権限・利用目的	関係部門が閲覧、担当者が更新
更新・承認方法	申請→確認→承認→登録→連携確認
保存・廃止方法	廃止日を記録。削除は関連履歴への影響を確認
利用先・依存関係	販売管理、購買、在庫集計
確認頻度・証跡	定期チェックと変更・承認履歴

保存期間はデータの種類や社内要件に応じて定める。全データに一律の年数を当てはめない。

4. 日常運用の流れ：品目マスターの例¶

申請：担当者が品目名、単位、利用開始日、変更理由を提出する。
確認：スチュワードが既存品目との重複や定義との整合を確認する。
判断：オーナーが重要な追加・変更を承認する。通常変更を委任する場合は範囲を決める。
登録・反映：登録権限を持つ担当者が反映し、他システムへの連携を確認する。
記録：変更前後、申請者、承認者、日時、理由を残す。
利用後の確認：不具合を窓口へ報告し、影響範囲を調べて修正する。

過去の品目の単位を変えると、在庫や過去の集計まで意味が変わる場合がある。上書きだけで済ませず、新コード・適用開始日・履歴管理などを検討する。

5. 問題や例外をどう扱うか¶

問題対応の例

重複を発見→窓口で記録→業務・利用先への影響を確認→責任者が修正方針を判断→元データと必要な連携先を修正→結果を確認→入力・申請手順を改善。

集計用Excelだけを直すと、翌月も同じ問題が発生する。正式な情報源や入力工程まで原因をたどる。

例外申請に残すこと

通常ルールを守れない理由と対象範囲
承認者、期限、代わりの確認方法
期限後の見直し・終了方法

緊急対応を永久的な例外にしない。重大な問題の連絡先と判断期限も事前に決める。

6. 品質と効果をどう測るか¶

指標	測り方の例	注意点
完全性	必須項目が入力済みの件数÷対象件数	入力済みでも正しいとは限らない
一意性	同じキーの重複件数	重複の業務定義を決める
妥当性	形式・範囲ルールに適合した件数÷対象件数	形式だけでは実態との一致は分からない
正確性	確認資料・実物などと一致した件数÷確認件数	確認方法と標本範囲を記録する
適時性	期限内に更新された件数÷更新対象件数	用途に必要な更新期限を決める
業務効果	集計の手直し時間、問い合わせ件数	データ整備が仕事に役立ったかを見る

測定条件と対象期間を固定して比較する。目標値や確認頻度はリスク・用途・対応能力に応じて設定する。

7. 社内規程・手順書ならどうするか¶

SharePoint等に置いた規程でも考え方は同じ。

文書番号、名称、管理部門、承認者、版数、施行日を記録する。
現行版を明確にし、旧版・下書きが現行版と混ざらないようにする。
閲覧権限と編集・承認権限を分ける。
改訂時に関連する手順書や案内も確認する。
内容を確認する周期と、期限切れの連絡先を決める。

社内規程Botに使う場合も、検索対象の現行性、利用者の閲覧権限、回答の出典が重要。資料を集めるだけでは正しい回答や適切な公開範囲を保証できない。

8. 始め方の一例¶

困っている業務を一つ選び、現状の手直し時間などを記録する。
使うデータと情報源、担当者、問題点を洗い出す。
オーナーと窓口を決め、必要な定義・品質・権限ルールを書く。
申請・変更・問題対応を通常業務に組み込んで試す。
指標と利用者の声を見て修正し、次の対象へ広げる。

よくある質問¶

Q. 規程を作れば運用できていると言える？
A. 実際に担当者が判断でき、問題が修正され、記録から確認できることが必要。

Q. データの意味を全社で一つに統一するべき？
A. 同じ意味で比較する項目は共通化する。用途で意味が違う場合は「受注売上」「出荷売上」のように区別し、関係を明示する。

Q. 中央集権と部門任せのどちらがよい？
A. 組織次第。共通基準は全社で決め、内容の判断は業務を知る部門が担う形もある。部門間の不一致を誰が調整するかも決める。

自社で確認したいこと¶

正式な情報源が分からず困っているデータは何か？
定義が違って横断集計できない項目は何か？
変更の承認者と修正窓口は明確か？
入力・連携のどこで誤りが発生するか？
改善前後で比較できる業務指標は何か？