企業対消費者(B to C)のインターネット・オークションを運営するオンセールは,取引時の「安心感」を売りにする工夫をしている。2000年4月に開始する,消費者対消費者(C to C)のオークションでも,安心感を武器にアクセス数や会員数の増加を狙う。C to Cサービスは,半年という限られた工期ですべてのシステムを独自開発した。

 オンセールhttp://www.onsale.co.jp/)は99年6月から,インターネット・オークションのサイト「ONSALE」を運営している。オンセール自身やパートナ企業の商品をサイトに掲載してオークションで販売する,企業対消費者(B to C)のオンライン・ショッピング・サイトである。

インフラの信頼性が売り

 オンセールの一番のセールス・ポイントは,オンライン・ショッピングのインフラとしての信頼性である。オンライン・ショッピング・サービスに付きまとう不安に,クレジット・カード番号など個人情報の流出や,詐欺行為への懸念がある。オンセールは,価格を決定する“入札の場”だけを提供するのではなく,落札した商品をオンセールが直接販売する形態を採る。つまり落札された商品は,オンセールがパートナ企業から仕入れて落札者に販売している。

 オンセールへの出品は無料だが,落札価格の10~15%程度を手数料としてオンセールが徴収する。その残りがオンセールからパートナ企業に仕入れ代金として支払われる。出荷時にはオンセール自身が検品する。商品を出荷すると落札者に電子メールで通知するほか,物流パートナとの連携で商品の送達状況に対する問い合わせにもすぐに答えられる体制を構築している。

 決済方法はクレジット・カードのみに限定した。オンセールのオークションに参加するにはユーザー登録が必要で,このときにクレジット・カードの番号も登録する。「銀行振り込みなどに比べて処理を簡素化できる。カードの期限切れや与信限度を超過ということがたまにあるが,トラブルらしいトラブルはない」(オンセール eシステム部 部長 白戸 和美氏)という。

写真の掲載も一役

写真1 オンセールのトップ・ページ
オークション形式で商品を販売する,B to CのECサイトとして運用してきた。落札価格に少し上乗せした価格で在庫品を購入できる「クイックバイ」サービスなども提供している。
 オークションへの参加者を増やすため,商品情報を充実させることと,できるだけ商品の写真を掲載することも心がけている。「メーカーが用意した商品紹介のWebページにリンクを張っているだけのオンライン・ショッピング・サイトもあるが,なるべく独自の情報を掲載するようにした。似た製品の市場価格なども参考にできるようにしている。(新品を扱うような)B to Cのサービスでも,写真のあるなしでユーザーの反応が全く違う」(オンセール eマーケティング部 広報担当 長谷川 武恒氏)という。オークション終了後に,ほぼ同等の商品を落札価格に少し上乗せした価格で販売する「クイックバイ」と呼ぶサービスもある。

 品ぞろえを強化するため,出品するパートナ企業の開拓を図っている。その発展系といえるのが,アプリケーション・サービス・プロバイダ(ASP)サービスである。オンセールが他社のブランドでオークションを運営する。このサービスを利用したオークションは,オンセールのサイトと共通のユーザーIDで利用できるため,ユーザーからは品ぞろえが増えたように見える。ASPでオークションを運営する企業には,落札者の情報だけを開示する。99年10月には,中古車販売のガリバーインターナショナルが,オンセールのオークション・システムを利用してインターネット・オークション「ガリバーカースクエア」を開催している(現在は休止中)。

B to Cの仕組みをC to Cに

 「オンセールのサイトは,登録ユーザーの数が2000年3月現在で約1万6000人。このうち60%程度のユーザーが実際に入札を経験している。月間のページ・ビュー数は200万~250万。会員登録しなくても購読できるオークション情報配信のメール・サービスの登録者が約2万5000人」(長谷川氏)。オークション・サイトとしてはさほど大きな規模ではない。そこでユーザー数/アクセス数増加の起爆剤として,2000年4月下旬から消費者対消費者(C to C)の,フリーマーケット形式のオークション・サービスも開催することにした。

 C to Cのオークション・サービスは,このところ人気のサービスである。しかし,ヤフーが運営するYahoo!オークション(http://auctions.yahoo.co.jp/)が,2000年4月5日現在で入札可能な商品が約50万件と,断然トップのサイトとなりつつある。

図1 C to Cオークションの仲介サービス
(a)オークションのみを仲介するケースでは,落札後の商品の送付や送金は出品者と落札者が直接交渉する。(b)オンセールでは,従来のB to Cのサービスに準じて,入金を確認する,商品の送達を確認したあとに代金を支払うといったサービスも提供する。
 後発であることの不利を補うため,オンセールでは既存のB to Cのサービスで展開してきた販売管理のノウハウをC to Cのサービスにも生かすことにした。具体的には「取引に介入して,決済代行と物流の管理を行う」(白戸氏)サービスである。

 C to Cのオークション・サイトの多くは,出品してから落札するまでの「場」だけを提供している。落札後は,落札者と出品者が直接コンタクトを取って,商品や代金をやりとりする(図1[拡大表示]-a)。ところが,この落札後の手続きがトラブルのもとになることがある。ほとんどのサイトが落札後のトラブル防止のためにガイドラインを用意しているものの,虚偽の出品をして落札者に代金を振り込ませ,商品を送らず代金だけだまし取ってしまうという事件が起こっているのも事実である。

落札後の取引を仲介する

 オンセールでは,出品から落札までの図1-a形態のサービスを無料で提供し,これに加えて落札後の手続きの一部を代行するサービスを「安心取引機能」として有料で提供することにした(図1[拡大表示]-b)。安心取引機能を利用するかどうかは出品者が決める。料金は落札価格に応じて一定の割合を掛けた額になる予定だ。

 この代行サービスでは,まず落札者がオンセールに代金を送る。B to Cサービスと同様のクレジット・カードでの決済のほか,C to Cでは銀行振り込みでの送金も受け付ける。オンセールは入金を確認すると,落札者のあて名を印字した宅配便の伝票を出品者に送る。この伝票の到着で,出品者は落札者が入金済みであると確認できる。出品者は,この伝票を使って商品を発送する。オンセールはあらかじめ控えておいた伝票番号を使って荷物の送達を確認し,手数料を引いた残りの代金を出品者に送る。

 商品は出品者から落札者に直接送られるので,オンセールでは検品しない。しかし送金先,送金元がいずれもオンセールになるので,代金の支払いについてはB to Cサービスと同様の信頼性を提供できるとしている。この取引代行サービスで同じソフトバンク系列のYahoo!オークションなどと差別化を図っていく考えだ。

B to Cシステムは米国版を移植

図2 B to Cのシステム
オークションのシステムは米オンセール社のものをローカライズした。オークションの機能は,データベース・サーバーにストアド・プロシージャとして実装してある。バックエンドにある物流や販売管理を行う部分は日本のパートナ企業や商習慣にあわせるためにスクリプト・ベースで独自に開発した。
 オンセールのシステムは3つの部分で構成する。(1)ユーザー・インタフェースを生成するWebサーバーおよびアプリケーション・サーバー,(2)オークションのルールに従って落札候補者や入札価格のデータを更新するデータベース・サーバー,そして(3)落札後の商品を管理する決済/販売管理サーバーである。

 B to Cのシステムは米オンセールのシステムをローカライズして運用している(図2[拡大表示])。いずれもサーバーOSはWindows NTで,WebサーバーにはInternet Information Server(IIS)を用いている。同等の機能を持つWebサーバーを3台用意し,負荷分散装置でアクセスを振り分けている。3台のWebサーバーと2台のアプリケーション・サーバーにC++で開発したユーザー・インタフェース用のアプリケーションが分散している。

 データベース・サーバー上のデータベース管理システム(DBMS)はOracle8iで,2ノード・クラスタ構成で運用している。オークションのさまざまなルールは,このDBMSのストアド・プロシージャとして実行。ここが実際のオークションを機能させるための心臓部である。

 以上は米国のシステムからの移植だが,物流や販売管理部分は日本独自のものを使っている。物流を受け持つパートナ会社とのインタフェースや,日米での商習慣の違いがあったためだという。オークションのシステムとは別に,オークション開催情報などを配信するメール・サーバーがある。Exchange Serverを2ノードのクラスタ構成で運用している。

C to Cシステムは国内で開発

 一方,4月にサービスを開始するC to Cのシステムは,すべて国内で開発した(図3[拡大表示])。「今回のC to Cのサービス提供は,将来にわたって最大のシステム変更となる。このシステムを軸にさまざまなサービスを付加していくことを考えると,独自開発のほうが有利と考えた」(白戸氏)という。

図3 C to Cのシステム
すべて国内で独自に開発した。B to Cシステム以上のアクセスを見込めるため,NTベースではなくSolarisベースで開発した。「Solarisサーバー1台でNTサーバー5台程度の能力と見ている」(オンセールの白戸氏)という。物流/販売管理サーバーはB to Cのシステムと共有する。
 たとえば,C to Cサービスでは,コンテンツのパーソナライズを行う。自分の入札履歴や,出品した商品への入札状況を確かめたり,落札者と出品者とが互いに相手を評価し合ったりして信頼度の目安とする機能を用意する。さらに,あらかじめ登録しておいた商品がオークションに出品されると自動で通知する逆検索機能なども組み込んでいる。将来は既存のB to Cのコンテンツまで横断的に検索するなどの統合も図る計画だ。

 「アクセスはB to Cのシステムと比較にならないほど多くなると見ている」(白戸氏)というように,より高い負荷がかかることを想定している。B to CのシステムではNTサーバー3台をWebサーバーにあてていたが,C to CのシステムではSolarisベースのNetscape Enterprise Server2台をあてる。「ハードウエアの能力の違いを加味すると,Solarisサーバー1台でNTサーバー5台程度のアクセスを処理できると考えている」(白戸氏)という。

 ユーザー・インタフェース部分のアプリケーションはB to Cシステムのようなネイティブ・アプリケーションではなく,米アレイア社のWebアプリケーション・サーバーであるColdFusionを用いて開発した。「C to Cサービスを提供することに決まったのが99年11月。ビジネスの面からも開発コストの面からも,サービス開始までに半年以上の時間はかけられなかった。開発を依頼したSIベンダーにColdFusionアプリケーションの経験があったこともあり,工期の短縮とシステム稼働後の保守性などを考えて採用した」(白戸氏)という。

 DBMSはB to Cシステムと同じOracle8iだが,オークションのルールを実行するアプリケーションは新しく作り直した。物流/販売管理サーバーは,B to Cシステムとの共用で,ここにもColdFusionを入れて,C to C用のアプリケーションを動かす。開発期間は約2カ月半。さらに1カ月のテスト期間を設け,サービス提供の決定から半年でのサービス開始にこぎつけることができた。

(斉藤 国博=kuni@nikkeibp.co.jp)