データマネジメント導入支援サービスには、次の３つがあります。
- データアーキテクチャ設計ワークショップ
- データマネジメント導入コンサルティングサービス
- データマネジメント運用請負サービス
データアーキテクチャ設計ワークショップ
企業のデータアキテクチャ（データの基本構造）を、次のようなワークショップ形式で設計していただくことで
- 企業全体の既存データには何がありどのような関係になっているのかを体系的に把握する
- ビジネスで付加価値を創出するために必要なデータを戦略的に収集する
ことができます。
- 形式
レクチャー＋グループワークのワークショップ形式です。
ワークショップを通して実際の成果物を作成することで、お客様の知的資産を自身で作成する力を実践的に習得することができます。 - 時間
1ワークショップ
2時間です。 - 参加人数
1ワークショップ
３名から5名が目安です。 - 成果物
世界標準のモデル記述言語UMLを使って、お客様のビジネス、データ、システムのモデル（設計図）を作成します。
成果物はお客様のナレッジ（知的資産）になります。 - 場所
オンライン、または、お客様の指定場所で実施いたします。 - ご費用
ワークショップ単価/人×人数×回数で初回のご費用をお見積りします。
データマネジメント導入コンサルティングサービス
データマネジメント導入支援サービスの内容に従って、ワークショップを実施することで、企業にデータマネジメントを導入するサービスです。
データマネジメント運用請負サービス
データマネジメントを導入後、貴社のデータ管理者としてデータマネジメントの運用を遂行するサービスです。
ご興味がある方は、問い合わせフォームからご連絡ください。
データマネジメントの重要性
変化が激しく、不透明で先行きが予測できない昨今の経営環境を、
- Volatility（変動性）
- Uncertainty（不確実性）
- Complexity（複雑性）
- Ambiguity（不透明性）
の頭文字をとってVUCA（ブーカ）という言葉で表すことがあります。
それは、SNSやモバイル技術によって人と人がつながる時間や距離が短くなったことで、個人の欲望や考えが、複雑なネットワークを介してすぐに世界中に広がり、いつどこで、どんな需要が生まれるか読みづらく、欲求の新陳代謝も激しくなっているからではないでしょうか。
このように、先行き不透明で予測困難な時代、経験や勘に頼るのではなく
稼ぐ力を持つ資産としてのデータをどう利活用してくか
ということが会社を発展させていくための重要な課題となっています。
「データは新しい石油（Data is the new oil）」と言われています。
会社に眠っているデータを、人やAIが、いかにうまく利活用して企業価値を生み出すことができるかが重要なのです。
皆さんは、データドリブン経営という言葉をご存知でしょうか。
一般的には、経営判断やビジネス戦略の決定に、データや分析結果を活用することを指しますが、ここでは、企業をDXの一環と捉えて、
社員一人ひとりがデータを利活用して自律的に業務課題を解決することができる状態に変革すること
を目指します。
データドリブン経営は、データマネジメントが導入された後、マネジメントサイクルの戦略期間の運用フェーズで、データを利活用してマネジメントサイクル（PDCA）を遂行します。
- 計画（Plan）
BSCのKPI目標を実現するためのアクションプラン（実践プラン）を策定します。 - 実行（Do）
アクションプラン（実践プラン）を遂行します。 - 検証（Check）
検証は次の順で行います。問題の特定（Where）
まず、KPI目標値と実績のGapである問題を発見します。
※KPI目標値には、ERMのフレームワークに従って、リスク許容度とリスクの発生可能性と影響度が設定されています。
次に、ドリルダウン・アップやスライシングによる多次元分析によって、どこに問題があるか特定します。
データ分析は、記述的分析、予測的分析、処方的分析に分けることができますが、多次元分析は、記述的分析（Descriptive Analytics）になります。
原因の推定（Why)
多次元分析によって、どこに（Where)問題があるか特定できたら、次に、なぜ（Why)問題が生じたのか、仮説推論（Abduction）で問題の原因を推定します。
そして、回帰分析など機械学習を通して原因の確からしさを検証します。
回帰分析は主に帰納（Induction）的な手法であり、与えられたデータから一般的な法則になる変数間の関係性を導きます。
なお、回帰分析は、予測的分析（Predictive Analytics）になります。 - 改善（Act）
改善は次の順で行います。課題の設定
まず、原因を取り除くことを課題（Issue）として設定します。
解決策の考案
次に、仮説推論（Abduction）で、課題に対する解決策（仮説）を考えます。
AIを活用した解決策（レコメンド、最適な治療法の提案、最適な学習経路の提案など）も含みます。
AIを活用した解決策は、処方的分析（Prescriptive Analytics）になります。
実験計画の策定
次に考案された課題解策を、ランダム化比較実験など因果推論の具体的な実験プランに落とし込みます。
解決策の検証
ランダム化比較実験を行い課題と解決策に、因果関係（一般的法則）があるか検証します。
すべての解決策（仮説）に統計的な有意性がない場合、課題（課題）も見直します。
業務の改革・改善
因果関係が実証された解決策をビジネスプロセスに組み込みます（実験から実践へ）。
ここでは、例えば、これまで人が行っていた活動をAIに置き換えたり、業務の流れそのものを変えるなど大幅なビジネスプロセスの変更を伴うものを業務改革と位置づけ、ある活動のビジネスルールの変更など、従来のビジネスプロセスの大幅な変更を伴わないものを業務改善と位置づけます。
そして、解決策が組み込まれたビジネスプロセスをベースにPlan（アクションプラン）を策定します。
実証された解決策を適用してアクションを実行し結論を導くのは演繹（Deduction）的アプローチです。
以上のように、データドリブン経営は、仮説検証を繰り返す科学的アプローチです。
PDCAの結果をすべて記録しノウハウとして蓄積することで学習し進化する組織が実現します。
さて、データにはライフサイクルがあります。
このデータのライフサイクルの中で、データが直接経済価値を生む活動は「データ利活用」です。
しかし、事業戦略を実現するために必要なデータを特定し、それを、どう収集し、どう活用するか考える計画活動がなければ、会社にとって必要なデータを計画的に収集し活用することはできません。
また、会社全体のデータを設計、実装し、生成、収集しなければ、適切な人が、適切なタイミングで、適切なデータを、適切な形式かつ適切な詳細度で活用することはできません。
間違ったデータの活用は、間違った意思決定につながりますし、誰もが機密データにアクセスできるようであればデータの漏洩リスクが高くなります。
さらに、データを適切に保存、維持しなければ、重要なデータが喪失する可能性もあります。
データを利活用するためには、データのライフサイクルを全体を通して、データを適切に管理するデータマネジメントが必要なのです。
データマネジメントに関する知識を体系立ててまとめた書籍にデータマネジメント知識体系（DMBOK）があります。
DMBOKでは、セキュリティや品質が確保されていないデータがもたらす事象として以下の例をあげています。
- 誤請求
- 顧客サービスコールの増加とそれを解決する能力の低下
- 事業機会の逸失による収益損失
- 合弁・買収の間に発生する業務統合の遅延
- 不正行為発覚の増加
- 不正なデータに起因する業務上の意思決定不備がもたらす損失
- 良好な信用力の欠如による事業の損失
データを効果的、効率的に利活用するためには、データを保護し、その品質を確保してデータの資産価値を維持向上させるためのデータマネジメントがとても重要です。
よく見受けられるのが、高額なデータウェアハウスを導入して、「後は、業務部門が自由に使ってください」、というアプローチです。
いくら箱（物理的基盤）だけ用意しても、
そこで、どんなデータを管理するのか、
メンテナンスはどうするのか、
ほしいデータの有無や所在、利用する際の制約に関する知識は誰が提供するのか、
など、データマネジメント（論理的基盤）が整備されていないと、業務部門も困惑するだけで、どうデータ利活用すればよいかわからず、宝の持ち腐れになってしまうのです。
なお、データマネジメントの詳細については、
【DMBOKで学ぶ】データマネジメントの導入方法
を御覧ください。
データマネジメント導入支援サービスの内容
ここでは、データマネジメント導入コンサルティングサービスの具体的な内容について説明します。
次の図は、DMBOKのデータマネジメント成熟度モデルを、各分野別に詳細化したものです。
データマネジメント成熟度モデルに合わせて、次の図のように、データ利活用の成熟度も上がり、DXが進みます。
データマネジメントの導入は、次の２つのステップで行います。
データマネジメントの定義
データマネジメントの定義は、データマネジメントが定義された状態（レベル３）を目指すステップです。
データマネジメントの定義は、マネジメントサイクルの戦略期間の設計フェーズの位置づけです。
具体的には、次のタスクから構成されます。
データマネジメントジョブのアサイン
最初に、データマネジメントジョブであるデータ管理者と、データ監督者のタスクの実行を監督するデータ監督者をアサインします。
データアーキテクチャ（概念レベル）の設計
次に、データアーキテクチャ（概念レベル）を設計します。
データアーキテクチャの要は、ビジネスのあるべき姿をデータに投影して、企業全体のデータの青写真をつくることです。
DMBOKでは、データアーキテクチャとして、以下の２つのモデルを作成すべきとしています。
- エンタープライズデータモデル（EDM：Enterprise Data Model)
EDMは、全体的でエンタープライズレベルの実装に依存しない概念または論理データモデルであり、企業全体にわたるデータに関して一貫した共通のビューを提供します。
EDMには、企業の重要なデータ、それらの間の関係、重要な手引きとなるビジネスルール（ビジネスメタデータとして記録する）、いくつかの重要な属性が含まれます。
これらは、すべてのデータが関連するシステム開発プロジェクトの基礎を定めているので、どのプロジェクトのレベルのデータモデルもEDMに基づいている必要があります。 - データフロー
データがビジネスプロセスやシステムをどのように移動するかを示すものです。
これは、データリネージュ（データの系統）のドキュメントであり、データの発信元、格納場所、使用場所、さまざまなプロセスとシステムの内部や間を移動する際に、データがどのように変換されるかを示します。
重要なのは、戦略的に重要なデータがどの業務活動で生成・収集、変換・蓄積、利活用、破棄されるのか、業務活動とデータライフサイクルの関係を抑えるとです。
これによって、データ品質を維持・向上させるためには、どの業務活動をどう設計、あるいは、改善すべきかあたりをつけることができます。
- 全社単位の全体概念データモデル
- 活動領域単位の概念データモデルおよび論理データモデル
- アプリケーション単位の論理データモデルおよび物理データモデル
から構成されます。
図：エンタープライズデータモデル 出典：データマネジメント知識体系 第二版
ここで、エンタープライズデータモデルを構成する3つのデータモデル
- 概念データモデル
- 論理データモデル
- 物理データモデル
について説明します。
この３つのモデルの違いを説明するために、まず、MDA（Model-Driven Architecture：モデル駆動アーキテクチャ）について説明します。
MDAは、標準化団体であるOMG(Object Management Group)が「20年持続するソフトウェアアーキテクチャ」を目標として2001年に提唱した概念で、以下の３つのモデルから構成されています。
- CIM（Computation Independent Model）
計算機処理に依存しないモデル。 - PIM（Platform Independent Model）
IT基盤に依存しないモデル。 - PSM（Platform Specific Model）
IT基盤に特化したモデル。
MDAは、この３つもモデルを分けて考えることで、より堅牢なシステムをつくることができるという考え方です。
MDAの考え方を踏まえて３つのデータモデルの違いについて説明します。
- 概念データモデル
ビジネスの仕組を実現するために必要なデータ（業務活動で発生する事実）の構造を明確にする。
CIMに該当する。 - 論理データモデル
システムの機能要件やデータの品質要件（一意性・一貫性・参照整合性など）を満たすデータの構造を明確にする。
PIMに該当する。 - 物理データモデル
システムの非機能要件（特に効率性）を満たし、IT基盤（データベース製品など）に適応したデータの構造を明確にする。
PSMに該当する。
データベース製品を変更する場合、物理データモデルは作り直す必要がありますが、論理データモデルは、IT基盤に依存しないので、再利用することができます。
また、システムの機能要件が変わると、論理データモデルは見直す必要がありますが、概念データモデルは、システムに依存しないので、ビジネスの仕組が変わらない限り不変です。
次の図は、スコープ（縦軸）とレベル（横軸）でエンタープライズデータモデルを分けたマトリクスです。
ビジネスプロセスのスコープのデータモデルが、活動領域のデータモデルになります。
データアーキテクチャ（概念レベル）の設計では、このうち、概念マスターデータモデル、業務概念データモデルを、次の手順で設計します。
事業成長モデルの設計
まず、事業成長モデルを設計することで企業のビジネスの本質を定義します。
概念マスターデータモデルの設計
- 事業成長モデルで顧客の価値観、顧客価値を測る指標、顧客の分類基準を定義する際、顧客エンティティを定義します。
顧客の分類基準は、顧客の参照データになります。 - 事業成長モデルで製品の価値提案、製品価値を測る指標、製品の分類基準を定義する際、製品エンティティを定義します。
製品の分類基準は、製品の参照データになります。 - 事業成長モデルで社員に求める価値観、社員の価値を測る指標、社員の分類基準を定義する際、製品エンティティを定義します。
社員の分類基準は、社員の参照データになります。 - 事業成長モデルで取引先（パートナー）に求める価値観、取引先の価値を測る指標、取引先の分類基準を定義する際、製品エンティティを定義します。
取引先の分類基準は、取引先の参照データになります。 - その他、事業成長モデルでニーズ・シーズの資産と、その価値を測る指標および資産の分類基準を定義する際、各資産のデータタイプを定義します。
各資産の分類基準は、各資産の参照データになります。
資産のうち、アプリケーションタイプとITタイプは、情報紙本ポートフォリオを使って整理します。その際、どのトランザクション処理アプリケーションが、どのデータタイプを管理するのか整理します。
これによって、企業におけるデータの過不足を明確にすることができます。
次の図は、UMLのクラス図で描いた概念マスターデータモデルの例です。
業務概念データモデルの設計
事業成長モデルでバリューチェーンと、それを構成するビジネスプロセスを設計する際、ビジネスプロセスごとのアクティビティフローと業務概念データモデルを設計します。
業務概念データモデルは、アクティビティフローのアクティビティからトランザクションデータタイプを抽出し、概念マスターデータモデルのマスターデータタイプと合わせて設計します。
次の図は、UMLのクラス図で描いた業務概念データモデルの例です。
データ戦略（概念レベル）の策定
データ戦略（概念レベル）は次の内容になります。
戦略的データの特定
事業成長モデルを戦略マップに展開することにっって価値創出プロセスを定義します。
その際、情報資本の一環として、ビジネスプロセスで付加価値を創出するために必要な戦略的データは何か特定します。
戦略的データには、店舗のPOSや、SNS、機械のセンサーなどから取得される生データ（非正規化データ）や、提案書など組織ナレッジになるコンテンツデータなどがあります。
データ統合戦略
データ基盤を構築して、企業全体のマスターデータ、生データ（非正規化データ）、非構造化データ、メタデータを一元管理するかどうか決定します。
データ連携戦略
ESBやEAIで、企業全体のデータ連携を一元管理するデータ連携基盤を構築するか決定します。
次の図は、データ基盤、データ連携基盤、データ分析環境から成るデータ管理基盤のイメージです。
ビジネスメタデータの定義
これまで設計されたデータタイプのビジネスメタデータを定義します。
データマネジメントプロセスの設計
ここでは、次のようなデータマネジメントの運用プロセスを設計します。
- データマネジメント計画の策定
年間のデータマネジメントのアクションプラン（実践プラン）を策定します。 - ドメインモデルの検証
アプリケーション開発プロジェクトでは、業務概念データモデルをインプットにしてドメインモデルを設計します。データ管理者は、その内容を、データ品質やセキュリティの観点で検証し、ビジネスメタデータとして定義します。 - 論理データモデルの検証
アプリケーション開発プロジェクトでは、論理概念データモデルとドメインモデルをインプットにして論理データモデルを設計します。アプリケーショデータ管理者は、その内容を、データ品質やセキュリティの観点で検証し、テクニカルメタデータとして定義します。 - 物理データモデルの検証
アプリケーション開発プロジェクトで設計された物理データモデルの内容を、データ品質やセキュリティの観点で検証し、オペレーショナルメタデータとして定義します。 - IT管理基盤の運用
ITサービスマネジメンのサービスオペレーションの内容に従ってIT管理基盤を運用します。
その一環として、コードマスターのメンテナンスも実施します。 - データ分析環境の構築
データ分析環境のデータマートを構築します。 - データ連携機能の開発
APIや非同期メッセージングの仕組を開発します。 - データ利用者からの問い合わせ対応
データの有無、所在、制約などデータ利用者からの問い合わせに答えます。 - データプロファイリングと評価
年に一度、実データを抽出し、メタデータの定義と合っているか評価します。
データマネジメントの実行
データマネジメントの実行は、データマネジメントが管理された状態（レベル4）を目指すステップです。
データマネジメントの実行は次のフェーズから構成されます。
- 戦略フェーズ
戦略フェーズは、マネジメントサイクルの戦略期間の戦略フェーズです。
戦略フェーズは、次のタスクから構成されます。 - 構築フェーズ
構築フェーズは、マネジメントサイクルの戦略期間の構築フェーズです。
データマネジメント導入プランを遂行するフェーズです。 - 運用フェーズ
運用フェーズは、マネジメントサイクルの戦略期間の運用フェーズです。
データマネジメントを運用するフェーズです。
データマネジメントの定義ステップで設計したデータマネジメントの運用プロセス従って運用します。
データマネジメント組織の設計
まず、データ管理者とデータ監督者に対応する部門を考え、データマネジメント組織を設計します。
データマネジメント組織は、データマネジメントを実施する職務と監督する職務を分掌し、データマネジメントの妥当性を保証します。
データマネジメント組織は、データマネジメントのビジョンをどう実現するか考えた上で、ジョブに部門を割り当てて設計します。
部門は経営環境の変化に応じて変わりますが、ジョブは不変です。
DMBOKでは、データマネジメント組織を次のように表しています。
- 立法機能
ポリシー、規定、エンタープライズデータアーキテクチャを定義する。 - 司法機能
課題管理と報告。 - 行政機能
データの保護とサービス、行政責任。
さて、データマネジメントを行う重要なジョブはデータスチュワード、データアーキテクト、データアナリスト（データサイエンティスト）の３つです。
この３つのジョブを総称してデータ管理者と呼びます。
また、データ管理者のタスク実行を監督するジョブをデータ監督者と呼びます。
次の図は、DMBOKのデータマネジメント組織を簡略化したものです。
アプリケーション戦略の策定
情報紙本ポートフォリオを構成するアプリケーションタイプの開発方法（業務パッケージを適用するかスクラッチ開発するか）を決定します。
次の図は、アプリケーションタイプの特殊性×規模で開発方法を選択した例です。
なお、次の図のERPなどのように、業務パッケージは、通常、複数のアプリケーションタイプに対して適用します。
データ戦略（論理レベル）の策定
データ戦略（論理レベル）は次の内容になります。
データベース戦略の策定
どのデータタイプをどのDB（RDBやNoSQL）で実現するか決定します。
これによってデータの表現形式（データモデリングスキーム）が決まるので、データアーキテクチャ（論理レベル）のデータモデルは、そのスキーム（リレーショナルスキームなど）で記述します。
データ統合戦略（論理レベル）の策定
生データはDWHで実現するか、データ分析環境を設けるか、戦略的データはCSVで統合するかなどデータ統合に関する方針を決定します。
データ連携戦略（論理レベル）の策定
非同期メッセージングなどデータ連携の形態を決定します。
データアーキテクチャ（論理レベル）のデータフローは、決定したデータ連携方式で記述します。
データアーキテクチャ（論理レベル）の設計
スコープ（縦軸）とレベル（横軸）でエンタープライズデータモデルを分けたマトリクスでいうと、データアーキテクチャ（論理レベル）の設計では、このうち、論理マスターデータモデル、業務論理データモデルと、データフローを設計します。
論理マスターデータモデルの設計
CIMである概念マスターデータモデルを論理データモデルであるPIMに変換します。
論理データモデルの設計については、【DMBOKで学ぶ】データモデリングを参照してください。
業務論理データモデルの設計
同様に、CIMである業務概念データモデルを論理データモデルであるPIMに変換します。
論理データモデルは、データ戦略（論理レベル）で決定したデータモデリングスキームを適用します。
次の図は、論理データモデルにリレーショナルスキームを適用し、ER図で記述した例です。
データフローの設計
データ戦略（論理レベル）で決定したデータ連携形態を適用してデータフローを設計します。
マスターデータのデータフローの例
次の図は、顧客情報が更新されるタイミングで、顧客データの主管システムである顧客管理システムから、顧客データが、マスター共有ハブを経由して販売管理システム、出荷管理システム、請求管理システムに移動する例です。
この例の場合、QueueとTopicによる非同期メッセージングを使ってデータ連携しています。
データを連携する場合、即時性が求められない限り、QueueやTopicを介した非同期メッセージングによって、アプリケーション間の依存度を下げて疎結合になるようにします。
また、データを連携するときデータ管理基盤の一つであるデータ連携基盤（ESB/EAI)を使っています。
データ連携についての詳細は、「アプリケーション統合方式の設計」を参照してください。
トランザクションデータのデータフローの例
次の図は、受注が登録されるタイミングで、受注データの主管システムである販売管理システムからQueueを経由して、受注データが、出荷管理システムに移動し、出荷の登録のタイミングで、出荷データの主管システムである出荷管理システムからTopicを経由して、出荷データが、請求管理システムと販売管理システムに移動する例です。
なお、データフローの設計の結果を受けて、ビジネスメタデータのデータソースを更新することでデータの来歴（リネージュ）を定義することができます。
CIMであるデータフロー（概念レベル）をデータフロー（論理レベル）に変換します。
データフロー（物理レベル）では、ActiveMQなど、データフロー（論理レベル）の構成要素に対する具体的なプロダクトやサービスが決定されます。
テクニカルメタデータの定義
データカテゴリ（論理データモデルのデータ）に対するテクニカルメタデータを定義します。
データマネジメント導入プランの策定
次の３つのアクションプランを策定します。
データ管理基盤構築計画
設計されたデータ管理基盤（論理レベル）に従って、次のように、データ管理基盤構築計画を策定します。
- マスター共有ハブ構築計画の策定
論理マスターデータモデルを物理マスターデータモデルに展開し、例えば、AWSのRDS上に構築します。 - メタデータ構築計画の策定
メタデータ管理システムを導入するか、Excelにメタデータを記述し、例えば、AWSのS3上で管理します。 - 非正規化データ構築計画の策定
多次元論理データモデルを多次元物理データモデルに展開し、例えば、AWSのRDSかRedshift上に構築します。 - データ分析環境構築計画の策定
例えば、AWSのRDSかRedshift上にデータマートを構築します。
データマネジメント組織構築計画
設計されたデータマネジメント組織に対してメンバーをアサインします。
データ統合・連携計画
次の順でデータ統合・連携するアクションプランを策定します。
- データ連携機能の構築計画策定
設計したデータフロー（論理レベル）に従って、データ連携機能を構築する計画を策定します。 - データ統合計画の策定
データの抽出（CSV）→名寄・クレンジング→変換→ロードする計画を策定します。