ニッセンは2000年1月，顧客がインターネットからカタログ商品を注文，在庫照会できる「通販インターネット受注システム」を稼働開始した。既存の基幹システムを生かすことで，わずか1.5カ月で開発。プラットフォーム非依存を重視し，全面的にJavaを採用した。2000年5月には，使い勝手の向上と新規顧客獲得のためにGUIを刷新するとともに，障害対策を強化して24時間連続でサービスを提供可能なシステムとした。

写真1●ニッセンの構築した通販インターネット受注システム
　カタログを使った衣料品や生活用品の通信販売を手がけるニッセンは2000年1月，商品受注用のWWW（World-Wide Web）システムを刷新し，稼働開始した（写真1[拡大表示]）。新システムでは，既存の基幹システムと連携し，リアルタイムで受注処理および在庫確認ができるようにした。「ただの注文の手段では面白くない。WWWでしかできないことにチャレンジしたかった」（通販事業部 マーケティング本部 インターネット事業推進部 執行役員部長 市場信行氏，写真2[拡大表示]）。稼働開始以降も大きな改良を加え，過剰在庫の商品を低価格で販売するなど，リアルタイム性を生かしたコンテンツを展開している。

　今回のシステム構築は1999年11月に開始し，約1カ月半の短期間で成し遂げた（図1[拡大表示]）。同社は12月が決算月であり，かつ年明けに春物の新しいカタログが発行になる。そのタイミングに合わせて，インターネットのサービスも開始したかった。短期で開発できた最大の理由は，既存の基幹システムをほぼそのまま利用できるようにしたこと。さらに，JSP（JavaServer Pages）やEJB（Enterprise JavaBeans）を使って開発生産性を高めたことも大きい。

写真2●通販事業部 マーケティング本部 インターネット事業推進部 執行役員部長の市場信行氏
　課題は，レスポンスと信頼性だった。アプリケーションの開発は，レスポンスを重視してJavaサーブレットを利用した。Javaアプレットも検討したが，1秒以内のレスポンス要件に耐えられなかった。システムの信頼性を確保するためには，マシンを冗長構成にした上で，監視用のプログラムを用意。さらに，通常時用と障害時用と2つの受注プログラムを作るなど障害対策を強化している。

　稼働開始して数カ月で，使い勝手における課題も見えてきた。ログインの手間がサービス利用へのハードルになることなどである。そのため，5月には操作画面に大幅な変更を加えた。

リアルタイム性追求で基幹へ直結

　同社は，95年12月からWWWサーバーを導入し，顧客がWWWブラウザから商品を注文するサービスを提供していた。

　旧システムは，米MicrosoftのWWWサーバーIIS（Internet Information Server）を用いASP（Active Server Pages）でプログラムを作成したものだった。入力された発注データから，決まったフォーマットで発注明細ファイルを作成し，グループウエア「Exchange Server」の機能を利用して特定のパブリック・フォルダへ格納する。フォルダにたまった発注データは担当のオペレータを介して基幹システム「Wings」へ入力する方法を取っていた。

写真3●通販事業部 管理本部 情報システム部 方式設計課 課長 大丸洋一氏
　このWWWシステムは，実際に発注がかかるまでにタイム・ラグが生じる。結果的に，商品の配達も遅くなってしまう。この課題を改善し，さらに顧客の利便性を考えてリアルタイムで在庫の照会をできるようにするため，99年10月ごろ，WWWシステムとWingsを連携する構想が持ち上がった。

　Wingsは元々，コール・センターで受けた注文を入力するシステムで利用していた。オペレータが電話で受け付け，Visual Basic（VB）で開発した専用クライアントからWingsに入力する形である。

　Wingsは，C言語で開発したプログラムで，米BEA SystemsのTPモニター「BEA TUXEDO」を使って動作している。業務ロジックを乗せたアプリケーション・サーバーとデータベース・サーバー（DBサーバー）が，それぞれ別のUNIXマシンで稼働している。クライアント側のVBアプリケーションには表示以外のロジックは入っていない，3階層のシステム構成を取っている。

　このWingsのアプリケーションをそのまま利用することを前提に開発に取り掛かった。既にWWWサーバーを立てており，フロント部分もできているため，Wingsとのつなぎの部分に開発を集約すればよかった。「“おぜん立てはできているんだから1カ月で開発しろ”と厳しい要求を突きつけられた」（通販事業部 管理本部 情報システム部 方式設計課 課長 大丸洋一氏，写真3[拡大表示]）

ASPを捨て，Javaで開発

図1●システム構築のポイント
　市場氏が短期開発を課した背景には，「インターネットのEC（エレクトロニック・コマース）システムでは，少々時間がかかって3カ月，遅くとも6カ月で立ち上げなければいけない」（同氏）という考えもあった。Wingsという既存のシステムに手を入れずに使う方針にしたこともあり，開発期間は約1カ月と設定した。短期開発が望まれるインターネットECシステムとはいえ厳しい条件である。まずは，製品や技術を選択し，システム構成を決めるのに1週間強を費やした。

　プラットフォームや開発ツールの選択では，拡張性と生産性を重視した（図2[拡大表示]）。ECでは，ユーザー数の増加に応じてサーバー機を追加し，システムを増強する可能性が高い。コストを抑えるために，プラットフォームは以前のWWWシステムで採用したWindows NTにすることを条件に掲げていた。

図2●ニッセンが選択した製品および技術とシステムの仕組み
ニッセンは，短期開発を念頭にシステム構成や製品を選択。既存の基幹システムをそのまま活用できるミドルウエア「Jolt」とWebアプリケーション・サーバー「WebLogic」の組み合わせを採用。また，生産性を重視した結果，できる限りEJBで部品化することで再利用性を高めている
　一方では，旧WWWシステムのプログラムにはASPを採用していたが，単一の製品や仕様への依存性が高くなることを懸念し，新システムではJavaの採用に踏み切った。Javaはプラットフォーム非依存の技術であり，今後顧客のニーズに応じてシステムを変更する必要が生じた時に，移植や拡張がしやすいといったメリットがある，との判断からである。

　Wingsのアプリケーションをそのまま使うという前提により，TUXEDOにアドインして利用する「BEA Jolt」の採用が決まった。JavaのAPI（Application Programming Interface）などを利用してTUXEDO上のアプリケーションを利用可能にするミドルウエアである。APサーバーには，Joltとのインタフェースを標準で備える「BEA WebLogic Server」を採用した。

レスポンスと短期開発を重視

　システム構成を考え始めたころは，購入金額を合計する計算のロジックなど，Javaアプレットをクライアント側で動作させる方法も考えた。だが，掲げていたレスポンスの要件は，“一つのユーザー操作に対して1秒以内で結果を返すこと”であった。アプリケーションはすべてサーバー側で動作するJavaサーブレットで実装する方法を取った。

　限られた期間で効率良く開発するために，画面表示を担うHTMLの部分にJSPを使って業務ロジックを切り離して開発したり，共通な機能は再利用できるようにEJBで部品化したりと，新技術を積極的に取り入れた。ただ，約1カ月という開発期間では，「何をEJBにするか，EJBはどうやって使うのか，をじっくり考える時間がなかった」（大丸氏）ため，部品化は思ったより進まなかった，という課題は残した。

APサーバーの機能で二重化

図3●システムの信頼性を確保するための工夫
基幹システムが止まった場合の代替策を用意したり，システムの冗長化，監視体制を強化したりと顧客に常時サービスを提供するための工夫を施した
　“手厚いカスタマ・サービス”を売りにする同社にとって，24時間常時注文を受け付けられるように立ち上げたシステムが，サーバー・ダウンを起こすことは許されない。システムの信頼性確保には細心の注意を払い，様々な対策を施した（図3[拡大表示]）。

　2000年1月に稼働開始し，通販インターネット受注システムの利用者も増えてサーバーの負荷も高まったことから，5月からはシステムをすべて冗長化構成にした。WWWサーバーは2台用意し，米Cisco Systemsの負荷分散装置「LocalDirector」を使って，顧客からのリクエストを振り分けている。また，APサーバー「WebLogic Server」も2台にして，製品の備えているクラスタリング機能を使い，1台に障害が発生した時にはもう1台が処理を引き継ぐような構成にした。実際に一度，1台のサーバーがダウンしたが，もう1台のサーバーに処理を引き継いで，システム・ダウンを逃れたこともある。

受注の代替ルートを用意

　信頼性を高めるための対策は，二重化だけではない。Wingsが停止している間も，顧客からの注文を受け付けられるように，代替プログラムを追加した。まず，Wingsが正常に動作している場合は，顧客からの注文を受けると APサーバー上で，Wingsに連携するためのJoltを呼び出すプログラムが動作する形になっている。

　もし，何らかの理由でWingsからの応答が返ってこない時には，別のプログラムを呼び出す。このプログラムでは，発注データから明細ファイルを生成してExchangeのフォルダにためておき，Wings再稼働後に，担当者に入力を依頼するという代替ルートをたどるように切り替わる。リアルタイムでの在庫照会や納期確認はできないが，顧客は24時間いつでも注文できる仕組みである。

写真4●ニッセンの通販カタログ
　システムに障害が起きた場合に，迅速に対応できるように監視体制も敷いている。監視用の端末を別に用意して，WWWサーバー，APサーバー，DBサーバーとすべてのサーバーに対してpingコマンド（マシンからレスポンスが返るかどうかを調べるコマンド）を発行して稼働を確認したり，APサーバーの管理用コマンドを使ってサービスの状態を確認したりするバッチ・プログラムを作成した。障害を検知した場合は，直ちに管理者へ障害内容を記したメールを送信するようになっている。

WWWの即時性を生かす

　2000年1月に立ち上げた当初は，同社の既存会員向けのシステムという位置付けだった。“カタログ冊子を見て商品を選ぶ”といった手順は従来と変わらず，電話やハガキと並ぶ注文手段の一つとしての役割が大きかった。リアルタイムに商品在庫を確認できるというメリットはあったものの，注文方法はカタログで調べた商品番号をWWWブラウザのフィールドに入力する形であった。

　しかし2月には，WWWサイト上でも商品情報を掲載し，注文できるサービスを導入した。海外一流ブランド品の衣類，バッグやアクセサリを扱う「仮想免税店」や，先シーズンで売り切れなかったり，予測を誤ったりした余剰在庫商品を割安価格で販売する「激安アウトレットモール」といった，インターネット独自の販売サービスやコンテンツを追加した。カタログと同じようなページはサイト上にはほとんどない（写真4[拡大表示]）。

　余剰在庫商品は数が限定されており，在庫を豊富に用意した正規のカタログ掲載商品と異なる特性がある。仮にカタログに掲載した場合，その数が少ないと買い損じてしまう顧客が出てくる。カタログに載っているのに商品が買えないのでは，顧客満足度を下げることになる。インターネットを使ったWWWシステムであれば売り切れ次第，その状況をリアルタイムで知らせることが可能だ。カタログでは売りにくい余剰在庫商品を効率良くさばくことができる。

GUIの設計で顧客層を広げる

　新システム稼働後に新たな課題も上がってきた。元々会員向けに始めたサービスであった名残から，最初にログインをする形を取っていた。また，追加したサービスごとにログインする必要がある上，各サービスで取り扱う商品に関してはそれぞれのサービスでログイン中に支払い処理を済ませるようになっていた。顧客が複数のサービスで別々に提供している商品を購入する場合には，ログインや支払い処理を何度も繰り返さなければならない。

図4●顧客が利用しやすいように設計した操作画面
従来のシステムでは，販売サービスごとにログインしたり，支払い処理をする必要があった。顧客の利便性を考慮し，ログイン回数を減らすなどだれでも利用しやすいような画面遷移に変更した
　手間がかかるだけでなく，これでは，会員以外の顧客を取り込むことは難しい。そこで5月に，各サービスごとにログインする仕組みを廃止，操作画面を一新した（図4[拡大表示]）。トップ・ページのメニューから各サービスを選択すれば，すぐに商品紹介のページに移って購入可能になった。ログイン時に要求していた会員番号やパスワードは，商品選択後の支払いという最後の処理時に入力するようにした。

　「ドアを開けておくだけ」（市場氏）にして，できるだけ顧客層を広げるように敷居を下げた。支払いは，各サービスを渡り歩いて選んだ商品を一時的に一つのショッピング・カートに保管し，最後に一括して処理できるように改善した。サービスのコンテンツとショッピング・カートは別々のフレームで区切られている。これにより，以前は商品の在庫や納期を，支払い処理の画面にいかないと確認できなかったが，現在はショッピング・カートのフレーム内にそれらの情報が表示されるので，商品選択時点で瞬時に分かるようになった。

　顧客の操作には，WWWブラウザ特有の問題への対処をするなど気を使った。注文をする時にSubmitボタンをダブル・クリックして二重に注文データが送信されないように，Submitボタンを押した時には，押下回数を数える関数を呼び出して2回目以降はデータ送信を無効にするなど工夫した。

　顧客の誘導策として同サイトで提供しているメール配信サービスへの登録時も，顧客の個人情報は一切入力せずにメール・アドレスのみ入力するようにしている。顧客を囲い込むためにむやみに情報を取るのではなく，サービスを利用するために必要最小限の情報だけ入力してもらう，という考えだ。「単純に顧客属性だけを取っても意味がない，実際に何を買ったかという動きが大事」（市場氏）

　今後は，注文履歴だけでなく，顧客がどんな商品に興味を示したかを分析するために，クリックごとのログを収集する予定。「現状は，満足できる専用ツールが存在しないため，当面は独自開発で進めていく」（大丸氏）。

（相馬 隆宏=souma@nikkeibp.co.jp）

システム概要

図A●システムの構成
　ニッセンの通販インターネット受注システムは，顧客登録，受発注，出荷，在庫管理，入金など10個のサブ・システムで構成する基幹システム「Wings」をベースにしたもの。Wingsは，米Hewlett-PackardのUNIX機「HP 9000 K570」上に構築した「TUXEDO」のアプリケーションと「HP 9000 V2500」上のリレーショナル・データベース管理システム（RDBMS）「Oracle」で構成する。従来から，コール・センターのオペレータがVisual Basicで開発したGUIを使ってWingsを利用している。

　新たに，TUXEDOとの連携機能を備える米BEA Systemsのミドルウエア「BEA Jolt」，Webアプリケーション・サーバー（APサーバー）の「BEA WebLogic Server」を導入して，WWWブラウザからWingsのデータをリアルタイムで更新および参照可能にした。JavaサーブレットとEJB（Enterprise JavaBeans）で開発したアプリケーションがJoltを介してWingsアプリケーションと連携する。

　フロントエンドは，WWWブラウザからリクエストを発行するとJavaサーブレットを介して，EJBがデータベースを検索する仕組み。検索結果から，JSP（JavaServer Pages）がHTMLのページを生成する。データベースには，米MicrosoftのRDBMS「SQL Server」を使用し，WWWサイトのコンテンツを構成する商品情報や画像などを管理する。WWWサーバー，APサーバーはそれぞれ2台ずつ用意し，冗長化している。米Cisco Systemsの負荷分散装置「LocalDirector」を使ってWWWブラウザからのリクエストを振り分ける。APサーバーの二重化にはクラスタリング機能を使った。

　WWWサーバーは，日本ベリサインが発行するサーバー用の電子証明書を取得しており，WWWブラウザとの間のデータのやり取りをSSL（Secure Sockets Layer）で暗号化してセキュリティを強化した。