整えたデータを保ち続ける組織のつくり方｜データオーナーとデータスチュワード

AI時代に必要なデータの意義と知識を紹介する連載、なぜAIの話は、いつも「データ」の話になるのか。

前回の連載：第5回では、整ったデータを安心してAIに渡すためのガバナンス：データ分類・アクセス制御・ガードレール・リネージと監査ログに関して解説しました。

前回の記事：整ったデータを安心してAIに渡すための4つの打ち手

今回は、実際に運用が始まったあとのお話である「整えた仕組みを、誰がこの先も維持し続けるのか」という観点で解説をしていきます。

はじめに——整えた仕組みを、誰が維持し続けるのか

データ基盤を作ったはいいが、半年経ったら定義が古くなって誰も直していない。
データの品質を点検する仕組みを入れたのに、チャットに届くアラート通知に、誰も目を通していない。
新しいデータやAIの用途が増えるたびに、アクセス制御や分類が後手に回る。
整えた直後はきれいだったデータが、管理・維持する人がいないために、また散らかっていく。
そしてまた綺麗にするために外部の力を借りる、という流れはよく聞く話です。

第2回で挙げた「9つの失敗パターン」の最後、パターン9「整えた状態を保つ担当がいない」が、まさにこの話でした。
そこでは「データオーナーとデータスチュワードという二つの役割があり、兼任でかまわないので決めておこう」とだけ触れて、本格的な解説は今回に預けていました。

さっそく「整えた状態を保つ担当がいない」への打ち手の詳細を見ていきます。

なぜ、整えた状態は放っておくと崩れていくのか

最初に押さえておきたいのは、データが「動くもの」だという事実です。

多くの読者は、データを倉庫に積まれた在庫のように、一度棚卸しをすれば一定期間そのまま使えるものだと感じているかもしれません。

けれども実際のデータは、もっと水に近い性質を持っています。
事業が動けば、データも形を変えていきます。
顧客が増えれば、登録される表記ゆれが増えます。
新しい商品ラインを立ち上げれば、売上の分類が変わります。
SaaSを乗り換えれば、フィールド名が変わり、過去のデータとつなぐ手当てが要ります。
組織変更があれば、責任の境目が動きます。
これらは、どこかで「データを直す」誰かがいなければ、現場の運用がねじれていく原因になります。

このとき、誤解されやすい点が1つあります。
データ基盤を整える仕事と、整えた状態を保つ仕事は、別の仕事だということです。
前者はプロジェクトとして区切りがあり、終わりがあります。
後者はプロジェクトではなく、事業が続く限り続く運用です。

データガバナンスが現場で形骸化していく原因を整理した解説では、「『一度導入したから安心』ではなく、運用フェーズで形骸化しないための工夫が要る」と指摘されています(出典: なぜデータガバナンスは形骸化するのか — SE-Navi)。

デジタル庁が2025年6月20日に公表した「データガバナンス・ガイドライン」も、データを有効に使いこなす総合的な能力を「データマチュリティ」と呼び、その不断の向上を企業に求めています(出典: データガバナンス・ガイドライン — デジタル庁)。

ここで起きやすいのが、「誰かがやるだろう」という空気です。
基盤を作ったITベンダーが手を引いたあと、社内の誰がオーナーシップを持つのか。品質のアラートが鳴ったとき、誰が一次受けをするのか。新しいデータ項目を追加したいとき、誰の決裁を取るのか。
これらが宙に浮いた状態で半年、一年と動けば、整えたデータは、ほぼ確実に劣化します。

裏を返せば、ここで決めるべきは、規模の大きい組織図ではありません。「この仕事は誰の担当か」が、一行ずつ書かれていること。
これが、整えた状態を保つための最小単位です。
次の章から、その「一行」をどう書くかを、具体的に見ていきます。

必要なのは専任チームではなく、2つの役割の明文化

データを保ち続けるために、まず押さえておきたい役割が2つあります。
データオーナーと、データスチュワードです。
名前だけ見ると「うちにはそんな人いない」と思われがちですが、中身を見ると、難しい話ではありません。
先に役割の中身を見て、そのあと「自社では誰がそれに当たるか」を考えていきます。

データオーナーは「決める人」

データオーナーは、その領域のデータについて最終的に責任を持つ人を指します。
多くの解説で共通しているのは、オーナーが「決める人」だという定義です。
たとえば、顧客データであれば、「顧客とは誰か(見込み・既存・解約を含むのか)」「重複は何をもって同一とするか」「どの部署までアクセスしてよいか」「外部のAIサービスに渡してよいか」といった問いに、最後の決裁を下す人がデータオーナーです。

データマネジメント基盤を提供するActian社や、データカタログを提供するAtlan社の解説では、オーナーは「データに関する決定権限と説明責任を持つ立場」と整理され、業務側の上位役職(部門長クラス)が担うのが基本だとされています(出典: Data Owner vs. Data Steward — Actian、Data Steward vs Data Owner — Atlan)。

ここで誤解しやすいのが、「データオーナーは全社で一人」というイメージです。実際は逆で、データの種類ごとに、別の人がオーナーになります。
売上データなら営業部長、顧客データならマーケティング部長やCS部長、契約データなら法務責任者や経営企画責任者。
肩書を新設するのではなく、すでに業務上、そのデータについて最終判断を下している人が、自然にオーナーになる。それが現実的な姿です。

データスチュワードは「実行する人」

データスチュワードは、データオーナーが決めた基準に従って、データの品質を日々維持し、定義を更新し、現場からの問い合わせに答え、ガードレールを実際に運用する人です。
オーナーが「決める人」なら、スチュワードは「実行する人」と覚えていただけると良いです。

データ統合・品質ツールを提供するTalend社や、Alation社などの解説では、スチュワードシップは「データの品質・健全性・適切な利用を、組織を横断して保つための日々の管理活動」と定義され、業務とITの橋渡しを担う役割だと整理されています(出典: What is Data Stewardship? — Talend、The Role of Data Stewards Today — Alation)。

スチュワードは経営企画・DX/AI推進・情報システム担当の中の誰かが、業務の一部として担うのが現実的です。重要なのは、「あなたはこのデータのスチュワードです」と社内での位置づけを明文化し、責任の所在をはっきりすることです。

データの種類ごとに、業務責任者をオーナーに当てはめる

ここまでをまとめると、データ管理に必要なのは、「決める人」と「実行する人」が、データの種類ごとに決まっていることです。
データの種類別に整理すると、次のような像になります。

この対応づけ自体は、業種や規模によって変わって構いません。
大事なのは、自社の事業構造に合わせて、似た形で一覧化できることです。
表を埋めたとき、空欄が残るデータがあれば、そこが「責任者の不在」になります。

経営として下すべき意思決定は、「専任を雇うか、兼任でいくか」ではなく、「兼任で構わないので、このデータの責任者は誰か、明文化したか」のほうです。

全社で一人、横断責任者を決める——構造化と非構造化を分断しない

データオーナーとデータスチュワードを、データの種類ごとに置く。これがデータ管理の最小ユニットだとすると、その上にもう一段、全社を見る役割が要ります。
なぜなら、データの種類ごとに責任者を置くだけだと、ある重要な落とし穴に落ちるからです。

その落とし穴とは、構造化データと非構造化データの分断です。

連載第3回では、売上や顧客数といった構造化データの整え方を扱いました。
これは多くの場合、情シスやデータエンジニアが中心になって動かす世界です。
一方、第4回で扱った非構造化データ——契約書・議事録・提案書などの文書——は、各事業部や法務、ナレッジ運用の現場が日々触っている世界です。

このとき「構造化はITの仕事、非構造化は現場の仕事」と縦割りで進めると、AIに横断的にデータを渡したいときに、整合が取れなくなります。
たとえば、顧客の取引履歴(構造化)と、その顧客との議事録(非構造化)を一緒にAIに渡して「次のアクションを提案させる」ような使い方は、構造化と非構造化が共通のIDでつながり、共通のメタデータで管理されていないと成立しません。
第4回で見た「共通ID・メタデータカタログ・横断参照」の3レイヤーは、誰かが横断して見ていないと、機能しないのです。

ここで登場するのが、横断責任者という発想です。

大企業ではCDOが横断責任者の役割を担う

大企業では、しばしばCDO(Chief Data Officer、最高データ責任者)という役職を置きます。
データを経営の資産として捉え、データ戦略・データガバナンス・データ活用を全社横断で見渡す立場です。

米国のIT情報メディア大手TechTargetの定義では、CDOは経営層の役職として、データガバナンス・データ品質・データ戦略を含む幅広いデータマネジメント責任を負い、企業のデータから最大の価値を引き出す役割だと整理されています(出典: What is a Chief Data Officer? — TechTarget)。
米国の調査会社Forrester Researchも、新任CDOの最初の90日に焦点を当てたレポートを出しており、CDOがデータバリューチェーン全体に責任を持つ立場であることを論じています(出典: First 90 Days: Chief Data Officer — Forrester)。

Gartnerの2025年5月12日の発表は、もう一段先の景色を示しています。同社の調査によれば、CDAO(Chief Data and Analytics Officer)の70%が、組織のAI戦略・運用モデルの構築に主たる責任を負っているとされています(出典: Gartner Survey Finds 70% of CDAOs Are Responsible for AI Strategy — Gartner Newsroom)。

データの責任者と、AIの責任者を分けて置く時代ではなくなり、「データもAIも、同じ人が経営に対して説明責任を負う」方向に動いている、ということです。

横断責任者における最小の役割

横断責任者の仕事を最小化して述べれば、次の2つに尽きます。

第1に、データの種類ごとにオーナーを指名すること。
前章の表のような対応づけを、社内で「これでいきます」と確定させる仕事です。

第2に、四半期に一度、データの状態を経営会議に上げること。
整えた仕組みが今、どれだけ機能しているか、どこに歪みが出ているかを、経営の場で可視化する仕事です。

この2つだけでも、データ管理の責任は、宙に浮かなくなります。
次章で示す役割分担マトリクスは、「誰に何を任せるか」を考えるための道具にもなります。

連載の打ち手を、誰が担当するかで束ねる

ここまでで、データの種類ごとにオーナー・スチュワードを置き、全社で一人、横断責任者を立てる、という骨格を見てきました。

本章では、その骨格を、連載第3〜5回で扱った12個の打ち手に当てはめます。「データ統合」「セマンティックレイヤー」「ガードレール」と聞いたとき、いったい誰が決め、誰が動かし、何を外注できるのか。一覧表にまとめます。

表の見方は、共通です。

• オーナー(決める人)：その打ち手の方針・基準・利用範囲を最終判断する人。経営の意思決定として責任を負う立場。

• スチュワード(実行する人)：方針を日々運用に落とし、品質を維持し、現場からの問い合わせに答える人。

• 外部に委ねやすい範囲：ベンダーやパートナーに任せやすい技術運用・実装の領域。

同じ人が複数のオーナーを兼ねたり、スチュワードが横断したりして構いません。重要なのは、空欄が残らないこと。空欄が残ったら、そこが将来の劣化の起点になります。

この表から、規模や業種を問わず、いくつかの共通パターンが浮かびます。

第1に、「決める」のは、ほとんどが業務側の部門長です。
データの定義、利用可否、機密度の判断は、現場の業務文脈を知っている人にしか下せません。
情シスやデータ担当が勝手に決めるべきではなく、また外部のベンダーに委ねる類の判断でもありません。
「うちの顧客とは誰か」「うちの売上はいつ計上するのか」を、最終的に決められるのは、その業務を経営している部門長だけです。

第2に、「実行する」のは、情シス・経営企画・データ担当に集中します。
中堅・成長企業では、これらの中の誰か数名が業務時間の一部を割いて、複数のデータの面倒を見る、というのが現実的な姿です。
スチュワードを部門ごとに別途立てる必要はなく、横断的に動ける数名がいれば、十分回せます。

第3に、「外に委ねやすい範囲」は、思ったより広いことが見えてきます。
データ統合の実装、品質チェックの自動化、ガードレールの導入、リネージ基盤の構築——これらの大半は、信頼できるベンダーやパートナーに任せられます。
社内で技術運用の人材を抱え込まなくても、データ管理は回せます。
社内に残すべき仕事は、「決める」と「日々の状態を見る」の二つに絞られます。

運用ルール——最低限決めておきたい3つ

役割を明文化したら、次に決めるのは運用ルールです。
とはいえ、最初から分厚い規程集を作る必要はありません。
レビュー頻度・変更プロセス・異常時対応。この3つを最初に決めておいてください。

レビュー頻度——いつ集まって、何を確認するか

レビュー頻度とは、「データの状態を、定期的に見る場」を持つことです。
現実的なのは、おおむね次の2つのリズムです。

• 月次レビュー：変化の早いデータ(売上・顧客・受注)について、品質アラートの状況、欠損や表記ゆれの傾向、現場からの問い合わせの傾向を、スチュワードと関係部門オーナーで30分ほど見る。

• 四半期レビュー：データ定義の見直し、新規データ項目の追加・廃止、アクセス制御や分類ラベルの棚卸しを、横断責任者を含めて1時間ほど見る。

これだけで構いません。
月次は実務サイド中心、四半期は経営も含めた振り返り、と切り分けると、議題がぶつかりません。
ここで重要なのは、「いつやるか」を最初からカレンダーに固定することです。「困ったら集まろう」では、絶対に集まりません。

変更プロセス——定義や分類を変えるとき、誰の判断を仰ぐか

データの定義や分類は、固定ではありません。
事業が変われば、当然動きます。問題は、「動かしたい」と思ったときに、誰が決裁し、どこに記録するかが、決まっているかどうかです。

まず、誰が変更を申請できるか。
現場の誰でも上げられるのか、各部門のスチュワード経由なのか。

次に、誰が承認するか。
原則として、そのデータのオーナーが承認します。
横断的な指標(例:全社の売上定義)を動かす場合は、横断責任者の承認も要ります。

最後に、どこに記録するか。
NotionでもConfluenceでもよいので、「変更日」「変更内容」「承認者」「影響範囲」を一行ずつ残す台帳を、一箇所に決めておきます。

これだけあれば、半年後に「いつから売上の定義が変わったんだっけ？」と迷うことがなくなります。
AIが過去の数字を引いてくるときも、定義の変更履歴が見えていれば、誤読を防げます。

異常時対応——アラートが鳴ったとき、誰が何をするか

データの品質チェックや、AIのガードレール監視を仕掛けると、ある程度の頻度でアラートが鳴ります。
アラートが鳴ったとき、誰がそれを受け、誰が判断し、誰が直すか。
これが決まっていないと、アラートは無視され、やがてチェックの仕組み自体が意味をなさなくなります。

異常時対応で決めておくべきことは以下の4つです。

• 一次受け：スチュワード(情シス・データ担当のいずれか)が、平日業務時間内にアラートを確認する責任を持つ。

• 判断：影響の大きさ(誤った数字がAIから出ている期間・対象)を、スチュワードが見立てる。経営判断が要るレベルなら、データオーナーと横断責任者にエスカレーション。

• 対応：軽微な品質問題はスチュワードが直し、定義の修正が要るレベルはオーナーが決裁。深刻な誤りであれば、AIの利用を一時停止する判断を、横断責任者が下す。

• 記録：異常の内容、原因、対応、再発防止策を、変更プロセスと同じ台帳に追記する。

ここでも、重要なのは「決まっていること」のほうで、「立派なアラート管理ツール」ではありません。
誰が一次受けか、どこに記録するか、どの段階で経営に上がるか——これが社内で口頭ではなく文章で共有されていれば、運用は回り出します。

最後に、形骸化を防ぐ3つの実践

役割を決め、運用ルールを決めました。これで「整えた状態」を保つ骨格は揃いました。

とはいえ、ここからが本番です。骨格は、放っておくと、また形骸化に向かいます。
データガバナンスの形骸化を分析した解説では、「導入時にいくら綿密に設計しても、運用フェーズで仕組みを保つ工夫がなければ、すぐに形骸化する」と指摘されています(出典: なぜデータガバナンスは形骸化するのか — SE-Navi)。

本章では、形骸化を防ぐための3つの工夫を挙げます。

責任を「人」ではなく「役職」に紐づける

第1の工夫は、責任の紐づけ先を、人の固有名詞ではなく、役職(ロール)にすることです。

「データオーナーは佐藤さん」と書いてしまうと、佐藤さんが異動・退職した瞬間に、責任は宙に浮きます。
代わりに、「営業データのオーナーは営業部長」「顧客データのオーナーはCS部長」のように、ポジションに紐づけて書くと、人が変わっても役割は残ります。
新しく営業部長になった人は、引き継ぎの段階で「この役職には、データのオーナーシップがついてくる」と自然に理解できます。

地味な工夫ですが、これがないと、組織変更や人事異動のたびに、データ管理体制が揺らぎます。

チェックをツールに寄せる

第2の工夫は、品質チェックや異常検知を、できるだけ人手ではなくツールに寄せることです。
スチュワードの仕事は、すべてを目視で確認することではなく、「ツールが上げたアラートに対して、人として判断する」ことです。

代表的なツールには、次のようなものがあります。

• dbt tests：データ変換のパイプラインの中に、品質テストを書き込んでおく仕組み。「このカラムにNULLが入ったらNG」「この値の合計が前日比で20%以上ずれたらNG」といったルールを、コードとして残せます(出典: dbt tests — dbt Docs)。

• Great Expectations：「データはこうあるべき」という期待値(Expectation)を宣言的に書き、それに反するレコードを自動で検出する仕組みです(出典: Great Expectations 公式ドキュメント)。

• Soda：データ品質の監視を、データガバナンスのワークフローと結びつけて運用するための仕組み。スチュワードのチームが品質を継続的に見るための支援機能が充実しています(出典: Data Quality for Data Governance — Soda)。

• Monte Carlo：データの可観測性(Observability)を専門に扱うサービス。データに発生した異常を自動で検知し、影響範囲を可視化する機能を持ちます(出典: Data Quality Governance That Actually Works — Monte Carlo)。

これらはあくまで代表例で、自社の規模やクラウド環境に合わせて選べばよいものです。
重要なのは、「ツールが見るべきことは、ツールに見させる」という思想です。
スチュワードの貴重な時間は、ツールが上げてきた異常に対して、「これは本当に問題か」「誰に上げるか」を判断することに使われるべきで、毎日CSVを開いて目視で見ることに使われるべきではありません。

経営の場で、データの状態を可視化する

第3の工夫は、データの状態を、四半期に一度、経営会議に上げることです。

これは、横断責任者の仕事として前述しました。
仕組みとしては、四半期ごとに次の3スライドを経営会議に持ち込むだけで、形骸化は大きく抑えられます。

• 主要データの品質状況(月次レビューの結果サマリー)

• データ定義・分類の変更履歴(変更プロセスで蓄積した台帳)

• 異常時対応の件数と内容(異常時対応の記録)

経営会議の場でこれを見せる意味は、データ管理が「経営にとって見るべきもの」だと、組織として位置づけられることと、現場のスチュワード・オーナーに対して、「自分たちの仕事は、四半期に一度経営に上がる」という見られている感覚が生まれることです。

形骸化を防ぐ最大のコツは、「最初からカレンダーに入れる」

3つの工夫を並べましたが、すべてに通底するのは、「後からやろうとしない」ということです。
月次レビューも、四半期レビューも、経営会議への報告も、最初に組織図と一緒に「いつやるか」を決めてカレンダーに入れてください。

整えた直後は、現場のテンションが高く、放っておいてもみんな見ています。
問題は、3か月後、半年後、誰も見なくなる瞬間です。その瞬間に備えて、「とにかくカレンダーに入っている時間が来たら集まる」を仕込んでおくことが、形骸化への最大の備えになります。

まとめ——「誰が、何に責任を持つか」が明確になっていること

連載第6回として、整えた状態を保ち続ける組織のつくり方を見てきました。
要点を一行に圧縮すれば、次のようになります。

データ管理は、一度やって終わりではありません。必要なのは大規模な専任チームではなく、「誰が、何に責任を持つか」が明文化されていることです。

データの「正しさ」を決めるデータオーナーと、それを日々運用に落とすデータスチュワード。
この二つの役割を、自社のデータの種類ごとに割り当て、全社で一人、横断責任者を立てる。そのうえで、レビュー頻度・変更プロセス・異常時対応という最低限の運用ルールを、最初からカレンダーに入れる。
これだけで、整えた状態は、ぐっと長持ちします。

連載第3〜5回で示した12の打ち手は、それぞれに「決める人」と「実行する人」と「外に委ねやすい範囲」が割り振れます。
本記事の第4章の表は、その割り振りを連載全体で束ねるための一覧です。
自社で表を一度埋めてみて、空欄が残るなら、そこが将来の劣化の起点になる場所です。

整えた仕組みは、保つ人がいるかどうかで、半年後の景色が決まります。
仕組みを作る人ではなく、保つ人がいるか——これが、AIを「導入して終わり」にしないための、最後の問いになります。

次回(第7回・最終回)——AI-Readyな企業の姿

ここまで連載6回をかけて、AIで成果を出すために自社のデータを整える「打ち手」と、それを保ち続ける「組織」を、ひとつずつ見てきました。
次回は最終回として、これらが整った先にある景色を書きます。

データが整い、ガバナンスが効き、運用組織が回っている会社では、AIは何ができるようになるのか。
そこに至るために経営は何を続け、何を変えていくのか。

連載のまとめとして、AI-Readyな企業の姿と、データから示唆を引き出し、業務改善に回し続ける成長サイクルを描く回になります。

連載：なぜAIの話は、いつも「データ」の話になるのか

第1回：なぜAIの話がデータの話になるのか
第2回：AIで成果を出すためのデータ整理
第3回：AIが使えるデータ基盤の作り方
第4回：非構造化データをAIが使えるようになる方法
第5回：整ったデータを安心してAIに渡すための4つの打ち手
第6回：整えたデータを保ち続ける組織のつくり方
第7回：データとAIが生み出す企業の成長サイクル