情シスは何度でも甦るさ。

ＶＢＡ！ＶＢＡ！

本の配送サービス比較 メルカリカウル用

雑記

メルカリカウルの配送方法ありすぎ

絶好調のメルカリの新サービス『メルカリカウル』を利用してみようと思い、読まなくなった書籍を売ってみようかとしてみたのだが、配送方法の選択肢の違いが全くわからず、出品できなかった。

で、まとめ記事は色々があるが、どこも説明が細かいんだけど、オレは一覧でざっと比較したいんだよ。ってタイプなので一覧にしてみた。

なお、本１冊を送るのを想定しているので、以下の配送方法は調べてねえ。

普通郵便、クロネコヤマト、らくらくメルカリ便（大型）

また、はこBOONはサービス停止のお知らせが出たので調べてません。

配送の比較表

どーん f:id:ryoben:20170515010149p:plain

Googleスプレッドシートにも作ったので、見づらい方はそちらをどうぞ

メルカリカウル配送方法比較 - Google スプレッドシート

なお、郵便受けに送るサービスでも、郵便受けに入らなかった場合は、対面で渡してくれるそうです。そんなもんなんですね。

また、スマートレターについては、メルカリで配送方法選べないけど、おすすめしてる記事があったので、載せてみた。 メルカリで選ぶ時は、ゆうメールとほぼ一緒だから、ゆうメールか、普通郵便選べばいいのではないだろうか。

厚さと重さってどんなもんなの

でもって調べてみて思ったのは、大きさは、スマートレター以外はA4サイズOKなので、本に関してはほとんど気にしなくていい。 ただし、問題は、厚さと重さ。 これが、わからん。

なので、身近にあった書籍のページ数と厚さと重さをだっと測って、それぞれが配送するのに１番安いサービスと２番目に安いサービスを調べてみたよ。

f:id:ryoben:20170515020455p:plain

値段的には、クリックポスト圧勝なのだが、送り状ラベルを自分で印刷する必要がある。つまり、プリンターが必要。これがつらい。 我が家にも、プリンターがないが、同じような人は多いんではないだろうか。

そうなると２番目の選択肢を考える必要になり、条件によっては、スマートレター、らくらくメルカリ便（ネコポス）、ゆうぱけっとｏｒゆうメールということになる。

なお、厚さに関しては、上記の大型本の平均を取ってみると、159ページで1cm という結果になった。ご参考までに。

まとめ

  • 本の厚さが３cmを超える → らくらくメルカリ便（小型）￥380
  • 本の厚さが３cm以内
    • プリンタ持ってる → クリックポスト￥164
    • プリンタ持ってない
      • 厚さ２cm 以内 かつ A5サイズ（25✕17） → スマートレター ￥180
      • 厚さ2.5cm 以内 → らくらくメルカリ便（ネコポス）￥195
      • 厚さ3cm 以内 → ゆうぱけっとorゆうメール ￥350

200円とか多少損してもいいから、トータルの作業も含めて一番ラクなのは、ゆうメールだろうか。 350円分の切手貼って、封筒に「ゆうメール」って書いて、ポストに投函するだけなんで。

ここまで調べるのに４時間かかったよ・・・。

最近流行りのRPAとは

雑記

今年で休刊が決まった日経ストラテジー。確かに最近惰性で読んでたが、気になったのがあった。

2017年5月号集が組まれたRPA（ロボティック・プロセス・オートメーション）。

wikiによると

ロボティック・プロセス・オートメーション（Robotic Process Automation, RPA）とは、認知技術（ルールエンジン・機械学習・人工知能等）を活用した、主にホワイトカラー業務の効率化・自動化の取組みである。人間の補完として業務を遂行できることから、仮想知的労働者（Digital Labor）とも言われている。 ロボティック・プロセス・オートメーション - Wikipedia

なんか、最近流行りのAI、ディープラーニング、IoT、ロボットなどを想像させるその用語から、また新しいバズワードかと思ったが、記事を読んでみると、

Oracle Functional Testing（OFT) に毛が生えた感じやん。

というのが第一印象。

OFTを知らない人向けに説明すると、Seleniumに毛が生えた感じといえばニュアンスが伝わるだろうか。

ようは、GUIの自動テストツール。

当ブログでは、OFTの記事をちょこちょこ書いているのですが、もともとはE2Eの自動テストのためのツールって、テストだけだと勿体無いから、テストツールを使って業務を自動化するという使い方はよくある話。

ryoben.hateblo.jp

じゃぁ、何が違うの。

この記事で紹介されているRPAは少し進化している。

  • Web以外のアプリケーション全てに対して動作を自動化できる
  • 各アプリケーションの操作をノンプログラミングで記述できる
  • 各アプリケーションをシームレスに繋いで、処理を条件分岐できる

例えばCRMで、新規登録された顧客マスタを、販売管理システムに手動で連携するとかのケースではないだろうか。（ASPだとAPIとかないし）

① WebのCRMシステムに新規登録された顧客一覧を表示し、CSVにダウンロード
② そのCSVをEXCELのマクロで加工して保存
③ CSVを、クラサバの販売管理システムにインポート

こういうケースだと、Webのテストツールで自動化できるのは、①だが、RPAだと、OS上の操作全てをエミュレートできるので、①〜③全部を自動化できる。

どんなツールなのか

紹介されていたのは、以下のツールたち。

  • Automation Anywhere Enterprise 米オートメーション・エニウェア （日本では、日立ソリューションズが代理店） www.automationanywhere.com

  • BizRobo! RPAテクノロジーズ bizrobo.com

  • UiPath Studio/Robots/Orchestrator 米ユー・アイバス （無料で使えるのコミュニティエディションがある。商用利用は条件あり） www.uipath.com

  • ナイス・ロボティックオートメーション アイティフォー www.itfor.co.jp

  • NTTアドバンステクノロジ WinActor www.nttdata.com

なぜ急に流行りだしたのか

導入事例として紹介されているユーザーは、三菱東京UFJ、オリックスグループ、日本生命保険、リクルートコミュニケーションズなどの大手も使っている。 ただ、使い方としては、バックオフィスの人員削減および、属人化排除のためと思われる泥臭い作業ばかりだ。

やはり、１企業の中で見た場合、どうしてもシステム化するより人で対応した方が費用対効果が高い領域というのは存在する。 契約関係とか、人事総務の手続き関係とか、細かい条件によって微妙に作業が異なったりで人の判断が必要な部分。または、ルールや手順がしょっちゅう変わって、システム化に向かない部分。
そういった部分について、ここ最近の自動化の技術が成熟してきて、RPAを導入することで費用対効果が出るようになったのだろうと考察する。

もう一点あるとすれば、クラウド化の影響。ここでいうクラウドは、SaaS。
勤怠、経費精算、人事システム、CRMとかのバックオフィス系のシステムはSaaSを利用するのは当たり前になってるが、ここにきて販売管理やらの基幹系までSaaSで置き換えるケースは増えてる。
そうなると、システムが完全に分離されちゃって、EAIなんかを使用して裏側でデータ連携はできない。
APIがあれば、まだ可能性もあるけど、開発にお金かかるし、とりあえず人手で対応。って負債ができちゃうのでは。

メンテが大変そう

システムのE2Eの自動テストって、メンテが大変じゃないですか。
ちょっと画面のレイアウト変わっただけでも、全部落ちるし。
記事の中でも紹介されていたが、それはRPAも同じで、メンテしやすい構成にすることが大事と書かれていた。
また、複数のアプリをシームレスにつなぐ分、処理の単位をどう区切るかも大事だそうだ。

確かにアプリケーションごとに処理を切り出すのが簡単そうだが、
『CRMに登録された顧客の業種によって、販売管理のマスタに登録する手順が異なる』とかいう業務の場合、CRM上の顧客の属性ごとに、販売管理側も含めたシナリオを作成するとかなると、大量のシナリオを作らねばならんことになり、メンテも死ねるので、やりたくないよねぇ。

ということで、コツはありそうである。

流行るの？

流行るか、流行らんかといえば、大企業では営業事務とか、企画事務とか、○○事務って名のつく派遣の社員の人とかいるじゃないですか。ああいうとこの人数を減らすのには、効きそうですよね。
ただ、現状初期費用が数百万円なので、大企業しか導入できん。
RPAの人気が上がれば、中小企業でも導入できるパッケージが提供されるだろうが。

お金かけたくないなら、RPAなんて言葉ができる前から存在する UWSC とかで効果あるか試してみればどうか。

日経情報ストラテジー 2017年 05 月号 [雑誌]

日経情報ストラテジー 2017年 05 月号 [雑誌]

公式手順でsqaleからHerokuに移行する

やってみた

国産PaaSのsqaleさんが、サービスシャットダウン。

f:id:ryoben:20170315001050p:plain

ということで、移行せよとのメールがきた。

後日、Herokuの移行手順公開したよ。とのメールがきたので、いざやってみた。

1. sqaleからDBをエクスポート

公式サイトに手順があるが、sshでログインして、mysqldumpコマンドでダンプを取得せよとのこと。

ただ、sqaleの環境からファイルをダウンロードする手段は提供されてない ので、なぜかawsのs3に転送しなければならないという鬼仕様。 そんな手順知らね。っていう人は、Heroku側のDBへのインポートも、sqaleのサーバからmysqlコマンドを実行することになると思われ。

俺の場合は、以前からawsにバックアップとるようにしてたので、aws経由でローカルにダンプファイルを持ってきてやった。

2. Herokuにアプリ作成・DBインポート

アカウントはすでに作ってたので、新規にアプリ作って、git push。なんかエラー出とるが、とりあえず無視。

mysqlコマンドで、ダンプしたファイルを食わせる。手順上、ClearDB MySQLの環境情報を調べるとこがわかりにくかった。
移行手順の画面上の「ClearDB MySQL」のリンクを押すと、ダッシュボードに飛ぶので、そこに自分のDB名が表示されており、それをクリックして、「ENDPOINT INFORMATION」というタブに遷移すると、userとpasswordが記載されている。

なお、ホスト名は、手順書通り、「us-cdbr-iron-east-04.cleardb.net」でOKである。

で、いざ食わすところで手順は終わりなのだが、直後にメールが飛んできた。

subject: [CRITICAL] ClearDB database size is near quota limit

Current database storage allocated: 91.88% (8.12% remaining)

これは、予期してたが、無料プランのDBの容量はいきなりギリギリ。追加するための有料プランは、$9.99で、Herokuのdynosの$7と合わせると、月額$16.99 とsqaleの940円の倍以上の金額に。

むむむ、EC2借りた方が安いやんけ。DigitalOceanやったら、$5やぞ。

まぁ、そこはさておき、とにかく、アプリケーションに接続や！

f:id:ryoben:20170315002500p:plain

ですよね。

薄々知ってたけど、deproy時に、rubyのバージョンが古いから、2.2.6に上げてデプロイするぜ。（sqale上は、2.1.0で動かしてた）って言われてたから、そこらへんか。

ローカルで、rubyのバージョン上げてbundle update したら、エラー吐きまくり。がおー。

gemの依存関係を修正したあとには、Heroku用に、Procfileを作成したり、database.ymlを修正したりして、２日間かけてようやく移行完了となりました。

あとは、DNSとか切り替えなきゃ。

結論：

手順は確かに簡単だが、Herokuになると、課金が２倍になる。（940円 → 1,916円（$16.99））

また、CleaDBの無料枠だと、使えるDBのプロセス数の関係で、重たい処理を流すと、DBがプロセス周りのエラーを吐き、Internal Serverエラーとなってしまう。なので、容量の問題以外にも、有料枠を使わざる得ない状況となってしまった。やはり、Herokuは、初めて使うPaaSとしてはハードルが若干高めな気がするなぁ。

　 　

後日発生した問題１ 処理時間が長いクエリが強制的にタイムアウトしちゃう

Herokuは、Webのリクエストタイムが30秒を超えるとタイムアウトで処理が落ちる。

で、ちょうど30秒超こえるかどうかのくらいのバッチ的な処理をWebからキックする処理があったのだが、見事にタイムアウトに引っかかってしまった。

そういうケースは、Herokuの場合、非同期処理として対応する必要があるようだ。

が、なんか処理結果見てみるとギリギリ処理は終わってたらしいので、まぁ、ほっとく。

後日発生した問題２ ：MySQLのauto_increment の値が変わる。

登録したレコードのIDがやたら飛ぶので、調べてみたら移行時に変わってた。

mysql> show variables like ‘%auto_inc%’;
+————————–+——-+
| Variable_name | Value |
+————————–+——-+
| auto_increment_increment | 10 |
| auto_increment_offset | 2 |
+————————–+——-+
2 rows in set (0.18 sec)

なので設定を変更する。

mysql> set @@auto_increment_increment=1;
mysql> set @@auto_increment_increment=1;

あとは、各テーブルについても、alter tableで、次の auto_increment 値を変更していった。

なぜかは不明。 → 設定変えてもまた同じ減少が発生するので調べたら、clerdbの仕様でした。レプリケーション時にIDが衝突しないための仕様だそうだ。 http://qiita.com/nsatohiro/items/0458e63c47c3d6ff37d0