Data Management

このポストについて 書籍『クラウドFinOps 第2版』を読んだところ、FinOps にデータマネジメントやデータエンジニアリングに深く関連する内容があるということがわかったのでまとめてみる。 書籍について J.R. Storment; Mike Fulle. クラウドFinOps 第2版 協調的でリアルタイムなクラウド価値の意思決定 O’Reilly Japan. 2025年3月に出版。 ちなみに原著の初版は2019年、第2版は2023年。 タイトルのとおり FinOps (後述) について書かれた書籍となっている。 著者は両名とも FinOps Foundation の関係者であり、本文中にも随所に FinOps Foundation についての記載が出てくる。 私はデータエンジニア、ソフトウェアエンジニアとして日々 AWS その他のクラウドサービスを利用している。 クラウドサービス上に例えばデータ基盤等を構築し、ビジネス上の価値を提供している。 その一方でクラウドを使うということは料金的な意味でのコストがかかるということでもある。 もちろん支払うコストは少ない方がいい。 それは分かるのだが、それ以上のクラウドコストについての体系的な考え方を持ち合わせていなかった。 毎日それなりの額を使ってるのにね。 というのが本書を読もうと思った理由だった。 FinOps とは 定義 これを書いている2025年8月現在における FinOps Foundation での定義は以下のようになっている。1 “FinOps is an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.” ...

このポストについて ​ DMBOK2 を読み進めていくシリーズ。 今回は第13章「データ品質」について。 これまで業務で「データ品質」という言葉が使われることがあったが、意味が限定的だったり人によって定義が違ったりしていた。 そのあたりクリアにできるとよい。 ​ 内容紹介 ​ データ品質の定義 ​ データ品質の簡潔な定義は「目的に適合している」。 データ品質管理の定義は「データを収集し扱うための技法を適用し、企業や地域のデータ利用者の、ニーズや利用に適したデータとすることを保証する活動を計画し、実施し、管理する」。 ​ データ基盤担当の仕事柄、データ品質というとどちらかというと上流であるデータソース側の定義が重要だと思っていたが、そうではなく下流であるデータ利用においての観点が起点になるというのが気づきだった。(でも考えてみれば当たり前) ​ ビジネス上の意義 ​ ステークホルダーの体験と組織の評判を高める ex. データが正しいことを顧客が信頼し、組織との取引に自信を持てる 組織がより有効な成果を出せるようにする ex. ビジネスチャンスの特定と効果的な請求により売上を獲得できる 低品質なデータによるリスクとコストを削減する ex. データが正しいかどうかをスタッフが見極める時間が減る ex. 誤ったデータによる誤った意思決定 組織の効率と生産性を向上する ex. カスタマーサービスにかかってくる電話が減り、問い合わせを解決できるようになる ​ 重要なデータ ​ データ品質管理における第一の原則は、組織とその顧客にとって最も重要なデータに改善努力を集中させること。 ​ ex. 顧客のメールアドレス欄のデータが不完全であれば、顧客にメールで商品情報を送ることができず、潜在的な売上を失う 1通のメールを送るごとに100円の収益が得られることが知られている → データ品質の改善に明確な価値があると言える ​ 重要なデータは組織や業界によって異なるが、以下のような用途で使用されることが多い。 ​ 規制、財務、経営報告 事業運営上のニーズ 製品の品質と顧客満足度の測定 事業戦略、特に競争上の差別化への取り組み ​ データ品質評価軸 ​ データ品質評価軸は、測定可能なデータの特徴または特性。 一般的な評価軸は次のとおり。 ​ No. 評価軸 説明 例 1 有効性Validity データの値が定義された領域の値と一致しているかどうか。 - 数値、日付などのデータ範囲- 電話番号などの書式 2 完全性Completeness 必要なデータがすべて存在するかどうか。カラム, レコード, データセットのレベルがある。 - カラム: 必須カラムにデータが入っているか？- データセット: 都道府県マスタに47都道府県の情報はあるか？ 3 一貫性Consistency データ値が同じアプローチ、評価、価値基準を用いてコード化されていることを保証すること。レコード内、レコード間、経時的な一貫性などがある。 - すべての顧客企業の住所は本社住所となっているか？- 生徒の成績評価は時を経ても同じか？ 4 整合性Integrity データに非一貫性や破綻した関係性がないこと。 - 顧客住所の国がカナダの場合、州としてカナダの州が記載されているか？ 5 適時性Timeliness データの取得または更新後、ユーザーがデータにアクセスできるようになるまでの時間を指す。 - 電力会社は電力需要データを数秒以内に利用して需給調整する必要がある- 政府機関が四半期末の2ヶ月後に GDP 報告書を作成 6 最新性Currency データが最後に更新されてから現在までの期間と、それがまだ正しいという可能性。データセットによって期待される最新性は異なる。 - 国コードは比較的静的- 銀行口座残高は変動的 7 妥当性Reasonableness データパターンが期待に合致しているかどうか。 - 先週のクリック数と比較して今日のクリック数は普通か否か？ 8 一意性/重複排除Uniqueness/Deduplication 現実世界の実体がデータセット内に2つ以上存在しないこと。 - ユーザー ID は重複していないか？- ユーザー ID は異なるが、同一の人物を表していないか？ 9 正確性Accuracy データが「現実の」実体を正しく表している程度。 - ユーザー名は現実世界の個人の名前なのか？- 顧客は実際にそのメールアドレスを使用しているのか？ ​ ここでようやく「データ品質」が具体的なものとして見えてきた。 測定が比較的容易なものもあれば困難なものもある。 ​ ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第8章「データ統合と相互運用性」について。 業務で扱っているデータ基盤はデータ統合が不完全であるため、なんとかしたいと考えている。 以降、特に注釈のない引用は DMBOK2 第8章からの引用とする。 データストレージと相互運用性とは データ統合と相互運用性 (DII: Data Integration and Interoperability) は次のように定義されている。 アプリケーションや組織内および相互間におけるデータの移動と統合を管理する データの移動を効率的に管理することがそのビジネス上の意義となる。 ほとんどの組織には数多くのデータストアがあり、組織内・組織間でデータを移動させることは IT 組織の重要な任務となっている。 複雑さとそれに伴うコストを管理するために、全社的な視点からデータ統合を設計しなければならない。 データウェアハウスなどのデータハブによりアプリケーション間のインターフェースの数を削減することができる。 DII のゴールは以下 法令を遵守しながら、必要とするフォーマットと時間枠でデータを安全に提供する。 共有のモデルとインターフェースを開発することでソリューションを管理するコストと複雑さを軽減する。 重要なイベントを特定し、アラートとアクションを自動的に起動する。 ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする。 概念・用語など 抽出、変換、取込 DII の中心にあるのが、抽出 (Extract)、変換 (Transform)、取込 (Load) のいわゆる ETL という基本プロセス。 抽出 ソースから必要なデータを選択し、抽出する 抽出されたデータはディスク上やメモリ上にステージングされる 業務システムで実行される場合は、少ないリソースを利用するように設計する 変換 ソースデータを変換してターゲットデータストアの構造と互換性を持つようにする フォーマット変更、構造の変更、意味的変換、重複排除、並べ替えなどがある 取込 ターゲットシステムに物理的に格納されるか、提供される ELT ターゲットシステムにより多くの変化機能がある場合は、プロセスの順序を ELT にすることができる データレイクへの取込を行うビッグデータ環境では一般的 レイテンシ ソースシステムでデータが生成されてから、ターゲットシステムでそのデータが利用可能になるまでの時間差。 アプローチによってレイテンシの高低が異なる。 バッチ 利用者や自動的な要求に応えて、定期的にアプリケーションや組織間を一定量まとまって移動させる レイテンシは高いが大量データを処理するときのパフォーマンスがいい 低レイテンシを実現するためのマイクロバッチもある 変更データキャプチャ データの変更 (挿入・変更・削除) のデータセットを監視し、その差分をターゲットのシステムに渡す DBMS のアクティビティログをコピーし、処理する形で行われることもある 準リアルタイムとイベント駆動 設定された予定により1日を通して分割された少量のデータセットで処理されたり、データ更新などのイベントが発生したときに処理されたりする 一般的にエンタープライズ・サービス・バスを利用して実装される 非同期 データ提供側は受信側の更新確認を待たずに処理を続行する リアルタイム、同期 次のトランザクションを実行する前に、他のアプリケーションからの確認を受け取るまで実行プロセスが待機する 非同期と比べて状態管理の負担が少ないが、他のトランザクションをブロックしたり遅延させたりすることもある 低レイテンシまたはストリーミング イベントが発生したときにシステムからリアルタイムで連続して流れる リプリケーション 分析やクエリによるパフォーマンス低下を防ぐために、トランザクション処理環境にリプリケーション (複製) を使用することがある。 多くの DBMS にはリプリケーションを作るためのユーティリティ機能がある。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データストレージとオペレーション」について。 主にデータベースの運用に関する内容となっており、いわゆるデータベースエンジニアの人には当たり前の話？が書かれている。 以降、特に注釈のない引用は DMBOK2 第6章からの引用とする。 データストレージとオペレーションとは 以下のように定義されている。 データの価値を最大化するために、永続化されるデータを設計し、実装し、サポートすること 主にデータベース管理者 (DBA: Database Administrators) が行うことになる。 次の2つのアクティビティが含まれる。 データベースサポート: データベース環境の初期実装からデータの取得、バックアップ、廃棄までのデータライフサイクル関連アクティビティ データベース技術サポート: 技術要件を決め、技術的なアーキテクチャを定義し、技術を実装・管理する 事業がデータに依存する企業においてはデータストレージとオペレーションのアクティビティは事業の継続性のために必要不可欠である。 ゴールは次のとおり データライフサイクル全体にわたるデータの可用性を管理する データ資産の完全性を保証する データ処理の性能を管理する 概念・用語など データベースアーキテクチャの種類 集中型データベース: 単一システム内で使うデータを一箇所にまとている 分散型データベース: 多数のノードにデータが配置される 連邦型データベース: 自立した複数のデータベースシステムを単一の連邦型データベースに割り当てる 仮想化／クラウドプラットフォーム: クラウド上のデータベースを実装 データベース処理のタイプ ACID: トランザクションの信頼性のための制約 原子性 (Atomicity): 操作はすべて実行されるかまったく実行されないかのどちらか 一貫性 (Consistency): トランザクションはシステムが定義するすべてのルールを常に満たさなければならない 独立性 (Isolation): 各トランザクションは実行中の他のトランザクションの影響を受けない 永続性 (Durability): トランザクションは完了すると元に戻せない BASE: データの量と多様性を受けた、ACID とは異なる考え 基本的に利用可能 (Basically Available): ノードの障害発生時もあるレベル以上の可用性を保証する ソフトステート (Soft State): データは一定の変動状態にある 最終的な一貫性の確保 (Eventual Consistency): データは最終的にすべてのノードで一貫性を保つが、各トランザクションの一貫性が常に確保されているわけではない CAP: 分散システムでは以下のどれか2つしか満たせない 一貫性 (Consistency): システムは常に想定どおり動作できなければならない 可用性 (Availability): システムは要求時に利用可能でなければならに 分断耐性 (Partition Tolerance): システムは部分的な障害の発生時に運用を続行できなければならない データベース構成 上から順により制御された構造であり、かつ古くからあるものとなっている。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第5章「データモデリングとデザイン」について。 第4章でデータモデリングについて言及されていたが、ここで詳しく見ていく。 以降、特に注釈のない引用は DMBOK2 第5章からの引用とする。 データモデリングとは データモデリングとは、データ要件を洗い出し、分析し、取扱スコープを決めるプロセスであり、データ要件を記述し伝えるために、明確に定義されたデータモデルと呼ばれる様式が用いられる。このプロセスは反復的であり、概念、論理、物理モデルが含まれる。 第4章 データアーキテクチャ ではエンタープライズ・データモデルという言葉が登場したが、この第5章ではそのデータモデルがより具体的に解説されている。 データモデルは効果的なデータマネジメントを行うにあたり必要なものとされている。 次のような意義がある。 データに関する共通語彙を提供する 組織のデータや情報システムに関しての明示的な知識を捉え文書化する プロジェクトにおいて主なコミュニケーションツールとして使われる アプリケーションをカスタマイズ、統合、リプレースする際の出発点となる データモデルは組織が把握した現状、またはあるべき姿として組織のデータを記述する。 カテゴリー情報、リソース情報、業務イベント情報、詳細取引情報がその対象となる。 データモデルの構成要素 ほとんどのデータモデルはエンティティ、リレーションシップ、属性、ドメインにより構成される。 エンティティ エンティティとはある組織が情報を収集する対象のこと。 組織が使う名詞。 以下は Marmaid の Entity Relationship Diagrams でエンティティを表現した例。 学校を例にしており、学生、コース、インストラクタがエンティティとして表されている。 --- title: Entity --- erDiagram Student Course Instructor リレーションシップ リレーションシップはエンティティ間の関連性を表す。 以下の例は学生はコースを “履修する”、インストラクタはコースを “教える” ことを表している。 --- title: Relationship --- erDiagram Student }|--|{ Course : take Instructor }|--|{ Course : teach 線の両端の形はリレーションシップの cardinality (多重度) を表している。 この場合ではそれぞれカラスの足状になっているが、それぞれ「1またはそれ以上」という意味で、「学生は1つ以上のコースを履修する」「コースは1人以上の学生に履修される」ということを表している。 リレーションシップの arity (項数) は一般的には二項型 (バイナリリレーションシップ) であることが多く、2つのエンティティ間の関係を表す。 一方で線の両端が同じエンティティにつながっている単項型、3のエンティティが関連する三項型もある。 以下は単項型の例で、前提となるコースの履修が必要であることを示す。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第4章「データアーキテクチャ」について。 やや抽象度が高い内容となっており、理解が難しいと感じた。 以降、特に注釈のない引用は DMBOK2 第4章からの引用とする。 データアーキテクチャとは データアーキテクチャの定義は以下のとおり。 企業の (組織構造に関係なく) データニーズを明確にし、ニーズに合うマスターとなる青写真を設計し、維持する。マスターとなる青写真を使ってデータ統合を手引し、データ資産をコントロールし、ビジネス戦略に合わせてデータへの投資を行う。 業務戦略と技術実装の間を橋渡しすることがデータアーキテクチャの目的。 以下が成果物、つまり前述の定義の「マスターとなる青写真」となる。 データの保存と処理の要件 企業の現在のデータ要件と長期のデータ要件を満たす構造や計画の立案 これらを記述するためにエンタープライズ・データモデル (EDM) とデータフロー設計が必要となる。(後述) エンタープライズアーキテクチャ データアーキテクチャとビジネス、アプリケーション、テクニカルなど他の領域のアーキテクチャとの違いは下表のようになる。 それぞれが影響を及ぼし合う関係となっており、データアーキテクチャはビジネスアーキテクチャによって決められる。 ドメイン エンタープライズ・ビジネスアーキテクチャ エンタープライズ・データアーキテクチャ エンタープライズ・アプリケーションアーキテクチャ エンタープライズ・テクニカルアーキテクチャ 目的 企業が顧客や他のステークホルダに どのように価値提供しているかを 明らかにする データがどのように整理・管理されるべきか記述する 企業内アプリケーションの 構造と機能を記述する システムを稼働して価値を 提供するために必要な 物理実装技術を記述する 要素 ビジネスモデル、業務プロセス、業務能力、サービス、イベント、戦略、語彙集 データモデル、データ定義、データマッピング仕様、データフロー、構造化データの API ビジネスシステム、ソフトウェアパッケージ、データベース テクニカルプラットフォーム、ネットワーク、セキュリティ、統合ツール 依存関係 他のドメインに対する要件を設定する ビジネスアーキテクチャによって作られ、要求されるデータを管理する ビジネス要件に基づいて特定されたデータに対応する アプリケーションアーキテクチャを提供し実行する 役割 ビジネスアーキテクトとアナリスト、ビジネス・データスチュワード データアーキテクトとモデラー、データスチュワード アプリケーションアーキテクト インフラストラクチャアーキテクト DMBOK2 表6 アーキテクチャ領域 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第15章「データマネジメント成熟度アセスメント」について。 データマネジメントの導入において重要な役割を果たしそうなので早めに確認しておきたかった。 以降、特に注釈のない引用は DMBOK2 第15章からの引用とする。 データマネジメント成熟度アセスメントとは データマネジメント成熟度アセスメント (DMMA: Data Management Maturity Assessment) はその名の通り、組織のデータマネジメントのレベルの評価に基づくプロセス改善の取り組みのこと。 能力成熟度アセスメント (CMA: Capability Maturity Assessment) というものがあり、それのデータマネジメント版が DMMA。 CMA では 成熟度モデルは進化の観点から定義され、それにはプロセスの特性を表すレベルが使用される。組織がプロセスの特性を理解すると、組織は成熟度を測り、その能力を向上させるための計画を立てることができる。(中略) 新しいレベルに上がる度にプロセスの実行はより一貫性を増し、予測可能な状態となり、信頼性が高くなる。 レベルは通常0~5の6段階で表される。 DMMA は 全体的なデータマネジメントを評価するために使用したり、単一の知識領域や、単一のプロセスに焦点を当てて使用したりできる。どのような点に焦点を当てたとしても、DMMA はデータマネジメント業務の健全性と有効性について、業務と IT の視点のギャップを埋めるために役立つ。 組織が DMMA を実施する理由は、規制への対応、データガバナンス、プロセス改善、etc. DMMA の第一のゴールはデータマネジメント活動の現状を評価することであり、それにより改善計画を立てることができるようになる。 アセスメントレベル 以下はアセスメントレベルの概要。 データマネジメントの各知識領域 (ex. データガバナンス、メタデータ管理、etc.) ごとにレベルが評価される。 level 0: 能力が欠如した状態 データマネジメントの取り組みがない level 1: 初期／場当たり的な状態 限られたツールセットを用いた一般的なデータマネジメント ガバナンスは低レベル データ処理は一部の専門家に依存し、役割や責任は部門別に定義されている level 2: 反復可能な状態 組織は一元化された共通ツールを使い始める 役割は明確化されており、一部の専門家のみに依存しない level 3: 定義された状態 拡張可能なプロセスの導入と制度化 組織全体である程度統制されたデータの複製 データ品質全体の総体的な向上 組織的なポリシー定義と統制 level 4: 管理された状態 新しいプロジェクトやタスクから得られる結果が予測され、リスクの管理が始まる データマネジメントに成果に対する評価尺度が含まれる データマネジメント用の標準ツールが集中管理計画とガバナンス機能に組み合わされている level 5: 最適化された状態 活動の成果は十分予測可能に 組織は継続的な改善に重点を置く 十分理解された評価尺度を使ってデータ品質とプロセスが管理・測定される 次のように各知識領域ごとに可視化することができる。 現状ランクと求められるランクの乖離が大きいところが組織にとってのリスクとなる。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第12章「メタデータ管理」について。 仕事でメタデータを扱い始めたので読んでおきたかった。 以降、特に注釈のない引用は DMBOK2 第12章からの引用とする。 メタデータとは 一般的な説明としては「データに関するデータ」とよく言われている。 データに関するデータはすべてメタデータなので、メタデータはとても幅広い内容となっている。 DMBOK2 ではメタデータの説明として図書館の例を挙げている。 そこには数十万の書籍と雑誌があるのに、図書目録がない。図書目録がなければ、読者は特定の本や特定のトピックの検索を開始する方法さえ分からないかもしれない。図書目録は、必要な情報 (図書館が所有する本と資料、保管場所) を提供するだけでなく、利用者が様々な着眼点 (対象分野、著者、タイトル) から資料を見つけることを可能にする。 (中略) メタデータを持たない組織は、図書目録のない図書館のようなものである。 データという資産を管理するためにも、データを利用するためにも、リスクマネジメントのためにもメタデータは必要となる。 メタデータの種類 メタデータはビジネス、テクニカル、オペレーショナルの3つに分類することができる。 ビジネスメタデータ 主にデータの内容と状態に重点を置く。 IT からは独立している。 dataset, table, column の定義と説明 業務ルール、変換ルール、計算方法、導出方法 データモデル etc. テクニカルメタデータ 技術的詳細やシステムに関する情報。 主に IT に関連している。 物理 database の table, column の名称 column のプロパティ アクセス権 etc. オペレーショナルメタデータ データの処理とアクセスの詳細を示す。 運用で得られる情報とも言える。 バッチプログラムのジョブ実行ログ データの抽出とその結果などの履歴 運用スケジュールの以上 etc. 以上、各種のメタデータで例に挙げたのはあくまで一部であり、現実にはもっと多くのメタデータが存在する。 メタデータを管理する意義 図書館の例からもわかるとおり、メタデータなしではデータを管理することはできない。 信頼性が高く管理されたメタデータにより、次のようなことができるようになる。 データのコンテキストを提供し、それによりデータ品質を測定可能にして信頼性を向上させる 業務効率の向上、および古いデータや誤ったデータの利用防止 データ利用者とエンジニアの間のコミュニケーションの改善 法令遵守の支援 etc. メタデータの管理が不十分だと次のようなことが起こる。 一貫性のないデータ利用と誤った定義によるリスク メタデータは複製されて保管されることによる冗長性 利用者の信頼性低下 etc. メタデータアーキテクチャ メタデータの内容は幅広いがしたがってその取得元も幅広く、ビジネス用語集、BI ツール、モデリングツール、等々が挙げられる。 これらを何らかの方法で集約し、一箇所のメタデータポータルで閲覧できるようにする必要がある。 つまり「ここに来ればデータについてのことがわかる」という入り口を設けることになる。 そのためのアーキテクチャの構成が4つ挙げられている。 ...

このポストについて DMBOK2 を読み進めていくシリーズ。 今回は第3章「データガバナンス」について。 DAMA ホイール図において中心に置かれているので先に読んでおこうと思った次第。 以降、特に注釈のない引用は DMBOK2 第3章からの引用とする。 データガバナンスとは データガバナンス (DG) の定義は、データ資産の管理 (マネジメント) に対して職務権限を通し統制 (コントロール) することである。統制とは計画を立て、実行を監視し、徹底させることを指す。 この定義からデータガバナンスがなぜ DAMA ホイール図の中心に位置しているかがわかる。 データガバナンスにより周囲の各知識領域の計画や実施を統制するという建付けになる。 データガバナンス (DG) のゴールは組織がデータを資産として管理できるようにすることである。DG はデータを資産として管理するための原則、ポリシー、プロセス、フレームワーク、評価指標を提供し、組織の各階層レベルでデータマネジメントアクティビティを牽引する。 これを可能にするためにデータガバナンスは持続可能であり、業務プロセスに組み込まれており、測定可能になっている必要がある。 データガバナンス組織 次の組織構成が一般的なデータガバナンスモデルであるとのこと。 DMBOK2 データガバナンス組織構成 右側がデータマネジメントを実施するロールになっており、左側がデータガバナンスによりデータマネジメントさせるロールになっている。 データガバナンス運営委員会が組織のデータガバナンスの頂点となっており、最も権限が強い。 各部門にはデータガバナンス評議会 (DGC) が置かれており、これらがポリシー・評価指標の開発などのデータガバナンスの取り組みや課題、報告を管理する。 データガバナンスオフィス (DGO) はデータスチュワード (後述) などで構成され、企業レベルのデータ定義とデータマネジメントにフォーカスする。 大規模、かつデータマネジメントの意識が高い組織でないとこういった組織構成はなかなか作れないのではと思った。 ライト版の図も欲しいところ。 DMBOK2 データ問題の報告経路 ポリシーやステークホルダー利害の不一致、権限、データ品質などなど、データに関する問題は上記のような報告経路をたどる。 データスチュワード制 データスチュワード制はデータとプロセスの実行責任と結果責任を表す最も一般的な呼び名であり、データ資産の効率的な統制と利用を確かなものとする。 ちょっとこの説明ではイメージしにくいかもしれない。 データガバナンスの文脈において、データスチュワードは現場を含む組織の各レベルでデータガバナンスを効かせるための活動を行う実務者だと理解した。 データスチュワードという職務名があってもいいが、そうでなくてもよいらしい。 次のようなことをやる。 核となるメタデータの作成と管理 ルールと標準の文書化 データ品質の問題管理 データガバナンス運営アクティビティの実施 データスチュワードについては以下も参考。 参考: データスチュワードとは？役割やメリット、育成方法、選定基準について解説！ | trocco®(トロッコ) データポリシー データポリシーとは、データとインフォーメーションを生成し、取得し、健全性を保ち、セキュリティを守り、品質を維持し、利用することを統制する基本的なルールに、原則と管理糸を盛り込む指示である。 ポリシーはデータガバナンスの “What” を説明する。 通常はデータマネジメント・プロフェッショナルか業務ポリシー担当者が起草し、最終的に DGC により承認される。 ...

このポストについて なんか個人的にデータマネジメントの機運が高まってきたので、ずっと積ん読していた DAMA-DMBOK を読んでいこうかなと。 で、せっかくなのでデータ関係の皆さんがよくやっているように自分としても読書メモをまとめてみようと思った。 内容を網羅するのではなく、現場のデータエンジニアとして活動した経験を踏まえて自分なりの観点でまとめてみたい。 今回は第1章「データマネジメント」で、それ以降は関心がある章をつまみ食い的に読んでいく。 DAMA-DMBOK とは DAMA とは DAta Management Association の略であり、 世界各地に80の支部を持ち、8,000名を越える会員を擁する全世界のデータ専門家のための国際的な非営利団体です。 特定のベンダーや技術、手法に依存しないことを前提として、データや情報、知識をエンタープライズの重要な資産として管理する必要性の理解を促し、この分野の成長を推進しております。 – 一般社団法人 データマネジメント協会 日本支部(DAMA Japan) とのこと。 この DAMA が刊行しているのがデータマネジメント知識体系ガイド (The DAMA Guide to Data Management Body of Knowledge) であり、その略称が DMBOK である。 ＤＡＭＡ ＤＭＢＯＫは、データマネジメントプロフェッショナルにとって有益な資料かつ指針となることを目指し、データ管理のもっとも信頼できる入門書となるよう編集されています – 一般社団法人 データマネジメント協会 日本支部(DAMA Japan) IT 業界歴の長い人なら PMBOK というプロジェクトマネジメントについて書かれた本をご存知かもしれないが、あれのデータマネジメント版だと思っていい。 私としてはデータマネジメントの教科書的なものだと考えている。 ...