出版不況と言われて久しい昨今ですが、読書自体はそこまで廃れていないようです。
こちらはビジネスパーソンが朝にどのようなことをしているかのアンケートの結果に関する記事。
読書が４位に来ています。
もっと下だろうと思っていただけに、これは嬉しい数字です。
電子化が進んでいる現在でも、体系だった知識やあるていど深い知識がほしい場合はまだまだインターネットよりも書籍のほうが優れていることが多いもの。
そういったメリットがこの数字につながったのではないかと思います。
‘調査メモ’ カテゴリーのアーカイブ
読書はまだまだ廃れていない
2009 年 6 月 18 日 木曜日本を読んだだけでは身につかないわけ
2009 年 6 月 7 日 日曜日私は月に数冊は本を読みます。
とくに実用書、ビジネス書の類を読むことが多いのですが、そんな中で、どうにも困っていることがありました。
それは、理解できたつもりのことが、いざ実行しようとするとうまくやれないということ。
「わかっているはずのことが、いったいなぜできないのか？」
いかにも不思議なことです。わかっているならできなくてはおかしいはずです。
なのになぜできないのか。
その疑問への答えが昨日わかりました。そのものズバリの回答がこの書籍に乗ってあったのです。
この書籍によると、私たちは本を読んで情報をインプットするだけでは実用的な能力として使えないのだそうです。
人間の脳は、ある情報をアウトプットして初めてその情報を整理して自分のものと出来るように作られているのだとか。
アウトプットが大事、とはよく聞きますが、それはあくまで「情報を公開することで新たな情報を引き寄せる」といったたぐいのノウハウだと思っていました。
しかし、学習のためにも、アウトプットは必要なものだったようです。
いや、目からうろこでした。
コスト削減とはケチケチ運動か
2009 年 5 月 11 日 月曜日前々から疑問に思っていました。
それは、ケチケチ運動はコスト削減に本当につながるのかということです。
コスト削減をうたい、ケチケチ運動を進めるのは私もよく見たことがあります。
たとえば紙代の節約のためチラシの裏をメモ用紙に使うようなものです。
ですが、よく観察していると、そのチラシをメモ用紙にするために社員が１０分から２０分くらいかけてせっせと作業していたりするのです。
社員の給料はどう考えても１０００円を超えるのですから、仮に１０分で終わっても六分の一で160円です。メモ用紙など100円もあれば余裕で買えます。
なんのことはない、ケチるためのコストで削減できたコストを優に越えてしまっているのです。
――ケチるための手間暇が結局コストになって、ケチったことによるコストダウンは効果が薄いか下手をすると逆効果になっている。ケチケチ運動をもってコスト削減するのは難しいのでは――？
それがずっと疑問だったのです。
よほど浪費しているような場合は別として、ケチケチ運動はしょせん見世物としての性格が強いような気がします。あるいは虚構の達成感を得るためかもしれません。なんにせよ、手間暇かけて今のコストを別のコストに振り替えて問題を見えにくくしているだけではないのでしょうか。
一社員として芝居に参加するのはいいとしても、店を回す立場の人間がケチケチ運動を進めてコスト削減をやったつもりになっていてはいけないと思うのです。
なのでケチケチ運動を私は嫌っていて、これまでやらずにいたのですが、これはコストダウンを怠っていることになるのであろうか、と少し悩んでいました。
今日、たまたま読んだ本で、悩みが解けました。
「コスト削減とはケチケチ運動ではない。大きなコストダウンはケチケチ運動などで達成されるものではない」
『無在庫販売のすすめ方』より
「そうですよね！」
と我が意を得た気持ちでした。
これまでの方針は間違っていなかったと安どするとともに、今後もこれまでどおりにやっていこうと意を強めました。
思いて学ばざればすなわち則ち殆うし。
先達の教示はありがたいものです。
マーケットプレイスにおける他の出品者の梱包方法についての考察
2009 年 4 月 8 日 水曜日今日マーケットプレイスで昔頼んでいた書籍を一気に開けたのですが、いろいろ梱包方法に違いがあって面白かったのでメモします。
古本市場
緑色の印刷済みエアーキャップ封筒を利用。そのため書籍自体は封筒に直で入れられていました。
このタイプは梱包材のコストが高いという難点があるものの、梱包の手間は省けるので人件費を抑えるのに向いています。古本市場ともなると一日に扱う量も大量になりますから、人件費削減のほうを優先したということなのでしょう。
それから宛名はバーコード付きのシールを利用していました。バーコードは二つで、上部にあるものが郵便番号、下部にあるものが受付番号（注文番号？）です。
面白いのは、封筒にはあくまで古本市場のロゴだけを印刷しており、差出人・変換先はシールに印刷していたこと（このため、シールは宛名印刷用としては広めのものを利用していた）。これはおそらく、差出人を封筒に印刷すると住所が変わったときに使えなくなるのを嫌ったのであろうと思われます。
そんな対策をとる点から逆算して、この特注の封筒はコスト削減のため一度に相当量を発注しているものと思われます（１万くらいでしょうか？）。
それから、料金後納郵便によるゆうメールにて発送されていました。古本市場ともなればおそらく特別運賃(2)になっているでしょうから、送るときの送料はかなり安く済ませられているでしょう。メール便を使わないのは、おそらくエアキャップ封筒は嵩張ることから使えないのだと思われます。ただ、トラブルがあったときに発送証明ができきない点が問題になる気がしますが、個別に追跡できるような領収証を取っているのでしょうか。
最後に、封は糊づけしていました。おそらくこれも封筒にもとからついている糊です。
ブックマート
普通の茶封筒を利用。社名印刷などは宛名に記載していました。
宛名はシールではなくて普通のコピー用紙を裁断したものをOPPテープでとめていたのが、人手が余り気味でかつ経費削減を求められているのかな、と思わせるものがあってすこし悲しい感じでした。
中の品物は普通のビニール袋で梱包されていました。OPP袋ではないのがちょっとびっくりです。普通のビニール袋はもろくないでしょうか。
ただ、シーラーを使って止めていたのは興味深かったです。シーラーはうまく使わないと破れたり空気がたまったりして取扱いが難しいのですが、割合とうまくできていました。
尚、発送はメール便でした。
ブックスはた
珍しい黒い樹脂系の袋を利用。品物はOPP袋でギチギチにくるんだ上に厚紙でカバーして送られていており、「これでもか」と言わんばかりの梱包がなされていました。（おかげで開けづらかったのは秘密です）もしかして梱包についてなにかしらのクレームをもらった結果でしょうか。黒い樹脂系の袋を使っているのも、水ぬれ対策である可能性があります。
また、宛名も表と裏にそれぞれ宛先と送り元を別々に印刷したコピー用紙を切ったものをOPPテープではりつけていました。
おそらく今回もっとも梱包に手間暇をかけていた出品者でしょう。
これは人件費や梱包コストでけっこうつらいんじゃないか、とおせっかいながら考えてしまいました。
ただ、黒い封筒というのはインパクトがけっこうあって、ポストに入っているのを見たとき何事かとびっくりしました。そんな大げさなと思うかもしれませんが、まあ、ポストを開けたら謎の黒い物体が入れられていたと想像してみてください。初めての経験だとけっこうギョッとすると思います。
また、ガムテープで留めているものだから全体的にやや見栄えが悪くなっていました。梱包に力を入れているのにそういう印象であるのは、どこかちぐはぐな気もします。そこまでコストをかけられるなら、封筒はライトカラーのものを選択し、封も普通のガムテープではなく透明のOPPテープを使ったほうが見栄えが良い気がするのですが、だめなのでしょうか。
ちなみにメール便でした。
古物商あだち
今回もっともふつうの梱包であった出品者。普通の茶封筒に切り取ったコピー用紙をOPPテープで貼り、ビニール袋（ここはちょっとチャチではある）で包んだ本を入れて発送していました。ここもメール便です。
最後に感想
どの店も考え方がよく出ており実に興味深いものがありました。どれも大変参考になりました。
中でも今回のマイベストは古本市場です。梱包の手間をもっとも削減できるのはこの店のやりかたでしょう。
印刷済み封筒を使うことによってブランドイメージの向上も図っており、さすがは、という思いがします。
エアキャップ封筒＋ゆうメールは、ふつうは梱包材の高さと送料の高さがネックになるのですが、大量発注によってフォローしたならば人件費削減によりコスト的にも十分見合うものになるのではないかと思います。
外部サーバーのMysqlのデータを利用して差し込み印刷をかけるとなると
2009 年 3 月 1 日 日曜日JAVAやPHPなどで作成されるWEBアプリでの業務システムは、オペレーターのクライアントはWindows、サーバーはLinuxという構成になることが多いです。
しかしながらWEBアプリには印刷機能が弱いという問題があり、ここが大量の処理を必要とする（請求書印刷など）場合に致命的なネックとなります。
そこを簡単にローコストで（つまり、VCなどで専用クライアントなどは造らずに）解決する方法はないかとよく考えるのですが、やはりMysqlのデータをWordかAccessから利用するのがよさそうです。
つまり、
- LANの中にもう一台Mysqlを置いてミラーリング、MysqlサーバーにODBCで直接接続し、差込印刷
- CSV形式で落としたテキストファイルを使ってWordかAccessから差込印刷
ということになります。
しかし前者はそれなりにインフラが必要になってしまう上に流れが複雑でトラブルを起こしやすそうです。
とすると、やはりトータルで考えれば後者がベストでしょうか。オペレーションが少々面倒にはなるでしょうが、それほど厳しくもないはずです。
CSVはしょせんテキストなのであまりにデータ量が多いと速度的に破たんするでしょうが、それでも１万か２万ていどの規模のデータ量ならこなせると思います。そして、それなら自社もしくは自部門で印刷をかけられる程度の案件はたいていフォローできるはずだと思います。
サイトの負荷対策を実行
2009 年 2 月 25 日 水曜日これまでブックジーではさくらの５００円コースを使っていましたが、夜間の重さと、ときどき503エラーが出る問題に悩まされていました。そこで本日、WEBARENAに引っ越しを敢行しました。
ついでにabでベンチを取っておきましたので、華麗なる（？）その過程をブログに記録しておきます。
//さくら（昼間）
Benchmarking book-g.com (be patient)
Finished 146 requests
Server Software: Apache/1.3.39
Server Hostname: book-g.com
Server Port: 80
Document Path: /
Document Length: 10363 bytes
Concurrency Level: 10
Time taken for tests: 60.312500 seconds
Complete requests: 146
Failed requests: 12
(Connect: 0, Length: 12, Exceptions: 0)
Write errors: 0
Non-2xx responses: 5
Total transferred: 1481334 bytes
HTML transferred: 1458429 bytes
Requests per second: 2.42 [#/sec] (mean)
Time per request: 4130.993 [ms] (mean)
Time per request: 413.099 [ms] (mean, across all concurrent requests)
Transfer rate: 23.98 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 20 7.6 15 31
Processing: 31 3980 2162.5 3906 9985
Waiting: 31 3770 2114.7 3687 9765
Total: 46 4000 2163.3 3921 10000
Percentage of the requests served within a certain time (ms)
50% 3921
66% 4765
75% 5234
80% 5734
90% 6718
95% 7640
98% 9000
99% 9093
100% 10000 (longest request)
昼間のべンチにもかかわらずすでにFailerが12あるのがわかります。これが夜間になると、あろうことか半分以上Failerになるという衝撃の数字が出てしまいました。引っ越しを決断した最大の理由です。いちおうこれでも最安値コースではなく真ん中のコースなのですが……。
1秒間に処理されたリクエスト数（Requests per second）は2.42。
Requests per second: 2.42 [#/sec] (mean)
C:\Documents and Settings\main>
//VPSに引っ越した後の数字
This is ApacheBench, Version 2.0.41-dev < $Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking book-g.com (be patient)
Finished 112 requests
Server Software: Apache/2.2.8
Server Hostname: book-g.com
Server Port: 80
Document Path: /
Document Length: 13537 bytes
Concurrency Level: 10
Time taken for tests: 60.484375 seconds
Complete requests: 112
Failed requests: 0
Write errors: 0
Total transferred: 1536262 bytes
HTML transferred: 1517391 bytes
Requests per second: 1.85 [#/sec] (mean)
Time per request: 5400.391 [ms] (mean)
Time per request: 540.039 [ms] (mean, across all concurrent requests)
Transfer rate: 24.80 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 18 6.9 15 31
Processing: 2313 5147 1424.9 5235 8953
Waiting: 2234 5077 1424.5 5171 8875
Total: 2328 5166 1425.8 5250 8968
Percentage of the requests served within a certain time (ms)
50% 5250
66% 5562
75% 6109
80% 6343
90% 7140
95% 7656
98% 8093
99% 8765
100% 8968 (longest request)
VPSに移行したあとの数字です。Failed requestsこそ０なものの、Requests per secondは 1.85 [#/sec] (mean) と、共用レンタルサーバに負けてしまっています。
いくら夜間だからとはいえこれはひどい。
と思ったら、PHPのアクセラレータを入れていないことに気がつきました。
//というわけでeAcceralatorを入れてみました。
C:\Documents and Settings\main>”C:\Program Files\Apache Group\Apache2\bin\ab” -c
10 -t 60 http://book-g.com/
This is ApacheBench, Version 2.0.41-dev < $Revision: 1.121.2.12 $> apache-2.0
Copyright (c) 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Copyright (c) 2006 The Apache Software Foundation, http://www.apache.org/
Benchmarking book-g.com (be patient)
Finished 497 requests
Server Software: Apache/2.2.8
Server Hostname: book-g.com
Server Port: 80
Document Path: /
Document Length: 13537 bytes
Concurrency Level: 10
Time taken for tests: 60.000 seconds
Complete requests: 497
Failed requests: 1
(Connect: 0, Length: 1, Exceptions: 0)
Write errors: 0
Total transferred: 6819709 bytes
HTML transferred: 6736376 bytes
Requests per second: 8.28 [#/sec] (mean)
Time per request: 1207.243 [ms] (mean)
Time per request: 120.724 [ms] (mean, across all concurrent requests)
Transfer rate: 110.98 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 15 18 6.6 15 31
Processing: 203 936 2924.6 516 43312
Waiting: 140 870 2924.7 453 43250
Total: 218 954 2925.2 531 43343
Percentage of the requests served within a certain time (ms)
50% 531
66% 625
75% 796
80% 843
90% 1093
95% 1218
98% 3453
99% 14765
100% 43343 (longest request)
C:\Documents and Settings\main>
見事Requests per secondは 8.28 [#/sec] (mean)に。まずは納得の結果となりました。ヤレヤレ。
P.S
これを書いているのが午前１時ごろで、終わったのが今さっきなのがとてもIT業界らしいですね。
