データマネジメントの導入プロセス

記事データマネジメントのデータマネジメントの導入アプローチでは、企業にどのようにデータマネジメントを導入するのか、その流れについて説明しました。
データマネジメントは、次の図のように一つの戦略サイクルで導入されます。

ここでは、より具体的なデータマネジメントの導入プロセスについて次の観点で説明します。

• データマネジメントモデルの設計
• データマネジメント戦略の策定
• データマネジメントシステムの構築
• データマネジメントシステムの運用
• データマネジメント導入支援サービス

データマネジメント導入プロセス一覧（Excel）のダウンロード

データマネジメントモデルの設計

次の図は、データマネジメントモデル設計の流れを表したものです。

ここでは、データマネジメントの目的、体制、方法など本質となる型を設計します。

一つひとつ見ていきましょう。

• データマネジメントの目的の設定
• データアーキテクチャ（概念レベル）の設計
• データ管理基盤（方針レベル）の設計
• データマネジメント組織（ジョブ）の設計
• データマネジメントプロセスの設計

データマネジメントの目的の設定（ビジネス要件の定義）

ここでは、なぜデータマネジメントを行うのか、その目的を設定（データ戦略の設計）します。
ビジネス要件を満たすために、それに関連するデータの品質とセキュリティを確保するという観点でデータマネジメントの目的を設定します。
ビジネス要件は、戦略マップの設計を受けて、次の３つの観点で定義します。

• 各種戦略目標の実現（有効性）
• 各種報告の信頼性確保（信頼性：内部統制）
• 各種法規の遵守（安全性：コンプライアンス）

データアーキテクチャ（概念レベル）の設計

次の手順でデータアーキテクチャ（概念レベル）を設計します。

1. ビジネス上のデータ要件を定義する観点の整理
   ビジネス上の要件を満たすために必要なデータ要件はどういう観点で定義するか整理します。
2. データ品質評価項目のの定義
   データ品質の評価項目（データの一意性など）を定義します。
3. データセキュリティを測る基準の定義
   データセキュリティを測る基準（機密レベルと規制対象カテゴリ）を定義します。
4. ビジネスメタデータとして定義する内容の定義
   ビジネスメタデータとして定義する内容を定義します。
5. データドメインの定義
   データドメイン（データの定義域）を定義します。
6. マスターデータのデータアーキテクチャ（概念レベル）の設計
   1. マスターデータの全体概念マスターデータモデルを設計します。
   2. マスターデータの全体概念データフローを設計します。
   3. マスターデータのビジネスメタデータを定義します。
   4. マスターデータを主管システムに割り当てます。
7. トランザクションデータのデータアーキテクチャ（概念レベル）の設計
   1. トランザクションデータの業務概念データモデルを設計します。
   2. トランザクションデータの業務概念データフローを設計します。
   3. トランザクションデータのビジネスメタデータを定義します。
   4. トランザクションデータを主管システムに割り当てます。
   5. 現行システムのデータが重複しているかどうか確認します。
8. 分析データのデータアーキテクチャ（概念レベル）の設計
   1. 分析データの全体概念分析データモデルを設計します。
   2. 分析データの全体概念データフローを設計します。
   3. 分析データのビジネスメタデータを定義します。
   4. 分析データを主管システムに割り当てます。

データ管理基盤（方針レベル）の設計

データウェアハウスやデータレイクなどデータを管理するための物理的基盤を導入するための基準や方針を次の手順で定義します。
データ管理基盤の導入方針には、データアーキテクチャ（概念レベル）の結果も反映させます。

1. データウェアハウスの導入基準の定義
   データウェアハウス導入するかどうか判断する基準を定義します。
2. データ分析環境の導入基準の定義
   データ分析環境を導入するかどうか判断する基準を定義します。
3. データレイクの導入基準の定義
   データレイクを導入するかどうか判断する基準を定義します。
4. NoSQLの導入基準の定義
   NoSQLを導入するかどうか基準する基準を定義します。
5. マスターデータ管理の基準の定義
   マスターデータをどう管理するのか（トランザクションハブや統合アプローチなど）判断する基準を定義します。
6. データ統合の基準の定義
   データをどう統合するのか（リアルタイム統合やイベント駆動統合など）判断する基準を定義します。
7. データ連携の基準の定義
   データをどう連携するのか（ESBなどの連携基盤を使って統合するかなど）判断する基準を定義します。
8. データウェアハウスの導入方針の設定
   データウェアハウスの導入方針を設定します。
9. データ分析環境の導入方針の設定
   データ分析環境の導入方針を設定します。
10. データレイクの導入方針の設定
    データレイクの導入方針を設定します。
11. NoSQLの導入方針の設定
    NoSQLの導入方針を設定します。
12. マスターデータ管理の方針の設定
    マスターデータ管理の方針を設定します。
13. データ統合方針の設定
    データ統合方針を設定します。
14. データ連携方針の設定
    データ連携方針を設定します。

データマネジメント組織（ジョブ）の設計

データマネジメントに関わる役割を次の手順で定義します。

1. データマネジメントの対象者の定義
   データマネジメントの対象者を定義します。
2. データマネジメントジョブの設計
   データマネジメントジョブと、それらの関係を設計します。

データマネジメントプロセスの設計

データマネジメントをどう進めるのかデータマネジメントプロセスを次の手順で設計します。

1. データマネジメントプロセスの定義
   データマネジメントの目的を実現するためのビジネスプロセス（価値を生み出す組織横断的な活動の単位）をデータマネジメントプロセスとして定義します。
2. データマネジメントのアクティビティフローの設計
   データマネジメントプロセス単位に、そのアクティビティフロー（本質的な活動の流れ）を設計します。
3. データマネジメントのアクションフローの設計
   アクティビティフローを構成する各活動単位を詳細化してアクションフロー（プロシージャ・実施手順レベル）に落とし込みます。

データマネジメント戦略の策定

次の図は、データマネジメント戦略策定の流れを表したものです。

ここでは、データマネジメントモデルを具体的にどう実現するのか戦略を策定します。
その際、データマネジメントのビジョン、および、あるべき（To-Be)データアーキテクチャ、データ管理基盤、データマネジメント組織を論理レベルで設計します。
その上で、現行（As-Is)のデータアーキテクチャ、データ管理基盤、データマネジメント組織とのギャップを明確にします。
その結果を踏まえて、データマネジメントシステムの構築計画、および、データマネジメントシステム運用計画を策定します。
一つひとつ見ていきましょう。

• データマネジメントのビジョンの設定
• データ管理基盤（製品レベル）の設計
• データアーキテクチャ（論理レベル）の設計
• データマネジメント組織（部門）の設計
• データマネジメントシステム構築計画の策定
• データマネジメントシステム運用計画の策定

データマネジメントのビジョンの設定

いつどのデータマネジメント成熟度レベルになるか設定します。
次の図は、DMBOKのデータマネジメント成熟度モデルを、各分野別に詳細化したものです。

データマネジメント成熟度モデルに合わせて、次の図のように、データ利活用の成熟度も上がります。

データアーキテクチャ（論理レベル）の設計

次の手順で、企業全体のデータモデル（静的モデル）とデータフロー（動的モデル）を論理レベルで設計します。
論理データフローにはデータ管理基盤（製品レベル）の結果も反映させます。

1. テクニカルメタデータとして定義する内容の定義
   テクニカルメタデータとして定義する内容を定義します。
2. マスターデータのデータアーキテクチャ（論理レベル）の設計
   1. マスターデータの全体論理マスターデータモデルは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   2. マスターデータの全体論理データフローは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   3. マスターデータのテクニカルメタデータは、各アプリケーションを開発する際、システム開発者が定義します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
3. トランザクションデータのデータアーキテクチャ（論理レベル）の設計
   1. トランザクションデータの業務論理データモデルは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   2. トランザクションデータの業務論理データフローは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   3. トランザクションデータのテクニカルメタデータは、各アプリケーションを開発する際、システム開発者が定義します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
4. 分析データのデータアーキテクチャ（論理レベル）の設計
   1. 分析データの全体論理分析データモデルを設計します。
   2. 分析データの全体論理データフローを設計します。
   3. 分析データのテクニカルメタデータを定義します。

データ管理基盤（製品レベル）の設計

次の手順でデータ管理基盤（製品レベル）を設計します。

1. データウェアハウスの製品選択基準の定義
   データウェアハウスの製品選択基準及び評価指標を定義します。
2. データ分析環境の製品選択基準の定義
   データ分析環境の製品選択基準及び評価指標を定義します。
3. データレイクの製品選択基準の定義
   データレイクの製品選択基準及び評価指標を定義します。
4. NoSQLの製品選択基準の定義
   NoSQLの製品選択基準及び評価指標を定義します。
5. マスターデータ管理の製品選択基準の定義
   マスターデータ管理の製品選択基準及び評価指標を定義します。
6. データ統合の製品選択基準の定義
   データ統合の製品選択基準及び評価指標を定義します。
7. データ連携の製品選択基準の定義
   データ連携の製品選択基準及び評価指標を定義します。
8. オペレーショナルメタデータとして定義する内容の定義
   オペレーショナルメタデータとして定義する内容を定義します。
9. データウェアハウスの設計（製品レベル）
   データウェアハウスの製品を選定します。
10. データ分析環境の設計（製品レベル）
    データ分析環境の製品を選定します。
11. データレイクの設計（製品レベル）
    データレイクの製品を選定します。
12. NoSQLの設計（製品レベル）
    NoSQLの製品を選定します。
13. マスターデータ管理の設計（製品レベル）
    マスターデータ管理の製品を選定します。
14. データ統合の設計（製品レベル）
    マスターデータ管理の方針を設定します。
15. データ統合の設計（製品レベル）
    データ統合の製品を選定します。
16. データ連携の設計（製品レベル）
    データ連携の製品を選定します。
17. データウェアハウスのオペレーショナルメタデータの定義
    データウェアハウスのオペレーショナルメタデータを定義します。
18. データ分析環境のオペレーショナルメタデータの定義
    データ分析環境のオペレーショナルメタデータを定義します。
19. データレイクのオペレーショナルメタデータの定義
    データレイクのオペレーショナルメタデータを定義します。
20. NoSQLのオペレーショナルメタデータの定義
    NoSQLのオペレーショナルメタデータを定義します。
21. マスターデータ管理のオペレーショナルメタデータの定義
    マスターデータ管理のオペレーショナルメタデータを定義します。
22. データ統合のオペレーショナルメタデータの定義
    データ統合のオペレーショナルメタデータを定義します。
23. データ連携のオペレーショナルメタデータの定義
    データ連携のオペレーショナルメタデータを定義します。

データマネジメント組織（部門）の設計

データマネジメント組織（部門）を設計します。

データマネジメントシステム構築計画の策定

次の観点でデータマネジメントシステム構築計画を策定します。

• データ管理基盤構築計画の策定
  システム開発プロセスに従ってデータ管理基盤構築計画を策定します。
• データマネジメント組織構築計画の策定
  データマネジメント組織構築計画を策定します。

データマネジメントシステム運用計画の策定

次の観点でデータマネジメントシステム運用計画を策定します。

• 個別アプリケーション設計時の検証計画の策定
  データアーキテクトは、年間のアプリケーション開発計画に従って、個別アプリケーション設計時の検証計画を策定します。
• 個別アプリケーション受入テスト時の検証計画の策定
  データスチュワードは、年間のアプリケーション開発計画に従って、個別アプリケーション受入時の検証計画を策定します。
• 既存アプリケーションの検証計画の策定
  データスチュワードは、調査できていない既存アプリケーションシステムやデータ管理基盤の品質やセキュリティの検証計画を策定します。
• データ運用の検証計画の策定
  データスチュワードは、アプリケーションシステムやデータ管理基盤のオペレーショナルメタデータを確認し、データのバックアップと復旧の検証する計画を策定します。
• コードマスター（参照データ）のメンテナンス計画の策定
  データスチュワードは、コードマスター（参照データ）のメンテナンス計画を策定します。
• データオーナーの問い合わせ対応計画の策定
  データスチュワードは、データオーナーの問い合わせ対応計画を策定します。
• データドリブン経営の支援計画の策定
  データサイエンティストは、年間の経営計画に従って、データドリブン経営の支援計画を策定します。
• データの改善・強化計画の策定
  データスチュワードは、データの改善・強化計画を策定します。

データマネジメントシステムの構築

次の図は、データマネジメントシステム構築の流れを表したものです。

ここでは、戦略フェーズで策定したデータマネジメントシステムの構築計画に従ってデータマネジメントシステム（データ管理基盤およびデータマネジメント組織）を構築します。
一つひとつ見ていきましょう。

• データ管理基盤の構築
  データマネジメントシステム構築計画に従ってデータ管理基盤を構築します。構築されたデータ管理基盤は、ITサービスマネジメントの一環として運用されます。
  受入テストの段階でデータ管理基盤の実データのプロファイリングをします。
  受入テストの段階でデータ管理基盤のセキュリティ監査をします。
• データマネジメント組織の構築
  データマネジメント組織構築計画に従ってデータマネジメント組織を構築します。
• データマネジメントシステムの検証
  構築されたデータマネジメントシステム（データ管理基盤、データマネジメント組織）の上でデータマネジメントプロセスが運用できるか検証します。

データマネジメントシステムの運用

次の図は、データマネジメントシステム運用の流れを表したものです。

ここでは、戦略フェーズで策定したデータマネジメントシステム運用計画に基づいて、データマネジメントシステムを運用します。
なお、データマネジメントシステム運用の手順は、設計フェーズで設計したデータマネジメントプロセスで定義されてたものです。
一つひとつ見ていきましょう。

• データマネジメントシステム運用計画の実行
• データマネジメントシステム運用計画の検証
• データマネジメントシステム運用計画の改善

データマネジメントシステム運用計画の実行

• データの維持管理（メンテナンス）
  データ管理者は、次のデータを維持管理します。
  • マスターデータの維持管理
    トランザクションデータハブ以外でマスターデータ管理する場合、データ管理者がマスターデータを維持管理します。
    トランザクションハブの場合、トランザクションハブを運用する部門がマスターデータを維持管理します。
  • 参照データの維持管理
    コードデータ（参照データ）は、データ分析するときの特徴量にもなり、これを会社全体で一元管理することはデータの一貫性を保つためにも重要です。
    コードデータをマスター化して会社全体で一元管理します。
  • メタデータの維持管理
    データ管理者は、ビジネスメタデータ、テクニカルメタデータ、オペレーショナルメタデータを維持管理します。
• データドリブン経営の支援
  データ管理者は、データドリブン経営のアクションである問題の特定、原因の推定、解決策の策定、実験計画の策定、解決策の検証の支援をします。
• データの品質検証
  データ管理者は、次の観点でデータの品質を検証します。
  • データモデルの品質検証
    • アプリケーションシステムのデータ要件の検証
      ビジネスメタデータのデータ要件とアプリケーションのデータ要件を参照し、アプリケーションの要件定義の妥当性をを検証します。
    • アプリケーションシステムのデータモデルの検証
      ビジネスメタデータのデータ要件とデータアーキテクチャ（概念レベル）を参照し、アプリケーションの論理データモデル、及び、物理データモデルとテクニカルメタデータの妥当性を検証します。
      • ビジネス上のデータ要件の検証
        ビジネスメタデータに定義されたビジネス上のデータ要件がデータモデルにどう反映されているか検証します。
      • データ品質要件の検証
        ビジネスメタデータに定義されたデータ品質要件を次の観点で検証します。
        • 一意性の検証
          同じ実体を表すデータが同じデータセット内に複数存在しないか検証します。
          例えば、識別子の場合、一意性を確保する必要があります。
        • 完全性の検証
          必要なデータが全て存在するようになるか検証します。
          例えば、非NUL制約が設定されているか確認します。
        • 正確性の検証
          データが現実の実体を正しく表すか検証します。
          例えば、データ入力インターフェースに不正なデータがシステムに書き込まれることを防ぐための編集機能や制御が有効であるかどうか確認します。
          また、属性のデータ型や許容値（CHECK制約など）を詳細に記述しているか確認することで検証することができます。
        • 参照整合性の検証
          参照キーを介したデータセット間の一貫性（例えば参照先のデータだけがないという欠落がない）が保持されるか検証します。
          例えば、データモデルに参照整合性制約が設定されているか確認します。
        • 一貫性の検証
          データが、特定のデータベースなどデータセット内で一貫して（正しいルールに貫かれて）表現されるか、あるいは、データセット間で一貫して関連付けられ、一貫して表現されるか検証します。
          一貫性は、１レコード内にある属性値と別の属性値との間（レコードレベルの一貫性）、あるレコードの属性値と別のレコードの属性値の間（クロスレコードの一貫性）、あるレコードの属性値と異なる時点における同じレコードの属性値との間（経時的一貫性）において定義されます。
          例えば、データモデルに存在制約が設定されているか確認します。
        • 有効性の検証
          データが定義域（データドメイン）に準拠するか検証します。
        • 適時性の検証
          データが適切な時点のものになるか検証します。
          データが発生して利用可能になるまで遅延する場合、どれだけ遅延を許容できるか（レイテンシの許容度）によってデータの可用性を定義することによって、データの適時性を判断することができます。
          レイテンシとは、ソースシステムでデータが生成されてからターゲットシステムでデータが利用可能になるまでの時間差のことです。
          適時性は、データ入力処理の妥当性を検証することによって行います。
    • 業務パッケージのデータ要件の検証
      ビジネスメタデータのデータ要件と業務パッケージのデータ要件をギャップ分析し、業務パッケージの仕様の妥当性をを検証します。
  • データのプロファイリング
    データのプロファイリングはシステム開発の受入テストのときに実施し、リリース後は、定期的に実施します。
    データのプロファイリングも参照してください。
    • ビジネス上のデータ要件の検証
      ビジネスメタデータに定義されたビジネス上のデータ要件が実際に反映されているか検証します。
    • データ品質要件の検証
      ビジネスメタデータに定義されたデータ品質要件を次の観点で検証します。
      • 一意性の検証
        同じ実体を表すデータが同じデータセット内に複数存在していないか検証します。
        例えば、識別子の場合、一意性を確保する必要があります。
      • 完全性の検証
        必要なデータが全て存在しているかどうか検証します。
      • 正確性の検証
        データが現実の実体を正しく表しているか検証します。
        例えば、データ入力インターフェースに不正なデータがシステムに書き込まれることを防ぐための編集機能や制御が有効であるかどうか確認します。
      • 参照整合性の検証
        参照キーを介したデータセット間の一貫性（例えば参照先のデータだけがないという欠落がない）が保持されているか検証します。
        例えば、参照整合性制約が働くか確認します。
      • 一貫性の検証
        データが、特定のデータベースなどデータセット内で一貫して（正しいルールに貫かれて）表現されているか、あるいは、データセット間で一貫して関連付けられ、一貫して表現されているか検証します。
        一貫性は、１レコード内にある属性値と別の属性値との間（レコードレベルの一貫性）、あるレコードの属性値と別のレコードの属性値の間（クロスレコードの一貫性）、あるレコードの属性値と異なる時点における同じレコードの属性値との間（経時的一貫性）において定義されます。
        例えば、存在制約が働くか確認します。
      • 有効性の検証
        データが定義域（データドメイン）に準拠しているか検証します。
      • 適時性の検証
        データが適切な時点のものであるか検証します。
        データが発生して利用可能になるまで遅延する場合、どれだけ遅延を許容できるか（レイテンシの許容度）によってデータの可用性を定義することによって、データの適時性を判断することができます。
        レイテンシとは、ソースシステムでデータが生成されてからターゲットシステムでデータが利用可能になるまでの時間差のことです。
  • データのクレンジング
    データのクレンジングも参照してください。
  • データの品質強化
    データの品質強化も参照してください。
• データのセキュリティ検証
  データ管理者は、次の観点でデータのセキュリティを検証します。
  • アプリケーション連携モデル（論理レベル）のセキュリティ検証
    アプリケーション連携モデル（論理レベル）を参照して、ビジネスメタデータに定義されたセキュリティリスクをどう解消しているか検証します。
  • データのセキュリティ検証
    データのセキュリティ監査を通して行います。
    データのセキュリティ監査はシステム開発の受入テストのときに実施し、リリース後は、定期的に実施します。
  • データのセキュリティ強化
    アプリケーション連携モデル（論理レベル）のセキュリティ検証や、データのセキュリティ検証を受けてセキュリティを強化します。
• データの経済性検証
  データ管理者は、次の観点でデータの経済性を検証します。
  • 分析データの経済性検証
    分析データの活用度と、それによる経済効果を検証します。
  • トランザクションデータの経済性検証
    ビジネスメタデータに定義されたビジネス上のデータ要件の遵守度合いと、それによる経済効果を検証します。
• データ運用の検証
  データ管理者は、次の観点でデータの運用を検証します。
  • データ管理基盤のデータ運用検証
    データ管理基盤のオペレーショナルメタデータを確認し、データのバックアップと復旧の検証をします。
  • アプリケーションシステムのデータ運用検証
    アプリケーションシステムのオペレーショナルメタデータを確認し、データのバックアップと復旧の検証をします。
  • 業務パッケージのデータ運用検証
    業務パッケージのオペレーショナルメタデータを確認し、データのバックアップと復旧の検証をします。

データマネジメントシステム運用計画の検証

データ管理者は、年間のデータマネジメント計画結果を検証します。

データマネジメントシステム運用計画の改善

データ管理者は、年間のデータマネジメント計画を改善します。その際、必要に応じて、データマネジメントモデルやデータマネジメント戦略も見直します。

データマネジメント支援サービス

弊社では、DXの一環としてデータマネジメントの導入を支援するサービスを実施しています。
本サービスの内容は次のようになります。

• データマネジメント体験ワークショップ
  データマネジメント体験ワークショップでは、ワークショップを通して、実際にデータマネジメントの成果物を作成することで、実践的に、貴社のデータ人材を育成します。
• データアーキテクチャ設計代行サービス
  弊社で貴社のデータアーキテクチャ設計を代行いたします。
• データカタログ作成代行サービス
  弊社で貴社のデータカタログ作成を代行いたします。
• データマネジメント代行サービス
  年間のデータマネジメントのデータマネジメントシステム運用計画に従って、次の運用タスクを代行いたします。

企業の担当者の方へ
一度、詳細をご説明いたします。
お問い合わせは以下のメールアドレスにお願いいたします。
culnou_dm@culnou.com