DX(デジタルトランスフォーメーション)推進コンサルティング 株式会社アイ・ティ・イノベーション

前回取り上げたAP鳥観図は、企業においてどのようなデータがあり、どんな業務機能で使われているのかを表現するものでした。それを描くだけでも現状の問題点（構造的な問題、サイロ、スパゲッティなど）や改善点を可視化できますが、企業情報システムのように複雑なシステムを理解するには、そのシステムを成り⽴たせている概念をとらえる必要があります。それをEntityと呼びます。このEntityの意味と構造を表現するのが概念データモデルです。今回はこの概念データモデルをみていきましょう。

＊＊＊
＜データモデル（企業の構造）を可視化しよう＞
自社の情報システムのデータモデル（ER図）をお持ちの企業は、思いのほか少ないものです。仮にお持ちだとしても、実際に見てみると多数の部分図に分かれていたり、物理レベルの詳細な回路図のようだったりすることが多いです。これでは全員の共通理解には使えません。概念レベルで良いので一枚で全体のつながりがわかるものが必要です。
左図に、架空会社をサンプルにしたデータモデルを示します。モデルの読みやすさのため、横軸、縦軸ごとにいくつかのエンティティ配置ルールを持たせています。みなさんがエンタープライズモデルを描く際の参考にしてください。まず縦軸のルールは上から下へ順番に、マスタ→残高・サマリ→トランザクションの順でエンティティを配置（リレーションシップが上から１：Ｎの関係になるように）します。マスタ群の下段には、複数のリソースエンティティの組み合わせからなるビジネスルールを配置します。次に横軸のルールですが、マスタ群は左から右へ順番に、「社員・自社組織系」、「取引先系」、「品目系」の３大リソースを配置するようにします。トランザクション群は、ビジネス活動の時系列に左から右へ配置します。エンティティ名はビジネス上の概念をあらわす言葉で表現します。この配置と命名のルールを定めておくことで、誰でもビジネス活動のありようを読み取ることができます。ビジネス上の概念を表現することは意外と難しいですが、関係者が意思疎通できる程度に共有することを目指しましょう。そうした概念が企業情報システムのあちこちに散在してしまっているのが、多くの企業情報システムの実情です。それら散在した概念をシステムから取り出してモデル上に配置するわけです。対象は、プロセスモデルであげたストックの中身（RDBではテーブル単位）となります。テーブル本数で見ると膨大な数があるとひるんでしまいがちですが、最低限共有すべき概念は実はそれほど多くはありません。順に見ていきましょう。

まずマスタデータです。マスタデータは、システム間で共有する「モノ」それ自体をあらわす基本概念が対象です。そして、それらをTOPエンティティとしてモデルの上部に配置します。サンプルでは、「会社」「社員」「組織」「拠点」「取引先」「品目」があげられています。これがデータモデルを描く起点となります。まずは、マスタの基本概念を押さえましょう。多くの企業のデータモデルを見てきた経験から言えば、このレベルはどこも似たような形になります(名称の違いはありますが)。つまりこのレベルではまだ、その企業固有の概念を表現したものとは言えないかもしれません。

さらにサブタイプを可視化しましょう。企業活動の現場においては、同じ言葉を使っていても、異なる部門では異なる種類の用途で使われることが多々あります。たとえば「取引先」という言葉の場合は、営業部門であれば自分たちの売り込み先である企業の特定部門を指すでしょう。物流部門にとっては、製品の納入先かもしれません。経理部門にとっては、売上の計上先を指します。「品目」の場合も同様です。営業部門では商品、製造部門では製品・仕掛品、調達部門では資材というように、異なる種類があります。この種類の違いがエンティティのサブタイプ候補となります。関係者同士でエンティティごとに「どういう種類のものがあるか？」ということを確認し合うことが重要です。お互いが理解する意味が食い違っていたり、うまくその意味を言語化できないことに気づくことも多いです。

トランザクションデータについては、事業活動をあらわすエンティティを時系列で配置します。サンプルでは、受発注から売上までの事実の単位を伝票の発生単位で捉えています。この捉え方はビジネス形態によって各社各様です。この機会に自社の情報システムではどういう単位で事業活動の事実を捉えているかを分析してみることをお勧めします。

次に、エンティティ間の関係（リレーションシップ）を見ていきましょう。「組織」と「取引先」の間にどんな関係があるでしょうか？「取引先」と「品目」の間はどうですか？こうした関係は、データ構造の主キー、外部キーで明示されていることも多いです。現行システムのER図があれば参考にしましょう。この過程でだんだんと、ビジネスルールを表現するエンティティがモデルに追加されていきます（例えば、購入条件など）。最初は、関係者間で「ちょっとそこは理解があっていないんじゃないかな」という箇所もあるでしょうし、うまくつながらない箇所もあるでしょう。これは概念モデルを描く過程で避けて通れないことです。どこまで描けば完成かと思われるかもしれませんが、モデルの完成形に絶対解はありません。関係者から見て、「自社のビジネスを表現するに足る主要なエンティティとその関係が表現できた」と感じられたら十分です。

＜未来の展望を描いてみよう＞
全体がつながってくると、情報システムの現状が見えてきます。データは淀みなくシステム間で行き渡っているでしょうか。システムはビジネスの主要概念を正しく捉えることができているでしょうか。今まで混沌の内に隠されていた課題は思いのほか多いと思います。

本シリーズのまとめとして、エンタープライズモデリングに取り組んだ企業事例を紹介しましょう。この企業では、昨今のビジネス環境の変化や市場開拓の必要性を踏まえ、情報システム部門が中心となって次世代の情報システムの在り方を検討していました。しかし、メンバーの業務理解不足や情報システムのブラックボックス化のため、経営層への積極的な提案ができていませんでした。メンバーが幅広い視野で次世代の検討を進められることが喫緊の課題という認識から、情シス部長が旗振り役となりエンタープライズモデリングにチャレンジすることを決断しました。メンバー構成は、情シスからベテラン1名と若手4名、事業部門から4名です。
まずプロセスモデルを描くことで、情報システムの全体像と主要なデータフローを可視化していきます。最初は、メンバーそれぞれの部分理解をもとに全体をつなごうとするものの、各自が口にするデータの意味が嚙み合わないこともあり、ところどころで流れがつながらず苦労します。メンバー同士でも理解度の差が大きく、特に若手メンバーはモデリングに全く参加できないこともありました。しかしベテランのサポートも得ながら理解を広げ、わからなかったことがわかるようになってきます。今までおとなしかったメンバーの発言も増えてきます。全員の理解が深まり、自信が芽生えてきた表れです。自信が持てれば、臆することなく対話に参加できるようになります。ベテランに対しても対等に質問ができます。そして、自分の担当範囲だけでなく広い全体観をもった意見や提案が出されるようになります。現状可視化の終盤では、幅広い視点から30を越える提言がまとめられました。未来への展望は、こうした地道な対話と共通理解の積み重ねから拓かれるものなのだと思います。

＊＊＊
本シリーズでは、現状可視化を中心にエンタープライズモデリングの進め方や勘所を解説しました。進め方に唯一の正解はありません。勘所を押さえ、実際の進め方はそれぞれで工夫いただければと思います。頑張れば自分達でもなんとか取り組めそう、と少しでも感じていただければ幸いです。また、今回含めることが出来なかったTOBEモデリングについても、設計（デザイン）の視点を交えながら別の機会（次回かもしれません）に取り上げたいと思います。お楽しみに！