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

読者の皆さん、あけましておめでとうございます。本年最初のブログは、あらためて企業内情報システム部門（ＩＴ子会社含む）の果たす役割について、ベンダーの役割と対比して整理してみたい。本シリーズはアーキテクチャがテーマなので、意図的に人や組織のあり方についての言及を避けてきた。しかし、あるべきEA像に向かうためには、最低限の自社／ベンダーの役割の明確化はやはり必要である。近年、丸投げに近いアウトソーシングの進展によって、自らの役割が分からなくなっているユーザ企業システム部門は少なくない。ここらで各々の具体的な役割を再定義しておきたい。

図1は、企業システムに関する仕事をアプリ開発、アプリ保守、インフラ管理、運用管理の4種類に分類して、それぞれについて情報システム部門とそのパートナーであるエンドユーザ及びITベンダーとの役割分担のあるべき姿を表したものである。図の右端には大よそのEAの各層（BA、DA、AA、TA）を位置づけてみた。

情報システム部門は、ユーザとベンダーの間に挟まれ、ともすると”手配師”になりがちだが、企画、開発、運用保守といったシステムのライフサイクル全般にわたって、ビジネスとシステムの（自動化できない）マッピングを行なうという重要な機能を担う必要がある。

情シス部門の作業内容は、システム企画・設計（即ち上流アーキテクト）が主体であるが、業務面ではユーザ部門と、技術面ではＩＴベンダーと、ある程度のオーバーラップが必要である。図1は左から右にめがけて標準化可能領域が広がることで、ベンダーアウトソースがより容易になることを示している。また、昨今のクラウドの台頭によりインフラ管理、運用管理のアウトソースがより拡大傾向にある。

では次に、上記の分業体制を前提とした場合に、情報システム部門とITベンダーそれぞれが管理する対象物について考えてみたい。対象にはありとあらゆるハード／ソフト資産が存在するが、データやドキュメントの形でデータベースに格納されて初めてその内容が形式知となる。情報システムのあらゆる管理対象の情報（仕様）を格納したデータベースのことをREPOSITORYと呼ぶが、これには目的によって幾つかの種類が存在する。

図2は企業システムにおける二種類のREPOSITORYメタモデルであり、上部は企業内情報を構成する比較的大きな論理部品のメタモデルで、下部はシステムを構成する精緻な物理部品のメタモデルである。前者は企業の情報資源管理を目的としたもので、各部品間での関係付けをたどって変更時の波及状況等を知ることができる。後者はITコンポーネント管理によるシステムのメンテナンスが目的で、必然的に物理的な実装環境に依存する事になる。

両者は目的も粒度も異なることから、おのずとその実現手段も変わってくる。

前者は1:N関連で理路整然とした正規化モデルとなる。こちらはプラットフォーム非依存なDBシステムが好ましい。適当なパッケージがなければ、コスト面、永続性の面から自製することをお勧めする。後者はコンポーネント間の関係はN:Mの複雑なケースが多い。物理実装に依存するので、ライブラリ管理ツール等のベンダー製品を組み合わせて用いるのが良い。

また、これらの管理者としては、前者は企業内情報システム部門に、後者はITベンダーに委ねることが妥当である。両者は、図中に緑色の点線で示したように、テーブル、画面／帳票、プログラムといった3つの主要部品どうしが対応付けられる。（手動での関連付けとなる可能性あり）

このように情報資源管理を担う情報システム部門と、コンポーネント管理を担うITベンダーでは、システム資産の管理対象も明らかに分かれる。大雑把に言えば、DA、AA中心の情報システム部門に対して、TA中心のITベンダーと言ったところであろうか。大規模、複雑化した企業システムにおいては、この両者をゴチャ混ぜにして管理すしようとすると訳が分からなくなる。たとえ企業システムの運営全てをインソースまたはアウトソースしたとしても、この論理的／物理的な両者の資産は明らかに別物として扱われなければならない。

以上、今回のブログはすぐそこまで来ているビッグデータ時代に備え、今一度、企業内情報システム部門の役割と、その管理対象物が何であるかを再定義してみた。非構造化データがスコープに含まれることは、放っておけば情報資源のコントロールが効かなくなることは目に見えている。今以上にデータを形式知化する為にメタデータ管理が重要になる点を付け加えておきたい。

本年もブログのご愛読よろしくお願いいたします。　Y.Nakayama