クライアント型SOAによるBtoCビジネス向けシステム

事例『一括！コマース「速販」』＋アカウンアグリゲーションシステム

当社の『一括！コマース「速販」』において、Yahoo! Auctions、Yahoo! Shopping、楽天の各種サーバに接続してクライアント型SOAを実現していることは、本連載の「第3回：クライアント型SOAの実例」や、連載「IdbAで構築する生産性が高いリッチクライアントの第3回」でも詳しく触れていますので、ここでは割愛させていただきます。

ここでは「複数サービスの乗り入れ」について解説いたします。

BtoCシステムにおいて複数サービスの乗り入れが一番魅力的です。例えば現在の自社サービスにサービス利用を加速化させる大手企業のサービスを乗り入れすることができれば、自社サービスのブランドが向上するだけではなく、サービスメニューの相乗効果により、自社サービスの利用頻度および利用者の確実な増加が容易に想像ができます。

この時、クライアント型SOAを使用しないで、サービスの乗り入れをしようと思えば、サーバ間接続という選択肢がありますが、これは大きな出費がかかりますし、システム上のリスクの観点から、交渉としてはハードルが高くなかなか実現しません。

例えば、読者の皆様が自社よりも格上の企業と提携をしようとした場合、自社が費用負担をするといっても提携先の大企業は手間やリスクを考えて、なかなか踏み出さない傾向があります。このようなことを経験された方も多いのではないでしょうか。

クライアント型SOAであれば接続先がWebシステム上でサービスを実現されているか、SOAPのインターフェースを公開していれば、接続先のサーバに手を加えることなくサービスの乗り入れができます。

当社もまさにこのような局面に直面し、自社ソリューションであるクライアント型SOAでさらに事業を拡大しようと画策しています。

詳細は近々報道発表いたしますが、当社の『一括！コマース「速販」』は大型の提携により順調に顧客を獲得しつつあります。しかしながら当社の経営戦略上、さらなる大きな利潤をあげる必要がありました。

 

現状と課題

図4のように、『一括！コマース「速販」』はECストア向けの受注管理・商品登録を一括で行うサービスです。
 

図4：『一括！コマース「速販」』について
（画像をクリックすると別ウィンドウに拡大図を表示します）

このビジネスを拡大するために、当社は簡単な調査を行いました。その結果、図5のような傾向があることがわかりました。
 

図5：ECストアの状況
（画像をクリックすると別ウィンドウに拡大図を表示します）

現在、国内で8.8万件を数えるECストアは一部大規模店舗が存在するも、ほとんどが小規模店舗になります（楽天、Yahoo! Japan、Biddersなどの決算報告書や有価証券報告書のデータから計算すれば、1店舗あたりの月商が平均で10万程度になります）。

よって、ほとんどのECストアが在庫を抱えてビジネスをすることが難しく、必然的に仕入元への発注は小口の発注になります。またECビジネスであるが故に、価格競争力を上げる必要があり、コスト圧縮が課題になります。小口の発注が多くなれば、仕入元への振り込み手数料が馬鹿にならなくなるため、多くのストアがコスト圧縮のため、仕入元が指定してくる銀行口座ごとに自社でも口座を持っています。

そこで『一括！コマース「速販」』に複数の銀行口座を一元的に管理できる「アカウントアグリゲーションサービス（注）」の乗り入れを検討しました。この乗り入れが実現できれば、『一括！コマース「速販」』で受注データ（入金データ）を管理し、これに支払いデータ（出金データ）をアカウントアグリゲーションサービスの乗り入れによって管理できれば、全体のキャッシュフローが計算できるようになります。
 

これは少人数かつ小資本で運営されているECストアにとって手間をかけずにキャッシュ状況を把握できるようになることを意味します。

この案を実現するためには各主要銀行との接続が必要になりました。

しかしながら主要銀行との接続を考えた場合、ベンチャー企業の域を脱していない当社にとって、各主要銀行との交渉によるサーバ接続は体力的にも、パワーバランス的にも非常に難しいことが予測され、サーバ間接続は断念せざるを得ない状況になってしまいました。そこで当社が選択したのが、クライアント型SOAの仕組みです。

現在、主要銀行のほとんどがネットバンキングを展開し、口座開設者に対してWebブラウザによるアクセスを許可しています。この仕組みを利用し、『一括！コマース「速販」』にWebブラウザの通信機能を搭載し、各主要銀行のネットバンキングとの接続を実現しました。


この方法では、既存のネットバンキングの仕組み（サーバ＋Webブラウザ）を流用するため、主要銀行側の負担や手間をなくし、当社側の負担だけで簡単に実現できます。これにより『一括！コマース「速販」』にアカウントアグリゲーションサービスを乗り入れるプランが一気に現実味を帯びることになります。

 

「クライアント型」であるがゆえのメリット

さらにこの仕組みは「クライアント型」であるがゆえの副産物も生み出しました。

従来のサーバ間接続でアカウントアグリゲーションサービスを採用した場合は図6の左図にあるような障壁にぶつかるはずだったのですが、それも「クライアント型」であるために上手く回避できたことです。
 

図6：クライアント型とサーバ型のアカウンアグリゲーションシステム
（画像をクリックすると別ウィンドウに拡大図を表示します）

図6の左図のようにサーバ間接続によりアカウントアグリゲーションサービスを採用した場合は、数千名規模の利用者が集中してアクセスした場合でも耐えうる大型のアグリゲートサーバが必要になります。

これは運営者側から見て大きなコスト負担になり、当社にとっては非現実的なことです。また利用者が所持している各主要銀行の口座番号やアクセスIDとパスワードなど、非常に機密性が高い個人情報を大量に保持・管理しなくてはならず、万が一の情報漏洩を考えれば、およそ選択することができないシステムになります。

さらに図6の左図の場合は、各主要銀行から利用者に対して貸与された口座番号やアクセスIDとパスワードを第三者（この場合は当社）に預ける形になり、そもそもこれは主要銀行の約款違反になるため選択できません。

その点、図6の右図のクライアント型の場合は、サーバ型で顕在化した大型サーバの構築が不要であり、運営料金のコスト負担や各主要銀行の口座番号、アクセスIDとパスワードなどの個人情報を利用者のクライアントで管理するため、個人情報の大量漏洩リスクがほぼ皆無になり、リスクヘッジの観点からも当社の負担を軽減することができました。