楽水

人々の創造が自由に表現できる舞台づくり

DX データ

【DMBOKで学ぶ】データマネジメント

投稿日:


皆様は、データドリブン経営という言葉を聞いたことがあるでしょうか。
データドリブン経営とは、データを経営に活かすことで経営目的(パーパス)を実現する手法のことです。

マネジメントサイクルの各活動(計画、実行、検証、改善)で、データを利活用するわけですが、そのためには、データライフサイクルを管理してデータ品質を維持・向上させるデータマネジメントが重要です。
データマネジメントとは、
データ資産の価値を提供、維持向上させるためにデータライフサイクルを通して計画、実施、監督すること
です。
データを資産と考えたとき、資産がもたらす経済価値を、それによる恩恵とコストの差で評価することが可能です。
ただ、データの場合、財務資産と異なり、

  • 減価償却しない
  • ある組織では価値があるが、違う組織では価値がない場合がある
  • 昨日は価値があったデータでも今日は価値がなくなる場合がある

など、独自の性質を持っています。
データマネジメント知識体系(DMBOK)では、品質の低いデータがもたらす事象として以下の例をあげています。

  • 誤請求
  • 顧客サービスコールの増加とそれを解決する能力の低下
  • 事業機会の逸失による収益損失
  • 合弁・買収の間に発生する業務統合の遅延
  • 不正行為発覚の増加
  • 不正なデータに起因する業務上の意思決定不備がもたらす損失
  • 良好な信用力の欠如による事業の損失

なので、データ品質を維持向上させて、データの資産価値を上げることがデータマネジメントの根幹になります。
それでは、データマネジメントはどのように導入すればよいのでしょうか。
ここでは、データマネジメントを導入するプロセスを次のように考えます。

この中で、データマネジメントの設計について次の観点で見ていきましょう。

データマネジメントの目的の設定

まず、なぜデータマネジメントをするのか、その拠り所となる目的を設定します。
例えば、

  • 稼ぐ力を持つ資産としてのデータの価値を上げ、データを活用することで企業価値を上げることができるようにする
  • そのために、資産としてのデータの品質を維持向上できるようにする
    なお、データの正確性、完全性、一意性、安全性、一貫性、適時性をデータ品質の指標とする。

などが考えられます。

データマネジメント方針(ポリシー)の定義

次に、データマネジメントの目的を実現するための方針を定義します。
データマネジメント方針は、データアーキテクチャ、データガバナンス組織、データマネジメントプロセス、データマネジメントシステムの設計思想になります。
例えば、次のような方針が考えられます。

  • データアーキテクチャを設計することで、企業全体のデータを俯瞰し、データ戦略を策定できるようにする
    データ戦略とは、事業戦略を踏まえて、資産価値があり投資すべきデータを特定することです。
  • データアーキテクチャをベースにメタデータを可視化し、データ品質を効果的に管理できるようにする
    戦略的に重要なデータの構造と要求される品質を明確にし、メタデータとして定義します。
  • データガバナンス組織を設け、データマネジメント活動を管理することで、データ品質の維持向上およびデータ活用の促進を図る
  • 全社のデータ基盤となるシステムを構築し、データ品質の維持向上およびデータ活用の効率化を図る

データマネジメントの目標の設定

データマネジメントの方針が定まったら、具体的なデータマネジメントの目標と達成期限を定めます。
データマネジメントの目標は、データマネジメントのレベル×適用範囲(スコープ)でフェーズ分けして設定することができます。
まず、データマネジメントのレベルですが、次のような例を考えることができます。

  • レベル1
    データの品質を維持向上させながらデータを活用することができるレベル。
    データの品質維持向上およびデータ活用ができる業務・システム基盤が整備されている。
    KPIの例
    業務・システム基盤整備率
    データ品質目標達成率
  • レベル2
    データを活用して意思決定することができるレベル。
    データを活用して業務を改善することができる。
    主にデータの記述的分析((Descriptive Analytics)を行う。
    KPIの例
    データを活用した業務改善実施数/年
  • レベル3
    データを活用して業務と資源を最適化することができるレベル。
    データを活用して事業戦略(事業の方向性)を策定することができる。
    主にデータの予測的分析(Predictive Analytics)を行う。
    KPIの例
    データを活用した業務改革実施数/年
  • レベル4
    データを活用してステークホルダーに対す価値を創出することができるレベル。
    データを活用して事業を変革・創出することができる。
    主にデータの処方的分析(Prescriptive Analytics)を行う。
    KPIの例
    データを活用した事業変革・創出数/年

次に、データマネジメントを適用する範囲ですが、次のような例を考えることができます。

  • ホールディングスにデータマネジメントを適用する
  • 主要事業にデータマネジメントを適用する
  • グループ全体にデータマネジメントを適用する

これらのデータマネジメントのレベル×スコープでフェーズを分けて目標を設定します。


データアーキテクチャの設計

続いて、データアーキテクチャの設計方針に基づいてデータアーキテクチャを設計します。
DMBOKでは、データアーキテクチャとして、以下の2つのモデルを作成すべきとしています。

  • エンタープライズデータモデル
    企業全体のデータの基本構造を示すモデル。
    戦略的に重要なデータの構造と要求される品質を明確にし、メタデータとして定義します。
  • データフロー
    ビジネスプロセスとデータのライフサイクルの関係を表すモデル。
    重要なのは、戦略的に重要なデータがどの業務活動で生成・収集、変換・蓄積、利活用、破棄されるのか、業務活動とデータライフサイクルの関係を抑えるとです。
    これによって、データ品質を維持・向上させるためには、どの業務活動をどう設計、あるいは、改善すべきかあたりをつけることができます。

エンタープライズデータモデルは、

  • 全社単位の全体概念データモデル
  • 業務領域単位の概念データモデルおよび論理データモデル
  • アプリケーション単位の論理データモデルおよび物理データモデル

から構成されます。

図:エンタープライズデータモデル 出典:データマネジメント知識体系 第二版

データガバナンス組織の設計

次に、データガバナンス組織の設計方針に基づいてデータガバナンス組織を設計します。
DMBOKではデータが適切にマネジメントされるよう統治するデータガバナンス組織を次のように表しています。

  • 立法機能
    ポリシー、規定、エンタープライズデータアーキテクチャを定義する。
  • 司法機能
    課題管理と報告。
  • 行政機能
    データの保護とサービス、行政責任。

この中のデータスチュワードは主に次のような活動を行います。

  • コアとなるメタデータの作成と管理
  • データに関するルールの文書化
  • データ品質の問題管理
  • データガバナンス運営

また、データアーキテクトは、先に説明したデータアーキテクチャを設計、実装する役割、データアナリストは、データを分析して経営上の意思決定を支援する役割です。
データスチュワード、データアーキテクト、データアナリストは、データマネジメントを行う3つ重要な役割です。
それぞれの役割をデータライフサイクルの活動で表すと次のようになります。

  • データスチュワードは、データライフサイクル全体を管理してデータ品質を維持、向上させる役割
  • データアーキテクトは、主にデータの設計・実装を行う役割
  • データアナリストはは、主にデータの利活用を行う役割

なので、データスチュワードが中心となり、データアーキテクトとデータアナリストに、各々の活動を任せるという体制になります。
例えば、データアナリストは、分析に必要なデータを理解し、準備する際、データスチュワードに必要なデータの在処を聞いて取得します。
また、データアーキテクトがエンタープライズデータモデルを設計するとき、モデルを構成する各データのメタデータを定義しますが、その際、データアーキテクトは、データスチュワードに依頼して、メタデータをデータカタログに登録してもらいます。
このように、3つの役割は互いに協力しながらタスクを遂行します。
なお、各役割に求められるスキルセットは次のようになります。
データスチュワード

  • コアとなるメタデータ(データドメイン含む)を作成し維持・管理する能力。
  • データに関するルールを定め文書化する能力。
  • データ品質に関する問題を発見し解決する能力。
  • データガバナンス運営能力。

データアーキテクト

  • データの品質要件をデータアーキテクチャに展開する能力。
  • 全社単位および各事業単位の全体概念データモデルを設計する能力。
  • 全社単位および各事業単位のビジネスモデルを分析する能力。
  • 全社単位および各事業単位のデータフローを設計する能力。
  • 業務領域単位の概念データモデルおよび論理データモデルを設計する能力。
  • アプリケーション単位の論理データモデルおよび物理データモデルを設計する能力。

データアナリスト

  • ビジネス課題を理解し、データによって解決すべきタスクに展開する能力。
  • 記述的分析(Descriptive Analytics)スキル
    過去に何が起こったかをデータから読み取り説明する能力。
  • 予測的分析(Predictive Analytics)スキル
    将来何が起こるかデータから読み取り予測する能力。
  • 処方的分析(Prescriptive Analytics)スキル
    データを分析してビジネス課題を解決する最適な処方を提示する能力。

さて、以上を踏まえて、データガバナンス組織を設計すると次のようになります。

これは一つの例ですが、各事業単位にデータマネジメントサービス(執行側)として3つの役割が配置され、新規事業に関わるアプリケーション開発プロジェクトのメンバーがデータモデルを設計し、データ分析できるよう教育、支援を行います。
また、企業全体で、データガバナンスオフィス(監督側)として、チーフとなる3つの役割が配置され、各事業単位のデータマネジメントサービスが正しくデータマネジメントしているか監督します。

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

次に、データマネジメントプロセスの設計について説明します。
データマネジメントプロセスは、次のようなデータライフサイクルの活動から構成されます。

データライフサイクルの各活動におけるデータマネジメントプロセスは次のようになります。

計画

データ戦略の策定

データを計画するプロセスは、事業戦略を踏まえて、資産価値があり投資すべき戦略的データを特定するプロセスです。
事業戦略をデータ戦略に落とし込むプロセスを設計します。
戦略的データは、体系的に考える必要があります。
例えば、戦略上重要な市場セグメントの顧客に関するデータを5W1Hで考えてみましょう。

  • Who
    この場合、Whoが顧客データになります。
  • When・How
    「いつ、どうしたは」、契約、購買、支払(支払方法含む)、Webアクセスなど顧客の行動データになります。
  • What
    「何を」は、商品やサービスなど顧客の購買対象(何を購買したか)など、顧客が求めるもの、つまり、行動の対象となるデータになります。
  • Where
    「どこで」は、どこの店舗で購買したかなど、行動場所のデータになります。
    その際、天候など、行動したタイミング(When)の状況がわかるデータも有効です。
  • Why
    最後に「なぜ」ですが、これは、行動の動機につながるデータで、顧客の嗜好や性格、感情など、顧客の行動を分析することで得られるインサイト(洞察)データです。

設計・実装

データアーキテクチャの設計

データの計画で特定された戦略的データの構造や品質要件をデータアーキテクチャに反映し、メタデータとしてデータカタログに登録するプロセスを設計します。
データアーキテクチャを設計することで、企業全体のデータを俯瞰することができ、漏れなくダブりなく戦略的データを特定することができるようになります。

システム開発(データ設計・実装)

また、システム開発の設計・実装プロセスのデータを設計・実装する過程に、データの品質要件を定義し、それが満たされるシステムが設計されているか(画面やビジネスロジックにおけるデータのバリデーションなど)チェック後、メタデータとして登録するプロセスを組み込みます。

生成・取得

データを生成・取得するビジネスプロセス

ここでは、設計、実装されたデータが生成・取得されるビジネスプロセスを洗い出し、その過程にデータをプロファイリングするプロセスを組み込みます。
データのプロファイリングとは、設計されたデータの構造と実際のデータの内容を比較して実情を推測、理解することで、具体的には次のような内容を確認します。

  • データ構造で定義されたものと、実際のデータから推測されるデータフォーマット
  • 入力されたデータにNULL値、空白、初期値がどれだけあるか
  • データ値が規定の有効値の集合(データドメイン)とどれだけ乖離しているか
  • 関連フィールドやカーディナリティルールなど、データセットに内在するパターンとリレーションシップ
  • 他のデータセットとの関連性

品質の悪いデータが生成・取得されると、その後のデータライフサイクル全てに影響するので、データが生成・取得される過程はとても重要です。
Garbage in, Garbage out(ガベージイン・ガベージアウト)。ゴミデータからはゴミデータしか生まれないのです。

格納・維持

データリポジトリ(DWH/DL)にデータを格納するプロセス

ここでは、生成・取得されたデータをETLなどで変換してデータウェアハウス(DWH)やデータレイク(DL)などのリポジトリに格納するプロセスデータをプロファイリングするプロセスを組み込みます。

データを更新するビジネスプロセス

データを更新するビジネスプロセスを洗い出し、データ品質をチェックするプロセスを組み込みます。
データライフサイクルの過程で、データがどのように変換、更新されたかをデータリネージュ(データの系統)として記録すると、データ品質の変化を追跡することが可能になります。

システム保守(データ再設計・実装)

システムを保守する過程で、データを再設計・実装する場合、メタデータを変更します。

破棄

データを削除するビジネスプロセス

データを削除するプロセスを洗い出し、データの一貫性が損なわれないかなど、データをプロファイリングするプロセスを組み込みます。

システム破棄

システムを破棄するプロセスに、メタデータを削除する過程を組み込みます。

利活用

データ分析

ここでは、データアナリストや業務担当者が、蓄積されたデータを分析してビジネス課題を解決するプロセスを設計します。
その過程で、データウェアハウスに格納されたデータを変換してデータマートに移す場合、そこにデータをプロファイリングするプロセスを組み込みます。
さて、データ分析をして経営に有効活用するためのの手法にCRISP-DM(Cross-Industry Standard Process for Data Mining)があります。

CRISP-DMでは、機械学習モデルを作成する前に、まず、データを理解し、準備する過程があります。
実は、多くの企業では、分析に必要なデータの構造や所在がわからず、データ分析の一連のプロセスの中で、多大なコストがデータの理解と準備に費やされていると聞きます。
データカタログなどに記録されたメタデータを活用することによって、分析に必要なデータが正しく理解でき、迅速に準備できるようになれば、データ分析の質とスピードが上がるはずです。
※なお、CRISP-DMについて詳しく知りたい方は、データサイエンスとはという記事をご覧ください。

システム開発(データ調査)

データを利活用するもう一つのプロセスがシステム開発です。
システム開発するとき、必要なデータが既にあるにもかかわらず、新たに設計、実装されると、データが重複し、データの一意性が低下します。
なので、システム開発する過程に、データカタログなどを参照して必要なデータを探すプロセスを組み込みます。
それから、データアナリストや業務担当者、システム開発者にデータカタログの使い方や、品質の高いデータモデルの設計方法を教育するプロセスも重要です。

改善・強化

データ品質改善

データの改善・強化は、マネジメントサイクル(PDCA)でいうとAction、継続的改善の部分になります。
上述したデータ品質をチェックするプロセスがPDCAのCheck、検証プロセスです。
データをプロファイリングすることでデータ品質の程度を測定し、問題がある場合、
データのライフサイクル全体を通して、どこに原因があるか探し、それを取り除くプロセス
データの品質を管理するための属性を追加するなどデータを強化するプロセス
を設計します。

なお、データマネジメントプロセスを業務フローで表す場合、業界標準の表記法UMLのアクティビティ図を使うと、コミュニケーションギャップを軽減することができます。

データマネジメントシステムの設計

最後に、データマネジメントシステムの設計方針に基づいてデータマネジメントシステムを設計します。

この例では、事業単位のアプリケーションがESBを介して機能別のマイクロサービスを共有しています。
また、アプリ基盤のマイクロサービスは、データ基盤のDAO(データアクセスオブジェクト)を介してデータにアクセスします。
データ構造をDAOによってラップすることで、データ構造の変更によるリスクを局所化することができます。
このデータマネジメントシステムは、
データを集中管理し、効率的にデータ品質が維持向上できるようにする
というデータマネジメントシステムの設計方針に則って設計されています。
これは、「データは集中させ、機能は分散させる」という方針に基づいたものです。
一般的に集中と分散は、コストとリスクのトレードオフの関係にあります。
データ構造は、比較的変化し難く、変更の頻度が少ないので、変更によるリスクが小さく、
アプリケーション機能は、変化し易く、変更の頻度が多いので、変更によるリスクが大きい
と考えることができます。
なので、データは集中管理した方が効率がよく、データ基盤にマスターデータ管理(MDM)やDWHを適用し、アプリケーション機能は分散した方がリスクが小さいため、アプリケーション基盤にはマイクロサービスを適用しています。
データ基盤のアーキテクチャをクローズアップすると次のようになります。

-DX, データ

執筆者:

関連記事

NoSQLとは何か、わかりやすく解説

少し前からビッグデータという言葉をよく聞きます。 モバイルデバイスが普及することによって、様々な種類のデータを簡単に送受信できるようになりました。 Twitterは1日あたり10テラバイトを超えるデー …

DXによる企業変革の進め方【耕して肥やす】

記事「DXを成功させる3つの鍵」を踏まえて、ここでは、DXによる企業変革の進め方について、以下の観点で解説します。 DXによって企業が目指すべき姿 DXによる企業変革の進め方 DXによって企業が目指す …

【DXの進め方】バリューチェーンと業務の分析

記事「DXによる企業変革の進め方」では、 既存の事業を運営しながら、 企業基盤の構築 事業の深化と探索 という、2つのプロセスを並行させて企業を再構築する方法について解説しました。 そこでは、まず、設 …

データマネジメント知識体系【DMBOK】とは

5Gが普及すると、ますます、IoTなどにより発生するビッグデータを、AIを活用してビジネスに活かすことが当たり前になってきます。 データは21世紀の石油と言われています。 「稼ぐ力を持つ資産としてのデ …

ドメイン駆動設計入門【DDDをわかりやすく解説】

突然ですが、エンジニアの皆さま、Javaで開発したWebアプリケーションの構成、このようになっていませんか? データとgetter/setterだけのオブジェクト(JavaBean) 画面のコントロー …