ビジネス系IT雑誌などで、EAI(Enterprise Application Integration)という言葉が踊っている。既存のシステムを有効活用するのは、確かに理想的である。しかし、実際のビジネスの現場ではシステム連携はどのように行われており、どのぐらいのニーズがあるのだろうか? システム連携の理想と現実を追った
アパレルメーカーで生地の仕入れをしながら、かたわらで業務のシステム化を任命されている友人に聞いてみた。
私 「仕入管理システムで扱う業務データってさ、仕入れ部門で完結しているわけ?」
友人 「いや、デザイン部でも、営業でも利用するよ」
私 「そのデータ連携ってどうしてるの?」
友人 「ファイルに落としてですねえ、フロッピーディスク経由で受け渡ししたり、紙でやりとりしたり……」
私 「システム上でやりとりできれば便利と思わない?」
友人 「思いますねえ。でも無理だろうなあ」
私 「なぜ?」
友人 「予算がつかないもの」
私 「なぜ?」
友人 「いまシステム化プロジェクト予算って、みんなお客さんに密着した店舗系のシステムにいっちゃうんですよ。バックオフィスの業務効率向上にお金をかけても効果が見込めない、と。社員がいるんだから、データが必要なら自分で入力し直せばいいじゃないかってことですね」
システム連携の取材を始めた当初、この友人の話は不幸な例外だと思っていた。まだシステム化の歴史が浅いから、データを共有することの理解が進んでいないんだと結論づけたのだ。しかし、どうやらこれが日本の業務システム連携の現実らしいということが次第に分かってきた。
ある外資系小売メーカーは、海外本社が開発した基幹システムを利用していたが、それでは対応できない業務があったため、別に日本の業務パッケージを導入した。この2つのシステム間は、長い間フロッピーディスク経由でデータ交換を行っていた。それが解消されたのは、システムの陳腐化を契機に新基幹システムが一から作り直されたときだった。
また、あるメーカーでは、情報システム部門とユーザー部門の対立がシステム連携を阻んだ。情報システム部門が選定したパッケージの基幹業務システムとユーザー部門が構築した営業支援システムの間でデータ共有が進まなかった。ユーザー部門の出す連携要望に、ただでさえ多忙な情報システム部門が消極的だったのだ。そのたび発生するコストをどちらが負担するかでもめた。
このように、企業の中ではシステム連携が進まなくても、いみじくも私の友人が指摘したように人手で何とかなる。というより、何とかしている状況にある。
しかし、企業をまたいで取り引きやビジネスの協業を行おうとすれば、どうしてもシステム的にも協力しあう必要が生じる。典型的なのがBtoC、BtoB向けのeビジネスである。
東京と広島を拠点にビジネスを展開するインターネットスーパーがある。ビジネスモデルがユニークで、数社のスーパーマーケットの商品を一元的に扱うWebポータルを運営しているのだ。スーパーマーケット版楽天市場といえるかもしれない。これによって、リアルのスーパーマーケットは新たなシステム投資なしにeビジネスに進出することができ、ポータルサイトは最初からスーパーマーケットのブランド力と品揃えを活用してビジネスを展開することができるというわけだ。
このサイトでは、利用者をそれぞれのスーパーのリアルな店舗から即日宅配可能な範囲に地域に限定しており、注文はWebサイト上から、あるいは独自に配布している商品カタログを見ながら電話で行う。そして当日13時までに注文すれば、その日の夕方には商品が届けられるという仕組みだ。決済には指定のクレジットカードを利用する。
このポータルサイトの試みは意欲的で、音声認識技術を利用したショッピングや、携帯電話にマイクロバーコードリーダを接続し、カタログのバーコードをなぞって注文ができるサービスなどもあり、サイバースペースでのスーパーマーケットのビジネススタイルを果敢に探っている。
さて、このeビジネスには複数のプレーヤーが関わっている。まずは参加するスーパーマーケットの情報システム部隊、ポータルサイトを構築し運用管理する部隊、注文情報を受けて利用者のために商品のピッキングや配達を行う実働部隊、そしてシステム構築をサポートする外注ソフトハウスなどだ。プレーヤーたちの所属する企業、ロケーションは、もちろんすべて異なっている。
データの流れをざっと説明しよう。
ユーザーにWebサイトから商品を選んでもらうためには商品カタログを掲載しなければ始まらない。これを実現するため、スーパーマーケットのPOS情報システムが利用されている。開店前に本部の親POSシステムからそれぞれの支店の複数の子POSシステムに対してデータがダウンロードされるのだが、ポータルサイトのシステムもこの子POSメンバーの1つであるようにふるまって商品情報を受け取る。この情報を元に、カタログ用に撮影された画像情報とともに商品カタログを生成する。
ユーザーからの注文情報は当日の締め切り時間である13時まで蓄積され、スーパーマーケットの情報システム部隊とバックヤードで待機する実働部隊の拠点に転送される。注文情報を受注情報として受け取ると、実働部隊は店舗でユーザーになりかわって商品のピッキングを始める。中には精肉などのようにグラム売りの商品もあるので、200gと注文を受けても、実際には205gになったりする。その場合は最終価格をシステムに入力し、ポータルサイト経由でサイトの利用者に通知しなければならない。
一方で、スーパーマーケットの発注担当者は店舗での商品の売れ行きとともにポータルサイトでの受注情報を合わせみて、次の発注量を検討するのである。
こうした複数のシステム間連携のインフラを、当初はデータ交換ミドルウェアが受け持つことに決まった。この製品は、TCP/IPで接続された異機種システム間のデータ転送を自動的に行うもので、データフォーマットの交換も行える。メインフレーム、UNIX、Windows環境など、さまざまなプラットフォームが混在する企業間システム連携では、最適のソリューションのはずだった。
ところが、いったんは導入した専用ミドルウェアは、FTPによるファイル転送という方法になってしまったのである。
このミドルウェアを利用するためには転送するデータの内容や構造を事前にきちんと設定しておかなければならなかった。しかし、成長過程にあるeビジネスでは刻々と状況が変化する。スーパーマーケットが必要とするデータ、ポータルサイトを構築する部隊が必要とするデータの種類は決めたそばから変わっていった。
また、参加するプレーヤーのすべてがこのデータ交換ミドルウェアの機能に習熟しているわけではなく、その利用に積極的というわけではなかった。なんといっても、eビジネスで一朝一夕に大きな収益を上げることは難しい。トライアルの意味合いが強いこの取り組みに対して、プレイヤー間に微妙な温度差があったといえよう。
結局、このミドルウェアを使って稼動テストまで行ったものの、それ以上の利用をいったん断念、誰もが新たな負担なしに理解しあえる技術を検討した結果、CSV形式のデータをFTP転送するという結論に落ち着いたのである。逆にいえば、FTPによるバッチ処理でも十分、現実的だったということでもある。
ではあるが、メンバーたちはミドルウェアを使ったシステム連携を完全に放棄したわけではない。実働部隊で陣頭指揮を執っているA氏は「利用を先に延ばしただけ。システム運用が完全に軌道に乗り、メンバーの余裕ができたところで、もう一度チャレンジしたい」と語っている。
上記は一例に過ぎないが、システム連携の現場での困難さの一端を垣間見せてくれる。
とはいえ、決して日本企業のすべてがシステム連携に苦しんでいるわけではない。見渡してみると、富士通の新営業情報システム「Safaia」や東レの基幹連携システム、沖電気工業の全社システム統合プロジェクトなど、大規模なEAI事例はいくらでも見出だすことができる。ERPパッケージを導入した企業は、必ずといっていいほどEAIに取り組んでいる。
しかし、ここで注意したいのは、事例として登場する企業の大半が大企業であるということだ。それもほぼトップダウンでプロジェクトが進んでいる。潤沢なIT予算が確保できなければ、そして関係者すべての間で理解が得られなければ、スマートなシステム連携は見果てぬ夢なのだろうか。持てる者のソリューションなのだろうか?
大企業の中にも、EAIとして語られるシステム統合には否定的な意見がある。今回、取材を打診したあるコンピュータメーカーの情報システム部門担当者はいった。「システムを完全に統合する方針で、EAIを必要としない方向で動いている。企業外部とのやりとりに関しても、いまのところ高価なEAI環境を必要とするには至っていない」。実際、“EAIツールは高価”という言葉を複数のIT業界関係者から聞いた。
みずほ銀行の大規模なシステム障害も、日本企業におけるEAI気運に水を差すことになるだろう。原因は旧三行の基幹システム連携部分で起こっており、まちがいなくEAIの失敗といえる。マスコミの論調も、“一からシステムを作り直す時間があったのに、既存の基幹システム温存を選んだからこうなったのだ”と非常に冷ややかだ。
EAIソリューションとは必ずしもEAIツールの導入を意味しない。同時に、企業の規模を問わず、今後何らかのシステム間の連携は不可避である。この取り組み自体が間違っているわけではない。
何より“今よりもう少し使い勝手のいいシステム”をのぞんでいけないはずがない。次回は、現状あいまいに受けとられているEAIの定義とその連携レベルをもう一度整理し直し、それらを実現する製品としてどのようなものが市場にあるのか、どうすれば自らの問題としてこのテクノロジーを考えられるのかをまとめてみたい。
吉田 育代(よしだ いくよ)
1962年生まれ、大阪市出身。関西大学社会学部卒。阪急百貨店宣伝部に、コピーライ ターとして入社。1年半後に上京し、広告制作プロダクションを経て、フリーに。その後、IT分野をカバーするライターに転身。企業情報システムを主な守備範囲として、 幅広く執筆活動を行う。著書に「日本オラクル伝」(ソフトバンク・パブリッシン グ 刊)、「まるごと図解 最新ASPがわかる」(技術評論社刊)、「B2B調達革新で蘇 る日本企業」(ソフトバンク・パブリッシング刊)。現在、「DB Magazine」(翔泳社)、「日経ソフトウエア」(日経BP社)に連載コーナー展開中。
メールアドレスはhonpo@kt.rim.or.jp
Copyright © ITmedia, Inc. All Rights Reserved.