他社製PBXとも連携

前述の通り、SphericallはPBXの代替品として開発されたものではない。長い目で見れば、従来のSVシリーズの領域までカバーしていく可能性はもちろんあるが、現時点でそうした使い方をするユーザー企業はあまりいないだろう。電話自体の機能については従来型のPBXのほうが上だし、今あるシステムをそのまま使ったほうがコスト面でも有利だ。

つまり、電話部分に関しては既存PBXとの連携が想定されているが、実はこの部分もSphericallはオープンになっている。連携できるのはNECのPBXだけではないのだ。「NECのPBXなら『これだけいいことがあります』ということはやっていく考えだが、コミュニケーションを統合するのがSphericallなわけだから、他社のPBXとも当然つながる」と第二企業ネットワークソリューション事業部長の平田英之氏は説明する。

このような戦略をとるのは、UNIVERGE専用ではSphericallの市場が広がらないからでもある。特にそれが顕著なのが海外。企業ネットワーク事業企画部統括マネージャーの秋本富士夫氏は「海外ではノーテルやシスコ、アバイアでも使えないとビジネスにならない」と話す。昨年夏から先行して海外ではSphericallの正式販売が始まっており、すでに他社製PBXとの連携例があるという。

国内においても、この戦略は変わらない。「Sphericallが今から作っていく新しい領域で、どんどん他社の“パーク”を取っていく」と保坂氏は意気込む。

ちなみに、海外ではすでに200システム以上の導入実績があるそうだ。

IT技術者にも扱い易い“糊”

ここまで端末などの面から、いかにSphericallが高いオープン性を有しているかを見てきたが、ある意味、さらに重要なのがSFAやERP、SCM、CRMなど業務システム側のインターフェースだろう。「業務やビジネスプロセスに、コミュニケーションの機能を埋め込むこと」（保坂氏）がSphericallの役割だからである。通信の知識がないIT系など多くの技術者にとって容易な開発環境を提供できなければ、業務システムとの連携など進展するはずがない。

そこで用意したのが最大のポイントともいえるSOC（Service Oriented Communications）である。これは、Sphericallと業務システムをつなぐためのAPIで、もちろんSOA（Service Oriented Architecture：サービス指向アーキテクチャ）を元に作った言葉だ。

図表2　SOAアーキテクチャに対応し業務システムと柔軟に連携できる

SOAとは、「在庫照会をする」「決済する」など業務上の1プロセスを「サービス」と見立て、それら「サービス」をSOAPなどのWebサービスにより連携させることで、システム全体を構築していくアーキテクチャ。業務プロセス単位で部品化された「サービス」の再利用・組み合わせによりソリューションを実現できるため、開発やその後の仕様変更・機能追加などにかかるコストや時間を大幅に削減できる。そのため最近、業務システムの新しい構築法として急速に採用が進んでいる。

SOCは、このSOAをさらにコミュニケーションの領域にまで広げるものといえる。XML、SOAP、WSDLといったIT技術者に非常になじみ深いWebサービスインターフェースにより、多種多様なコミュニケーション機能を業務システムに簡単に組み込めるのである。

例えば、グーグルがGoogle Mapsの機能をAPIで公開して以降、ちょっとした知識さえあれば、簡単に地図機能を自社のWebサイトなどに組み込むことが可能になったが、同様のことが企業のコミュニケーション分野でも実現すると考えると分かり易いかもしれない。従来のSVシリーズで業務システム連携を行うには情報システム部門が関わる必要があったが、Sphericallなら事業部門などの「現場で動かせるレベル」（平田氏）になるという。

秋本氏は、Sphericallを業務システムや多様なコミュニケーション手段をつなぎ合わせる“糊”にたとえるが、SFAやERP、CRMなどさまざまな業務システムに簡単にコミュニケーション機能を付加できる“糊”が登場したのである。