膨張したIT環境を統一しよう特集:企業システムを柔軟に統合する Part.1

パッケージなど個別ソリューションの導入は終わりを告げ、いまユーザー企業の情報マネージャは「全社で統一されたIT基盤」に関心を寄せているようだ。その背景と、解決技術について解説する。

» 2004年02月20日 12時00分 公開
[岩崎史絵,@IT]

 いま、企業システムの開発においてどのようなトレンドが起こっているのだろうか。@ITが昨年9月にユーザー企業の情報マネージャに向け実施した「勤務先情報マネジメント体制の『問題点』」というアンケートによると、「統一システム基盤/ITガバナンスの欠如」という課題が1位になった(図1参照)。ERPやSCM、CRMといった個別パッケージのブームが去り、残ったのは各業務部門でバラバラに導入したシステム群だ。これらの運用に頭を悩ます情報マネージャは多い。

ALT 図1 勤務先情報マネジメント体制の「問題点」

 こうした個別パッケージは業務部門主導で導入したものが多く、極端な場合ほかのシステムと連携せず、その部門内でだけ動いているシステムもある。これでは情報システム部門の目が届くはずはないのだが、運用フェイズに入ると当然のように情報システム部門に運用が託される。また “場当たり”的に導入していった結果、同じような機能を持つシステムが社内のあちこちに分散しているケースもある。この状況を把握できず、「ERPを全社ビックバン導入してITを整えよう」と、さらなる過剰投資に踏み切る企業も少なくはない。

 ここで問題が2つある。1つは、会社として統一した情報戦略基盤を作る必要があるということ。そのためには、情報マネージャもしくはITが分かる経営層の指揮の下、社内のITガバナンスを整備しなくてはならない。ITガバナンスの確立は、組織運営・経営戦略・投資戦略といった、技術力以外のマネジメント能力が強く要求される分野だ。これについては「情報マネジメント」のほかの連載で解説しているので、ここでは省略する。そこでもう1つの技術的な課題である「全社バラバラのITをいかに効率よくまとめていくか?」に焦点を当てることにする。

なぜシステムを連携させるのか?

 個別システムを連携させるニーズとして、以下の3点が挙げられる。

  • 運用管理負荷の削減
  • 既存資産を生かした効率的なITの構築
  • 新規開発の削減と効率化

 「運用負荷の削減」については先に述べたとおり、孤立したシステムが存在するという問題だ。導入している部門内で運用できればベストだが、サーバのダウンやネットワーク障害など、技術知識がないと対処できない問題も多々発生する。そこで情報システム部門の出番だが、その都度「どんな原因でどういう不具合が起こったか」をチェックしなければならず、作業負荷が掛かる。同じ企業システムのインフラの中で一括して運用できればこうした負担は削減されるわけだ。

 もう1つ、運用負荷以上に問題になっているのが、「ITの全体最適化」という問題だ。これも先述したとおり、例えば顧客システムが各事業部でバラバラに構築されて情報が統一されていないといった状況がある。CRMパッケージを入れて顧客データや対応状況は閲覧できているとしても、営業部やフィールドサービス部門だけに閉じており、製品開発や会計といったバックエンドの業務部門まで情報が届いていないことが多い。

 とはいえ、既存システムが存在するのに機能が豊富なパッケージ製品を導入するのは考えものだ。確かにパッケージという共通基盤があれば、フロントエンドモジュールからバックエンドモジュールまでシームレスにつながる。ただ、慣れた既存システムを捨てて新しいシステムを入れて本当に現場に根付くのか不明だし、余計なコストが掛かる。むしろユーザー企業からは「既存の仕組みを生かし、自社のビジネスフローにのっとってITの仕組みを再構築したい」というニーズが高い。

 また金融機関などでは、先物取引や株取引処理システムを金融市場の取引インフラである「SWIFT」に接続する必要がある。従来、SWIFTへの接続は個別システムごとにバラバラに接続していた。だが扱う金融商品の数が増すごとに新たにシステムを開発し、接続プログラムをいちいち記述していたのでは、迅速なサービス開始はのぞめない。そこでこうした複数のシステムをハブ&スポークの形につなぎ、共通化できるバックエンドの処理を共通化して、一括してSWIFTに流すなどの試みが立ち上がっている。インテグレーション・サーバ「Vitria:BusinesWare」を提供しているビトリア・テクノロジー ビジネス・ディベロップメント ディレクターの齋藤真一氏によれば、「各システムの共通処理やを接続用のサーバで一元化することで、新規アプリケーションのサービスインまで工数が減り、運用負荷も大幅に削減できるようになります」と語る。

システム連携に際して生じる技術的な問題

 一方、「システム連携」に当たって発生する技術課題を見ていこう。

 複数のシステムを連携するに当たり、まず気にかかるのは開発工数だ。ハードウェア環境もデータ形式も実装技術も異なる個別システムを連携するには、かなりの工数を覚悟しなくてはならない。技術特性やデータ構造を洗い出さなくてはならないうえ、転送/フォーマット変換プログラムを作成するのも大変な手間だ。さらに、どのようなビジネスプロセスで各システムを連携させていくかを決める必要がある。

 また、接続するシステムは普段の業務で使っているもの。連携させるためにいちいちシステムを止めていたのでは普段の業務に支障が出てしまう。開発作業はもちろん、テストやデバッグなどの工程では本システムを使わざるを得ない。

 さらに頭を悩ますのは運用フェイズだ。例えば新しいアプリケーションを追加したり、パッケージのバージョンアップなどが発生すると、それに伴い連携プログラムを修正させる必要がある。具体的にはデータ転送やメッセージング用プログラムの追加開発、新アプリケーション接続によるビジネスロジックプログラムなどの変更などだ。

 ビジネス的な観点や、情報システム部門の仕事から考えると、確かにシステム全体を統合することは必要だ。しかしその作業を1つ1つ手作業で行っていたのでは、工数もコストも膨大に掛かるうえ、変更や追加開発に対応し切れない硬直したシステムが出来上がってしまう。

 こうした問題を解決するのが、EAI(Enterprise Application Integration)やインテグレーション・サーバと呼ばれる製品群だ。主要パッケージやメインフレームに対応したアダプタを備え、データフォーマットやシステムの違いを吸収する。さらに最近はEAI機能に加え、ビジネスの流れに従ってシステムの動きそのものを制御するBPM(Business Process Management)機能を備えた製品も多く出てきており、各ベンダもEAIよりむしろBPM機能を全面に押し出してアピールしている。

 BPMとは耳慣れない言葉だが、具体的に何ができるのか。シービヨンド・テクノロジー・コーポレーション 技術本部セールス・サポート部の六戸力氏は「各行部門にまたがって、仕事をする“人”と“システム”の流れを洗い出し、そのフローを最適化するための仕組みです」と語る。さらにビトリア・テクノロジーでは「フローの最適化と実装、それに可視化により常に改善していく機能を持ちます」(齋藤氏)。また、サヴィオン・テクノロジーでは「業務は人によって成り立っています。この人間系の業務をシミュレーションし、さらに支援する仕組みを作り出し、可視化し、改善していくものです」(宇野澤庸弘社長)という。これらをまとめると、次のようになる。

BPMの機能

  • 各部門間にまたがった業務フローに従い、データや処理の流れを記述・制御する機能を持つ
  • 業務フローに従い、必要なデータを転送する機能を持つ
  • ビジネスフローが正しく流れているかモニタリングし、異常があれば通達する
  • ビジネスフローのボトルネック部分を検出し、それを解消するためのフロー記述やシミュレーション機能を持つ


 こうなると、もはや「EAI」というITレベルの連携ではなく、会社のビジネス全体を最適化するフェイズに入ったきたということだ。次に、これらの機能を実現するIT技術について見ていこう。

キーワードは「疎結合」

 EAI/BPMを実現する手段としては、次の3つの技術がメインに使われている。

XML
Webサービス
J2EE
主にデータ変換/転送のための中間フォーマットとして使われている。 データ転送/連携に使われている。またWebサービスの1規格であるビジネスプロセス実装言語「BPEL4WS」は、プロセス連携の標準技術として多くの製品に採用されている。 ビジネスロジックの記述に使われたり、何らかの処理が発生した際、その処理に従って必要なアプリケーションをキックし、データやメッセージを流す。

 これらの技術の特徴として挙げられるのは、「疎結合」であるという点だ。システム同士をがっちりと密結合させるのでなく、中間ファイルを使ったり、ビジネスロジック部分を切り出すことで、変化に柔軟に対応できる仕組みだ。

 「例えば手組み開発の場合、接続用プログラムの中にビジネスプロセスの流れやメッセージ変換の仕組みを入れ込んでしまうので、接続先のシステムに何らかの変更があった場合、再度作り直す必要があります。しかし統合用サーバだと、データ変換層、メッセージング層、ビジネスプロセス層と分かれており、接続しているシステム本体に何らかの変更があっても中間部分を書き換えるだけで済むので、運用後の技術的な変化対応やビジネスプロセスの書き換えなどに柔軟に対応できます」(ビトリア・テクノロジー 齋藤氏)。

 EAI/BPM製品が持つもう1つのポイントは、ビジネスプロセスのモニタリングができること。システム全体の運用管理だけでなく、プロセスの処理状況を監視し、場合によってはプロセスそのものを変更することができる。具体的には、モニタリング結果を受け、専用のGUIツールを使って新しいビジネスプロセスを定義すれば、自動的にBPEL4WSなどに変換/デプロイされて、動く仕組みだ。

 とはいえ、こうしたツールがカバーするのはやはりITの流れであり、人間系のプロセスを巻き込んで制御・監視する機能は弱い。サヴィオン・テクノロジーの宇野澤社長は、「システムの処理フローをいくら監視し、実行しても人間系の業務が変わらなければBPMの意味はありません」と指摘。例えばサヴィオンの「Savvion BusinessManager」は、社員や派遣、アルバイトなどの業務をシミュレーションし、各人の時間ごとの処理能力と時給換算までできる仕組みを備えている。「人とITを巻き込んでビジネスプロセスを最適化することで、真のBPMが実現できます」(宇野澤社長)。

プロジェクトに当たって情報マネージャが担う役割

 では、実際にEAI/BPMツールの導入に当たり、情報マネージャは何をやらなければならないのか。

 シービヨンド・テクノロジー・コーポレーションの六戸氏は「極端な話、IT自体の構築については、われわれツールベンダやSIベンダに任せておけばいい」と言い切る。例えば種々のシステムのインターフェイスやデータ形式などの洗い出しは、そのシステムを納入したSI会社や技術者の方が知識もノウハウもある。

 「それより、複数のシステム=複数の業務部門をつなぐということですから、社内組織の取りまとめが最大のポイントになります。業務部門ごとの個別最適に陥らず、全体最適の面からビジネスの流れを再定義するため、各部門に協力を要請できること。そして新しいビジネスプロセスを実行するよう、業務部門全体を盛り上げていくプロジェクトマネジメント能力や段取りが必要になります」(六戸氏)。全社のITを統合するには、やはり情報システム部門主導による「ITガバナンスの確立」が必要とされるようだ。

 ビトリア・テクノロジーの齋藤氏は上記に加え、「できれば(1)現状のビジネスプロセスはどんな姿をしており(As-Isモデル)、(2)それをどのように変更させたいのか(To-Beモデル)、分析・設計ができればベストです。ツール側は連携アダプタやビジネスプロセスの実装機能は持っていますが、この中に流れをどんなふうに記述するかは、『ユーザー企業が何をやりたいか』に大きく依存しますから」と語る。

 次回は主要製品の特徴について、詳しく見ていくことにする。

Copyright © ITmedia, Inc. All Rights Reserved.