「顧客との関係強化」をITで実装：顧客指向開発のすすめ（6）（2/2 ページ）

[營田（つくた）茂生，日立ソフトウェアエンジニアリング]

（Enterprise Architecture）の適用

　EA（Enterprise Architecture）は、中長期的な視点で、IT戦略／IT投資のムリ・ムラ・ムダを省き、ビジネスやビジネス環境の変化に対応しやすいITシステムを作るための取り組みである。

　連載の第4回目「“経営者の視点”で考えるアーキテクチャ」に示したように、現代の企業はサプライチェーンとして、ほかの企業や社会のさまざまな仕組みと連動することで成り立っている。筆者個人の意見としては、このような観点から見るとEAでも視野が狭いのではないかと考えている。

　しかし、顧客との関係強化を図るITシステムを実現するためには、企業＝Enterprise単位で（あるいはEnterpriseを超えて）さまざまなシステムが連携する。大きく複雑に見えるITシステムを解きほぐすための視座として有効ではないかと考える。

　図1のEAのフレームワークに示すようにEAでは4つの階層的な体系に整理している。全体で見れば大きく複雑に見える全社のITシステムも、1つ1つは単純である。組み合わせると複雑さが増すうえ、時間の経過によりエンハンスを繰り返すことで、より複雑に絡み合ってしまう。

　EAの第2の機能として業務・システムに関する組織全体での改善活動に道筋を付けるとある。AsIs（現状）モデルを整理することで、先の章で提起したmake-or-buy分析に寄与する基礎情報に整理することができる。理想とするToBeモデルを整備し、そこで得られる組織全体の現状と理想目標を比較し、理想目標に至るまでの移行管理計画や業務システム開発に当たっての組織内共通ルールを策定することを要請している。

　ここで、連載の第4回目「“経営者の視点”で考えるアーキテクチャ」に示した図、経営者の視点─部門／部署の視点の差異を再掲したい。

　この図にあるように、ToBeモデルは企業としてどうあるべきかを示すものである。ToBeモデルなしに「これくらいならなんとかできそう」ということでITシステム構築・導入に手を付けるべきではない。

　EAフレームワーク図を、理想＝ToBeモデルを目指すというイメージで再構成したものを図3に示す。高い理想であるToBeモデルを目指した次期モデルでありたい。

SOAとアンバンドリング・リバンドリング

　現在の多くのITシステムが抱える問題として、ビジネスの機能やプロセスが緊密に結び付き過ぎることで、変化に対応できなくなっているという点が挙げられる。

　過去（システム構築時）のビジネスに対応した現行ITシステムのままでは、提供できるITサービスに制限が出る。

　現状のITシステムのさまざまなインターフェイスは、レストランでウェイターに料理方法を伝えているのと同じである。本来は欲しい料理を告げればよいはず。筆者はSOA（service-oriented architecture）は、ビジネスの変化に即応する（Agilty、On Demand、Adaptive）ことを実現するためのアーキテクチャと定義する。

　システム開発あるいはプログラミングによる実装のレベルにおけるSOAとしては、さまざまな手法が確立されつつある。今回は少しレイヤを変え、リエンジニアリングという側面からSOAを適用する方法を考えてみる。

　無駄の排除と身軽さを確保するため、「機能ごとへの解体」を検討する。これまで密結合していて、なかなか手を付けられなかった機能群を、本来持つ（提供する）べき機能と、付随する何かに解体してみる。このことで見えてくるのは、これまで購入した機能、構築した機能の中には、捨てることができる付随する何かが含まれているということである。これがアンバンドルである。

　次に、make-or-buy分析につながるリバンドルである。

　アンバンドル化され、本来持つ（提供する）べき機能だけになっていることで、あらゆる業界、あらゆる市場にまたがる多彩なビジネスプロセスをまとめて再構成し、提供することが可能となる。これまでのように、内製したり、購入したりして、内部にITシステムを構築する以外の選択肢もあり得るということを意味する。

　実際のビジネスのスピードに合うITシステムとするため、アンバンドル、リバンドルを行い、無駄の排除と身軽さを確保したい。

データ統合とメタデータ管理

　最後にデータコンソリデーションとメタデータ管理について触れておく。

　顧客との関係強化をITシステムでサポートできるようにするためには、顧客や顧客をサポートするために必要なデータ群が扱いやすい形で整理されている状況を維持し続ける仕組みが必要である。

　これがデータ統合とメタデータ管理である。データ統合は、全社内のさまざまなサブシステム内に散在するデータを統合すること、メタデータ管理は、情報をある一連の属性に関連付けて管理し、データの取得や処理を容易にするための方法である。

　前の章でも述べたように、現在のITシステムでは、密結合されていることが多い。これは、データについても同じである。そのサブシステム内では、有効に使用できるデータ形式であっても、ほかのサブシステムとの連動を考えたとき、そのままでは使用できないことが多い。

　データ統合の仕組みとして、大きく2つの方法が考えられる。

　まず、データHubによる仮想データ統合である。これは、現在のサブシステムの持つデータ構造やサブシステムのデータの持ち方を変えることなく、統合されているかのように利用可能とする仕組みである。統合されているかのように利用可能である半面、変更は各サブシステム側とデータHub側双方で同期を取った管理が必要となり、ITシステムの柔軟性確保という観点では、ToBeモデルとはなり得ないと考える。

　次に、メタデータ管理によるデータ統合である。各サブシステムの持つデータをメタデータ管理する。メタデータ管理とは、どこに・何が・どのような形でデータが存在するのかを管理することである。図5ではメタデータ管理を中核として、各サブシステムのデータを集中管理するイメージとしている。

　ITシステムの柔軟性確保という観点では、ToBeモデルとしてこのレベルを目指すべきである。

---

　ビジネスの時間軸と投入できるコスト・リソースの制約により、EAとして考えたToBeモデルをすぐに実現することは難しいかもしれない。しかし、ITに限らずビジネスには制約は付き物である。

　グッド・カスタマー・エクスペリエンスを生み出し続けるための組織とはどうあるべきか、それをサポートするITとはどうあるべきか、制約を乗り越えて実現していくことの一助となれば幸いである。