My Family, My Treasure, My Life

My Family,
My Treasure,
My Life

My Family

Best Shot Album

Since '02.08.03

Column Index

新しいSOAの実装方法「クライアント型SOA」のすすめ
2005/8/29-2006/5/31

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

プチSOAとは

   前回はクライアント型SOAの新しい適用分野として官公庁電子申請システムを例に解説しました。今回はBtoCビジネスを支えるサービス利用者のクライアントを対象にしたクライアント型SOAにフォーカスをあてていきます。事例をもとに、サービス企画者の方々を対象に解説していきます。

   さて本題に入る前に、気になるトピックがありましたので少し触れてみたいと思います。

   すでにご存知の方もいらっしゃるかと思いますが、2006年のキーワードとして「プチSOA」という言葉がメディアで取り上げられていました。その内容に書いてありましたが、言葉として定着してきた「SOA」は今年大きく変わりそうです。

   従来SOAは全社横断型のプロジェクトをベースに、ビジネスプロセスの再構築をうたってきました。このやり方はERPが日本で流行したときと同じような動きに見えましたし、当時ERPバブルで儲かったソリューションプロバイダの方々の「夢よ、もう一度」といった感じなのでしょうか。

   大規模ビジネスを展開しているソリューションプロバイダの方々はこぞって「これからはSOAです！」と昨年声高らかに解説されていました。

   方向性は間違っていないと思うのですが、全社横断型のプロジェクトでアーキテクチャを一新するためには、顧客側の体制だけではなく、ソリューションプロバイダ側にも、技術の標準化、クオリティの向上、コンサルティング、開発・サポートの技術者の確保など大掛かりな体制が必要になります。ここであえて説明はしませんが、機が熟するのにはもうしばらくかかりそうです。

   そこで、各社が打ち出そうとしているのが「プチSOA」です。

   SOAは全社横断型の大型プロジェクトでなくても、事業部単位や部門単位のシステムにおいて十分効果を発揮できる分野があることに気がつきはじめたからです。

図1：プチSOAの適用範囲

プチSOAの種類

プチSOAは大きく2種類に分かれます。「サーバ側で小規模のSOAを実現するスモールシステム（図2）」と「クライアント側で小規模なSOAを実現するスモールシステム（図3）」です。

図2：サーバ型プチSOA

図3：クライアント型プチSOA

上記の2つは、サーバ側に開発の手を入れるか、クライアント側に開発の手を入れるかの違いに見えますが、実は適用範囲は大きく変わってきます。

まずはサーバ型とクライアント型の違いを比較してきましょう。表1に、それぞれの得手不得手についてまとめてみました。

比較項目	サーバ型	クライアント型
社外サーバと接続したい	△	◎
データをクライアントに置きたくない	◎	○
サーバシステムを改変したくない	×	○
処理プロセスを再構築したい	◎	○

表1：サーバ型とクライアント型の比較

それでは表1の項目について上から順に解説していきます。

社外サーバと接続したい

   まず「社外サーバと接続したい」ですが、技術的には社外のサーバとの接続はサーバ型もクライアント型も実現は可能です。

   しかし現実問題として、他社のサーバとサーバtoサーバで直結することは担当者にとって勇気がいることであり、リスクヘッジの観点から進めるのがなかなか大変です。

   その点、クライアント型は接続先ですでにクライアントからのセキュアな接続環境が整っているケースが多いため、クライアント側で接続する抵抗が少なく、実現が意外に容易です。よって、サーバ型には△を、クライアント型には◎をつけています。

データをクライアントに置きたくない

続いて「データをクライアントに置きたくない」ですが、クライアント型でもシンクライアントのシステムを構築することはできます。

しかしコストの観点から既存のシステムをあまり生かさずに大改造が必要なシンクライアントによるSOA構築よりも、「サーバ＋Webブラウザ」のようなポータル的なシステムに軍配が上がるとの判断で、サーバ型には◎を、クライアント型には○をつけています。

サーバシステムを改変したくない

次に「サーバシステムを改変したくない」ですが、サーバを改変するサーバ型は当然×で、クライアント型には○をつけています。

処理プロセスを再構築したい

最後に「処理プロセスを再構築したい」ですが、これは両方とも実現可能です。しかしサーバ型のソリーション陣営のほうが、処理プロセスの再構築を支援できるソリューションが揃っていることから、サーバ型に◎を、クライアント型に○をつけています。

適用範囲

この4つの観点からそれぞれの適用範囲を考えてみると、表2のようになります。

サーバ型	1社内部でのSOA導入（業務プロセス改定が必要）
クライアント型	1社内部でのSOA導入（業務プロセス改定少ない）
クライアント型	BtoCシステムでのSOA導入（特に社外サーバとの接続がある場合）

表2：適用範囲

それではBtoCのシステムにおいて、何故クライアント型SOAが適切であるかについて説明していきます。

BtoCシステムにおけるクライアント型SOA

   「クライアント型SOA」という言葉は読者の皆様にとってまだ耳慣れない言葉だと思います。しかし業界の動向を見ていると、2006年は大手もこの分野に名乗りをあげることが予測され、2006年半ばには一般的な言葉になると思います。

   クライアント型SOAのシステム的な採用メリットはこれまでの連載で触れましたので、ここでは深く触れません。

   再確認するとすれば、「様々なメジャーサイトを見てください」です。メジャーサイトでは、連鎖的ビジネスを展開して他業種との相乗効果を狙ったビジネス展開をしています。

   この傾向が存在していること自体、BtoCのシステムにおいてSOAのニーズがあることの確固たる証明になります。

   また、現時点においてインターネット人口全体の中で本格的に使用している人がまだ少ないため、システム上の理由でWebポータル的なシステムが利用されつつあります。

   しかしながら利用者の頻度が向上し、より利便性を求めるようになった場合はやはりクライアント型SOAが最適な解になると考えています（詳しくは「第4回：クライアント型SOAによる官公庁電子申請システム」を参照ください）。

   それでは、実際のBtoCシステムにおけるクライアント型SOAの事例と今後の展開について解説していきます。

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

   当社の『一括！コマース「速販」』において、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とパスワードなどの個人情報を利用者のクライアントで管理するため、個人情報の大量漏洩リスクがほぼ皆無になり、リスクヘッジの観点からも当社の負担を軽減することができました。

クライアント型SOAによるビジネスの加速化

   以上のようにクライアント型SOAによって、アライアンス（提携）時におけるシステム面での障壁を軽減することができ、ビジネスの加速化が可能になりました。クライアント型SOAが存在していなければ、当社よりも格上の企業とのアライアンスは難航したでしょうし、仮に提携ができたとしても当社はリスクの面やコストの面、そして時間の面でも大きな負担を強いられたでしょう。

   ここで読者の皆様にあえて問いたいです。

   読者の皆様がビジネスモデルを設計する際に、システム面が大きな障害になっていることはありませんか。

   現在、ITはいたるところで採用され生活基盤として深く広く浸透しつつあります。このような環境でシステム面を無視してアライアンスを実現することはほとんどないと考えます。それゆえに、システムが障壁になっているように見えることも多いのではないでしょうか。

   システム連携においてサーバtoサーバの仕組みは、非常にしっかりとした連携を実現する手段の1つではありますが、すべてのシステム連携においてこの密連携を実現する必要はありません。今回のようなクライアントを介した疎結合での適切なケースもあるのです。当たり前ですが、大事なことは適所適材な判断によりシステムを構築することです。

   特に今回の事例で皆様に感じ取っていただきたいのは、クライアント型SOA（疎結合）により、サービス主体者は他社とのアライアンスを容易にするだけでなく、大型サーバの構築・運営コストおよび個人情報の管理リスクをも軽減するということです。

   日本企業の大部分がこの4月から来期のビジネスに突入します。おそらく今の時期は来期ビジネスプランの最終的な議論をされている時期ではないでしょうか。本連載を読まれる方は今一度、来期戦略上で今のプランよりも良い方法があるかどうか、再考していただきたいと思います。

   おそらく調査をすれば、クライアントの技術は数年前のクライアントサーバ型のテクノロジーよりもメンテナンスや生産性が格段に向上しており、読者の皆様のビジネスに耐え得るものとして存在していることに気がつかれると思います。

次回について

今回は「クライアント型SOAによるBtoCビジネス向けシステム」と題して解説してきましたが、クライアント型SOAの新しい適用分野をご理解いただけましたでしょうか。

次回はクライアント型SOAのプロジェクト運営面や開発面に触れていきます。是非、ご期待ください。

第1回	クライアント型SOAとは
第2回	クライアント型SOAの設計方法と開発方法
第3回	クライアント型SOAの実例
第4回	クライアント型SOAによる官公庁電子申請システム
第5回	クライアント型SOAによるBtoCビジネス向けのシステム
第6回	クライアント型SOAによるスモール&クイックスタート - 最適な投資とは
第7回	ストックビジネスを変えるクライアント型SOA
第8回	クライアント型SOAが実現するBtoBクライアント

このサイトはリンクフリーです。ご自由にどうぞ。