Hatena::ブログ(Diary)

放浪するエンジニアの覚え書き このページをアンテナに追加 RSSフィード

2009-09-03

「本屋さんも愛するプログラマ」が考える翌日配送システム

| 17:41 |  「本屋さんも愛するプログラマ」が考える翌日配送システム - 放浪するエンジニアの覚え書き のブックマークコメント

先週の東洋経済誌(2009/8/29号)はAmazonと出版業界の特集記事だった。

自分は、Amazonが日本進出する前からの超ヘビーユーザーなのであるが、最近は、殆どがCD購入(iPod Classicには20,000曲以上入っている&入りきらない)。洋楽やJazzは、とにかく安く&広く購入できるのでありがたい。

ただ、本屋さんに行くのが子供の頃から大好きで、活字中毒者でもある(「活字中毒者」という言葉は椎名誠氏の造語だと思うが、そうだろうか。。。)。

その本屋さんが少なくなっているという。

東洋経済誌から引用(P77)すると、

1996年までは書店数も増加したが、1996年をピークに書籍・雑誌の売り上げは減少に転じ、出版社・書店の倒産・廃業が相次ぐようになった。

特に厳しいのが、書店の経営で売上高の減少率は1995年から累計で40.5%にもなる。

08年の調査では、書店の平均経常利益率は0.57%にすぎない。

と書いてある。「本屋さん大好き人間」としては、とても悲しいことだ。

この辺りの事情は、出版業界特有の慣例も関係しているようで、「35ブックス」といった「責任販売制度」が導入されると書いてある。

本屋さんが、本を「借りて」棚に並べて、売れなかった本を返品するというのは知っていた(これを委託販売制度というらしい。これに反して、岩波書店は「買い切り」なので注文しないと本が来ない)が、その「返品」が業界を疲弊させてしまっているとのこと。

丸善社長の小城氏も「責任販売」を成功させなければならない、と言っている。

「責任販売制度」というのは、返品に対してペナルティーを課す制度。

仕入れたらそれを売り切りましょう、ということのようだ。

「35ブックス」では、書店の粗利を35%に増やす代わりに、返品時に35%で買い取る(=65%を書店が負担する)ということらしい。

たしかに、委託販売では、お店の「特色(色)」も出しにくいだろうし、モチベーションの高いお店にとっては公平ではない。

だが、0.57%しか経常利益がでないお店に、65%ものペナルティーを払うことができるのだろうか?と思った。そうすると、どんどん街の本屋さんがなくなって、大型店だけが残ってしまうような気がする。

こんなに前置きが長くなってしまったのは、街の本屋さんが好きな故。

これに対して、面白い記事が掲載されていた(p83)。

ネットユーザーにアンケートをとったところ、実際の本屋さんでしか本を買わない人が41.3%いて、ネット書店のみの利用者は1.6%しかいないとのこと。

ネット書店を利用する理由のトップは、「書店に在庫がない場合、書店に注文するより早く手に入れることができるから(61.4%)」だそうだ。

たしかに、本屋さんで本を注文すると、「他の店舗にあれば2-3日で届くが、ないと10日から2週間かかります」といわれてしまう。これは、多分、書籍の流通形態の課題だと思うが、このタイミングでお客さんが離れてしまっている、ということだ。

こう言われてしまったお客さんは、Amazonに行って本を買ってしまうので、同じ本を書店で買うことはない。

「35ブックス」だと、そう答えたタイミングで65%のペナルティーになってしまうのだ

それじゃあ、街の本屋さんはどんどん減ってしまう。

それなら、「本屋さんの互助会的な仕組みが作れないか」と思って、ない頭を絞って、浅はかなアイデアを書いてみた。

ポイントは、

  • 互助会的な仕組みを作って、65%のペナルティーを払わないようにする。
  • Amazonに対抗するために、翌日配送できるようにする。(Amazonには即日配送システムがあるが、別途課金されるし、即日配送できる地域と時間帯が限られている。)
  • お客さんのために、配送料を無料にする。

という点。

翌日配送の範囲は、運輸業者によって決まってしまうところだが、DNSのアナロジーで考える。

よく知られているように、DNSは「ゾーン」という考え方を使って、近所でアドレスが解決できなければ、その上位のサーバーに問合せるようにできている。

それを真似て、「在庫があれば、翌日配送できる範囲」を1つのゾーンとし、そこに本屋さんを所属させる

これをイメージにすると、以下のようになる。

f:id:tetsuya_odaka:20090901122456p:image


さて、これを具体的にどう使うかというと、以下の絵になる。

本屋さん(書店1)にいって、「xxxxxっていう本、置いていますか?」と聞かれたとする。このとき、自前のシステムとか、棚を調べて、あれば一件落着。なかったときにどうするかだ。

そのときは、書店1の所属するゾーンの台帳を見に行って、同じゾーンに在庫を持つお店(書店2)があれば、そこに電話して在庫の確認と、出荷の依頼をする。ゾーンはそもそも「翌日配送可能な範囲」となっているので、出荷意の依頼をする。書店2が本を出荷してくれれば、お客さんの元には、Amazonよりも早く翌日に本が届く。

もしなければ、その上のゾーンに問い合わせにいって、在庫のあるお店(書店3)に出荷をお願いする。この場合には、2-3日の配送期間となる。東京を中心に考えると、これくらいのリードタイムであれば、大抵のところには本を届けることができると思う。

なので、ゾーンは3段階くらいでいいように思う。

f:id:tetsuya_odaka:20090901153323j:image


さて、このときの「値決め」が問題。先に書いたように、欠品はお客さんに関係ないので、配送料は書店1,2が負担しなくてはならない。

例として、2000円の単行本としよう。

まず、オークションなどで利用される「クロネコメール便」を仮定すると、大抵の本は80円で送れる。

とすると、書店2は梱包をしてコンビニまで行き、80円を払ってお客さんに本を送る。

なので、粗利は2000円の35%=700円から80円を引いて620円となる。

だが、書店1からの紹介がなければ売れなかったかもしれない

この本を返品した場合、書店2は2000円の65%=1300円を負担しなくてはならない。

この辺りで、「期待損失」とか、「期待利益」とか確率の話が出てきそうだが、そういう話は不毛なので、「ああ、1300円を払わなくてよかった」と考える。

そして、

  • 配送量は、書店1(紹介者)が負担する。
  • 配送作業は、書店2(出荷者)が負担する。

と決めて、余りの620円を折半にして、書店1・2が310円ずつ受け取ることにする。

それじゃ、書店2が損なのじゃないか?という声が上がると思うが、このモデルのいいところは、

  • 立地のよいお店は紹介業を生業とすることもできる。立地的に不利なお店でも、紹介で本を売ることができるし、出荷にかかる手間(人件費)は埋没費用になっている(=配送をしてもしなくても負担しなくてはならない)。
  • 立地的には分が悪いが、安くて広い場所に、倉庫的な本屋さんが現れるかもしれない。
  • お店が、自らの特色(色)を出せば出すほどよい
  • お店の輪が、広がれば広がるだけよい

ということ。粗利は薄くなるが、本屋さんがつながることで、大型点より小回りの効くネットワークになる。

さて、これをどう作ろうかという話になるが、これにもいいところがある。

というのも、本を頼むお客さんは本の表紙とかは知ってる、ということ(現に、現物を見ずに、ありますか?と聞いている)。つまり、イメージのような大きなデータを保管する必要はない

このログで、Google App Engineを検証してきたが、その無料のストレージ(1GB)でも、テキストデータなら相当溜め込める。それに、お店IDとか書いているが、メンテナンスとかが面倒なので、

  • ISBN
  • 在庫数
  • 連絡先名
  • 電話番号

がいいかもしれない。マスタを作って正規化、なんていう定石はとらない(GAEでも推奨していないし)。

街の本屋さんはSOHOの一種でもあるし、草の根的に始めるのであれば、クラウドを利用するのがいいと思われる。

zoneに保管する、これらの「在庫データ」は以下の方針でメンテナンスする。

普通に設計すると、在庫数が肝なので、「リアルタイムでキッチリ管理されていなくてはならない」と思ってしまう

だが、このメンテナンスの手間とタイミングは微妙だろう。本屋さんだと、本に挟んである「しおり」みたいな物(あれはなんて呼ぶのだろう)で、「売り」の管理をしている可能性がある。そうであれば、閉店後に集計している可能性がある。推測するに、あの「しおり」は、卸に戻されそうだ。Amazonだと、あれが挟まったままくるので、特例的に電子化されていると(これも)推測。

ともあれ、本の入荷と出荷の「適当な」タイミングで、zoneをメンテナンスする。zoneには、更新のためのAPIを持たせる。

ここで、「適当」と書いたのは、このモデルでは、最終的な在庫確認を「電話」で行うことにしているから。人間を介すことができるのは、本屋さんという「物理的な店舗」での利用を想定しているからで、これによって、

  • 在庫数の更新が(現物と)非同期になった際のヘッジになる。
  • HTTPWebサービスという形式をとったとして、分散トランだとかの「難しい」処理(=開発にお金のかかる処理)が不要になる。

というメリットがある。クリック・アンド・モルタル

本屋さんの「棚卸」の際に、一括してzoneを更新するAPIは必要と思われる。最悪は、このタイミングでzoneの数を調整する。

f:id:tetsuya_odaka:20090901155152j:image

と書きなぐってきたが、花キューピッドのモデルに近いな、と思った。

花キューピッドは、花屋さんが生花を贈る仕組みで、(残念なのは)「現物そのものを贈れない」こと。

本は、ISBNで管理できるし、「物による違いが(新書であれば)ない」ので、このやり方でいい感じがする。

もし古本屋さんが来た場合、図書館を輪に入れる場合など、いろいろ考えられる。

古本屋さんの場合には、「現物の状態」があるので、Amazonのビジネスモデルが一番よいような気がする。と考えると、Amazonが新刊も含めて、取り込んでしまうと素晴らしい!!

そうだ、これを、EzoGPのインキュベータにしよう。