おい、DMBOKってなんなんだ？（その2/3）

おい、DMBOKってなんなんだ？（その1/3）の続き。
『データマネジメント知識体系ガイドDAMA-DMBOK』のデータマネジメント知識領域についてまとめていく。

DAMA-DMBOKのデータ管理要素
引用: DAMAホイール図

この記事のまとめ方

必要な時に振り返ることができるように、各章のイントロダクションを定義とゴール、Essential conceptsの小見出しで区切る。

• 定義は各章（データ管理要素）の概要説明にあたる部分をまとめる。

• ゴールはそのままで目指すべき目的。

• Essential conceptsは要素を理解するために必要な概念や用語を記載する。

分かりにくいものには少し説明を加えるが、基本的に内容を思い出すキーになる程度に簡潔にまとめていく。学習メモなので、詳細が気になる方は本を買っていただきたい。

6. データ統合と相互運用性

定義

アプリケーションや組織内および相互間におけるデータの移動と統合を管理する。

Data Integration and Interoperability（DII）は、データを活用するためには必須です。データガバナンス、アーキテクチャ、セキュリティ、メタデータ、ストレージと運用、モデリングと設計のデータマネジメント領域が必要となり、まさに統合領域といえます。現在のアプリケーションは各々のストアを持っており統合する必要性が生まれます。DIIは避けて通れません。ウゲーって感じですが、これができないとソースデータから集約データハブへ、ハブからBIダッシュボードなどのターゲットシステムへとデータが流れませんので、ビックデータ活用という文脈では中核をなす領域になっています。

ゴール

- 法令を遵守しながら、必要とするフォーマットと時間枠でデータを安全に提供する
- 共有のモデルとインターフェースを開発することでソリューションを管理するコストと複雑さを削減する
- 重要なイベント（機会と脅威）を特定し、アラートとアクションを自動的に起動する
- ビジネスインテリジェンス、アナリティクス、マスターデータ管理、業務効率化の取り組みをサポートする

ゴールの文章は（記事を書いているときの）実務でやっていることそのままでしたので、首がもげるくらいに頷きながら読んでいました。設計上は将来の拡張性を確保するために全社的視点が必要で、実装は反復的かつ段階的に実する。これは肝に銘じておく必要があると思います。データ統合は業務上の責任を全うするとあるのですが、これはすでに各ストアのデータを業務で使用していることが多いので統合した後でも業務遂行に支障が出てはいけないと理解しました。

Essential concepts

• 抽出（Extract）、変換（Transform）、取込（Load）
  ETL（ソースデータストア→E→ステージングストア←T→L→ターゲットストア）は、更新タイミングやバッチで要件に応じて実行される。ステージング（一時保存）エリアへの格納も監査やオペレーションの要件によって選択する。ELT（ソースデータストア→E→L→ターゲットストア←T）は、データレイクを採用したビックデータ環境では一般的。

• レイテンシ（遅延）
  データが利用可能になるまでの時間。バッチ・ETL（任意タイミング）、変更データキャプチャ（任意期間の差分）、イベント駆動、非同期、リアルタイム（同期）、ストリーミングなんかの用語を押さえておくと良さそうです。

• リプリケーション（複製）

• アーカイブ

• カノニカルモデル（データ共通モデル）
  チョット具体的に何かわかりませんでした。言葉としては共通フォーマットです。

• データ連携モデル
  ポイント・ツー・ポイント（データソースから直接データを渡す）、ハブ＆スポーク（中央データハブに共有データを集約し、ハブからデータを渡す）、パブリッシュ・サブスクライブ（データをプッシュするシステムとプルするシステムを分ける）なんかがあるようです。

• DIIアーキテクチャの概念
  アプリケーションカップリング（システムの結合度合い。密結合/疎結合）、オーケストレーション（システム内での複数プロセスの構成と実行方法）、エンタープライズアプリケーション結合：EAI（複数の異なるシステムを連携させることで、各々のデータやプロセスの統合を目指す概念。ハブ＆スポーク型の集中処理）、サービス指向アーキテクチャ：SOA（ユーザーからみた機能単位/サービスを組み合わせてシステムを構築すること）、エンタープライズ・サービスバス：ESB（SOAに基づくアプリケーション統合。バス型の分散処理による疎結合）、複合イベント処理：CEP（データを格納する前か、場合によっては格納せずに、データを照会する技術を使用した処理）、データフェデレーション・仮想化、DaaS（SaaSのデータ版、ライセンス提供によってデータを提供する）

• データ交換基準
  ISO（国際標準化機構）、NIEM（国家情報交換モデル）

7. ドキュメントとコンテンツ管理

定義

データとインフォメーションはあらゆる形式と媒体から入手される。これらがデータとインフォメーションのライフサイクル管理のため、アクティビティを計画し、実行し、統制する。

ドキュメントやコンテンツを管理するモチベーションは、規則遵守、eディスカバリ、業務効率化であるとこの本はおっしゃています。メールやSlack、esaなど弊社内には日々大量のドキュメントが生み出されています。これをどうやって管理するのかって考えながら読むと理解が進みました。ただし、全社的な動きすぎるのでまずはチーム内のドキュメント整理から始めるなどのスモールスタートが現実的だと感じました。

ゴール

- レコード管理について、法的義務を遵守して顧客の期待に応える
- ドキュメントとコンテンツを効果的かつ効率的に蓄積し、検索し、利用できるようにする
- 構造化データと非構造化データ間の統合機能を実現する

ゴールは、法的義務と業務インフォメーションの共有につきます。そのための業務レコードの維持方法のベストプラクティスをARMAなる組織が、「一般的に認められたレコード維持管理の原則（GARP）」という文章を発表しているらしいです。以下にその目次項目だけ上げておきます。
- 説明責任の原則（上級管理職を設け、プログラム監査能力を確保）
- 完全性の原則（管理するレコードと情報の信憑性と信頼性の確保）
- 保護の原則（個人情報や保護対象の情報の適切な保護）
- コンプライアンスの原則（適用される法律やその他拘束力のある当局や組織の方針に準拠）
- 可用性の原則（必要なときに効率的かつ正確に検索できるように維持）
- 保持の原則（しかるべき時まで情報を保持）
- 処分の原則（法律や規制などに基づく適切な処分）
- 透明性の原則（スタッフおよびステークホルダが利用できるに維持）

Essential concepts

• コンテンツ
  ここではドキュメント内容などで定義された区分のデータや情報のこと。ドキュメントが水ならコンテンツはバケツ。このコンテンツにもライフサイクルがありメタデータの管理も必要。個人的には、コンテンツ管理ツールとしてはesaが有用でうまく整理することでエンタープライズコンテンツ管理：ECMが達成できるのはないかと考えています。

• 統制語彙（タクソノミ）
  明確に許可された用語を定義したリストのこと。シソーラスやオントロジなどの言葉も知っておくといいかもです。

• ドキュメント/レコード
  電子または紙のオブジェクト。レコードはドキュメントの一部と定義されていました。ドキュメントとレコードのライフサイクル管理には、目録管理、ポリシー、分類、ストレージ、検索と配布、保存と破棄が含まれる。これらの項目を考えるとesaは非常に優秀なツールであると思います（運用方法の徹底が必要ですが。）。

• データマップ
  IT環境の目録。所有者情報、管理担当者情報、関連する地理的な位置、データタイプなどなど。

• eディスカバリ
  法律用語。公判の事前段階に両当事者がお互いの情報を要求すること。

• インフォメーションアーキテクチャ
  統制語彙、タクソノミとオントロジ、ナビゲーションマップ、メタデータマップ、検索機能仕様、ユースケース、ユーザーフローを含むインフォメーションやコンテンツ本体の構造を作成するプロセス。

• 検索エンジン
  用語を指定して、コンテンツ内にその用語が含まれたWEBサイトを検索するソフトウェア。

• 意味的モデル
  概念のネットワークとそのリレーションを記述する知識モデリングの一種。

• 意味検索
  キーワードではなく、意味と文脈による検索。いわゆるAIによる先端技術。

• 非構造化データ
  大きく捉えるとRDBに格納されていないデータ。多種多様なので一つの単語で記述することができない。

• ワークフロー
  作成、処理、ルーティング、ルール、管理、セキュリティ、電子署名、締め切り、エスカレーション、レポート作成および配信機能を含んだシステム。CMSなどで自動化される必要がある。

8. 参照データとマスターデータ

定義

組織のゴールを達成し、データの冗長性を生むリスクを低減し、より高い品質を保証し、データ統合のコストを削減するために、共有データを管理する。

例えば、顧客リスト、所在地コード、部門リスト、納品オプション、部品リスト、コストセンターコード、政府課税コードなど業務遂行に必要な共通データが共有されていたら・・・。素晴らしいですね。これを実現することがマスターデータ管理です。

ゴール

- 組織内の業務領域やアプリケーションを横断して情報資産を共有できるようにする。
- 照合済みで品質評価済みのマスターデータと参照データを正式なソースとして提供する。
- 標準、共通データモデル、統合パターンを使用してコストと複雑さを低減する。 

ゴール達成に向けての指針は共有、所有権（共有されるため、スチュワード制管理が必要）、品質、スチュワード任務、変更管理、権限に従う。

Essential concepts

• マスターデータと参照データの相違点
  マスターデータの定義：業務活動に関連する共通概念を抽象的に表現することにより、その活動に意味を与えるデータ。
  具体的には、参照データ（ex コードとそのコードの意味を持つテーブル、あまり更新されない）、エンタープライズ構造データ（ex 勘定科目表）、トランザクション構造データ（ex 顧客識別子）を含む。ここで参照データがマスターデータに含まれていますが、マスターデータは少し広めの概念ということらしいです。そして、それぞれ管理の焦点が異なりマスターデータ管理（MDM）は値と識別子の管理、参照データ管理（RDM）は定義ドメイン値とそれぞれの定義の管理だそうです。言葉だけでは何のこと？って感じでしたが実務で扱うようになると分けたくなります。笑。

• 参照データ
  定義：他のデータを特徴付けたり、データベース内のデータと外部組織の情報とを関連付けたりするために使用されるデータ。
  表すものの粒度や複雑性によって、シンプルリスト（コードと摘要がペアになったリスト）、相互参照リスト（参照コード間の対応表）、タクソノミ（階層関係を保ったリスト）、オントロジ（メタデータの一種）などで構成される。
  独自参照データ、業界参照データ、地理データ、地球統計学データ、演算用参照データなどなど一貫性を保ち全社共通で利用できる理想的な状態と業務プロセスに対応した柔軟な状態のバランスを保ちながら管理する。

• マスターデータ
  定義：ビジネスエンティティ（従業員、顧客、製品、財務構造、資産、場所など）に関するデータ。
  SORとは、正式記録システム（System of Record、定義された一連のルールや期待に基づいてデータを作成/補足し維持するための正式なシステム）、正式参照システム（System of Reference、データ利用者がトランザクションや分析のために信頼できるデータを取得する正式なシステム）などで”真実”のバージョン管理を行うシステムのこと。信頼できるソース。
  MDMの難しいところは、人が類似概念を様々な方法で表現する生き物であるところ。つまり、表現の違いを取り持つことが最も困難。そんなMDMの主要処理手順は、データモデル管理（システム重視を克服し、全社的レベルの定義を構築する）、データ取得（信頼性の高い繰り返し可能なプロセス）、データ検証（データの間違いを特定）、データの標準化（データ内容の一致を保証）、データの強化（エンティティ解決サービスを向上させる属性の追加）、エンティティの解決（実体の類似性の意思決定）、スチュワード制と共有（責任者の任命）が含まれる。
  パーティマスターデータ（個人や組織、業務関係の中で果たす役割に関するデータ）、財務マスターデータ（事業単位、コストセンタ、プロフィットセンタ、勘定科目、予算、財務予測、プロジェクトなどに関するデータ）、法令マスターデータ（契約や規制などの法的事項に関するデータ）、製品マスターデータ（社内の製品やサービス、業界全体の製品やサービスを扱うデータ）、ロケーションマスターデータ（業務関係者の地理情報）、業種マスターなど多くのマスターデータがある。

• データ共有アーキテクチャ
  データ共有ハブアーキテクチャモデル（ex 各種ソースシステムDB→LDS→MDS→DWH/DM）

9. データウェアハウジングとビジネスインテリジェンス

定義

意思決定を支えるデータを提供して、レポート作成、クエリ発行、分析に携わるナレッジワーカーを支援するため、計画を立案し、実行し、統制する。

1980年代にコンセプトが登場して以来、ビジネス上の意思決定を主に改善するビジネスインテリジェンスと共に発展してきた。1990年代に本格的に構築され始め、全社的データマネジメントの中核として認識されている。確立されたデータウェアハウスであるが、未だに進化を続けており、最近ではデータレイクなどの新しい概念が生まれている。
データウェアハウスの構築意義は、業務遂行機能の強化とBIアクティビティの支援だと思います。BIの目的が過去分析から未来予測へと拡張されていることからそのニーズに応えるべくデータウェアハウスもどんどん進化しているのだと理解しています。

ゴール

- 業務遂行機能、規制遵守要件、ビジネスインテリジェンス関連アクティビティを支援するため、統合データの提供に必要な技術環境、ITプロセス、業務のプロセスを構築し維持する。
- ナレッジワーカーの効果的な業務分析と意思決定を支援し実現する。

原則が大事なので、まとめます。ビジネス上のゴールに重点を置く、データの最終形を考慮しながら開始する、全体を捉えてデザインし順次実施し仕上げる、初めではなく最後に要約して最適化する、透明性とセルフサービスを促進する、DWHと共にメタデータを構築する、協調する（データガバナンスやデータ品質などの取り組みに対して）、誰にでも合う服はない（利用者やグループごとに適切なツールの選択）。そのままをチーム共有したいくらいの素晴らしい原則だと思いました。

Essential concepts

• ビジネスインテリジェンス（BI）
  意味については二つの意味がある。組織の業務と改善の機会を把握するために使われるデータ分析の一種（適切な問い合わせによって戦略的目標を達成する方法を正しく決定できる）と一連の技術（意思決定サポートツール）。

• データウェアハウス（DWH）
  統合意思決定支援データベースとその関連データストア。広義ではBIのためにデータ配信機能を持つ全てのデータストアや抽出データ。エンタープライズ・データウェアハウス（EDW）。

• データウェアハウジング
  構造化データおよび非構造化データ（管理は至難の技）を取り込み処理（クレンジング、変換、制御など）し、DWH内で維持する（メタデータリポジトリとのやりとりも含む）こと。

• コーポレートインフォメーション・ファクトリ（CIF、インモン発案）
  『サブジェクト別（業務実態指向）に統合化された（データの統合）時系列（時間情報を持ったスナップショット）で不変（上書き更新されない）の時系列要約データと明細データ（永続化/非永続化、履歴データ）の集合』と定義。全てのデータを単一のデータウェアハウスレイヤー（エンタープライズデータモデル）に格納することを提唱。
  CIFのコンポーネント（アプリケーション、ステージングエリア、統合と変換、オペレーショナル・データストア（ODS）、データマート、オペレーショナルデータマート（Op DM）、データウェアハウス、オペレーショナルレポート、参照データ、マスターデータ、外部データ）。

• ディメンショナルDW（キンボール発案）
  『クエリと分析のために特別に構成されたトランザクションデータのコピー』と定義。スタースキーマと呼ばれ、ファクト（量的データ）とディメンション（属性）で構成され、ファクトについての問い合わせに対応できるようになっている。DWバス（統合ディメンション）が肝。クレンジング、標準化、統制されたデータを部門別データマートとして構成することを提唱。
  データウェアハウスチェスピースのコンポーネント（オペレーショナル・ソースシステム、データステージング領域、データプレゼンテーション領域、データアクセスツール）。CIFとほぼ対応しているが、キンボールの方がDWHの役割が拡張されている。あと第三のアプローチ的にデータボールトってのが出てきましたが、割愛www。

• DWアーキテクチャコンポーネント
  データライフサイクルに沿ってコンポーネントの整理すると、ソースシステムからステージング領域に移動し、適切な処理（マスターデータや参照データとの統合を含む）をされDW（セントラルウェアハウスで履歴も保存）やODS（更新が早い（リアルタイム）一定期間のストア）に統合され（ETLやデータ仮想化など）保管。マート（単一の業務プロセス用に作られるストア）やキューブ（多次元データセット）を介してアクセスされBIツールやレポーティングに活用される。

• 取込処理の種類
  DWのデータ統合プロセスは2種類ある。履歴取込み（データに問題がない限りは一度のみ実行）と継続的更新（スケジュールに沿って定期的に実行。バッチ、準リアルタイム（トリクルフィード、メッセージング、ストリーミング）などがある）。

10. メタデータ管理

定義

高品質な統合されたメタデータを利用できるようにするためにアクティビティを計画し、導入し、統制する。

メタデータとは、「データに関するデータ」ってなんのこと？となる定義ではなくしっかり理解したいところ。ITプロセスと業務プロセス、データのルールと制約、論理的および物理的なデータ構造に関する情報。メタデータを持たない組織は、図書目録のない図書館のようなものでデータマネジメントおよび活用する上で不可欠なものです。

ゴール

- 業務用語とその利用法に関する組織の理解を提供する。
- 様々なソースのメタデータを収集し統合する。
- メタデータにアクセスするための標準的な方法を提供する。
- メタデータの品質とセキュリティを確保する。

ゴール達成のための指針として、組織のコミットメント（データ資産の管理の一環として）、戦略（ビジネス上の優先順位に合致）、全社的視点（将来の拡張性の確保）、ソーシャル化（メタデータの重要性の企業内認識）、アクセス、品質（プロセスオーナーの責任）、監査、改善（フィードバックの仕組み）があげられる。
弊社内でもよくデータ品質について議論をします。ビジネス戦略に合致したデータ品質の向上を目指すのですが、データ品質からメタデータ管理まで理解してもらえることはほぼないです。データマネジメントの責任を持った部署から説明して社内理解を高めていく必要があり、本当に苦労します。さらに、上層部のコミットメントが得られていないとなると・・・推進はほぼ不可能と思います。

Essential concepts

• メタデータ対データ
  メタデータもデータなのでその線引きはどこなのか・・・。メタデータの役割（ex データ生成タイミングの管理、既存データの定義の整理、システム間データ移動の管理など）から定義していくことが必要である。

• メタデータの種類
  ビジネス（内容と状態に重点をおいたガバナンスに必要な詳細）、テクニカル（技術的詳細）、オペレーショナル（処理とアクセスの詳細）の3分類される。カテゴリーによって情報の範囲や生成する機能を理解しやすくなる。

• ISO/IEC11179メタデータレジストリ規格

• 非構造化データのメタデータ
  データレイクにインジェストされた非構造化データに、後でアクセスできるよう最小限のメタデータを属性を収集しておく。

• メタデータのソース
  様々なソース（アプリケーション・メタデータリポジトリ、業務用語集、BIツール、構成管理ツール、データディクショナリ、データ統合ツール、データベースカタログ、データマッピング管理ツール、データ品質ツール、ディレクトリ、カタログ、イベントメッセージング・ツール、モデリングツール、参照データリポジトリ、サービスレジストリなど）から取集されるが、成果物としてではなく副産物として生成されることも多く統合・管理にはスチュワードシップが求められる。

• メタデータアーキテクチャの種類
  通常データと同様にライフサイクルの段階（入手、保存、統合、維持、利用）ごとにアーキテクチャ層が設けられている。集中型メタデータアーキテクチャや分散型メタデータアーキテクチャ、ハイブリット型メタデータアーキテクチャ、双方向メタデータアーキテクチャがある。メタデータもデータ統合の考え方と同じで、ストアを儲けるかどうかで分類されていると理解しています。

後半のまとめ

最後のデータ品質のところは特に重要と感じて、一つの記事として分離しまいた。（これだけ見ておいて！としやすいので。）

MLOpsやAutoMLなどの解析の自動化が進めば、それだけデータマネジメントの重要性が高まってきます。私のようなキャリアチェンジDSとしては、今後どのようなスキルが必要なのかを考え、生き残り戦略を立てる必要があります。そういった意味で、データマネジメントの知識を習得することは筋のいい投資ではないかと思っています。学んだ後は実践あるのみです！そのうち、実践編とかでまとめてみたいです。