Datavault Builder と DAMA-DMBOK フレームワーク — 11 の知識領域をどう支援するか

Datavault Builder の CEO 兼共同創業者である Petr Beles による考察

私が最も頻繁に受ける質問は次の 2 つです： 「Datavault Builder は実際に何を解決してくれるのか？」 「個別ツールを何個も継ぎ接ぎするよりも、なぜ Datavault Builder の方が完全なソリューションと言えるのか？」

この問いを投げかけてくるのは、多くの場合、BICC（ビジネスインテリジェンス・コンピテンシーセンター）の責任者やチーフデータアーキテクトです。彼らは、モデリングツール、ELT ツール、オーケストレーター、リネージツール、品質管理ツール、ドキュメントポータルなど、最大 9 つもの異なるベンダー、契約、バージョンアップ対応が入り乱れたアーキテクチャ図を前に頭を抱え、「データウェアハウスをもっとまともな方法で提供できないものか」と悩んでいるのです。

DAMA-DMBOK のホイール（Wheel）は、その価値を可視化するための最適なフレームワークです。 データマネジメントにおける 11 の知識領域を 1 枚の図に整理しているからです。自社のツールスタックをこのホイールの上にマッピングしてみると、どの領域がどの製品でカバーされ、どの領域に隙間や製品間の継ぎ目が存在しているかが一目瞭然になります。そこで本稿では、ホイールの領域を 1 つずつ順を追って見ていき、Datavault Builder が各領域で何を提供しているのかを具体的に解説します。

その前に、本稿の他のどの部分よりも重要な「前提」を 1 つ明確にしておきたいと思います。

DAMA-DMBOK はデータマネジメントのフレームワークであり、組織・プロセス・人の規律を定義したものです。 一方、Datavault Builder はそのフレームワークの特定領域を技術的に強力に支援するプラットフォームです。ホイール上のいくつかの領域 — 特に「データガバナンス」「データオーナーシップ」「スチュワードシップ」— は本質的に組織の規律であり、どんなソフトウェアツールであっても人間の代わりにそれを自動所有することはできません。プラットフォームができるのは、それらの規律を維持することを困難にしている「技術的摩擦」を取り除くことです。この境界線を明確にしておくことこそが、本稿を単なる機能アピールではなく、誠実な技術解説にするための鍵です。

これらの知識領域のうちいくつかは、Datavault Builder の「機能の 1 つ」ではありません。それらは当社が存在する「存在理由（レゾンデートル）」そのものです。 「データモデリング」「データ統合」、そして「データウェアハウス＆ BI」こそが、私たちが本プラットフォームをゼロから設計した中核領域です。かつて遅く、手作業が多く、エラーの温床だったこれらの領域を、自動化され、追跡可能で、高速なものに変革すること — それが私たちのミッションです。個別ツールの組み合わせよりも本プラットフォームが完全だと感じられる理由は、これらの中核 3 領域に加えてガバナンス、アーキテクチャ、メタデータが、6 つの異なる製品の連携ではなく「単一のモデルと単一の信頼できる情報源（SSOT）」を共有しているからです。ホイール上のその他の領域については、私たちはその規律に大きく貢献するか、専門のツールとクリーンに共存する立場をとっています。

この前提を踏まえ、11 の知識領域を順に見ていきましょう。

※DAMA-DMBOK は組織のデータマネジメント能力を定義したものであり、ソフトウェア製品そのものではありません。本稿におけるポジショニングは、Datavault Builder がそれらの能力に対してどこで技術的支援を提供しているかを示すものであり、テクノロジープラットフォームが組織のガバナンス、スチュワードシップ、役割分担、ビジネスプロセスを完全に代替することを意味するものではありません。

知識領域	主な課題	Datavault Builder による解決アプローチ
1. データガバナンス	独立した別予算プロジェクトとして扱われると形骸化する	• 開発プロセスそのものにガバナンス推進機能を内包 • 標準化されたメタデータ層 • 独立した別予算が不要
2. データアーキテクチャ	個別設計された乱立アーキテクチャが保守コストを増大させる	• 実証済みの標準化パターン • ポイント・ツー・ポイント配管の排除 • ドキュメントの全自動生成
3. データモデリング＆デザイン	ビジネスモデルと技術実装が時間の経過とともに乖離する	• ビジュアルなビジネスデータモデル • 単一の信頼できる情報源（SSOT） • バージョン管理された変更履歴
4. メタデータマネジメント	並行して保守されるメタデータ台帳が本番コードと乖離する	• メタデータの 1 回限りの入力・取得 • 列レベルの自動データリネージ • 監査証跡のオンデマンド抽出
5. データ統合＆相互運用性	新しいデータソースの追加が毎回手作業の個別開発になる	• モデルからのコード全自動生成 • 冪等性（Idempotent）と再実行可能性 • プラットフォーム間の高いポータビリティ
6. データウェアハウス＆ BI	不整合なデータが BI や AI の分析結果に対する信頼を損なう	• クレンジングと統合の一元化 • 完全な履歴保持 • BI と AI の双方を支える共通基盤
7. データセキュリティ	規制産業での認証基準と既存 IAM/SIEM との統合が必須	• ISO 27001:2022 認証 ＋ SOC 2 Type 2 適合 • Entra ID、Okta、Keycloak、AD による SSO • ソブリンクラウド／オンプレミス対応
8. データ品質	暗黙の修正が事実を葬り去り、根本原因の解決を妨げる	• Raw Vault による全生データの完全保存 • 不整合行をスチュワードへ自動ルーティング • モデル上で品質 KPI を可視化
9. マスターデータ＆参照データ	手作業でキュレーションされたマスターが現実から乖離して陳腐化する	• ハブと Same-As リンクによる統合 • 継続的な自動リコンサイル • 完全な変更履歴の保持
10. データストレージ＆オペレーション	ストレージやバックアップの車輪の再発明は無駄な二重投資になる	• 既存の商用・クラウド DB 上で動作 • ロード処理とリリースのオーケストレーション • 不要な並行運用層を作らない

1. データガバナンス

ガバナンスは第一に**「人・プロセス・組織の規律」**です。オーナーシップ、意思決定権、ポリシー、スチュワードシップの中に宿るものであり、これらはツールではなく組織自身が定めなければなりません。Datavault Builder はその組織的責務を肩代わりするものではありません。私たちが提供するのは、ガバナンスの中で自動化可能な技術領域を最も抵抗の少ない標準的な開発プロセスへと落とし込み、人間側の規律が「ドキュメントのないスパゲッティパイプライン」と戦うのではなく、堅牢な技術的土台の上で機能できるようにすることです。

Datavault Builder のガバナンス支援における最大の特徴は、ガバナンス推進機能が日々の開発・デリバリープロセスの中に直接組み込まれている点にあります。DWH が完成した後に、追加のコストをかけて外付けするものではありません。この違いこそが、私の経験上、多くの企業のガバナンスイニシアチブが静かに頓挫してしまう最大の原因です。ガバナンスが独立した別プロジェクトとして扱われると、個々のデータ利用部門からは「自分たちの利用価値に直接寄与しない余計なコスト」と見なされ、優先順位を下げられてしまうのです。

命名規則、Raw Vault の構造パターン、Business Vault の計算ルール、ロードロジックをメタデータ層で一元標準化し、ビジネス定義やオーナー情報をモデルのすぐ隣に記録することを「標準の作業手順」にすることで、ガバナンスは誰も争う必要のない、個別予算も不要な当たり前の習慣になります。実装とガバナンスが乖離することは原理的に起こり得ません。

2. データアーキテクチャ

確立されたベストプラクティスの上に構築された Datavault Builder は、データの調和、クレンジング、履歴保持、リネージ、データマート提供に至るデータ統合のための完全なアーキテクチャを標準装備しています。このアーキテクチャは数多くの本番環境で検証済みであるため、アーキテクチャ検討による遅延なしに、初日から価値提供を開始できます。自動化を通じて従来の手作業 DWH に伴っていた莫大なコストを削減し、私たちが長年の実プロジェクトで培った実証済みパターンを適用することで、アーキテクチャ上のリスクを完全に排除します。

このアプローチにより、かつて膨大な工数を要していた以下の作業が不要になります：

• アプリケーション間の個別インターフェースの設計・構築・保守が不要： プラットフォームが各ソースシステムの接続、ステージング、統合を一手に引き受けるため、ポイント・ツー・ポイントの手作業パイプラインを保守し続ける必要がありません。
• 手作業でのドキュメント作成と同期作業が不要： ドキュメントはモデル自身から全自動生成されるため、常に最新かつプロジェクト横断で一貫性が保たれます。手組み DWH で蓄積しがちな「ドキュメントの技術的負債」がそもそも発生しません。
• 新メンバーのオンボーディングが劇的に迅速かつ低コストに： すべてのプロジェクトが同一の標準化アーキテクチャとパターンに従うため、あるプロジェクトを学んだ開発者は、社内の他のすべての Datavault Builder プロジェクトに即座に貢献できます。

これら全体を支える核心的な設計思想は、履歴を保持するコア層（Raw Vault および Business Vault）と、柔軟で仮想化可能なプレゼンテーション層の間の**「関心事の分離（Separation of Concerns）」**です。コア層はあらゆる事実を永久に保持し、プレゼンテーション層は過去の履歴を書き換えることなく何度でも再構築・拡張できます。この分離こそが、将来の新しいレポート要件、新しい BI ツール、新たな規制対応に対しても、何ヶ月ものプロジェクトをやり直すことなく柔軟に対応できる強靭さをもたらします。

3. データモデリング＆デザイン

これは Datavault Builder がそのために作られた中核 3 領域の 1 つです。その中心にあるのは、視覚的に設計され、テーブル名やカラム名ではなく、ビジネスの現場で実際に使われている用語（顧客、商品、契約、取引）で表現された**「ビジネスデータモデル」**です。このモデルは、データエンジニアとビジネスユーザーの間の架け橋となります。エンジニアにとっては精密で曖昧さがないため迷わず実装でき、ビジネスユーザーにとっては SQL を読まなくても内容を直感的に検証できます。両者がまったく同じ成果物を囲んで対話できるようになり、多くのデータプロジェクトが直面するコミュニケーションの断絶を解消します。

このモデルは、本番環境にデプロイされる全成果物に対する「単一の信頼できる情報源（SSOT）」としても機能します。手作業で同期させなければならないような「論理モデル」と「物理コード」の二重管理は存在しません。モデルの変更はすべてバージョン管理され、ビジネス上の理由と紐づけられます。「なぜこの DWH はこのような構造になっているのか？」という疑問への答えは、すべてモデルの中にあります。これは、ビジネスの意図がアーキテクチャを決定する**「モデルファーストアプローチ」**です。

4. メタデータマネジメント

ここでの原則は極めてシンプルです：「メタデータは 1 度だけ入力・取得され、更新される」。モデル内で何かが変更されたとき — 新しい属性の追加、ソース名の変更、ビジネスルールの更新 — その変更は必要なすべての場所へ即座に反映されます。デプロイされるコード、リネージグラフ、ドキュメント、そして監査証跡です。手動で更新すべき並行メタデータカタログは存在せず、モデルとドキュメントの間で記述内容が食い違うリスクもありません。Datavault Builder は**「アクティブ・メタデータリポジトリ」**として機能し、ロード日時、実行履歴、適用ルールといった技術的・運用のメタデータは、DWH の稼働に伴って全自動で収集されます。

また、本プラットフォームはビジネス用語集（Business Glossary）との統合を標準でサポートしています。技術的なハブ、リンク、サテライトを用語集に定義されたビジネス用語（顧客、契約、商品等）と直接マッピングできるため、概念データアーキテクチャと物理データアーキテクチャの一致が構造的に維持されます。

ソースシステムから最終的なデータマートに至るまでの列レベル（カラムレベル）のエンドツーエンド・データリネージも、手作業で描くのではなく自動生成されます。「この数字はどこから来たのか？」という質問には、何日も調査することなく、グラフをひと目見るだけで即答できます。

すべてのメタデータが一貫した単一レイヤーに集約されているため、規制監査への対応は大規模プロジェクトではなく単なる「クエリの実行」で済みます。GDPR、BCBS 239、HIPAA、SOX、EU AI 法などの規制フレームワークは、データがどのように流れ、個人データがどこに保存され、誰がアクセスし、どのように処理されたかの客観的な証拠を要求します。Datavault Builder を使用すれば、特別な監査用エクスポートや土壇場でのリネージ復元作業を行うことなく、必要な証拠を即座に提示できます。

5. データ統合＆相互運用性

これは 2 つ目の中核領域です。ロード、データ変換、履歴管理といった統合コードは、データソースごとに手書きするのではなく、モデルから全自動生成されます。ロード処理は冪等（べきとう：Idempotent）かつ再実行可能に設計されており、**「不変の履歴（Immutable History）」**が保証されます。障害発生時やロジック修正後でも、データの二重計上や不整合を起こすことなく安全に再ロードでき、いつ何がロードされたかという監査証跡は完全に保たれます。新しいデータソースの追加は、長期間の手組み開発ではなく、単なる「モデリング作業」へと変わります。

統合レイヤーは、基盤となるデータベース（Snowflake、Databricks、BigQuery、SQL Server、Microsoft Fabric、Oracle、Exasol、PostgreSQL）に対して高度にポータブルであり、クラウド環境でもオンプレミス環境でも同様に快適に動作します。このポータビリティには 2 つの大きな意義があります。1 つはクラウドベンダーへのロックインを回避できること（DWH コードを書き直すことなくプラットフォーム間を移行したり、ハイブリッド運用が可能）。もう 1 つは、完全なデータ主権（Data Sovereignty）を常に維持できることです。将来、規制や地政学的要請が変化した場合でも、既存資産を捨て去ることなく、特定の国内、自社データセンター、あるいはソブリンクラウドへと柔軟にデータを配置できます。

6. データウェアハウス＆ BI

3 つ目の中核領域であり、ここで最も重要なのは「プラットフォームがどのようなデータを提供するのか」です。私たちは単に生データを右から左へ移動させているのではありません。ソースシステム間で調和され、ビジネスキーが突合され、履歴が保持され、定義が付与された、クレンジング・統合・コンテキスト化された高品質なデータを提供します。

これにより、単一のデータウェアハウスがまったく異なる 2 種類の利用者に対して等しく絶大な価値を発揮します。1 つは、整合性が保証された認定マートを参照する従来の BI・アナリティクスツール（Power BI、Tableau、Qlik、Looker 等）。もう 1 つは、信頼性の高い出力を得るためにまさにそのような整合性とコンテキストを必要とする AI・機械学習（ML）ワークロードです。履歴データはネイティブに保持されるため、「特定の日付時点で何が分かっていたか（As-Was）」という時点照会（PIT）は、特別な開発プロジェクトを組むことなく最初から標準機能として利用できます。

この基盤を支えているのが、**「明細を最初に保持し、集計は最後に行う」**という確固たる設計順序です。ソースデータは元の粒度のまま完全な履歴とともに Raw Vault に保存され、集計、ビジネスルール、データマートはその完全な事実データから導出されます。これにより、将来新しい分析要件が発生した場合でも、ソースシステムからデータを取り直すことなく、過去の全明細データに対して即座に新たなマートを構築できます。

7. データセキュリティ

Datavault Builder は ISO 27001:2022 認証を取得しており、SOC 2 Type 2 適合保証を受けています。そのため、プラットフォーム自体が、厳格な規制下にあるエンタープライズ企業が契約前に求めるセキュリティ要件と運用統制を完全に満たしています。

さらに、セキュリティチームがデータ環境を安全に運用するための技術的土台を提供します：ロール別・機密区分別の多層アクセス制御、データ移動とアクセスのエンドツーエンドの監査ログ、そしてデータの所在地・主権の要件（スイスおよび EU ホスティング、ソブリンクラウド、完全オンプレミス）への完全適合です。

認証機能は、お客様がすでに運用しているアイデンティティプロバイダー — Microsoft Entra ID（旧 Azure AD）、Okta、Keycloak、Active Directory、その他 SAML 2.0 / OIDC 準拠プロバイダー — とシームレスに統合され、既存のシングルサインオン（SSO）、多要素認証（MFA）、グループポリシーをそのまま継承できます。既存の IAM、鍵管理システム、SIEM と協調して機能します。

8. データ品質

Datavault Builder は、データ品質に対して極めて理にかなったアプローチを採用しています。まず最初に行うのは**「単一の事実の記録（Single Source of Facts）」の確立です。Raw Vault はソースシステムから受け取ったすべてのレコードを、到着したそのままの形で完全な履歴とともに保存します。いかなるデータも破棄されず、暗黙のうちに勝手に修正されることもありません。これは Data Vault コミュニティで「受動的データ品質（Passive Data Quality）」**と呼ばれるものであり、いかなるルールを適用する前であっても、アーキテクチャ自体が事実の完全性を保護します。

その完全な事実の記録に対して、下流の用途に適しているかどうかを判断するためのビジネスルールや品質ルールを適用します。その結果として実現するのが**「2 系統のデータフロー（Two-Track Flow）」**です：

• ルールをクリアした正常データ：レポート、データマート、AI ワークロードへと即座に公開。
• ルールに適合しなかった異常データ：担当する役割（通常はデータスチュワード）へと自動ルーティング。違反したルール、元のソースレコード、修正に必要な文脈情報がセットで通知されます。

いかなるデータも行方不明にならず、正常なデータの配信をブロックすることもなく、実際に問題を修正できる権限を持つ現場の担当者が即座に不整合を把握できます。異常データをソースの所有者であるスチュワードへフィードバックするこの仕組みこそが、下流での対症療法ではなく**「根本原因の解消」**を実現する鍵です。

品質 KPI（完全性、正確性、適時性、一貫性）は、データを保持する同一モデル上で測定・可視化されます。

9. マスターデータ＆参照データ

Datavault Builder はマスターデータ管理（MDM）専用システムではなく、私たちがそうであると主張することもありません。しかし私たちが提供しているのは、多くの組織が見落としがちな極めて強力な基盤です。それは**「中核エンティティに対する統合ビュー」**です。

ハブ、ビジネスキー、および Same-As リンクは Data Vault のネイティブな概念であり、これらは複数のソースシステムにまたがる同一の顧客、商品、従業員、口座を識別し、それらのビューを 1 つにまとめるためにまさに必要なモデリング規律です。

実務において、このように継続的に照合・統合されたビューは、多くの企業が抱えるマスターデータ要件の大部分を満たします。手作業で作成されたマスター台帳は特定時点のスナップショットに過ぎず、現実の変化から取り残されがちです。一方、Datavault Builder の統合ビューは実際のソースシステムから継続的にリコンサイルされ、すべての変更履歴が完全に保存されます。顧客の住所変更、商品の再分類、契約条件の改定など、時間に伴うあらゆる変化が、日付、ソース、過去の状態とともに透明に追跡可能です。

国コードや通貨などの参照データセットもバージョン管理され、ウェアハウス全体で共有されます。スチュワードシップの高度なワークフロー、サバイバーシップルール（名寄せの優先ルール）、ゴールデンレコードの厳格な統制が必要な場合は、専用の MDM ソリューションを導入するのが適切であり、Datavault Builder はそれらのツールと美しく連携します。しかし多くの場合、本プラットフォームが提供する統合ビューだけで十分な成果が得られます。

10. データストレージ＆オペレーション

ストレージレイヤーに関しては、お客様がすでに運用している既存のデータベースエンジンを活用します。Datavault Builder は以下をサポートしています：

• Snowflake
• Databricks
• Google BigQuery
• Microsoft SQL Server
• Microsoft Azure SQL
• Microsoft Azure Synapse
• Microsoft Fabric
• Oracle
• Exasol
• PostgreSQL

Datavault Builder は、選択されたプラットフォームの上で、ロード処理のオーケストレーション、データベースオブジェクトの自動生成、リリースのライフサイクル管理を実行します。ストレージ、クエリパフォーマンス、自動スケーリング、バックアップ、キャパシティ管理、ディザスタリカバリといった運用上の課題は、これらのデータベースプラットフォーム自身が最も得意とする領域です。私たちがそれらを車輪の再発明として二重に作り直す理由はありません。

11. ドキュメント＆コンテンツマネジメント

私たちはこの領域を対象外としています。契約書、メール、画像、スキャン PDF などのコンテンツ管理は、専用のエンタープライズコンテンツ管理（ECM）システムが担当すべきです。私たちが提供するのは、それらのシステムが効果的に機能するために必要な「統合データとメタデータ」です。一貫したビジネスキー、統制された参照データ、リネージ、ビジネス定義を提供することで、コンテンツ管理システム内の契約書や請求書 PDF を、ウェアハウス内の正しい顧客、商品、取引データと確実に紐づけることができます。

データマネジメント規律の今後の展望

最後に、データマネジメントという規律自体がどこへ向かっているのかについて触れておきます。次期 DMBOK 改訂に向けて浮上している主要テーマ — データプロダクト、アクティブ・メタデータ、AI ガバナンス、ビジネスオーナーシップの強化 — は、すべて前述した共通の基盤の上に成り立っています。すなわち、「信頼できるメタデータ」「自動化されたデータリネージ」「ビジネス部門が読める共通モデル」です。

これらの基盤をすでに確立している組織にとって、新たな手法の導入は、これまでの取り組みの自然な延長線上のステップとなります。ゼロから新たな巨額プロジェクトを立ち上げる必要は一切ありません。

自社のデータ基盤がどの位置にあるか確認してみませんか？

私が新しいお客様と対話する際、最も有意義なディスカッションは、常に次の質問から始まります： 「現在、最も手作業の負荷がかかっているのはどの領域ですか？ そして、どこを最も迅速に効率化したいですか？」

私たちは、短い DAMA-DMBOK 自己診断ツールをご用意しました。各カテゴリ 3 問、1〜5 の選択式で回答することで、領域別のスコアと、一般的な Datavault Builder 導入企業のベンチマークと比較したレーダーチャートが即座に出力されます。また、現在各領域でいくつの個別ツールを併用しているかも把握でき、多くのチームがそのツールの多さに驚かれます。