皆様は、データドリブン経営という言葉を聞いたことがあるでしょうか。
データドリブン経営とは、稼ぐ力をもつ資産としてのデータを経営に活かすことで経営目的（パーパス）を実現する手法のことです。
マネジメントサイクルの各活動（計画、実行、検証、改善）で、データを利活用するわけですが、そのためには、データライフサイクルを管理してデータ品質を維持・向上させるデータマネジメントが重要です。
データマネジメント知識体系（DMBOK）では、データマネジメントを、
データという資産の価値を提供し、管理し、守り、高めるために、それらのライフサイクルを通して計画、方針、スケジュール、手順などを開発、実施、監督すること
と定義しています。
また、DMBOKでは、データマネジメントのゴールを次のように設定しています。
- 自社や顧客、従業員、ビジネスパートナーを含むステークホルダーの情報ニーズを理解し、サポートする
- データ資産を取得し、保管し、保護し、健全性を担保する
- データの品質を担保する
- ステークホルダーが保有するデータのプライバシーと機密性を確保する
- 不正または不適切なデータへのアクセス、操作、使用を防止する
- 企業が付加価値を創造するためにデータを効果的に利用できるようにする
なので、データマネジメントは、データを
- セキュリティ
データの機密性、完全性、可用性が確保できているか - 品質
データの正確性、完全性、一意性、一貫性、適時性など、データがどれだけ信頼できるか - 経済性
データが、どれだけ経済価値を生み出せるか
という観点から評価し、それらを維持向上させる活動ということができます。
なので、データドリブン経営、および、データマネジメントが機能するかどうかは、データは価値を生み出す重要な資産であるという価値観が風土として組織にどの程度浸透しているかどうかによって決まるということになります。
さて、DMBOKでは、セキュリティや品質が確保されていないデータがもたらす事象として以下の例をあげています。
- 誤請求
- 顧客サービスコールの増加とそれを解決する能力の低下
- 事業機会の逸失による収益損失
- 合弁・買収の間に発生する業務統合の遅延
- 不正行為発覚の増加
- 不正なデータに起因する業務上の意思決定不備がもたらす損失
- 良好な信用力の欠如による事業の損失
なので、データを保護し、その品質を維持向上させてデータの資産価値を上げることがデータマネジメントの根幹になります。
それでは、データマネジメントはどのように導入すればよいのでしょうか。
ここでは、データマネジメントを導入するプロセスを次のように考えます。
データマネジメントの設計では、データマネジメントの「基本方針」、「対策基準」、「実施手順」をデータマネジメントポリシーとして定義します。
- 基本方針（Policy）
組織における、データマネジメントに対する根本的な考え方を表すものであり、組織が、「なぜデータマネジメントが必要であるのか」や「どのような方針でデータマネジメントを考えるのか」といった、組織のデータマネジメントに対する取組み姿勢を示すものです。 - 対策基準（Standard）
実際にデータマネジメントを行う上での指針、指標、基準を記述します。
多くの場合、対策基準には、基本方針を実現するために、どのような対策を行うのかという一般的な規定のみを記述します。
対策基準は、データアーキテクチャ（What）、データガバナンス組織（Who）、データ基盤（Where）の観点で定義します。 - 実施手順（Procedure）
実施手順には、データマネジメントの対策基準を具体的な手順（データマネジメントプロセス：When・How）として記載します。
次に、データマネジメント戦略を、「ビジョン」、「戦略」、「アクションプラン」という観点で策定します。
- ビジョン
組織や企業の代表者による「どこに向かってデータマネジメントを進めるのか（目標：Goal）」や「目標に向かってどのようにデータマネジメントを進めるのか」といった宣言が含まれます。 - 戦略
実際にデータマネジメントを進める上での戦略を、データ戦略、データガバナンス体制、データマネジメントサービスの観点で策定します。 - アクションプラン
データマネジメントのアクションプランですが、これは、個別戦略に従って、データマネジメントを導入するアクションプランです。
データマネジメント導入計画に従って、構築フェーズでは、データガバナンス組織、データ基盤を確立、構築し、データマネジメントポリシーで定義したデータマネジメントプロセスがまわるか検証します。
ここでは、設計フェーズで考えるデータマネジメントの骨格を次の観点で説明します。
- データマネジメントの設計
- データマネジメント戦略の策定
基本方針の設定
データマネジメントの基本方針（Policy）は、次の例のように、なぜデータマネジメントを行うのか、その思想的拠り所になるものです。
事業パーパスを実現するために以下の方針でデータマネジメントを行う。
- まず、データのセキュリティを確保して、事業パーパスの実現を阻害するリスクを下げる
- 次に、データの品質を高めて、信頼の高いデータを使って事実に基づいた判断ができるようにする
- その上で、資産としてのデータの価値を高めビジネスの持続性を上げる
そのために、
- 事業パーパスの実現を阻害する可能性のあるデータを明らかにし、それをコントロールするための組織、システム、ビジネスプロセスを設計する
- 事業パーパスを実現するために有効なデータを明らかにし、データの品質や経済価値を高めるための組織、システム、ビジネスプロセスを設計する
なお、対策基準には、次のように、より具体的な方針を宣言します。
- 基準
以下の指標と基準をもってデータの品質を評価します。
正確性
事実が正確にデータとして記録されていること。 - 対策
そのために、正確にデータを生成、取得できるシステムとビジネスプロセスを設計します。
データアーキテクチャの設計
データアーキテクチャは、データマネジメントの根幹となる青写真です。
データアーキテクチャをベースにデータマネジメントの実施手順が設計されるので、データアーキテクチャを作らずにデータマネジメントを行うことは、地図を持たずに航海するようなものです。
※詳細は下記「データマネジメントプロセスの設計」の「データアーキテクチャの設計」プロセスを参照してください。
なお、データアーキテクチャの詳細については、データアーキテクチャの設計方法を参照ください。
データガバナンス組織の設計
次に、データガバナンス組織の設計について説明します。
データガバナンス組織ですが、まず、役割としてのジョブ（職務）を設計し、それから各ジョブに部門を割り当てて体制を設計します。
部門は経営環境の変化に応じて変わりますが、ジョブは不変です。
データガバナンス組織の設計ではジョブを設計し、データマネジメント戦略を受けて、ジョブに部門を割り当ててデータガバナンス体制を設計します。
さて、ここでは、データマネジメントを行う役割を、次の観点で分類します。
- 利用と提供
データを利活用して事業課題を解決する責務を持つデータ利用者と、データ利用者が効率的、効果的にデータを利活用できるようにする責務を持つデータ提供者を分けます。 - 内部統制
内部統制を働かせるために、データマネジメントを監督する側と、実行する側で職務を分掌します。
DMBOKではデータが適切にマネジメントされるよう統治するデータガバナンス組織を次のように表しています。
- 立法機能
ポリシー、規定、エンタープライズデータアーキテクチャを定義する。 - 司法機能
課題管理と報告。 - 行政機能
データの保護とサービス、行政責任。
- 立法機能
- 管理範囲
全社レベルのデータを管理する役割と、各社レベルのデータを管理する役割で分類します。 - 意思決定
最終的な意思決定を行う責任者と、職務を遂行する担当者で分類します。
さて、データマネジメントを行う重要な役割は次の３つです。
- データスチュワード
データの生成から強化までのライフサイクルを通して、データの品質、セキュリティ、有効性（経済価値）という観点からデータの資産価値を維持、向上させる役割。
DMBOKでは、データスチュワードのタスクを次のように定義しています。- コアとなるメタデータの作成と管理
- データに関するルールの文書化
- データ品質の問題管理
- データガバナンス運営
- データアーキテクト
データの計画段階で、データアーキテクチャを設計し、アプリケーションのデータ設計・実装結果を検証する役割。 - データアナリスト
データ資産を有効活用して事業の経済価値を上げる役割。
データサイエンティストともいいます。
データアナリストが行うデータ分析には次の３種類があります。- 記述的分析（Descriptive Analytics）
過去に何が起こったかをデータから読み取り説明するための分析。 - 予測的分析（Predictive Analytics）
将来何が起こるかデータから読み取り予測するための分析。 - 処方的分析（Prescriptive Analytics）
データを分析してビジネス課題を解決する最適な処方を提示するための分析。
- 記述的分析（Descriptive 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などを介してデータを利用する場合や、担当者がデータカタログを利用する場合も含まれます。
データマネジメント戦略の検証
データマネジメントの成熟度を検証し、目標が達成できたか確認します。
詳細は、データマネジメント戦略の策定を参照ください。
データマネジメントポリシーの適用
データマネジメントポリシーの適用は、次のように他のプロセスに含まれる監査部分になります。
監査したという事実は、ビジネスメタデータに記録され、データのリネージュとして反映されます。
さて、データマネジメントプロセスが明確になると、各ジョブで何をすべきかが明確になります。
そこで、業務フローのアクティビティをジョブ（職務）のタスク（課業）として定義します。
例えば、各社データ管理実行者の場合、次のようになります。
データマネジメント導入ビジョンの設定
データマネジメントの基本戦略は、具体的なデータマネジメントの目標と達成期限を定めます。
データマネジメントの最終目標は、事業目標の一環として設定します。
データマネジメントの目標は、データマネジメントのレベル×適用範囲（スコープ）でフェーズ分けして設定することができます。
まず、データマネジメントのレベルですが、主にデータマネジメントプロセスの成熟度とデータ利活用の成熟度を基準にすると、次のような例を考えることができます。
データマネジメントプロセスの成熟度は、CMMI(Capability Maturity Model Integration：能力成熟度モデル統合) ベースに考えます。
CMMIとは、組織がプロセスをより適切に管理できるようになることを目的として遵守するべき指針を体系化したものです。
- レベル１
- データマネジメントプロセスの成熟度
データマネジメントプロセスを導入する際の、出発点のレベル。 - データ利活用の成熟度
データを活用できていない状態。
- データマネジメントプロセスの成熟度
- レベル2
- データマネジメントプロセスの成熟度
管理された状態。
データマネジメントポリシーおよびデータマネジメント戦略が存在し、反復してプロセスを実行できるレベル。
データの品質維持向上およびデータ利活用ができるデータ基盤が整備されている。 - データ利活用の成熟度
データの品質を維持向上させながらデータを活用することができるレベル。 - KPIの例
データ基盤整備率
データ品質目標達成率
- データマネジメントプロセスの成熟度
- レベル3
- データマネジメントプロセスの成熟度
定義された状態（制度化された状態）。
プロセスが標準ビジネスプロセスとして明示的に定義され関係者の承認を受けているレベル。 - データ利活用の成熟度
データを活用して意思決定することができるレベル。
データを活用して業務を改善することができる。
主にデータの記述的分析（（Descriptive Analytics）を行う。 - KPIの例
データを活用した業務改善実施数/年
- データマネジメントプロセスの成熟度
- レベル4
- データマネジメントプロセスの成熟度
定量的に管理された状態（制御できる状態）。
プロセス管理が実施され、さまざまなタスク領域を定量的に制御しているレベル。 - データ利活用の成熟度
データを活用して業務と資源を最適化することができるレベル。
データを活用して事業戦略（事業の方向性）を策定することができる。
主にデータの予測的分析（Predictive Analytics）を行う。 - KPIの例
データを活用した業務改革実施数/年
- データマネジメントプロセスの成熟度
- レベル5
- データマネジメントプロセスの成熟度
最適化している状態（プロセスを定量的に改善する状態）。
継続的に自らのプロセスを最適化し改善しているレベル。 - データ利活用の成熟度
データを活用してステークホルダーに対す価値を創出することができるレベル。
データを活用して事業を変革・創出することができる。
主にデータの処方的分析（Prescriptive Analytics）を行う。 - KPIの例
データを活用した事業変革・創出数/年
- データマネジメントプロセスの成熟度
次に、データマネジメントを適用する範囲ですが、次のような例を考えることができます。
- ホールディングスにデータマネジメントを適用する
- 主要事業にデータマネジメントを適用する
- グループ全体にデータマネジメントを適用する
これらのデータマネジメントのレベル×スコープでフェーズを分けて目標を設定します。
データ戦略の策定
データ戦略では、データアーキテクチャを構成するデータのうち戦略的に重要なデータを明確にします。
データマネジメントを設計する過程で明確にする、事業パーパスの実現を阻害する可能性のあるデータや、事業パーパスを実現するために有効なデータと戦略的に重要なデータは違います。
事業パーパスのある時点の実例が事業ビジョン、事業ビジョンをどう実現するかを示したのが事業戦略です。
なので、戦略的に重要なデータは、事業戦略に基づいて選択する必要があります。
例えば、市場の占有率×成長率で事業単位の組み合わせを考える事業ポートフォリオに基づいて全社戦略を考える場合、投資対象となる事業単位に所属するデータが投資対象となり、投資レベルによってリソースの配分の程度が決まります。
この例の場合、新規事業の成長を促す戦略（探索）と、次の花形をつくる戦略（深化）があり、それぞれに所属するデータが投資対象になります。
なので、事業パーパスを実現するために有効なデータの一つに顧客の問い合わせデータがあった場合、投資対象事業の問い合わせデータが戦略的に優先度の高いデータになります。
データガバナンス体制の設計
データマネジメントサービスの設計
データマネジメント導入計画の策定
基本戦略で、データマネジメント導入全体の流れを定義しました。
「データマネジメント導入計画の策定」では、各フェーズごとのアクションプランを策定します。
[…] 前回、データマネジメントについて解説しましたが、データマネジメントを進める上で欠かせないのがデータアーキテクチャです。 今回は、データアーキテクチャについて次の観点で […]
[…] ここでは、データマネジメントプロセスの一環として、データ品質を管理するプロセスを次の順で解説します。 […]