【実践！DX】データアーキテクチャの設計

前回、データマネジメントについて解説しましたが、データマネジメントを進める上で欠かせないのがデータアーキテクチャです。
今回は、データアーキテクチャについて次の観点で解説します。

• データアーキテクチャとは何か
• DXとデータアーキテクチャ
• データアーキテクチャの設計方法

関連記事
データマネジメントの導入方法

データアーキテクチャとは何か

エンタープライズアーキテクチャ（EA）

を構成する一要素で、企業のデータの基本的な構造や振舞を表すものです。
データマネジメント知識体系（DMBOK）には、データアーキテクチャの定義が次のように記述されています。

企業のデータニーズを明確にし、ニーズに合う基本となる青写真を設計し維持する。
基本となる青写真を使ってデータ統合を手引きし、データ資産を統制し、事業戦略に合わせてデータへの投資を行うこと

重要なのは、データアーキテクチャは、

• どのデータを統合するのか
• どのデータを統制するのか
• どのデータ資産に投資をするか

など、データマネジメントに関する意思決定を導く青写真であるといいうことです。
なので、データアーキテクチャはデータマネジメントの一環として設計されるもので、その目的は
データという資産の価値を提供し、管理し、守り、高めること
です。

DXとデータアーキテクチャ

DXによる企業変革の進め方

では、DXを実現する企業の構造を次のように表しました。

この企業構造の最下層がエンタープライズアーキテクチャ（EA）になっていますが、データアーキテクチャ（DA）は、EAの一要素です。
次の図は、EAの４階層ですが、これを見るとDAはBA（ビジネスアーキテクチャ）の下位に位置付けられています。

データとは、業務活動によって発生する事実を表したものです。
なので、DAは、「ビジネスの仕組（BA）をデータという視点で表したもの」という位置付けになります。
そういう意味で、DAは、アプリケーションアーキテクチャやテクノロジーアーキテクチャのようにシステムの観点で考えるものではなく、ビジネスの観点で考えるべきものです。
※DAはビジネスの視点でデータをモデル化したものを、システムの視点で展開していきます。
DMBOKでは、データアーキテクチャとして、以下の２つのモデルを作成すべきとしています。

• エンタープライズデータモデル（EDM：Enterprise Data Model)
  EDMは、全体的でエンタープライズレベルの実装に依存しない概念または論理データモデルであり、企業全体にわたるデータに関して一貫した共通のビューを提供します。
  EDMには、企業の重要なデータ、それらの間の関係、重要な手引きとなるビジネスルール（ビジネスメタデータとして記録する）、いくつかの重要な属性が含まれます。
  これらは、すべてのデータが関連するシステム開発プロジェクトの基礎を定めているので、どのプロジェクトのレベルのデータモデルもEDMに基づいている必要があります。
• データフロー
  データがビジネスプロセスやシステムをどのように移動するかを示すものです。
  これは、データリネージュ（データの系統）のドキュメントであり、データの発信元、格納場所、使用場所、さまざまなプロセスとシステムの内部や間を移動する際に、データがどのように変換されるかを示します。
  重要なのは、戦略的に重要なデータがどの業務活動で生成・収集、変換・蓄積、利活用、破棄されるのか、業務活動とデータライフサイクルの関係を抑えるとです。
  これによって、データ品質を維持・向上させるためには、どの業務活動をどう設計、あるいは、改善すべきかあたりをつけることができます。

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

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

から構成されます。

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

ここで、エンタープライズデータモデルを構成する３階層のデータモデル

• 概念データモデル
• 論理データモデル
• 物理データモデル

について説明します。
この３つのモデルの違いを説明するために、まず、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の考え方を踏まえて３つのデータモデルの違いについて説明します。

データベース製品を変更する場合、物理データモデルは作り直す必要がありますが、論理データモデルは、IT基盤に依存しないので、再利用することができます。
また、システムの機能要件が変わると、論理データモデルは見直す必要がありますが、概念データモデルは、システムに依存しないので、ビジネスの仕組が変わらない限り不変です。
次の図は、スコープ（縦軸）とレベル（横軸）でエンタープライズデータモデルを分けたマトリクスです。

各モデルを設計するタイミングを事業ライフサイクルの戦略サイクルで分けると次のようになります。

• 設計フェーズ
  全体概念マスターデータモデルの設計
  全体概念分析データモデルの設計
  業務概念データモデルの設計
  アプリケーション概念データモデルの設計
• 戦略フェーズ
  全体論理マスターデータモデルの設計
  全体論理分析データモデルの設計
  業務論理データモデルの設計
  アプリケーション論理データモデルの設計
• 構築フェーズ
  アプリケーション物理データモデルの設計

次にデータフローですが、EDM同様、スコープ（縦軸）とレベル（横軸）で分解すると次の図のようになります。

各モデルを設計するタイミングを事業ライフサイクルの戦略サイクルで分けると次のようになります。

• 設計フェーズ
  全体概念データフローの設計
  業務概念データフローの設計
• 戦略フェーズ
  全体論理データフローの設計
  業務論理データフローの設計
  アプリケーション論理データフローの設計
• 構築フェーズ
  アプリケーション物理データフローの設計

次の図は、全体概念データフロー（CRUD表）の例です。

次の図は、業務概念データフローの例です。

次の図は、アプリケーション論理データフロー（DFD）の例です。

それでは、DAはどのように設計するのでしょうか。

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

DMBOKでは、データを次のように分類しています。

データアーキテクチャは、このうち構造化データを対象にします。
ここでは、次の観点でデータアーキテクチャの設計方法について解説します。

• データの構造化
• マスターデータの設計
• バリューチェーンの設計
• ビジネスプロセスの設計
• トランザクションデータの設計

なお、データアーキテクチャを設計するためにはデータモデリング技術が不可欠です。
データモデリングについては、【DMBOKで学ぶ】データモデリングを参照してください。

データの構造化

データアーキテクチャは「ビジネスの仕組（BA）をデータという視点で表したもの」です。
ビジネスの構造を考えるときは、ビジネスを構成する要素を分類して構造化する場合と、ビジネスの構成要素間の意味的な関連を考えて構造化する場合があります。
ここでは、ビジネスの観点でデータを構造化し、概念データモデルを作るときの考え方を次の観点で説明します。

• ビジネス構成要素の分類（classification）
• ビジネス構成要素の関連（association）

ビジネス構成要素の分類（classification）

私たちが物事を認識するときは、それらに共通な性質を抜き出し、ある概念としてとらえます。
これを抽象化といいます。
集合で考えると、要素（物事）が集合（概念）に属するという関係をつくります。
次のベン図は、一台一台の扇風機が「扇風機」という集合に属していることを表しています。

UMLでは、集合をクラス、集合に属する要素をオブジェクトで表します。

この抽象化は、最も基本的な分類方法ですが、別のケースもあります。

このベン図は、冷却機という集合が、扇風機の集合とクーラーの集合を含んでいます。
つまり、扇風機の集合やクーラーの集合は、より一般的な概念である冷却機という集合の部分集合になっています。
論理的にいうと「扇風機ならば（⇒）冷却機である」という関係です。
UMLでは、集合と部分集合の関係を、クラスとサブクラスの汎化関係（より一般的な概念と、より特殊な概念の関係）で表します。

この、特殊な概念（サブクラス）から一般的な概念（クラス）を考えることも分類方法の一つで、これを一般化といいます。
このように、ビジネス要素を分類する方法には、抽象化と一般化があります。
さて、先ほど、冷却機という集合が、扇風機の集合とクーラーの集合を部分集合として含んでいるケースを考えましたが、次のように、扇風機の集合とクーラーの集合が要素として他の集合に属するケースも考えられます。

このように、ある集合の部分集合を要素として持つ集合のことを集合族といいます。

UMLでは、集合族と集合の関係を、集合族が集合を集約するという関係として表すことができます。

この場合、「冷却機」クラスに対して、「冷却機の種類」はメタクラスという位置付けになります。
「冷却機」クラスの識別子が冷却機一台一台を識別する製造番号になっているのに対して、「冷却機の種類」クラスは、冷却機の種類一つ一つを識別する商品番号になっていることに注意してください。
「冷却機の種類」オブジェクトと「冷却機」オブジェクトの関係をオブジェクト図で表すと次のようになります。

「扇風機」クラスと「冷却機」クラスが部分集合と集合の関係で「一般化」を表すのに対し、「冷却機」クラスと「冷却機の種類」クラスの関係は、要素と集合の関係になり「抽象化」を表すということになります。

以上を踏まえて、ビジネス構成要素の一般的な分類構造を表すと次のようになります。

ここでは、個々の要素を抽象化した概念を「分類」としています。
分類には、他の分類を含む「複合分類」と、これ以上分けることができない「単位分類」があります。
分類と、複合分類や単位分類の関係は集合と部分集合の汎化関係になり、複合分類と他の集合の集約関係は、集合族と集合の関係になります。
また、分類や要素には、何らかの分類基準があります。
この分類基準は、集合の条件（要素の性質）を表します。
例えば、「白いものの集合」であれば、「白いもの」が集合の条件となり分類基準になります。
※分類基準は述語論理でいえば「述語」の部分です。
分類基準は参照データかマスターデータになります。
なお、ビジネス構成要素の分類は、主にマスターデータの設計の際に適用されます。

ビジネス構成要素の関連（association）

次に、ビジネス構成要素の意味的な関連について説明します。
ビジネスの構成要素間の関連は５W１Hで考えます。
※５W1Hの要素がすべて必要というわけではありません。
データとは、業務活動によって発生する事実を表したものです。
なので、データには、業務活動によって発生する実体（もの）のデータと、事象（こと）のデータがあります。
実体（もの）のデータがマスターデータ、事象（こと）のデータがトランザクションデータです。
例えば、出荷という事象が発生すると、その事実は出荷データとして表されます。
この出荷など業務活動の事象を表すトランザクションデータは、５W１HのWhenとHow（いつどのように）を表す事実になります。
それでは、出荷データを中心に５W１Hの残りの要素を踏まえてデータの概念構造を考えてみましょう。

• なぜ出荷したのか（Why）
  出荷の原因となった事象として「受注」が関連します。
• 何を出荷したのか（What）
  出荷対象としての「製品」が関連します。
• どこに出荷したのか（Where）
  出荷先としての「顧客」が関連します。
• 誰が出荷したのか（Who）
  出荷者としての「社員」が関連します。

以上を踏まえて概念データモデルを描くと次のようになります。

この構成の中の「受注」と「出荷」がトランザクションデータ、残りがマスターデータになります。
なお、次の図の出荷ステータスのように、トランザクションデータの分類基準（参照データ）を考えることもできます。

構造化については、クラス図を使った概念モデルの作り方も参照ください。

マスターデータの設計

データアーキテクチャを設計するときは、会社全体のマスターデータから設計します。
マスターデータ管理で、DMBOKにある次のマスターデータについて解説しました。

• パーティマスターデータ
• 財務マスターデータ
• 法令マスターデータ
• 製品マスターデータ
• ロケーションマスターデータ
• 業種マスターデータ

ここでは、ビジネス構成要素の一般的な分類構造を使ってマスターデータを設計する方法について、パーティマスターデータとして、顧客マスターデータと社員マスターデータ、製品マスターデータ、財務マスターデータ、ロケーションマスターデータを例にして説明します。

顧客マスターデータの設計

ビジネス構成要素の一般的な分類構造

を使って顧客マスターデータを設計すると次のようになります。

一人一人の顧客は、市場によって分類されます。
この例では、最小単位の市場を「市場セグメント」という概念で表しています。
マーケティングの大家、フィリップ・コトラーは、市場の分類基準を次の４つに分けています。

1. 地理的変数
   地理的変数は、国、地域、都市規模などによる分類で、気候、経済発展度、文化・宗教、政策などによる消費者の行動の違いを明確にします。
2. 人口統計変数
   人口統計変数は、性別、年齢、職業、所得、学歴などの個人のプロフィールを示す変数で、これにより、消費財のターゲットの選定することができます。
3. 心理的変数
   心理的変数は、社会階層、ライフスタイル、性格など、人の価値観や消費行動に影響する因子で、雑誌、ファッションなど感性的な消費が中心となる分野では、この心理的変数による細分化が特に重要となります。
4. 行動変数
   製品に対する知識、態度、使用状況などの行動変数で市場を細分化することによって、きめ細かなマーケティングを展開することができます。

顧客を市場で分類するのではなく、顧客分類基準を設けて、直接分類することもできます。
この例では、顧客を契約先、出荷先、請求先などの役割によって分類できるようにしています。
また、この例では、顧客を個人顧客と法人顧客に分け、それぞれ、個人データ、法人データを関連づけています。
こうすることによって、次のようなメリットがあります。

• 個人データは、個人顧客だけでなく社員など個人に関連するデータに紐づけて一元的に管理できます。これによって、個人情報保護法などコンプライアンス（法律遵守）に効率的に対応するができます。
• 同様に、法人データは、法人顧客だけでなく仕入先など法人に関連するデータに紐づけて一元的に管理できます。
• 同じ法人でも複数の部門が顧客である場合や、契約先、出荷先、請求先など役割が異なる場合でも対応できます。

社員マスターデータの設計

ビジネス構成要素の一般的な分類構造

を使って社員マスターデータを設計すると次のようになります。

社員は、組織によって分類することができます。
この例では、組織は、職務（ジョブ）、事業、場所によって規定されることになっています。
また、ジョブ型雇用のように、社員が、直接、職務によって分類される場合も考えられます。

製品マスターデータの設計

ビジネス構成要素の一般的な分類構造

を使って製品マスターデータを設計すると次のようになります。

この例では、一つ一つの製品単体を分類した概念が製品になっています。
また、製品の最小単位を製品アイテムとしています。
フィリップ・コトラーは、製品を次の階層構造で表しています。

• ニーズ
  製品ファミリーのもととなる中核ニーズ。
  生命保険の例
  安全。
• 製品ファミリー
  中核ニーズを満足させる全ての製品クラス。
  生命保険の例
  貯蓄と所得。
• 製品クラス
  製品ファミリーの中で機能的一貫性を持っているとみなされる製品グループ。
  生命保険の例
  金融手段。
• 製品ライン
  製品クラスの中で、機能、顧客、販路、価格水準などを同じくすることで密接に関連づけられている製品グループ。
  生命保険の例
  生命保険。
• 製品タイプ
  製品ラインの中で、形態や様式が同じもの。
  生命保険の例
  長期契約の生命保険。
• ブランド
  製品ラインの中の一つあるいは複数のアイテムにつけられた名前であり、アイテムの特性や出所を明らかにするもの。
  生命保険の例
  プルーデンシャル。
• アイテム
  製品ラインやブランドの中で、サイズ、価格、外見、その他の特性で区別される単位。
  生命保険の例
  プルーデンシャル更新可能長期保険。

製品の階層構造をオブジェクト図で表すと次にようなイメージになります。

財務マスターデータの設計

ビジネス構成要素の一般的な分類構造

を使って財務マスターデータの勘定（account）データを設計すると次のようになります。

受注や出庫などトランザクションデータは、勘定データの原因になります。

ロケーションマスターデータの設計

ビジネス構成要素の一般的な分類構造

を使ってロケーションマスターデータを設計すると次のようになります。

この例では、場所の最小単位を倉庫や店舗など拠点としています。
場所には、緯度経度を持つ地点が対応します。

バリューチェーンの設計

トランザクションデータを設計するためには、業務活動で発生する事象を明確にするためにバリューチェーンとビジネスプロセスを明確にする必要があります。
※バリューチェーンとビジネスプロセスはBAとして設計します。
一般的な活動領域をベースに、事業のバリューチェーンの主要活動は何か考えてみましょう。
商品を仕入れて販売する小売事業の場合、主要活動は次のようになります。

サービスを提供する事業の場合、主要活動は次のようになります。

製造業の場合、主要活動は次のようになります。

今回は、商品を仕入れて販売する小売事業の場合を例として考えます。

ビジネスプロセスの設計

バリューチェーンの主要活動が明確になったら、主要活動のビジネスプロセスを設計します。
ビジネスプロセスは大きく次のように分けることができます。

• オペレーションプロセス
  活動領域でいうと顧客に直接価値を提供する営業活動のビジネスプロセスです。
• 顧客関係管理（CRM）プロセス
  活動領域でいうと顧客管理のビジネスプロセスです。
  フィリップ・コトラーのカスタマージャーニーでオペレーションプロセスとCRMプロセスの関係を表すと次のようになります。
  
• 製品ライフサイクル管理（PLM）プロセス
  活動領域でいうと製品（商品）管理のビジネスプロセスです。
• 投資家関係管理（IRM）プロセス
  投資家との良好な関係を構築するビジネスプロセスで、活動領域でいうとパートナー管理のビジネスプロセスの一種です。
• パートナー関係管理（PRM）プロセス
  仕入先などパートナーとの良好な関係を構築するビジネスプロセスで、活動領域でいうとパートナー管理のビジネスプロセスになります。
• 人的資源管理（HRM）プロセス
  活動領域でいうと社員管理のビジネスプロセスです。
• 資産管理（AM）プロセス
  活動領域でいうと設備管理（固定資産管理）のビジネスプロセスです。
• データマネジメント（DM）プロセス
  データマネジメントのプロセスで、活動領域でいう情報管理のビジネスプロセスの一種です。
• ITサービスマネジメント（ITSM）プロセス
  ITSMのプロセスで、活動領域でいう情報管理のビジネスプロセスの一種です。
• 財務管理プロセス
  活動領域でいうと財務活動のビジネスプロセスです。
• 経営管理プロセス
  活動領域でいうと経営活動のビジネスプロセスです。

ここでは、オペレーションプロセスの購買と販売のプロセスについて考えてみましょう。

• 購買プロセス
  仕入先から製品を購買し代金を支払うまでのプロセス。
• 販売プロセス
  顧客から注文を受けて製品を出荷後、代金を受け取るまでのプロセス。

購買プロセス
購買プロセスの流れをアクティビティフローで表すと次のようになります。

販売プロセス
販売プロセスの流れをアクティビティフローで表すと次のようになります。

次に、それぞれの活動が勘定にどう関連するか確認しましょう。
各々の勘定は、勘定データ（財務マスターデータ）に対応します。
※製品在庫は棚卸資産の製品のことです。
購買プロセス

販売プロセス

トランザクションデータの設計

会社全体のマスターデータが設計できたら、それを参照して、データアーキテクチャのトランザクションデータを設計します。

1. 全体概念データモデルの設計
2. 活動領域別概念データモデルの設計
3. 活動領域別論理データモデルの設計

全体概念データモデルの設計

全体概念データモデルは、EDM（エンタープライズデータモデル）の最上位のモデルです。

まず、バリューチェーンを構成する活動領域間でデータが流れる関係を、全体概念データモデルの静的モデルとして作成します。

それから、全体概念データモデルの動的モデルとしてデータフローを作成します。
データフローは、横軸にバリューチェーンの活動の流れ、縦軸にデータを配置し、どの活動でデータがどう変遷するか記述します。

Cはデータの生成（Create）、Rはデータの読込み（Read）、Uはデータの更新（Update）を表します。
なお、次のようにシステムと活動の関係が明確になっていれば、どのシステムで何のデータが管理されるのかが明確になります。

※なお、全体概念データモデルの静的モデルは、AA（アプリケーションアーキテクチャ）でマイクロサービスを設計するときに使うこともできます。

活動領域別概念データモデルの設計

活動領域別概念データモデは、EDMの２階層目の概念データモデルです。

活動領域別概念データモデルは、バリューチェーンを構成する活動領域別の概念データモデルです。
データアーキテクチャは「ビジネスの仕組（BA）をデータという視点で表したもの」です。
なので、モデル化対象のビジネスの考え方を概念データモデルに反映させるようにします。
例として、販売、出荷、債権管理の活動領域別の概念データモデルを考えてみましょう。

• 販売
  すでに販売プロセスが明確になっているので、それを参照して販売活動のトランザクションデータを抽出します。
  販売プロセスの中で販売活動のトランザクションデータは「受注」です。
  • 「受注」の概念データモデル
    
    この概念データモデルを見ると次のことがわかります。
    • このビジネスでは、一取引で複数の製品を注文できる
    • 店舗販売をしている
    • 受注済、出荷済、請求済など注文ステータスを設定できる
• 出荷
  販売プロセスの中で出荷活動のトランザクションデータは「出荷」と「出庫」です。
  「出荷」と「出庫」、それぞれ分けて概念データモデルを作成します。
  • 「出荷」の概念データモデル
    
    この概念データモデルを見ると次のことがわかります。
    • このビジネスでは、一つの注文の製品を複数に分けて出荷することがある（分納）
    • このビジネスでは、複数の注文をまとめて出荷することがある（一括納入）
    • 配送済、配送中、配送完了など出荷ステータスを設定できる
  • 「出庫」の概念データモデル
    
    この概念データモデルを見ると次のことがわかります。
    • 出庫に対して倉庫の多重度が１、製品の多重度が多になっていることから、このビジネスでは、一つの倉庫に複数種類の製品が保管されている
    • 出庫に対して倉庫の多重度が１、出荷に対して出庫の多重度が多になっていることから、このビジネスでは、製品の種類が異なると倉庫が分かれる場合がある
    • ピッキング済、検品済、梱包済など出庫ステータスを設定できる
  • 「売上」の概念データモデル
    なお、「出荷」に対応した「売上」勘定データの概念データモデルは次のようになります。
    
    売上明細の単位が月別・顧客別であれば、その月の出荷が売上明細に関連します。
  • 「製品在庫」の概念データモデル
    また、「出庫」に対応した「製品在庫」勘定データの概念データモデルは次のようになります。
    
    在庫明細が月別・製品別・倉庫別であれば、その月の出庫が在庫明細に関連します。
• 債権管理
  販売プロセスの中で債権管理活動のトランザクションデータは「請求」と「入金」です。
  「請求」と「入金」、それぞれ分けて概念データモデルを作成します。
  • 「請求」の概念データモデル
    
    この概念データモデルを見ると次のことがわかります。
    • このビジネスでは、締日になると、それまでの出荷に対して代金を請求する
    • 請求済、入金済など請求ステータスを設定できる
  • 「入金」の概念データモデル
    
    この概念データモデルを見ると次のことがわかります。
    • このビジネスでは、請求代金が複数回に分けて入金されることがある
    • 銀行振込で入金される
  • 「売掛金」の概念データモデル
    なお、「請求」に対応した「売掛金」勘定データの概念データモデルは次のようになります。
    
    売掛金明細が月別・顧客別であれば、その月の請求が売掛金明細に関連します。

活動領域別論理データモデルの設計

活動領域別論理データモデは、EDMの２階層目の論理データモデルです。

論理データモデルとは、論理的に正しいデータモデルということです。
その正しさの判断基準は、主に

• システムの機能要件を満たしているか（例えば、画面の項目が全てデータ項目として定義されているかなど）
• 一意性、一貫性などのデータの品質基準を満たしているか

になります。
データの一意性とは、同じ実体を表すデータが同じデータセット内に複数存在してないことを示し、データの正規化という方法で実現することができます。
次の受注の概念データモデルでは、受注と製品の間の多重度が多対多になっています。

これは、受注というデータセット内に、受注明細という同じ実体を表すデータ複数存在していることを示しています。
そこで、データの一意性を確保するために、受注データから受注明細を分離して正規化すると次の図のようになります。

論理データモデルは、データモデルの表記法であるER図を使って記述します。
ここでは、次の理由により、概念データモデルと論理データモデルの表記法を分けています。

• 概念データモデルはビジネスの視点のモデルで、通常、業務担当者が記述するため、概念の表現力が豊かなクラス図の方が適している
• 論理データモデルはシステムの視点のモデルで、通常、システム開発者が記述するため、リレーショナルモデルに展開できるER図の方が適している
• 概念データモデルをクラス図で記述することで、アプリケーション開発のドメインモデルとして再利用できる

以上、今回はデータアーキテクチャの設計方法について解説しました。