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

多くの企業では、ITとビジネスに通じた人材の不在が問題となっています。その両方に通じた人材は極めて少ないです。また、ビジネスとITをつなぐ情報システムに内包される知識も、組織縦割りやベンダー依存により社内外に散在してしまいました。情報システムを今一度、ビジネスの事実を捉える全体システムとして把握し直さねばなりません。企業で日々営まれる事業活動は、情報システムのデータの構造とその流れ、つまりデータアーキテクチャで表現することができます。ビジネスに関与する人々が意思疎通できる程度にデータアーキテクチャを可視化したもの、それが私のいうエンタープライズモデルです。そして、ITシステムはそれに則って構想されるべきものです。ビジネスとITを行き来する人材の共通言語こそが、エンタープライズモデルだと考えます。エンタープライズモデルとはこのように、ソフトウェアを作るためではなく情報システムの骨格を捉えることを目的とします。混沌に陥った情報システムにとって、それは変革に向けた探検のための地図といえるでしょう。

＊＊＊
＜スコーピングのセオリー＞

前回では、エンタープライズモデリングの実施ステップを説明しました。ここにそのステップを再掲します。エンタープライズモデリングの要諦は、全体観をもって「現状を知る」「あるべき姿を描く」ということにあります。ソリューションは個々の課題への反応ではなく、全体像から導かれる必要があります。課題とは、例えばビジネス環境の変化や市場開拓への対応があげられます。冒頭で述べた問題（業務理解不足やシステムのブラックボックス化など）を乗り越え、幅広い視野で次世代の検討を進められることが、エンタープライズモデリングの目指すゴールです。企業活動を支える情報システムの構造とその状況を理解する、そして構造的な問題を関係者と共有する、そのうえであるべき姿を描くというステップを踏んでいきます。冒頭で「探検」という言葉を使いましたが、その前半部分とは「そこに何があるか」を知るために未知の領域へ足を踏み入れることに他なりません。

ここで、その探検のためのスコーピングを考えてみましょう。
近年、情報システムの範囲は広がる一方です。LOB（Line of Business、事業部門）から全社（1法人）へ、さらに国内からグローバルのグループ企業群へという具合です。ここでLOBとは、各事業本部が業務を遂行するうえで利用する、主要な基幹アプリケーションのことも指します。具体例を挙げると、販売管理、生産管理、原価計算、調達、会計、人事などがあります。少なくとも１つのLOBが探検の最小単位となりえますが、エンタープライズモデリングでは「1つ外側のスコープ（世界）」、つまり全社で考えることが望ましいです。つまり、LOBを越えて全社を俯瞰するわけです。全社スコープで見たとき、そのアプリケーションは膨大な数にあがるでしょう。企業によっては大小様々で数百を越えることもザラでしょう。それらを万遍なく網羅することは得策ではありませんし、非現実的です。まずはLOBごとにメインとなる主役級のアプリケーションシステムを見極め、それを補う準主役級を加えた範囲から始めましょう。そのスコープを出発点に、可視化を進めるのが良いでしょう。最初から対象を増やしすぎないことがポイントです。可視化を進めるなかで、探検を広げていくべき領域が見えてくるでしょう。「スコープは広く浅く」がエンタープライズモデリングのセオリーです。分析の手法としては、現状のシステムドキュメント(物理モデル)からリバースすることが多いです。最低限、システム間のデータのやり取りが分かるインタフェース一覧と、データ構造がわかるものがあればOKです。わざわざドキュメントなど見なくても有識者に聞けばわかる、と言う意見もありますが人の記憶とはあやふやなものです。一度はドキュメントに立ち戻るのが良いでしょう。また、ドキュメントが最新でなくても全体像を炙り出すには十分なことが多いのです。それをもとに描いたモデルを見ながら関係者と対話をしつつ、過不足を補うアプローチが共通理解への近道となることが多いです。

＜プロセスモデルでデータの流れを可視化しよう＞

架空会社をサンプルにプロセスモデルの例を示します。記述様式は極めてシンプルです。システムとサブシステムの掲載、システム間の主なデータのやりとり、そして主要なデータストック（DB）です。文字通りバーズ・アイ（鳥の眼）で上空から見た、全社レベルの俯瞰図を描きます。システムの保有DB及び連携データは、上空から見える幹線道路や主要な貯蔵庫に限定します。システムは、取引の発生から会計に向けて、左から右に時系列に沿って配置します（SCMでは原材料購買から生産管理が左端に配置）。データは主に、その発生元から利用システムへの移動・コピーの流れに着目します。最近はAPI等でのデータ共有も増えていますが、システム間のデータの所在と流れを押さえましょう。ただし、細かい回路図のようなフローにしてはなりません。あくまで上空から見て情報システムの動脈たる幹線が一目でわかるように描くことがセオリーです。枝葉末節なフローはあえて描かない、という割り切りが必要です。一言でデータの流れと言っても、全社レベルとなればインタフェースの数は膨大でしょう。ビジネスにとって主要なデータに着目することがセオリーです。ビジネスにとって主要データとは何でしょうか？機械的に識別することが難しい場合も多いでしょう。それを識別できるのはビジネスに関わる人だけ、ということもあるでしょう。しかしそこにもセオリーはあります。システムを跨って共有性の高いマスタデータと、ビジネス活動の事実（取引実績）をあらわすトランザクションデータに着目することです。

まずマスタデータを見てみましょう。共有性が高いマスタの中で、まず押さえるべきは3大リソースと呼ばれるものです。具体的には、社員・自社組織（人事組織、事業所などの物理的な拠点など）、取引先（顧客やサプライヤーなど）、品目・商材（メーカーなら製商品や無形のサービス、不動産業なら物件、ビルなど）です。これらはビジネスを語るうえで主要な「もの」をあらわす概念となります。プロセスモデルでは大きなまとまり（群）の粒度であらわせば十分でしょう。例えば自社組織の場合、具体的には組織、部署、部課といったマスタがあるかもしれませんが、それらを「組織群」としてひとまとめで扱います。得意先や仕入先といったマスタは「取引先群」にまとめることができるでしょう。まずこの粒度感で描きましょう。

次にトランザクションデータです。トランザクションは、ビジネス活動の事実を捉えるデータを中心に描きましょう。具体的には、受発注から仕入、生産、出荷、売上につながる実績のつながりに着目しましょう。つまり受発注に始まり、会計へ至る企業活動の事実(データ)の連鎖を表現します。これがビジネスの動脈たる幹線となるわけです。その他のトランザクション、例えば計画や見積といったデータや在庫残高や売上原価も事業活動にとって重要ですが、支線と割り切って必要に応じて肉付けしていくのが良いでしょう。幹線が見えると支線も見えてくるものです。まずは幹線から徐々に広げていきましょう。こうして、膨大なインタフェースから主要なデータを浮かび上がらせていくことができるわけです。

＊＊＊
全体がつながってくると、情報システムの現状が見えてきます。今まで混沌の内に隠されていた問題点が、思いのほか多いことに気づくでしょう。しかし、データの流れを捉えただけではまだ半分を理解したことにしかなりません。関係者の意思疎通には、データの意味やその関係の理解が必要となります。それをあらわすのがデータモデルです。次回は、データモデルを対象にエンタープライズモデリングの要諦を見ていきたいと思います。お楽しみに！