楽水

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

DX データ

【DMBOKで学ぶ】データマネジメントの導入方法

投稿日:


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

マネジメントサイクルの各活動(計画、実行、検証、改善)で、データを利活用するわけですが、そのためには、データライフサイクルを管理してデータ品質を維持・向上させるデータマネジメントが重要です。
データマネジメント知識体系(DMBOK)では、データマネジメントを、

データという資産の価値を提供し、管理し、守り、高めるために、
それらのライフサイクルを通して
計画、方針、スケジュール、手順などを
開発、実施、監督
すること

と定義しています。
また、DMBOKでは、データマネジメントのゴールを次のように設定しています。

  • 自社や顧客、従業員、ビジネスパートナーを含むステークホルダーの情報ニーズを理解し、サポートする
  • データ資産を取得し、保管し、保護し、健全性を担保する
  • データの品質を担保する
  • ステークホルダーが保有するデータのプライバシーと機密性を確保する
  • 不正または不適切なデータへのアクセス、操作、使用を防止する
  • 企業が付加価値を創造するためにデータを効果的に利用できるようにする

なので、データマネジメントは、データを

  • セキュリティ
    データの機密性、完全性、可用性が確保できているか
  • 品質
    データの正確性、完全性、一意性、一貫性、適時性など、データがどれだけ信頼できるか
  • 経済性
    データが、どれだけ経済価値を生み出せるか

という観点から評価し、それらを維持向上させる活動ということができます。
なので、データドリブン経営、および、データマネジメントが機能するかどうかは、データは価値を生み出す重要な資産であるという意識が組織にどの程度浸透しているかどうかによって決まるということになります。
さて、DMBOKでは、セキュリティや品質が確保されていないデータがもたらす事象として以下の例をあげています。

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

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

データマネジメントの設計では、データマネジメントの「基本方針」、「対策基準」、「実施手順」をデータマネジメントポリシーとして定義します。

  • 基本方針(Policy)
    組織における、データマネジメントに対する根本的な考え方を表すものであり、組織が、「なぜデータマネジメントが必要であるのか」や「どのような方針でデータマネジメントを考えるのか」といった、組織のデータマネジメントに対する取組み姿勢を示すものです。
  • 対策基準(Standard)
    実際にデータマネジメントを行う上での指針、指標、基準を記述します。
    多くの場合、対策基準には、基本方針を実現するために、どのような対策を行うのかという一般的な規定のみを記述します。
    対策基準は、データアーキテクチャ(What)、データガバナンス組織(Who)、データマネジメントシステム(Where)の観点で定義します。
  • 実施手順(Procedure)
    実施手順には、データマネジメントの対策基準を具体的な手順(データマネジメントプロセス:When・How)として記載します。

次に、データマネジメント戦略を、「基本戦略」、「個別戦略」、「導入計画」という観点で策定します。

  • 基本戦略
    組織や企業の代表者による「どこに向かってデータマネジメントを進めるのか(目標:Goal)」や「目標に向かってどのようにデータマネジメントを進めるのか」といった宣言が含まれます。
  • 個別戦略
    実際にデータマネジメントを進める上での戦略を、データ戦略、データガバナンス体制、データマネジメントサービスの観点で策定します。
  • 導入計画
    データマネジメントの導入計画ですが、これは、個別戦略に従って、データマネジメントを導入するアクションプランです。

データマネジメント導入計画に従って、構築フェーズでは、データガバナンス組織、データマネジメントシステムを確立、構築し、データマネジメントポリシーで定義したデータマネジメントプロセスがまわるか検証します。

ここでは、設計フェーズで考えるデータマネジメントの骨格を次の観点で説明します。

基本方針の設定

データマネジメントの基本方針(Policy)は、次の例のように、なぜデータマネジメントを行うのか、その思想的拠り所になるものです。
事業パーパスを実現するために以下の方針でデータマネジメントを行う。

  1. まず、データのセキュリティを確保して、事業パーパスの実現を阻害するリスクを下げる
  2. 次に、データの品質を高めて、信頼の高いデータを使って事実に基づいた判断ができるようにする
  3. その上で、資産としてのデータの価値を高めビジネスの持続性を上げる

そのために、

  • 事業パーパスの実現を阻害する可能性のあるデータを明らかにし、それをコントロールするための組織、システム、ビジネスプロセスを設計する
  • 事業パーパスを実現するために有効なデータを明らかにし、データの品質や経済価値を高めるための組織、システム、ビジネスプロセスを設計する

なお、対策基準には、次のように、より具体的な方針を宣言します。

  • 基準
    以下の指標と基準をもってデータの品質を評価します。
    正確性
    事実が正確にデータとして記録されていること。
  • 対策
    そのために、正確にデータを生成、取得できるシステムとビジネスプロセスを設計します。

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

データアーキテクチャは、データマネジメントの根幹となる青写真です。
データアーキテクチャを起点に、データマネジメントの実施手順が設計されます。
例えば、次のように、データアーキテクチャのEDM(エンタープライズデータモデル)から重要なデータを選定し、データフローから、そのデータを管理するシステムを明らかにし、どのビジネスプロセスのどのアクティビティでどのようなコントロールをすべきか設計することができます。
データセキュリティを確保するための設計の流れ

データ品質を上げるための設計の流れ

データアーキテクチャの詳細については、データアーキテクチャの設計方法を参照ください。

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

次に、データガバナンス組織の設計について説明します。
データガバナンス組織ですが、まず、役割としてのジョブ(職務)を設計し、それから各ジョブに部門を割り当てて体制を設計します。
部門は経営環境の変化に応じて変わりますが、ジョブは不変です。
データガバナンス組織の設計ではジョブを設計し、データマネジメント戦略を受けて、ジョブに部門を割り当ててデータガバナンス体制を設計します。
さて、ここでは、データマネジメントを行う役割を、次の観点で分類します。

  • 利用と提供
    データを利用する側か提供する側で分類します。
  • 内部統制
    内部統制を働かせるために、データマネジメントを監督する側と、実行する側で職務を分掌します。
    DMBOKではデータが適切にマネジメントされるよう統治するデータガバナンス組織を次のように表しています。

    • 立法機能
      ポリシー、規定、エンタープライズデータアーキテクチャを定義する。
    • 司法機能
      課題管理と報告。
    • 行政機能
      データの保護とサービス、行政責任。
  • 管理範囲
    全社レベルのデータを管理する役割と、各社レベルのデータを管理する役割で分類します。
  • 意思決定
    最終的な意思決定を行う責任者と、職務を遂行する担当者で分類します。

さて、データマネジメントを行う重要な役割は次の3つです。

  • データスチュワード
    データの生成から強化までのライフサイクルを通して、データの品質、セキュリティ、有効性(経済価値)という観点からデータの資産価値を維持、向上させる役割。
    DMBOKでは、データスチュワードのタスクを次のように定義しています。

    • コアとなるメタデータの作成と管理
    • データに関するルールの文書化
    • データ品質の問題管理
    • データガバナンス運営
  • データアーキテクト
    データの計画段階で、データアーキテクチャを設計し、アプリケーションのデータ設計・実装結果を検証する役割。
  • データアナリスト
    データ資産を有効活用して事業の経済価値を上げる役割。
    データサイエンティストともいいます。
    データアナリストが行うデータ分析には次の3種類があります。

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

以上を踏まえて、ジョブを設計すると次のようになります。

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

次に、データマネジメントシステムの設計について説明します。
企業全体のシステム構成のイメージは次のようになります。

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

データマネジメントシステムの特徴は次のようになります。

  • マスターデータや参照データは全社で一元管理される
  • SoR(System of Record:記録システム)のデータは、変換されてデータウェアハウスに取り込まれる
  • データウェアハウスのデータは目的別にデータマートを介して利用される
  • データレークのデータはAIやIoTなどさまざまな形で利用される
  • 資産としてのデータはメタデータが定義されたデータカタログで管理される
  • データはデータ連携基盤を介してやり取りされる

データマネジメントシステムには、コマンド・クエリ責務分離 (CQRS: Command and Query Responsibility Segregation)パターンが適用されます。
CQRSは、データストアに対する更新操作を集めたコマンド処理と、読み取り操作(クエリ)を集めたクエリ処理を完全に分離するアーキテクチャパターンです。

この場合、SoRが書き込み用データストアを管理し、データリポジトリが読み込み用データストアになります。
なお、システムに関連する役割は次のようになります。

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

次に、データマネジメントプロセスの設計について説明します。
データマネジメントプロセスは次のように分類することができます。

これは、次の観点で分類されています。

  • 内部統制
    監督するプロセスと実行するプロセスで分類します。
  • マネジメントサイクル
    計画(Plan)、実施(Do)、検証(Check)、改善(Act)で分類します。
  • データライフサイクル
    データのライフサイクルに応じてプロセスを分類します。
    データのライフサイクルは次のようになります。

    データマネジメントシステムに対応させると次のようになります。

データが生成・取得され、変換され、破棄されるという流れはデータのリネージュ(系統)としてデータカタログに記録されていきます。
代表的なデータマネジメントプロセスについて見ていきましょう。

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


全社データアーキテクトがデータマネジメントポリシーの一環として設計したデータアーキテクチャをベースに、全社データ管理実行者がデータカタログにビジネスメタデータを登録します。

データマネジメント計画の策定


全社データ管理責任者は、年間のシステム投資計画(いつどのようなシステム開発を実施するのか)を参照して、年間のデータマネジメント計画を策定します。
年間のデータマネジメント計画は、システム開発やシステム処分のタイミングに合わせて、データ設計の検証、データ取得・生成の検証、データ変換・蓄積の検証、データ利用の検証、データ破棄の検証を実施する計画、および、既存のシステムに対する定期的なデータ取得・生成の検証、データ変換・蓄積の検証、データ利用の検証を実施する計画を立案したもです。
また、すでに運用されている既存のデータに対する
全社データガバナンス責任者は、年間データマネジメント計画の内容を監査します。

データ設計の検証


システム開発者は、システム開発時、データアーキテクチャを継承して各システムのデータモデルを設計します。
データアーキテクトは、データ品質やデータセキュリティの観点でデータモデルの内容を検証します。
データアーキテクトは、データモデルだけでなく、UIのバリデーション、データの変換ロジック(データの変換・蓄積の場合)、データのアクセスコントロールでデータ品質やセキュリティが担保されているか検証します。
データアーキテクトがデータアーキテクチャを更新し、データ管理実行者がビジネメタデータを更新することで、各システムのデータモデルとの整合性を保ち
データガバナンス実行者は、データ設計の検証結果を監査し、問題なければビジネスメタデータのデータリネージュを更新します。

データ生成・取得の検証


システム開発でシステムテストが終了後、システム開発者は、物理データモデルの内容をテクニカルメタデータとして登録後、実データを生成、取得します。
※データカタログ管理ツールには、物理データモデルの内容をテクニカルメタデータに自動登録する機能があります。
各社データ管理実行者は、ユーザー受け入れテストの一貫として、データのプロファイリングやデータのセキュリティ検証を行い、問題があれば、それを解決し、必要に応じてデータの強化・改善を行います。
また、年間データマネジメント計画に従い、定期的に既存システムのデータ生成・取得に対するデータのプロファイリングやデータのセキュリティ検証も行い、問題があれば、それを解決し、必要に応じてデータの強化・改善を行います。
データガバナンス実行者は、データ生成・取得の検証結果を監査し、問題なければビジネスメタデータのデータリネージュを更新します。

データ利用者のアクセスコントロール


データ利用者は、データカタログを参照し、必要なデータがある場合、ビジネスメタデータとして登録されているデータオーナー(各社データ管理責任者)に利用依頼の連絡をします。
データオーナーがデータのアクセスを許可する場合、システム開発者は、データ利用者が必要なデータにアクセスできるようにします。
データ利用者のアクセスコントロールには、担当者がデータを利用する場合だけでなく、システムがAPIなどを介してデータを利用する場合や、担当者がデータカタログを利用する場合も含まれます。

データマネジメントポリシーの適用

データマネジメントポリシーの適用は、次のように他のプロセスに含まれる監査部分になります。
監査したという事実は、ビジネスメタデータに記録され、データのリネージュとして反映されます。

さて、データマネジメントプロセスが明確になると、各ジョブで何をすべきかが明確になります。
そこで、業務フローのアクティビティをジョブ(職務)のタスク(課業)として定義します。
例えば、各社データ管理実行者の場合、次のようになります。

基本戦略の策定

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

  • レベル1
    • プロセスの成熟度(CMMI)
      データマネジメントプロセスを導入する際の、出発点のレベル。
    • データ利活用の成熟度
      データを活用できていない状態。
  • レベル2
    • プロセスの成熟度(CMMI)
      管理された状態。
      データマネジメントポリシーおよびデータマネジメント戦略が存在し、反復してプロセスを実行できるレベル。
      データの品質維持向上およびデータ利活用ができるデータマネジメントシステムが整備されている。
    • データ利活用の成熟度
      データの品質を維持向上させながらデータを活用することができるレベル。
    • KPIの例
      データマネジメントシステム整備率
      データ品質目標達成率
  • レベル3
    • プロセスの成熟度(CMMI)
      定義された状態(制度化された状態)。
      プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル。
    • データ利活用の成熟度
      データを活用して意思決定することができるレベル。
      データを活用して業務を改善することができる。
      主にデータの記述的分析((Descriptive Analytics)を行う。
    • KPIの例
      データを活用した業務改善実施数/年
  • レベル4
    • プロセスの成熟度(CMMI)
      定量的に管理された状態(制御できる状態)。
      プロセス管理が実施され、さまざまなタスク領域を定量的に制御しているレベル。
    • データ利活用の成熟度
      データを活用して業務と資源を最適化することができるレベル。
      データを活用して事業戦略(事業の方向性)を策定することができる。
      主にデータの予測的分析(Predictive Analytics)を行う。
    • KPIの例
      データを活用した業務改革実施数/年
  • レベル5
    • プロセスの成熟度(CMMI)
      最適化している状態(プロセスを定量的に改善する状態)。
      継続的に自らのプロセスを最適化し改善しているレベル。
    • データ利活用の成熟度
      データを活用してステークホルダーに対す価値を創出することができるレベル。
      データを活用して事業を変革・創出することができる。
      主にデータの処方的分析(Prescriptive Analytics)を行う。
    • KPIの例
      データを活用した事業変革・創出数/年

CMMI(Capability Maturity Model Integration:能力成熟度モデル統合) とは、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものです。
次に、データマネジメントを適用する範囲ですが、次のような例を考えることができます。

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

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


データ戦略の策定

データ戦略では、データアーキテクチャを構成するデータのうち戦略的に重要なデータを明確にします。

データガバナンス体制の設計

ジョブに部門を割り当てて、フェーズごとに体制を確立します。

データマネジメントサービスの設計

データマネジメントシステムのDAOをサービスとして設計します。

データマネジメント導入計画の策定

基本戦略で、データマネジメント導入全体の流れを定義しました。

「データマネジメント導入計画の策定」では、各フェーズごとのアクションプランを策定します。

-DX, データ

執筆者:

関連記事

DXを成功させる3つの鍵

前回の記事「なぜDXをする必要があるのか?」でも説明しましたが、 DXとは、 企業を データやデジタル技術を活用することで 環境の変化に応じて迅速に事業を変革・創出し 顧客を中心としたステークホルダー …

テクノロジーアーキテクチャ(TA)とは

エンタープライズアーキテクチャ(EA)とはという記事で、テクノロジーアーキテクチャ(Technology Architecture)とは、IT基盤の設計思想、および、基本構造を表すと書きました。 また …

学習し進化する組織【最強組織のつくり方】

自律的に学ぶ強い組織というテーマはさまざまなところで議論されています。 ピーター・M・センゲ 「最強組織の法則」 競争相手より早く学べる能力、それが競争力を維持する唯一の鍵である。 最強組織の法則―新 …

仮説検証プロセスとは

先行き不透明で予測困難な時代、これまでうまくいった方法を前提に計画、実行、検証、改善というPDCAサイクルをまわしても、前提自体が間違っている場合、うまく機能しません。 このような時代、まず、実験して …

DX(デジタルトランスフォーメーション)とは【わかりやすく解説】

少し前からDX(デジタルトランスフォーメーション)という言葉が頻繁に使われるようになりました。 今回は、DXって聞いたことがあるけど、今ひとつピンとこないという方むけに、 DXとは何か DXが求められ …