マスタデータ管理のための現状整理
小野氏、鈴木氏 著の「DX Ready 期間システム刷新術」を読んで、私の過去の経験と非常に重なるところがあった。現所属でもマスタデータ管理の企画が立ち上がり検討を進めているので、整理のためにも書き出しみる。
現所属ではマスタデータ管理を進めるにあたり、まずは現状整理ということで動きがはじまりました。しかし、現行の物理データモデルに引っ張られて実装済みのテーブル単位で整理を進めている。今の業務を正しく表現できているかを見るには物理モデルから進むのは難しいと思うので、論理モデルを整理してみるのが良いと考える。
マスタデータ管理の企画が立ち上がった背景
私の所属していた企業ではデジタルトランスフォーメーション（DX）として基幹システムの刷新を進めていました。基幹システムの刷新自体がDXというよりはDX推進の基盤固めのような位置付けです。
はじめの頃は複雑化したシステムのシンプル化に焦点が当たっていましたが、データマネジメントの啓発活動が実りデータ整備、特にマスタデータの整備が重要となることが理解されました。
しかし、データ観点で整備するという経験がないため、現行の物理テーブルをもとに共通っぽいテーブルを抽出し、マスタとして整備・管理を行うという形で進めようとしていました。これでは今のデータモデルから抜け出せないと思いしっかりと現行論理モデルを書くところから再スタートしました。
概要
現行の論理データモデリングを書くと言うのは、企業が業務で扱うデータ項目とその関係性を可視化するプロセスです。しっかりと管理されている場合はそれほど問題にはなりませんが、積み重なる改修や機能拡張、緊急対応などで実体と合っていないことがよくあると思います。その場合、業務で使用される画面や帳票からデータを収集し、そのデータ間の関係を明らかにすることで現行論理データモデルを整理します。論理データモデルを整理することで、現在の業務の仕様や制約を把握し、データの流れを視覚的に理解できるようになります。
現論理データモデル作成の手順
インプット情報の収集
データ項目の抽出
エンティティの作成
エンティティ間の関係を作成
ユーザー部門との検討
1. インプット情報の収集
現行システムの画面や帳票の一覧表、画面コピー、帳票の出力結果などを収集します。業務の流れに合わせてデータ整備するため業務フローなども同時に収集しておきます。
2. データ項目の抽出
収集した画面や帳票からデータ項目を抽出します。この時点ではまだエンティティとしてまとめないで、データ項目一覧として管理します。この際に”コード”や”ID”などにはマークをつけておきます。これが次のステップでエンティティを作成する際の識別子となるためです。
3. エンティティの作成
抽出したデータ項目からエンティティを定義します。画面や帳票をもとにデータ項目を抽出しているためほとんどの場合発生しないはずですが、物理データモデリングの際に付与するようなシステム項目はここでは使いません。
今の会社ではエンティティに種類があると言った際に、マスタとトランザクションでしょ？と言われました。大きな考え方はずれていないと思いますが、その時にはリソース、イベント、対照表が存在すると説明しました。これだけじゃないし、手法によって変わるところもあると思いますが、ここでは3つだけ説明します。
リソースエンティティ
リソースエンティティとは、名前の通りビジネスの運営に必要なリソースとなるエンティティです。ビジネス上のリソースとなるものを追跡したり管理したりする必要があるものです。属性にタイムスタンプを持たなかったり、実態（モノ）があるなどの特徴があります。例えば：
製品（会社が販売するもの）
従業員（会社で働く人）
顧客（会社の製品を買う人）
設備（会社が所有する機械や道具）
サプライヤー（会社に物を売る人や企業）
イベント
イベントエンティティとは、会社や組織で起きる重要な出来事です。注文や取引、出荷などのイベント（出来事）を管理するため、タイムスタンプが存在します。例えば：
受注（顧客が製品を注文したという出来事）
出荷（製品を顧客に発送したという出来事）
対照表エンティティ
対照表エンティティは別々のリソース間の関係を表現します。例えば：
所属（グループと従業員の関係）
エリア店舗（地域と支店の関係）
エンティティの種類をマスタとトランザクションだけと考えていると、このエンティティがマスタデータ管理を進める上で「これは共通か個別か？」「誰が管理するのか？」みたいな話になりがちでした。これは物理データモデルから検討を始めて、このエンティティに業務上の制約になりうる属性が入っていたからだと思います。
実際には、この段階では対照表エンティティはほとんど出てこないと思います。画面や帳票で直接的に表現されないものが多いと思います。対象表エンティティは次のステップで関係を整理している際に出てくることの方が多いでしょう。
4. エンティティ間の関係を作成
関係のあるエンティティ同士を線で結び関係を明らかにします。次の順番で進める事をお勧めします。
リソース - イベントの関係を整理
イベント - イベントの関係を整理
リソース - リソースの関係を整理
1. リソース - イベントの関係を整理
単純にやりやすいからです。ビジネスを進める上でどのような会社資産を使って何をするかを表現します。つまりビジネスの出発点になるところを整理します。
2. イベント - イベントの関係を整理
出発点が整理されたら、後続の業務をイメージしながら関係を整理します。
私の所属ではこの段階で「マスタだと思ってたのに違った」みたいな言葉を漏らす人がいました。自身の担当では先行イベントをマスタ（リソース）と捉えて実装していたと言うことだと思います。
なお、複数のイベントが先行イベントとなるものが存在すると思います。現行論理データモデルをしっかりと書くのであればただの後続イベントとは分けて書いた方がいいかもしれません。しかし、今回はマスタ管理する対象を整理することが目的だったのでとりあえず後続イベントとして整理しました。
3. リソース - リソースの関係を整理
イベント間の関係を線で結べたら、リソース同士の関係も整理します。上記の対照表エンティティで記載した通り、これが対象表となります。
「会社」と「部署」のように直感的にわかるようなものもあると思いますが、画面や帳票、業務フローなどで登録順などを確認すると紐付けが必要なものが見えたりします。
5. ユーザー部門との検討
ここまでの整理で現行論理データモデルは業務をかなり捉えられているものになっていると思います。しかし、実際の業務においてはシステムには存在していなかったデータをインプットにしているものがあったり、運用でカバーしている業務ルールが存在したりします。
そう言ったものを作成した論理データモデルに反映させるためにもユーザー部門との対話が必要となります。
まとめ
マスタデータ管理を開始するにあたり、現行の論理データモデルを整備することは非常に効果的だと考えています。しかしシステムの人は現行の物理データモデルやER図から出発しがちです。結果として現行に引っ張られてしまうと思うので、現行システムの画面や帳票からデータ項目を抽出し、エンティティやその関係を整理することをお勧めします。
この記事が気に入ったらサポートをしてみませんか？