PR

図1●古書取引システムの概要
これまで手作業で実施していた古書交換会における清算処理をシステム化した。清算情報を一元管理するサーバーをJava Servletで開発したほか,Windows 2000 Professionalを搭載したパソコンに周辺機器を接続してレジ用PCを自作した
図2●将来的にはシステムを組合員にも開放へ
詳細な時期は未定だが,2004年中にシステムを組合員にも開放する。インターネットを介して落札情報や清算情報の照会,書籍情報の事前登録などをできるようにする。既にデータセンターにサーバーを設置してあり,古書会館にあるシステムとはWebサービスでデータを連携させる予定である

 東京都古書籍商業協同組合は2003年9月末,交換会で取引した古書を清算するシステム「古書取引システム」をカットオーバーした。コストを抑えるためにオープンソース・ソフトを積極的に採用したほか,現金の清算レジをパソコンで自作した。ハードウエアを除いたシステム開発費用は約3000万円。アプリケーションを開発した後に仕様変更などが発生して稼働時期が約3カ月遅れるトラブルもあった。

Accessの独学からスタート

 同組合では1週間に6回,古書を取引する交換会を開催している。交換会では,出品→入札→開札→落札→清算というプロセスで古書をやり取りする。これまでは,落札部分のみをシステム化していた。同組合の飯野基氏がMicrosoft Accessを独学し,3カ月かけて構築したものだ。

 しかし,使っていくうちに印刷などの部分でさまざまな要望が出てきて,「カスタマイズに限界が出てきた」(同氏)。さらに,年に1回開かれる「大市」と呼ぶ特別な交換会でシステムの利用者が増えると,動作が不安定になってレスポンスが悪くなる問題も発覚した。「パソコンの性能が問題ではなく,作り方が悪いと総務部長に突っ込まれた」(同氏)。

 独学では限界があるため,システム・インテグレータのスリー・エー・システムズに依頼して解決することにした。DBの部分をMSDE(Microsoft Data Engine)に変更してパフォーマンスを向上させたほか,印刷部分も要望に合わせてカスタマイズした。すると今度は「落札部分をデジタル化できたのであれば,清算部分もデジタル化して作業を簡易化させようということになった」(飯野氏)。

レジをパソコンで自作

 それまで清算の処理はすべて手作業で実施していた。落札した結果をAccessで入力し,伝票を出力してレジで一人ひとり清算していた。交換会には1日200人前後の組合員が来場する。来場者全員が清算するわけではないが,紙の伝票を持ってきてレジに手で入力するため,時間がかかるだけでなく,入力ミスも発生する。清算の処理を効率化すると同時に,履歴をシステムで管理できるようにしたかった。

 2003年4月から開発を開始し,問題となったのが清算レジ。市販のレジは完成された形になっていてカスタマイズが難しかった。例えばレジでは商品マスターの登録が必要になるが,古書の取引では商品マスターが日々変わる。書籍のタイトルが膨大にあるほか,タイトルが同じでも別商品になり単価が異なる。「POSレジやLinux内蔵のレジなどをいろいろ検討したが,結局無理だった」(スリー・エー・システムズ システム開発本部 流通システム開発部 リーダー 山谷勝美氏)。

 そのため,レジをパソコンで自作することにした。Windows 2000 Professionalを搭載したパソコンに,レシートの出力装置とキャッシュ・ドローワを接続して使う。レジ用のアプリケーションはVisual C#で開発し,タッチパネルで操作できるようにした。

 レジとは別に清算情報を管理するサーバーも構築した。清算サーバーの構築には,コストを抑えるためにオープンソース・ソフトを全面的に採用した。OSはTurbolinux 8 Server,DBはPostgreSQLを利用する。アプリケーションは,オープンソースのフレームワークStrutsを使ってJavaで開発したが,当時はStrutsに関する情報が少なくて苦労した。最終的に開発した画面数は約90になった。

 清算サーバーと清算用レジの処理は以下のようになる(図1[拡大表示])。古書が落札されると,職員は従来からあるAccessアプリケーションを利用して交換会サーバーに落札情報を登録する。登録が終わったら,清算サーバーのWebアプリケーションを利用してMSDEから清算サーバーのPostgreSQLに落札情報を取り込む。清算する際は,清算用レジから清算サーバーのPostgreSQLにアクセスして落札情報を確認,清算結果を登録する。

仕様変更で稼働を3カ月延期

 開発は順調に進んだが,開発後に仕様の抜けや変更などが発生してカットオーバー時期を延期するトラブルが起きた。当初は2003年7月の稼働を予定していたが,途中で大市の仕様が抜けていることが発覚した。通常の交換会では落札した古書の支払い期限が決まっていないが,大市では決められている。「通常の交換会と大市で処理を分けないといけないし,帳票も変える必要があった」(飯野氏)。

 さらに,画面まわりや使い勝手などで要望が増えたほか,「実際のシステムの運用に当たって移行作業に時間がかかった。9月中旬から下旬にかけて大市があったために作業に影響した」(スリー・エー・システムズ システム開発本部 営業企画部 マネージャー 釜我徹也氏)。これらの要因が加わり,最終的に2003年9月末まで稼働時期を約3カ月延期した。

ゴールはまだまだ先

 今回のシステム化で清算の処理を効率化できたほか,Webブラウザを利用して取引履歴を簡単に確認できるようになった。しかし,最終的なゴールはまだまだ先にある。将来的には,出品や入札,開札までも含め,「古書の取引そのものを電子化して効率化する」(理事 総務部長 河野高孝氏)のが目標である。

 例えば落札情報はデジタル化してあるが,その登録作業は大変だ。「落札の伝票は多いときで1日千枚を超え,少ないときでも何百枚は出る。その日のうちに3~5人で入力している」(河野氏)。そのため,2004年中にシステムを組合員にも開放し,インターネットを介して書籍の情報を事前登録できるようにする予定である(図2[拡大表示])。事前に登録してもらえれば,入力の手間を省ける。

 同時に落札情報や清算情報の照会などもできるようにして組合員の利便性も高める。サーバーはすでにデータセンターに設置してあり,現在はデータのバックアップ・サーバーとして利用している。今後WebアプリケーションをWebサービスとして開発し,同組合に設置してある交換会サーバーや清算サーバーともデータを連携できるようにする。

(榊原 康=sakakiba@nikkeibp.co.jp)