SOA(サービス指向アーキテクチャ)環境のデータ連携ミドルウエアなどを手がけるソニックソフトウェアと,データベース接続やメインフレーム接続などのミドルウエアを手がけるデータディレクトテクノロジーズの2社は,2008年3月1日に両社共通の代表取締役社長を迎え入れ,経営統合へと舵を切った。2社の親会社はいずれも米Progress Softwareで,同社の事業部門として米Sonic Softwareと米DataDirect Technologiesが存在する。日本の2法人の社長を務める田上一巳氏に,経営統合の経緯や狙いを聞いた。

(聞き手は日川 佳三=ITpro



ソニックソフトウェアとデータディレクトテクノロジーズの2社でともに代表取締役社長を努める田上一巳氏
[画像のクリックで拡大表示]

ソニックソフトウェアとデータディレクトテクノロジーズの2社を統合することにした経緯は?

 米Progress Softwareからは当初,ソニックソフトウェアの社長に就任してほしいという依頼を受けていた。その後,米国で10カ月にわたって,Sonic Software部門やDataDirect Technologies部門の担当者や米Progress SoftwareのCEO(最高経営責任者)と話し合った。その結果,どちらが先に言い出したというのでもないのだが,日本では2社の社長に同時に就任し,経営を統合していったほうがよい,という流れになった。米Progress Softwareの関連企業は世界46カ国にあるが,統合するのは日本が初めてのケースとなる。

 2社が手がけている製品の分野は,実は私の経歴と極めて似ている。例えば,コグノス時代にはBI/BAM系の製品を手がけていたが,これはソニックソフトウェアに当てはめると,金融に特化してはいるものの「Apama」が相当する。シービヨンド・テクノロジー・コーポレーション時代にはEAI/BPMを主にやっていたが,この分野に概要する製品として,データディレクトテクノロジーズにはODBC/JDBCドライバなどが,ソニックソフトウェアにはESBがある。さらに,ジャストシステム時代にはXML環境のxfy事業を立ち上げたが,データディレクトテクノロジーズにはStylus Studioがある。

2社のビジネスを統合する目的は?

 まず,データディレクトテクノロジーズが今後の展望として,よりエンタープライズ(企業)寄りの市場を指向している,ということが挙げられる。主流製品であるODBC/JDBCドライバは従来,使われる場所こそエンタープライズではあるものの,エンタープライズの中にあるコンシューマ製品というイメージがあった。今後は,よりエンタープライズ寄りの製品やサービスに組み込んで展開していきたい,と考えている。

 次に,2社の製品を組み合わせることで,提供できる製品やサービスの幅が広がる。今からしゃべることは,この1週間に起こったことだが,ソニックソフトウェアの既存顧客の例を紹介しよう。この会社は,ソニックソフトウェアのESB(Enterprise Service Bus)製品であるSonic ESBを適用したSOA環境を持っており,このSOA環境とメインフレームとのデータ連携に悩んでいた。FTP(ファイル転送)で連携させようと考えていたようなので,データディレクトテクノロジーズが販売するメインフレーム向けSOA環境ソフト「DataDirect Shadow」を提案した。今,まさに評価のフェーズに入っているところだ。

 提供できる製品やサービスの幅が広がるというのは,「足し算」ではなく「掛け算」で効く。米Progress Softwareからは「売り上げは以前の3倍でいいよ」と軽くジョークのように言われているが,私も3倍くらいでいいんじゃないかな,と考えている。今までの製品の売り上げが伸びるというだけでなく,用途別に製品などを分かりやすくパッケージ化した“ソリューション”として,新規の需要を開拓できるはずだ。製品は難しいものだが,ソリューションなら顧客から見て分かりやすく,コスト効率も良い。

以前から販売している個々の“製品”と,個々の製品を束ねたり付加価値を付けるなどした“ソリューション”との違いは何か?

 製品は“部品”だと考えてほしい。ユーザー企業には,ある程度もう出来上がっているシステムがあって,その悪い部分を補強するのが製品だ。悪い部分を補強するためのものだから,「テクノロジーが良い」だとか,「この機能が良い」だとかいう会話になる。ところが,ソリューションとして大きな絵を描けるようになってくると,スクラッチで一から新規の業務システムを構築する,といった需要にフィットし,こうした市場に参入できるようになる。これはステージの違いだ。つまり,ある部分のリプレースで入っていくのか,新規構築で入っていけるのか,の違いである。

 ソリューションの提案には,顧客の言葉で話せることも大切だ。例えば,「ESB」とか言われても,それは我々がIT業界にいるから分かるのであって,業務部門にいるユーザーには厳しい。ここに,個々の技術部品としての製品ではなく,提案ごとのソリューションにする意味がある。お客と話ができるアプリケーション・エンジニアを育てることも,今後生き残っていくためには重要だ。野球で言えば,プロ野球の選手並みに野球が上手い必要はないが,少なくとも野球のルールくらいは知っていなければ会話にならない。

 コアとなるソリューションという意味で「ソリューション・コア」と呼ぶパッケージを,今後3カ月以内に複数用意したいと考えている。ユーザー企業の業務部門向けにソリューションをメッセージとして伝えられるパッケージ製品に仕上げたい。顧客は,具体的にどんな部品が使われているか,などは知る必要がない。一方,SIベンダーやパートナ企業やIT部門向けには,従来通りの詳細な製品情報を提供する。さらに,これもソリューションの提案には大切なことだが,価格も可能な限り分かりやすく提示したい。今の時代,価格をまったく提示しないで「個別対応です」とか言っていたら相手にされないからだ。

XMLエディタ製品であるStylus Studioの需要は?

 従来のXMLは,単なるオフィス文書のデータ保存形式であったり,システム間連携のメッセージ形式であったりした。それ以上のものではなかった。ユーザーがその存在を意識しない使われ方だった。ところが,ここ最近のことだが,XMLのメリットを理解した上で「積極的にXMLのメリットを活用したい」と,エンドユーザーが考え始めるようになったのだ。

 例えば,RDB(リレーショナル・データベース)のようなキッチリした実装が向かないケースにおいて,オブジェクト指向の考えに基づくXMLのような技術が生きる。例えば電子カタログの実装や文書作成に向くだろう。あのAmazonのWebサイトもデータをXMLで保持している。複数分野ごとに別個の項目名を持たせたい場合,RDBだと実装が難しくなるが,XMLならタグを作ってデータを入れておくだけでいい。

 XMLなら,部品化やその再利用も容易だ。ネジなどのような,同じ見た目で種類の多い部材商品をWebカタログ販売する場合などを考えてみよう。XMLなら,あるアイテムの一部のデータに変更を加えた際,そのデータを組み込んでいる他のアイテムに対しても自動的にデータの変更が反映される。こうした運用が易しくなるのだ。