「自社にどんなデータがどこにあるか、誰に聞けばわかるかがわからない」——これはデータ活用推進の大きな障壁です。この問題を解決するのがデータカタログです。Ataccama・Alation・Atlan などの専用製品や、Google Cloud の Dataplex のようなデータガバナンス基盤がありますが、機能や利用規模に応じて導入・運用の負荷が発生するため、まず既存のExcelやWiki（Confluence・Notion等）から始める方法もあります。本記事では後者のやり方を解説します。なお専用ツールが持つ自動メタデータ収集・リネージ・横断検索までを再現するものではなく、「何のデータがどこにあり、誰に聞けばよいか」を見える化することが目的です。なお本記事が扱うのは「データがどこにあるか」の台帳です。「売上」「稼働率」といった指標の意味を揃える話はBIを作る前に整備するデータ辞書：指標定義を統一して「数字の争い」を減らすで扱っており、本記事では踏み込みません。
データカタログに最低限必要な情報
データカタログとは、社内にどのようなデータ資産があり、どこに存在し、誰が管理し、どう利用できるかを整理して検索できるようにする仕組みです。データ項目の意味を定義する「データ辞書」とは役割が異なります。ツールの有無にかかわらず、以下の情報を整備することで「あのデータはどこにある？」という問いに答えられる状態を作ります。
| 記録項目 | 内容 | 記録例 |
|---|---|---|
| データソース名 | どのシステム・ファイル・DBか | 顧客管理DB（Salesforce）・受注管理Excel |
| データの内容 | 何が記録されているデータか | 顧客の基本情報・受注履歴・在庫スナップショット |
| 更新頻度・鮮度 | どれくらいの頻度で更新されるか | 日次・週次・リアルタイム |
| データオーナー | 誰が管理責任を持つか | 営業部・田中○○（内線○○） |
| アクセス方法 | どうすれば使えるか・申請が必要か | BIツールで直接・申請フォームで申請 |
| 取り扱い区分 | 個人情報の有無・公開範囲 | 個人情報あり／部署限定 |
| 既知の品質問題 | わかっている問題・注意点 | 2020年以前のデータは入力形式が異なる |
データカタログの基本項目テンプレート
Excelでのデータカタログ作成手順
Excelでデータカタログを作る場合、まず「データソース一覧シート」と「テーブル・フィールド定義シート」の2つのシートから始めます。
- データソース一覧シート：上記テンプレートの項目で、自社のデータソースを1行1件で一覧化します。最初は網羅より優先度の高いものから始めます（BIで使っているデータ・よく問い合わせが来るデータ等）
- テーブル・フィールド定義シート：主要なDBテーブル・Excelファイルについて、フィールド名・データ型・意味・入力ルール・値の範囲を記録します。これがビジネスロジックの辞書になります
- メンテナンスルール：カタログを最新に保つために、「データソースや定義に変更があったときは3営業日以内に更新する」といった更新ルールを設けます。期限は自社の変更管理プロセスに合わせて決めてください。あわせてメンテナンス担当者を明確にします
WikiやNotionでのデータカタログ運用
ConfluenceやNotionなどのWikiツールを使うと、データカタログをチーム全員が閲覧・検索・更新しやすい形で管理できます。Excelより検索性が高く、コメント・リンクが使えるためドキュメントとしての使いやすさが向上します。
- Notionでのデータベース機能活用：Notionのデータベース（テーブルビュー）で、データソース一覧をプロパティ付きで管理します。フィルタ・ソート・ビュー切り替えで「営業部が使うデータだけ表示」などの絞り込みが簡単にできます
- タグによる分類：「業種別」「更新頻度別」「品質状態（整備済み・要整備）」などのタグを付与し、カタログを横断的に検索できる構造を作ります
- ページリンクの活用：関連するデータソース・定義書・BIダッシュボードへのリンクをカタログページに集約することで、データから関連情報に素早くアクセスできます
データカタログの運用定着：更新を続けるための仕組み
データカタログで最も難しいのは「作ることより、更新を続けること」です。一度作ったカタログが古くなり放置されるのは、更新のルールと責任者が明確でないことが原因です。カタログの更新ルールの例としては「データソースに変更が発生した時点（新規システム追加・カラム定義変更・管理担当の変更）から3営業日以内に更新する」という即時更新の形があります。システム改修を伴う場合は、本番反映後を起点にすると開発側の運用と齟齬が出にくくなります。定期的な見直し（四半期に1回全ページをレビュー）と組み合わせると、鮮度を保ちやすくなります。
最初から項目を増やしすぎない
※ まず必要最小限から始め、利用状況を見ながら項目を足していきます
更新の負荷を下げるために、カタログの項目は利用目的に直結するものへ絞ることをお勧めします。データソース名・データの内容・管理担当・更新頻度・アクセス方法・既知の品質問題あたりに限定すれば、登録と更新の負荷を抑えられます。まず必要最小限から始め、利用状況を見ながら項目を足していく進め方が現実的です。はじめから全フィールドを詳細に記録しようとすると、記録そのものが目的になりやすく、着手も継続も難しくなります。
データカタログをBI活用に活かす方法
データカタログが整備されると、BI・分析プロジェクトで必要なデータを探す時間を減らすことが期待できます。「このレポートを作るにはどのデータが必要か」→「カタログで該当データソースを検索」→「管理担当に利用申請」という流れが確立すれば、データ特定から利用開始までの時間短縮につながります。BIツールを使う分析担当者が「このデータは信頼できるか・どこから来たか」を確認する際の一次情報としてカタログを使えるようになると、分析の速度と品質が向上します。
カタログに「既知の品質問題」を記録しておくことで、BI分析担当者が問題のあるデータを使って誤った分析をするリスクを下げられます。「2022年以前のデータは税率計算が誤っている」「○月のデータはシステム移行の影響で欠損がある」という注記があることで、分析担当者が適切な期間・条件でデータを使えるようになります。ただしカタログに記載した品質情報は、データ品質を保証するものではありません。利用者が注意すべき既知の問題を共有するための情報、という位置づけを明確にしておくと誤解を避けられます。
専用ツールへの移行を見据えたExcel/Wikiカタログの設計
将来的にAtlan・Dataplex・Alation等のデータカタログ専用ツールへの移行を視野に入れている場合、ExcelやWikiでのカタログ設計を移行しやすい形にしておくことが大切です。具体的には「データソース名」「テーブル・フィールド名」「管理担当」「説明」「品質ステータス」の標準項目を統一し、ファイルやページの命名規則を揃えておくと、整理した内容を移行設計に活用しやすくなります。取り込み方式やメタデータの持ち方は製品ごとに異なります。専用ツールはDBのスキーマを自動で収集する機能が中心のため、移行時は手作業で書いた業務上の文脈（説明・管理担当など）を突き合わせる作業になります。
ExcelやWikiのカタログは、組織のデータ活用が初期段階にある時期の「橋渡し」として機能します。まずこの段階で「何がどこにあるか」を組織が意識し始め、カタログを使う習慣が根付いた段階で専用ツールへ移行すると、ツールを導入したものの使われずに終わる、という状況を避けやすくなります。データカタログは「ツール導入」ではなく「データ可視化の文化づくり」から始めることが最終的な成功につながります。
よくある質問
どのデータソースから記録すればよいですか？
まずは「問い合わせが多いデータ」や「複数部門で利用されているデータ」から始める方法が分かりやすいです。誰かが一度でも「あのデータどこ？」と聞いてきたデータは、今後も聞かれる可能性が高いためです。網羅性から入ると対象が多すぎて着手できないため、直近で問い合わせがあったもの、BIやレポートで実際に使っているものを優先してください。なお優先順位は利用頻度・業務上の重要度・品質リスクなど複数の観点で決められるので、自社で判断しやすい軸を選んで構いません。10件ほど書いた時点で、何が重要かの感覚がつかめます。
管理担当を決められない場合はどうすればよいですか？
正式な責任者を決めようとすると止まるので、まずは「問い合わせ先」として、そのデータに詳しい担当者を記録してください。責任者の任命は組織の合意が要りますが、「この件はこの人に聞けばわかる」は現場で判明しています。カタログの目的は責任の所在を定めることではなく、聞く相手が分かる状態を作ることです。なお、データの管理・利用・品質に責任を持つ役割としてのデータオーナーと、実務上の問い合わせ先は分けて管理すると混乱を防げます。
ExcelとWikiのどちらで始めるべきですか？
社内で既に使われているほうを選んでください。カタログが更新されなくなる原因の多くは、普段開かない場所に置かれていることです。Confluenceを日常的に使っているならConfluence、そうでなければExcelで構いません。ツールの機能差より、担当者が毎日目にする場所にあるかどうかが更新率を左右します。
まとめ
データカタログは専用ツールがなくてもExcelやWikiで始められます。まず優先度の高いデータソース10件から記録する、というスモールスタートで「あのデータはどこにある？」に答えられる状態を段階的に作っていくことをお勧めします。重要なのは、はじめから記録する項目を増やしすぎないことです。データソース名・データの内容・管理担当・更新頻度・アクセス方法・既知の品質問題あたりに絞れば、登録と更新の負荷を抑えられます。必要になった項目は、使いながら足していけば足ります。ここで作った台帳は、将来専用ツールを導入する際に整理内容を引き継ぐ土台にもなり、ツールを入れたものの使われずに終わる状況を避けやすくなります。データカタログの設計・整備支援についてはBFT Insightにご相談ください。