2026年、当社のデータマネジメントについて「技術負債」と「理解負債」の観点であらためて考えてみる

本記事の内容は筆者個人の見解であり、当社の公式な見解を示すものではありません。

自己紹介
本記事について
Snowflakeを採用した背景
当社のデータ基盤
評価の前に
データマネジメントの評価
- 評価の観点
- 評価の内容
余談
さいごに
参考文献

自己紹介

こんにちは。三井住友カードでデータマネジメントを担当している小林です。現在はマーケティング本部に所属していますが、もともとはIT部門（いわゆるJTCの情シス）に10年以上在籍していました。いまはプロジェクトマネージャーみたいなことをやらせてもらっています。

いま取り組んでいることは、自社契約のAWSテナントにSnowflakeの環境がもうすぐできるので、まずはユーザのオンボーディングを中心に推進しています。将来的にはデータ基盤全体のアーキテクチャをどうするか議論しながら、既存のデータ基盤（情報系）をマイグレーションすることを目指しています。

本記事について

想定読者
- ビジネスユーザが現場で実践しているデータマネジメントに興味がある方
- DMBOK（Data Management Body of Knowledge）という言葉を聞いたことがある方

書くこと
- Snowflakeを採用した背景
- 当社のデータマネジメントの取組みをDMBOKの観点で評価
書かないこと
- DMBOK、DAMAホイール図などの内容やデータマネジメントそのものの話
- データエンジニアリング、インフラエンジニアリングに関する技術的な話

Snowflakeを採用した背景

当社で最初にSnowflakeを導入したのは2023年で、TポイントとVポイントの統合プロジェクトの中で、CCCMKホールディングス（4月からVポイントマーケティングに社名変更）とポイントデータを連携する目的で環境を構築しています。 www.smbc-card.com

そんな中、近年のキャッシュレスの進展などによりデータ基盤で取り扱う決済データが増加し、予測系AI向けのデータプレパレーション、マクロの消費動向レポーティングなどユースケースが拡大するなか、「処理パフォーマンスが悪い」「最新のデータスタックを活用できない」「独自のプログラミング言語が主流で人材の確保が困難」などといった課題が顕在化し、自然とSnowflakeを全社データ基盤として採用する案が浮上してきました。

ただ、他社契約のテナントに構築した関係で、ロール/スキーマ設定、DevOpsなどを当社側でコントロールするには制約が多く、全社データ基盤として採用するには難しいと判断し、新たにSnowflakeの環境を構築することにしました。

当社のデータ基盤

本記事では、基本的にデータマネジメントの対象とするデータ基盤はSnowflakeとしますが、データパイプラインやデータアーキテクチャの観点もあるので、データソースの基幹系、情報系、Snowflakeの接続しているSaaSなども俯瞰しながら評価することにします。

評価の前に

DMBOKの話は書かないとしましたが、少しだけします。よく拝見させていただいているよしむらさんの記事に、DMBOKのデータマネジメント成熟度アセスメントをされた話があります。 note.com

詳細は割愛しますが、以下のようにおっしゃっていて、当社もだいたい「このような会社」なので、レベル2～3に該当するかと思います。

DMBOKのアセスメントレベル

レベル0．能力が欠如した状態

レベル1．初期/場当たり的な状態：成功は個人の能力に依存している

レベル2．反復可能な状態：プロセスに最低限の統制が行われている

レベル3．定義された状態：基準が設定され守られている

レベル4．管理された状態：プロセスが数値化され統制されている

レベル5．最適化された状態：プロセス改善のゴールが数値化されている

このような会社であれば、２～３の評価となります。

各業務システムからデータ分析用のシステムにデータ連携されていて、社員が使えるような状態になっている

テーブル定義書、コード定義書が公開されていて、システム的なメタデータがわかる

システム部門がデータ環境を管理しているが、会社としてのデータ戦略は存在しない

データ環境を使って各々の部門が活用しているが、全社として組織的に使えているかと言えばそうではない

各々の部門がいい感じに統制しているが、全社としてデータを資産として管理しているわけではない

なんとなく当社の状態がわかりました。しかしながら、ここからレベルを上げるには具体的にどうしたらいいのかとか、そもそもレベルをあげてどうよくなるのかとかがDMBOKを読んでもよく分からなかったので、今回Snowflakeを導入するタイミングで一度現場の観点で独自に評価してみようと思い至りました。

データマネジメントの評価

当社のデータマネジメントについて、最近Claude CodeなどのAIコーディングツールが普及する中で注目されている「技術負債」「理解負債」の観点で独自に評価してみました。

技術負債
- システム構成、データ基盤、データベースなどが、「後で修正が必要だとわかっていながら、スピードやコストを優先して選択した不完全な状態」のこと
理解負債
- データ基盤の利用者、管理者が、「コードの内容や書き方、テーブルやカラムの意味、システムの機能などを正しく説明できない状態」のこと

評価の観点

	理解負債：Low(セルフサービス)	理解負債：Mid(属人化)	理解負債：High(人材不足)
技術負債：Low	★★★ ベストプラクティスを実践できている状態	★★ ベストプラクティスを実践できていないが、検討できている状態	★★ ベストプラクティスを検討できない状態。いわゆる宝の持ち腐れ
技術負債：Mid	★★ レガシーな要素はあるが、運用でカバーできている状態	★★ レガシーな要素があり、改善に着手したほうがいい状態	★ 現場で混乱・ミスが発生しており、はやく改善したほうがいい危険な状態
技術負債：High	★★ エンハンスが難しく運用負荷も高い	★ エンハンスが難しく運用負荷も高い。はやく改善したほうがいい危険な状態	★ もはや改善することが難しい状態

評価の内容

各知識領域ごとの評価は以下の通りです。

知識領域	概要	対象	取組み	評価	技術負債	理解負債
データガバナンスとスチュワード制	データに関する意思決定権限・説明責任・方針策定を定義し、データ所有者・スチュワードの役割を明確化	ー	スキーマ、テーブル単位でデータオーナーやデータスチュワードが定められているわけではなく、リスク管理の観点で、データ基盤毎に業務所管・システム所管を定めている。後述するデータモデルの見直しに取り組む際に、DWH/Martの範囲でデータプロダクトオーナーを配置することを検討している	★★	-	Mid
データアーキテクチャ	エンタープライズ全体のデータ構造・フロー・システム間関係を設計	基幹系情報系 Snowflake SaaS等	Snowflakeへのマイグレーションを目指しているが、アーキテクチャとして完成系と考えているわけではなく、継続的にベストプラクティスを検討している状況。とはいえ、後述するデータ統合の課題があるため、現状のアーキテクチャを前提にできることから進めていく方針	★★	-	Mid
データモデリングとデザイン	ビジネス要件を論理的・物理的なデータ構造（エンティティ・リレーション）として定義	Snowflake	約500名へのユーザの実態調査から、10テーブル以上を参照する複雑なクエリがざらにあることが判明している。Snowflakeが推奨するJoin数（スタースキーマで2~5）と比較すると、データモデルを見直す余地があると思われる。実際ユーザからコード品質の問題が指摘されており、原因の一部と考えられる。またDWH/共通Martを要望する声も上がっている	★	Mid	High
データストレージとオペレーション	データベースの物理的な格納・運用・保守・バックアップ・リカバリを管理する領域	Snowflake	Snowflakeの機能を活用することで、オートスケーリング、タイムトラベル等による運用負荷の軽減、処理パフォーマンスの改善が見込まれる。コストについては、既存データ基盤のワークロードベースでざっくり試算すると5分の1以下になる見込み	★★★	Low	Low
データセキュリティ	アクセス制御・暗号化・プライバシー保護・コンプライアンス対応を実現	Snowflake	アクセス制御は、全ユーザが参照できるスキーマ、特定のユーザグループが参照・更新できるデータセットなどのビジネス要件を極力シンプルになるように整理し、RBAC/スキーマの設計はひととおり終えている。いまはSnowflakeで取り扱っていない機密情報についても、動的にマスキングする機能等を採用し、安全に管理するための運用ルールを策定する予定	★★	Low	Mid
データ統合と相互運用性	異なるシステム間でのデータ移動・変換・統合を管理	基幹系情報系 Snowflake SaaS等	基幹系からSnowflakeまでのデータパイプラインが複数の情報系システムを経由する「リレー方式」の状態になっており、実際ユーザからデータ鮮度の改善要望が出ている。基幹系で行っている加工・集計処理を情報系側へ順次オフロードしているが、まだ道半ば。最終的にはSnowflake側で加工する方針（いわゆるETLからELTへの転換）は立てているが、実行計画は策定できていない状況	★	High	Mid
ドキュメントとコンテンツ管理	ー	-	（今回は対象外）	ー
参照データとマスターデータ	ー	-	（今回は対象外）	ー
DWHとビジネスインテリジェンス	分析・意思決定のためのデータ環境整備、レポーティング・ダッシュボード基盤を提供	情報系Snowflake	既存の情報系で約100のBIダッシュボードが常時稼働しており、データアナリストが分析支援する体制になっている。DWH基盤をSnowflakeに移行する論点、前述のデータモデリングの課題、生成AIの台頭によりBIそのものの位置づけをどうするかの論点などはあるが、本知識領域の対象外として評価する。	★★★	Low	Low
メタデータ管理	データの定義・所在・リネージ（系譜）など「データを説明するデータ」を管理	基幹系情報系 Snowflake SaaS等	Snowflakeの構築に合わせて、約800のテーブル、カラム、リネージ、スキーマ等を記載したドキュメントを作成中。SaaSのデータカタログプロダクトは比較評価まで実施済だが、Snowflakeの開発、運用がある程度軌道に乗るまで、まずはSnowsightから最低限のビジネスメタデータをタグ付けすることからスタート	★★	Mid	Mid
データ品質	データの正確性・完全性・一貫性・適時性を測定・監視・改善	Snowflake	いろんな評価軸はあるが、いったんデータソースが正確である前提で、Snowflakeと一致しているか、論理的な妥当性があるか、「一貫性」の観点でSnowflakeのモニタリング機能を用いて測定・監視するところから始める予定。またquery_historyなどからクエリ内のテーブルやカラムを測定・監視するダッシュボードを作成し、コード品質の改善やデータモデルの検討に活用することを検討している	★★	Low	Mid

あくまでも現場の観点で、難題ではあるけどすぐに取り組んだほうがいいもの、DMBOKの基準からすると不十分かもしれないけど急いで考えなくてもいいもの、ユーザから直接要望が出ているもの、Snowflakeで新たにできるようになったことを少しずつ取り入れたいもの、みたいな感じで独自に評価しています。

逆にデータマネジメントの世界でよく言われる、エンタープライズアーキテクチャを策定しようとか、データマネジメントオフィスを設置しようとか、トップダウンのアプローチで取り組むようなことはいまのところ採用していないので、そういったことをできていないからといって評価を下げることはしていません。

★1としているデータの鮮度を落としているリレー方式のデータパイプライン(データ統合)は技術負債が積み上がった典型例ですし、データモデリングの領域で取り上げたコード品質の問題は技術負債が生み出した理解負債に相当すると考えます。データマネジメントの活動は、ある意味こういった負債を取り除いたり、積み上がらないようにすることなのかもしれません。

あと、Snowlflakeをメインにしているので、これから取り組むことがほとんどにはなりますが、ざっくり知識領域の関連をまとめると、以下の通りになりました。

余談

データマネジメントの取り組みについてあらためて考えてみると、こちらもよしむらさんの記事ですが、何年か前に読んだときのことを思い出しました。 note.com

こちらの記事では、企業がデータ利活用をはじめるとき、データアナリスト、データサイエンティストが「①データ分析」に力を入れる。ビジネスの成果が出ると、データを利用できる基盤がないことが課題になり、データエンジニアが活躍して「②データ基盤」が整えられる。次に「③データ整備」といったデータマネジメントに起因する課題に取り組むため、データマネージャーが対応する、といった話をされています。

当社が6~7年前にデータビジネスを始めたときも、データアナリスト、データサイエンティストと名乗る人が「分析」をはじめて、そのうちプロジェクトの増加に伴い、データ処理のパフォーマンスが求められて新たな「基盤」を導入して、そのうち分析をするためのデータセットを「整備」して、みたいなことに取り組んできたので、記事を読んだときは、まさに当社のことを書いていると思って、ちょっと衝撃をうけた記憶があります。

今回の評価と照らし合わせると、「①データ分析（DWH/BI）」や「②データ基盤（データストレージ）」が★3に対して、「③データ整備（データモデリング、データ統合）」が★1と相対的に低くなっているのは、ビジネスのアウトプットや生産力に直結する①②を結果的に優先して取り組んでいて、③が後回しになっていることが如実に表れているといえます。データマネジメントの担当としては、取り組むべき課題はしっかり主張して対応していきたいと思います。