なぜ御社のデータカタログは誰も見ないのか？「作りっぱなし」を防ぐ運用の仕組み

～ツール導入はゴールではない。「データのお世話」をする評価制度と文化の設計～

はじめに：高機能ツールが「廃墟」になるまで

「データ活用を民主化するために、データカタログを導入しよう」

そう意気込んで、AlationやAtlan、あるいはGoogle CloudのData Plexといったモダンなカタログツールを導入する企業が増えています。ライセンス費用に加え、導入支援や初期設定を含めれば、その投資額は年間数百万円から、規模によっては一千万円近くに達することもあるでしょう。

しかし、導入から半年後。管理画面のログイン履歴を見て愕然とする担当者は少なくありません。アクティブユーザーは、開発を行ったデータエンジニア数名のみ。本来のターゲットであるはずのデータアナリストやビジネス部門の社員は、最初の1週間しかログインしていない——。

現場に理由を聞けば、こんな答えが返ってきます。「欲しい定義が書いていなかったから、結局Slackで詳しい人に聞いたほうが早い」「以前見たときに情報が古かったから、もう見ていない」

結論から申し上げれば、カタログが使われないのは「ツールの機能不足」ではありません。「運用ルール」と「インセンティブ（入力する動機）」の設計ミスです。

本稿では、多くの企業が陥る「カタログの廃墟化」を防ぎ、データ資産を正しく管理するための運用の仕組みについて解説します。

多くのプロジェクトが、「ツールを導入すれば、自動的にメタデータが収集され、カタログが完成する」という幻想を抱いたままスタートします。

確かに、最近のツールは優秀です。データベースに接続すれば、「テーブル名」「カラム名」「データ型」「リネージ（データの流れ）」といった**「技術メタデータ」**は自動で吸い上げてくれます。

しかし、ユーザーが本当に知りたいのはそこではありません。「この『売上』カラムは税込なのか？キャンセル分はマイナス計上されているのか？」「『アクティブユーザー』の定義は、ログインベースか、起動ベースか？」

こうした**「ビジネスメタデータ（意味・文脈）」**は、どれだけ高いツールを入れても、人間が入力しない限り永遠に「空白（Null）」のままです。この空白だらけのカタログを見たユーザーが、「これならスプレッドシートの定義書の方がマシだ」と離脱していくのです。

では、なぜビジネスメタデータは埋まらないのでしょうか。多くの企業は「Wikiのように、気づいた人が追記して育てていきましょう」という「性善説」に基づいた運用ルールを敷きます。しかし、これは100%破綻します。

自分の業務で手一杯な現場社員にとって、他人のためにドキュメントを書く時間は「1円の得にもならないボランティア」だからです。

また、情報の鮮度も問題です。一度善意で書かれた説明も、システムの改修に合わせてメンテナンスされなければ、すぐに嘘の情報になります。「最終更新：3年前」と表示されたカタログを見て、業務上の重要な意思決定を行う人はいません。

この状況を打破するための第一歩は、「すべてのデータを管理しようとしない」ことです。 DWH内にある数千、数万のテーブル全てに定義を書こうとするから挫折します。データの重要度に応じて「ティアリング（階層化）」を行いましょう。

Tier 1（最重要資産）: 全社KPI、決算数値、顧客マスタなど。これらは記述を義務化し、データの品質をSLA（サービス品質保証）で担保します。
Tier 2（部門資産）: 特定の部署内でのみ使用されるデータ。記述は推奨レベルとし、各部門の責任に委ねます。
Tier 3（その他）: 一時テーブルやワーク用データ。自動収集される技術メタデータのみで十分とし、説明記述は不要とします。

「まずはTier 1だけ見れば、絶対に正しい情報がある」という安心感を作ることが、カタログへの信頼を取り戻す第一歩です。

次に、誰がTier 1のデータを管理するのか、という「役割」の問題です。ここで重要なのが、**「データスチュワード（データ管財人）」**という役割の任命です。これはIT部門だけでなく、各ビジネス部門（営業、経理、人事など）から選出します。

そして最も重要なのが、**「この役割を人事評価（MBO）に組み込むこと」**です。

「カタログの整備率」や「ユーザーからのデータに関する問い合わせ対応数」を目標設定に入れ、カタログメンテナンスを「ボランティア」から「業務」へと昇華させなければなりません。

弊社のコンサルティングでは、日本企業では曖昧になりがちなこの「データスチュワードのジョブディスクリプション（職務記述書）」の策定から支援し、評価制度として定着させます。

最後に、エンジニアに対するアプローチです。データエンジニアに「開発が終わったら、ブラウザでカタログツールを開いて説明を書いてください」とお願いしても、なかなか定着しません。ツールを行き来するのは手間だからです。

現代のモダンデータスタックにおいては、開発ワークフローの中にドキュメント記述を「強制的に」組み込む手法が有効です。

例えば、dbt (data build tool) を利用している場合、コード（YAMLファイル）の中にdescription（説明）を書かないと、CI/CDパイプラインでのテストが通らない（デプロイできない）という仕組みを作ることができます。

「ドキュメントもコードの一部」として管理し、開発の流れの中で自然に（あるいは強制的に）メタデータが生成される仕組みを作れば、カタログは常に最新の状態に保たれます。

データカタログ導入の失敗は、それを「一度作って終わりの辞書」だと捉えてしまうことに起因します。データカタログの本質は、毎日雑草を抜き、水をやり、手入れをし続けなければすぐに荒れ果ててしまう**「庭」**に近いものです。

高価なツールを導入する前に、まずはその庭を手入れする「庭師（データスチュワード）」を任命し、彼らが報われる評価制度と、手入れを楽にする技術的なワークフローを整備してください。

「ツールを入れたが、誰も見ていない気がする」もしそう感じているのであれば、ツールのリプレイスを検討する前に、まずは我々と一緒に「運用の再設計」から始めてみませんか？