SPECIAL
2005/05/16 00:00 更新

特別インタビュー
すべての日本企業に経営のスピードと柔軟さを


業界はSOA（サービス指向アーキテクチャー）の大合唱だ。1990年代半ば、ガートナーによって提唱されたSOAは、Webサービス標準の整備という後押しを受け、メインストームに躍り出た。膨大なビジネスアプリケーション資産を誇るSAPは、「ESA」（エンタープライズ・サービス・アーキテクチャー）を提唱、これを実現する「SAP NetWeaver」プラットフォームによって、企業に経営のスピードと柔軟さを提供しようとしている。SAPジャパンの玉木一郎バイスプレジデント、ソリューション統括本部長に話を聞いた。

浅井（ITmedia）　業界ではSOAが大きな話題となっています。


玉木一郎氏

玉木　かつてはベストオブブリードの考え方のもと、技術基盤の異なるソフトウェア同士を統合しようとし、そのコストは結局のところ企業が個々に負担してきました。しかし、もはや市場はそうした考え方に大きな疑問を発しています。多くのIT企業が淘汰・吸収合併されているのはそのためです。別の視点に立つと、業務アプリケーションやミドルウェアはこれまで独立して存在してきましたが、今やこの境界線は極めてあいまいです。例えば業務アプリケーションはビジネスプロセスを統合する以上、単に機能を提供するだけでは不十分で、統合するためのインフラストラクチャーを持たざるを得なくなっているからです。　逆に単なるプラットフォーム、単なるミドルウェアだけを提供するベンダーは厳しい局面を迎えるでしょう。道具だけがあっても意味がないからです。SOAで提供されるサービスの価値とは、ビジネスロジックそのものであって、枠組みだけを幾ら提供していても、それは要素技術の提供に終わってしまいます。

手作りとパッケージの良いとこ取りをできるSOA

　これまでのシステムは、企業の「戦略」以前を扱ってきました。企業が「己を知る」「市場環境を知る」ためのコストが非常に高くついたので、これを改善するERPは大きな役割を果たすことができたのです。

　しかし、ここへきて企業は競争戦略のための道具としてITを活用しようとしています。競争優位を築くということは、他社と明確な差別化をすることで、それを支えるITにも自ずと個別解が必要となります。日本の企業の多くは、「差別化すべきところは標準化できない、手作りで幾らお金をかけてもかまわない」と考えていました。確かに合理性はあったのですが、競争環境の変化のスピードが加速してきたことによって問題を抱えてしまいました。差別化するために手作りしたシステムは、変化に滅法弱いからです。その一方で、対極に位置するパッケージも個別解に見えません。こういう「手作りvs.パッケージ」の二元論では、差別化と変化のスピードという2つの軸に対して解答を用意できないのです。

　アプリケーションがビジネスロジックを提供するエンジンだとすれば、個々の企業が一から作るのではなく、実証されたものを活用すべきです。しかし、それらを組み上げて個別解を作るプロセスは、もっと柔軟にあたかも手作りシステムのようにできるべきです。この行き着く解答がサービス志向のアーキテクチャーであるSOAなのです。

SAPはカスタマイズできるのに、なぜSOAなのか？

新野淳一

新野（＠IT）　SAPの顧客らには、既にIDocやBAPIによってインタフェースが提供され、カスタマイズが実現できています。なぜ、SOAなのでしょうか。

玉木　ERPのような基幹系が企業システムの大半を占めていた1990年代は、SAPソリューションをカスタマイズすれば事足りました。しかし、ITの進歩によって、その適用範囲が拡大し、交換すべきデータは、受注・発注のようなトランザクションデータに限らず、非定型なデータまで広がっています。

　また、従来であれば、すべて企業内にあったプロセス、例えば典型的な例は「生産」ですが、今や日本から海外へと移ってしまっています。つまり、企業の中に閉じていた「購買」「生産」「販売」という一連のバリューチェーンが企業をまたがるようになった結果、単にインタフェースが提供されていればいいというわけではなくなっています。システムとシステムをまたがった上に、もう一度ビジネスプロセスを再構築するレイヤが必要になってきたのです。

　これと同様にエンドユーザーも企業の内部に閉じた存在ではなくなっています。社外のパートナーが自由に、しかしセキュリティは維持しながらシステムにアクセスできるようにしなければなりません。遠隔地の人とコラボレーションできたり、個々のビジネスプロセスで適切な判断のための知識や知恵をユーザに与えることも必要です。

　また、異なる企業同士が一緒に仕事をする場合には共通言語が必要になります。例えば、製品や顧客のマスターデータで、これを一元化するか、あるいはだれかが通訳する必要があります。

　SAPの強みは、「リアルタイム統合」であり、これは今後も変わりません。ただERPやシステムの概念が企業の内側から外側へ拡大したことによって、その定義が拡大してきているのです。

新野（＠IT）　SOAは標準的な技術によってシステムを統合していく考え方です。SAPはどのように差別化を図っていくのでしょうか。

玉木　もちろんSAPの強みはサービスの元となる膨大なビジネスアプリケーションの資産であり、それは間違いなく世界一です。そこにSOAのプラットフォームを用意することによって、SAPの導入やアップグレードで、企業は即SOAの実現に踏み込んでいくことができます。SOAだからといって「べき論」に終始したり、オブジェクトの設計を最初から始める必要などありません。サービス化とモデル化の現実解を提供することで柔軟な形でのSOAが可能になるのです。アプリケーションが外部開放的になっていれば、いつ、どの程度までSOAの技術を使ったシナリオに変えていくかは、その時々の戦略的な優先度によって決めればいいのです。

　ある企業にとっては、システムの90%はそのままにし、10％をSOAによって柔軟な環境にするだけで良いかもしれません。なぜなら、その10％が顧客接点を担うプロセスで、頻繁なプロセス変更が必要になるからです。あるいは、購買、生産、販売というバリューチェーンの各プロセスを外部に切り離したりシェアード・サービス化を進める企業もあるでしょう。この場合はシステム全体がSOAの技術に基づいていなければ柔軟性を維持できません。こうしたことは戦略によって決まることであって、アーキテクチャーが決めることではありません。だからこそ、その戦略を支えるインフラをどこからでも利用できるようにしておく必要があるのです。例えばSAP R/3の後継となったmySAP ERPは、SOAを実現したERPです。これを可能にするのがサービス化されたアプリケーションロジックとSOAプラットフォーム、そしてモデル指向の開発プロセス等です。

求められるのは真のソリューションアドバイザー

浅井英二

浅井（ITmedia）　SOAになったとき、パートナーとのエコシステムはどうなるのでしょうか。

玉木　SOAの世界では、われわれを取り巻くエコシステムは大きく変わります。現在はSAPがソフトウェアを提供し、プラットフォームベンダーがハードウェアを提供し、導入する、あるいはメンテナンスするというサービスが存在します。しかし今後、こうした従来の役割分担は、高い付加価値を生むあり方とはみなされなくなるでしょう。

　日本企業のCIOといわれる人たちは、従来であれば、ITのインフラを構築することによって経営トップに対する説明責任を果たせたのですが、それが突然、経営戦略に対してどういうことができるか解答を求められている。つまりCIOの役割は、「CPIO」つまりチーフ・プロセス・イノベーション・オフィサーへと変わったのです。そのような時代に求められるのは、企業にとっての信頼されるアドバイザーとなり、企業戦略とITの架け橋として、価値実現までのロードマップを立案できるパートナーです。

　SOAというアーキテクチャーに則り、既存のソフトウェアを活用しながら個別解を組み上げるためには、テクノロジーに対する洞察に加え、さらに深い業界のノウハウも重要になるでしょう。その上で、「ソリューションの幅（広さ）」、「戦略的な度合い（深さ）」、それに「ロードマップ（時間）」を見ながらソリューションを構築していくことが求められていくはずです。

[ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.