最終的な日程は、3/25発送、3/26着、3/27受け入れ完、3/30作業開始、4/2作業完了です。納期は4/3でしたから、納期はきちんと守られました。納品物の品質も（自炊したことがないので比較対象がないのですが）ざっとチェックした限りでは特に問題なさそうに思いました。
というわけで納期も品質も守っていて◎なのですが、いくつか微妙な感じを受けるところがあったのでメモ。
一番に気になったのが、前のエントリでも書きましたが
- 物理的な到着日付より、ブックスキャン側の受付日付が一日遅れる（遅れた）こと
ヤマト便の到着お知らせメールによると、3/25に発送して3/26の午前に到着していますが、ブックスキャン側での「センター到着確認時刻」は3/27でした。
常にそうなのか混雑していたからかはわかりませんが、これはとても感じがよろしくないです。
まず、「到着している（と運送業者は言っている）のにそのことがどこにも表示されない」状態がまる一日続くので、とても不安になります。送付先や手続きを間違えたのかといろいろ調べてしまいましたし、ダンボールがどっかいってるんじゃないか、無視されてるんじゃないか、と心配になりました。
また、ブックスキャンの納期はブックスキャン側のセンター到着時刻から数えるので、これだと先方がいかようにも納期を操作できるような印象を与えてしまうでしょう（そんな意図はないのかもしれませんが、このズレは改善したほうが絶対よいと思います）。
最低限、荷物が到着した事実だけはASAPでウェブ上に表示するのが礼儀だと思いますね。納期は短く数えられてしまいますが、到着したらそこから納期を数えるのが一般的な感覚なので、どっちにしても利用者は物理的な到着時刻から納期を数えます。
あるいは物理的な到着から論理受付までの最大遅延を記載しておくという手もあるかもしれません。きちんと最大遅延が守られているのであれば、そこは納期の約束からは外しても許されるかもしれない（納期はブックスキャン側の受け入れ完了からの日数で、到着から受け入れまでに設備の都合で丸一日かかる可能性がある、とはっきり言っておくのは、これはアリかもしれません）。
- 「頼んだ分を一括でチューンして」というと優先度を下げられます。優先度を上げるには一冊ずつポチポチしないといけない（これはブックスキャンのウェブ上に書いてあるので、そこは問題ありません）。
この件は、ウェブ上で先人が指摘してくれていたので、おかげで低優先度（何週間も先回しになるケースがあるようです）にならずに済みましたので実害はないのですが、とても気に入らないインターフェースです。
この制限、端的にいうと「ユーザを面倒くさくすることで、ジョブ投入量を律速する」という設計になっているわけですが、それは全然ダメだろうと思います。だって、手でしこしこやると制限回避できるわけですよ。だから、プレミアム会員としてはやるわけですね。しこしこ、ストレス溜めながらクリックゲーをするわけで。正直（感情的に）頭に来ます。
規定値の保存とかはできなくて、毎度、チェックボックスをクリックしないといけないし。
ウェブ上では「スクリプトでやってやろうかしら」みたいな言及も目にしましたが、それは本末転倒で、単純に一括で入れられるけど一回に10冊まで（それが終わるまでは次の10冊は入れられない）とか、一日に10冊、といった制限で律速して、ユーザインターフェースは単純かつストレスレスにしたほうがよいと思います。
- ウェブのインターフェースがあまりよくなくて、あっちこっち飛ばないといけない。「○○はここでできます」というリンクがあちこちに貼ってあるが、ここに行っても直感的にどうすればいいかわからない、ということが何回かありました。まあ慣れの問題ですが。
- Dropbox転送を使ってみたが、フォルダ名が "BOOKSCAN" 固定(に見える)。
問題は、「名前が固定であること」ではなく「BOOKSCANという名前になるということがどこにも書かれていない」ということです（少なくとも記載は見つけられませんでした）。すぐ横に書いといてよ。 - 依頼したもの一覧のリストが「作業中」になって見えないことがあった。実際には数時間で見えるようになりましたが、「一週間たっても出てこなかったら電話して」という言い草に少し腹立たしい感じが。そんなに待たないとエラーかどうか確定できないのかい、的な。
「いろいろと走りながら、後付けで構築せざるを得ないんだろうなあ」と同情してしまいました。
