読者です 読者をやめる 読者になる 読者になる

あおみかんのブログ

フリーランスのIT系エンジニア。ゲーム制作スタジオ4th cluster代表。

ホッテントリ砲の威力とか、例の記事への感想とかの雑記

昨日書いた記事がめちゃめちゃ広まっちゃいまして、せっかくなのでPV数とかをざっと公開してみようと思います。

現時点で654ブクマ、FBでは177シェア、ツイート数は不明ですが、僕のメインのツイートは48リツイートと、そこまで伸びてない感じ。

aknep.hatenablog.com

ということで、途中までは僕の周囲のTwitterユーザーへ、途中からはいわゆる「はてな民」に広まっていったという事のようです。

はてなブログ標準搭載のアクセス解析データとかも貼っておきます。

f:id:akn_ep:20170303140037p:plain

f:id:akn_ep:20170303140044p:plain

別に、この手の炎上ネタをわざわざ書き続ける炎上まとめサイトとかを誰かに作って欲しいわけじゃないんですが、個人からの発信でも、このくらいのインパクトを出すことは可能なのだなという実例として興味深いので、知見として共有しておこうと思いました。

はてブ砲の威力はだいたい5万PV〜7万PV程度、と考えるとちょうどかなと思います。

アクセス元を見る限り、何やらsmartnewsにも載ってたみたいですね。

この件についての僕の感想

半面、ブコメを見ていると「MFクラウド一択だな!」みたいな思考停止気味のコメントが散見されて、まぁ通りすがりで僕のエントリをざっと見ているだけだから仕方ないかもしれないんですが、あんまり考えてないでしょって感じがしました。

これはMF/freeeの両方を別々の仕事で使っている感想なんですが、MFクラウド会計は簿記に忠実なぶん、簿記が全然分からないと割と手も足も出ないです。 freeeはとにかく何も分かってなくても申告できます。 まぁ、何も分かってない状態で申告すると、2年目、3年目と積算して行ったときに段々おかしな帳簿になっていくので、結局は理解する必要が出てきますが…。

また、残念ながら弥生のクラウドは使ったことがないので僕は分かってないです

「会社が傾いたのでフリーランスを半年だけやってみる」みたいな人にとっては、簿記を一から覚えるのはハードル高いですし、とりあえず売上だけざっと計上して、大きな経費だけ算入して申告、みたいな方法でも良いわけですし、freeeの採用メリットはあります。

但し、月額課金しているサービスで、解約フローがここまで粗末なのは、利用者側としては面倒が増えるので腹立たしい。僕が主張したいのはその一点です。機能面はどのサービスも、そこそこ良く出来ています。

会計ソフトのfreeeが解約すらさせてくれない悪徳サービスな件

jp.techcrunch.com

会計アプリのfreeeがマネーフォワードを訴訟したのは記憶に新しいですね。

さて、そんなfreee、まぁまぁ便利なのですが、事業も立ち上がってきて、税理士さんに任せた方が良くなってきたので、今期から税理士さんに任せることにして、freeeの方は解約することにしました。 今までありがとうfreee。そう思っていた時代が僕にもありました。

なんということでしょう!

会計の自動化、省力化を謳うfreeeが、解約だけは「電話での対応」を求めるわけです! とっても伝統的な日本風の解約手順ですね!なんて素敵なんでしょう!

……じゃねーよ。おかしいだろ!何様なんだよ。

ちなみに、問合せを繰り返していますが、回答は一切無く、本日3/2の時点でも放置されたままです。いつになったら電話来るんですかね?

解約に伴って消滅するデータとか色々あって、立ち上げ期のサービスであれば解約時にユーザーサポートでの処理が必要、なんて理屈は割と分かるんですが、潤沢な開発力を持っているfreeeにはそういう事情もないし、意図的にやっていると言わざるを得ません。 非常に不愉快、というか迷惑ですね。

ちなみに、会社ではMFクラウド会計を使ってるんですが、あっちの方が複式簿記をきちんと意識して作られているので、簿記がちゃんと分かるならMFクラウド会計の方が良さそうだという印象です。

続報

この後すぐ電話が来たので、解約することが出来ました。 事情を聞いたところ、以下のような話をしていました。

書かないのもフェアじゃないので、最低限ですが、記載しておきます。

  • 「解約したつもりはないのに解約になっていた」などのクレームが頻発した
  • 解約に関する責任をfreee側で負うために電話確認を一度行う方針を取るように変更した
  • 以前はWeb上から解約できたが、以上の理由で仕様を変更した

とのことです。

それなら、Twitterみたいに30日間はデータが復旧できるようにするとか、手は色々あると思うし釈然としませんが、なぜそうなったのかについては納得が行きました。電話サポートの人が思ったよりちゃんと把握していて、ここについては好印象。

僕もWebサービスの開発に係わる事は多いんですが、この辺りは確かに厄介な問題ではあります。 ただ、解約操作をWebからだけではなくメールからのconfirmationも挟むとかで、上記のクレームは防げると思うので、やはり今の仕様は良くないと思います。サポートに負担もかかるし。

3月分以降の使用料の請求は行わないとのことで、実害はないんですが、現状「解約すらさせてくれない」というのがユーザーに不安を与える状況なのも事実なので、本エントリはこのまま公開しておきます。

続々報

ホッテントリ入りしてたので、もう少しだけ経過を追記しておきます。

さて、Twitterで同じ状況に陥っている方の様子を見る限り、どうやら、僕の所に電話が来たのは、Twitterやブログで騒いでいたのをキャッチして、慌てて特定して連絡を取ってきたという状況のように思われます。

何故かというと、その方は僕より早い日付に解約の申請をしたのに、まだ電話が来てないからです。 (※いわゆる炎上案件で迷惑かけるのも違うので、その方のツイートは貼りませんが…)

僕は、結局のところ上記の電話は「僕は解約する気しかなさそうだから、色々詰められるだろう事を覚悟の上でサポート部門の偉い人が電話をかけてきた」という事だと推測しています。

憶測ですが、他のユーザーには「何故やめるんですか?MFクラウドに変えるんですか?」「今なら2ヶ月割引します!もうちょっとだけ使ってみませんか!?」等と言って、無理にでも囲い込もうとする、という手を使っている、という可能性も捨てきれません。(実際にそういう事例があったら是非教えてください!)

これまた全然関係ないですが、さっき請求書を発行するためにmisocaを久々に使ったんですが、サクサク動くし動作分かりやすいしmisoca神かよって思いました。 freeeからもcsvで入力した顧客データの書き出しとかは出来るので、何もかもが囲い込み戦略というわけではないのでしょうね。

ブコメ反応

何かホッテントリ1位になってたので、せっかくなので、いくつかのブコメについて簡単にコメントしておこうと思います。 個人攻撃とかしたいわけじゃないので、特定のコメント宛ではなく、大意で要約します。

一部、単に読んでないでブコメしてるだけって人もちらほら居ますが、まぁ丁寧に読んでくださる人が勘違いしてしまうのを避ける目的で、ざっと記載しますね。

解約の実装って大変だから…

それな。

…と言う気持ちについてはさておき、freeeさんは内部的には解約処理を持っているようです。

書き方がちょっと曖昧でしたが、電話口で「以前はWebで解約だったんですが、勝手に解約されるなどのクレームが多かったので、今のフローに変えました」と言っていました。Twitter等をみても、以前はWebで解約できたようなので、解約に電話を挟んでいるのは、意図してやっていることのようです。

その意図が、電話担当者さんの言うようなクレームを無くすためのユーザー価値を目指した物なのか、ブコメで言われているような囲い込み戦略によるものなのかは断定しかねます。

憶測は余計じゃないの?

Twitterで検索すると、結構な数、実際にそう言って引き留められたらしき事例がヒットするので、ただの憶測とも言えない事が後で分かりました。

…この記事がバズってしまったので、少し前のツイートは遡りにくいですが。

解約には電話が必要なのってそこまで怒ることか?

手軽さをウリにしているサービスがやっているという意味でダブルスタンダードである点、電話を1週間以上もかけてこない(他で見掛けた事例では半月もかけていない!)点の2つが問題点だと考えています。 引越時の電気やガスの解約に電話が必要なのとは、性質が異なると思います。

Refile+S3のpresignにSwiftからダイレクトにアップロードする

画像等のファイルをS3(とかのクラウドストレージ)に置くのが当たり前になってきた昨今、クライアントから画像をアップロードするときにアプリケーションサーバーを経由するのは、そこからさらにS3に挙げるという点ではムダ。

この改善方法として、クライアントサイド(ブラウザやネイティブアプリ)からS3に直接アップロードして、アプリケーションサーバーには「ここに置いといたよ」とだけ伝える方法がある。 このアプローチは、特にherokuのようなアプリケーションサーバーに負荷をかけたくない環境では高い効果を発揮する。

で、このエントリの対象読者は、上の文で何が言いたいか分かってくれる人。

そうじゃない人は、諦めてアプリケーションサーバーに頼ってCarrierWaveかPaperclipの安定版を使う事を強くオススメする。

さて本題。

CarrierWaveの後継と噂される(同じ人が開発している)Rails向けの画像取り扱いgemのRefileというのがある。まだ安定バージョンではないし、Rails5系に組み込もうとするとSinatraとrakeのバージョンがぶつかってしまったり面倒が多いが、設計はCarrierWaveよりもさらに洗練されているっぽい。

GitHub - refile/refile: Ruby file uploads, take 3

Refileにはdirect uploadとPresigned uploadsという機能がある。(大文字小文字はREADMEに倣った)

direct uploadはフォームをsubmitしようとしたときにファイルを1個ずつRails側に送って、それが完了してからフォームをsubmitする方式。

Presigned uploadsは、上記で言ったS3に直接上げる方式。

Refileでは、Javascriptからのアップロードのみ実装されているので、これをSwift側で実装する。

ざっくり言えば refile/refile.js at master · refile/refile · GitHub の移植。

// まずはpresign情報を取得する
request("https://example.com/attachments/cache/presign").validate().responseSwiftyJSON { (presignResponse) in
    // ※エラー処理は自分で書いて下さいね。 switchで .Success / .Failure 分岐するのが個人的には好き。
    let url = presignResponse.value!["url"].stringValue
    let fields = presignResponse.value!["fields"].dictionaryValue
    let asName = presignResponse.value!["as"].stringValue
    
    Alamofire.upload(multipartFormData: { (multipartFormData) in
        
        for (name, value) in fields {
            multipartFormData.append(value.stringValue.data(using: .utf8)!, withName: name)
        }
        
        // 以下のNSDataを用意する部分もお好みで。 UIImagePNGRepresentation を使っても良いし、拡張子などで分岐しても良い。
        let image = UIImage(named: "image1.jpg")!
        let imageData = UIImageJPEGRepresentation(image, 1.0)!
        
        multipartFormData.append(imageData, withName: asName)
        
    }, to: url, encodingCompletion: { (encodingResult) in
        // ここにもAlamofireのドキュメントを参照してエラー分岐等を書く必要があると思います。
        print("uploaded")
    })
}

ここで得たデータをPOSTやPUTしてruby側でActiveRecordに渡してやる必要があるけれど、そこはまだやってないので追記するつもり。

ちなみに現状のGemfileの中身はこんな感じ。

tagすら切られてない中途半端なバージョンなので、不用意にバージョンが上がってバグらないように一応refを固定。

gem 'rails', '~> 5.0.1'

# Refile (最新版, unstableなので依存解決のために無理して入れてます)
gem "refile", require: "refile/rails", github: 'refile/refile', ref: 'd7a42dcd7c'
gem "refile-mini_magick"
gem "refile-s3"
# Refileのために以下が必要っぽい
gem "sinatra", github: "sinatra/sinatra", tag: "v2.0.0.beta2"

そういえば、全然関係ないんですが、最近Skyrimにハマってます。めっちゃ面白いですね。

JWTで認証するGem「Knock」でRSA認証する

Knockのデフォルトは secret_key_base を使ったHMAC using SHA-256らしい。

つまり、公開鍵暗号じゃないので、クライアントサイドで自由に中身を見れるというJWTの利点を半分失ってる(安全性については問題ないと思うけど…)

(追記)…と適当な事を書いてたら補足を頂きました。その通りですね! @koniyan ありがとう。

※この辺とても難しいし、僕は暗号の専門家じゃないので、重要なプロジェクトで使う場合は、鵜呑みにしないで裏を取ってくださいね。

で、このメモで書いておきたいのは、KnockでRSA認証する方法。ただそれだけ。

まず、g knock:install で生成される knock.rb の各項目に以下のような感じで書く。 File.readにしてるけど、ENVに設定すればENVから引っ張り出しても良いと思う。(ENVに改行入れる手段とかは知らない…)

# knock.rb
config.token_signature_algorithm = 'RS256'
config.token_secret_signature_key = OpenSSL::PKey.read(File.read(Rails.root.join('keys','jwt-private.pem')))
config.token_public_key = OpenSSL::PKey.read(File.read(Rails.root.join('keys','jwt-public.pem')))

で、以下のコマンドで鍵ペアを生成する。

openssl genrsa 2048 > jwt-private.pem
openssl rsa -in jwt-private.pem -pubout -out jwt-public.pem

あとは所定の位置にpemファイルを置いておくだけ。 クライアントサイドで複合したい時は、jwt-public.pem を誰でも見れるところに置いておくなりして、複合すればOK。お手軽。

特に分かりやすい利点としては、複合したトークンのexpをチェックするだけで期限がチェックできるので、トークンの延長をすべきか否かの判断とかが手軽にできる。とか。そのへん。

いばらきクリエイターズハウスの次期入居者募集が開始になりました

僕が4th clusterの活動でお世話になっている県の事業「いばらきクリエイターズハウス」が、新しい入居者を募集することになりました。

www.i-contents.jp

せっかくなので、ちょっと使い勝手とかについて紹介してみようと思います。

これは、あくまで一期生である4th clusterのメンバーとしての僕の個人的な感想なので、もしかすると間違いが含まれているかもしれません。鵜呑みにしないようにお願いします。まだ立ち上がったばかりの企画ですから、廃止される制度や、変更される制度もあると思います。

個人的には、この記事を公開することで、入る事で自分にとってメリットがある人が尻込みせずに入れると良いな、と思ってます。

立地

立地は、そんなに良くないです。東京が日本の中心だと思っている人からすると、もの凄く悪く感じると思います。 つくば駅からの移動には「松代循環」というバスを使うことになります。バス停からは徒歩10分程度なのは少し救いですね。 僕としては、立地が悪いから逆に目の前の仕事に集中出来るって言うのもあって、悪くないと感じています。

近場にスーパーマーケット(※21時閉店)があったり、そこに100円ショップが入ってたり、少し行くとハナマサがあったりするので、最低源の昼食調達には困らないです。

あと、すぐ裏に運動公園(グラウンド?)があるので、日曜日や平日の夕方は野球練習の声が聞こえてきて、割とうるさいですね。これは、ちょっと残念。 …まぁ、音楽をガンガンかけてると気にならないですし、僕が人の声に過敏なだけっていうのもあります。 それに、都会の喧噪に比べればかなり静かです。

建物

建物はちょっと古いですが、バブルの時期にコンクリートもりもりで建てたゴツいRCなので、割とイイカンジです。 冬場の水回りは寒いんですが、個室はファンヒーターで暖めれば割と快適です。

窓が薄めなので、気になるようなら防寒シートとか貼ったりカーテンを取り替えたり、まぁ普通の家と同じ様な対策をするといいです。

ウォシュレットとかはついてないです。勝手につけることも物理的には可能そうですね。

当然ですが、家電類は備え付けではないので、自前で用意する必要があります。

制度

いろいろと支援制度があります。フリーランスのデザイナーさんだったら、県からの案件を紹介して貰えたり、僕らみたいな立場だと出展の支援が貰えたりします。

お金

家賃は無料なんですが、水道光熱費とかがかかります。月に1万〜2万程度を見ておけば足りると思います。

あと、ネットは自前で用意する必要がありますね。

他の入居者との交流

サイトを見ると分かるんですが、第一期は「理系バンド」から「イラストレーター」まで、さまざまなクリエイター(のたまご)がいました。交流はそこそこありましたが、これは次期入居者のメンツ次第で変わりそうですね。 良い空気を作ってくれると、第一期入居者としては、嬉しいです。

まとまらない

まとめを書こうと思ったけど、五月雨式だったのでまとまりませんでした。もう眠いし、この辺で終わりにしようと思います。

クリエイターズハウス、有用な人にとってはめっちゃ有用だし、そうじゃない人にとっては役に立たないです(当たり前だw) 気になっている人は、現地に見に来てみたり、僕にコメント欄で相談してみたりすると良いかもしれませんよ。

ClipMenu, Clippy がハングアップするので Pastebot に乗り換えたら神だった

クリップボード管理アプリで ClipMenu や、その思想を受け継ぐClippyがありますが、僕の環境だと度々CPUが100%に張り付きます。

何かないかなーと思っていたら、Tweetbotなどで有名なチームTapbotsが、Pastebotというアプリを出してました。 かなり使いやすいのでオススメ。

Pastebot Beta

僕のことを書いたエッセイが出るので買ってください

文学フリマに「社長の彼氏ができました」というタイトルのエッセイが出ます。 そう、僕の事を書いたエッセイです。最近付き合い始めた彼女が書きました。いわゆるひとつのノロケってやつです。

最後にもう一度リンクしますが、11/23に行われる文フリで売られるようです。

c.bunfree.net

せっかくなので、エッセイっぽく紹介してみます。

※ 以下、普段と少し文体が変わります。

この本は、僕についての本だ。だが同時に、彼女の本だ。 文章自体にタイトルをつけるなら「ライター志望の彼女が出来ました」ってところだろう。

けれど、僕は何も私生活の全てを切り売りして君たちに提供したいわけじゃない。何かを開示する義務があるわけでもない。ましてや彼女の持つ様々な障害について事細かに描写してバリアフリーの啓蒙がしたいわけでもない。僕たちの日々は僕たちだけのものだ。 ただ僕は、彼女への気持ちを文章の形で表出したいだけだ。君たちはそれを横からかすめて読むに過ぎない。 公開されないものは、世界にとって存在しないのと同じだから。 誰かの人生の彩りや糧になるかもしれないから。

続きを読む