ブログのデザインテーマを Life に変更

staff.hatenablog.com

これまで使ってたテーマは Epic だった。でもいつから使っていたのかわからない。一年半前に Pathbook に変えたようだが、その後 Epic にかえていたようだ。

blog.kyanny.me

kyanny@quipper.com

Quipper に入社したとき、ひとつだけ残念だったことがある。メールアドレスのローカルパートを選べなかったのだ。当時はファーストネームを使う決まりで、俺のメールアドレスは kensuke@quipper.com になった。Twitter でも GitHub でもブログの独自ドメインでも使っている kyanny を使えたらよかったのにな、と思ったものだった。まぁ、些細なことなんですが。

つい先ほど、メールアドレスが ID と違う問題に決着がつけられた。メールアドレスのルールは俺の入社後ほどなくしてフルネームを使うように変更され、ずっとそれで運用されてきたが、ついに同姓同名のひとがあらわれた。その場合の回避ルールも定められていたのだが、これをきっかけに議論が再燃？した。「メールを書く機会は少ないけど、実は Google カレンダーの予定に招待するとき探しづらくて不便だった」という声が多くあがったのだ。わかりやすさのために GitHub と Slack で同じユーザーネームを利用することが推奨されていて、ならば予定に招待するときも見慣れたユーザーネームで探したい、ということだ。

いくつか意見が出たものの、割とあっさり「ユーザーネーム@quipper.com というエイリアスを発行しよう」という方針に決まり、バックオフィス部門のひとたちが手際よく進めてくれて、無事に kyanny@quipper.com というメールアドレスも使えるようになった、という次第。

Quipper のいいところは、こういう「些細だけど、あるとちょっと嬉しい、けどやるのはちょっと面倒くさい」ことを、面倒くさがらずどんどんやっていくところだと思う。どうでもいい、といえばその通りなんですよ。予定に招待するときの手間も、累積すればそれなりにはなるだろうけど、そこを改善しても生産性に有意な差が出るほどではない。エイリアス全員分作るのは、一回やれば済むとはいえ、面倒くさい。「でも、やるんだよ」

Quipper 全体ではもう数百名くらい社員がいて、それなりの規模の組織になっているし、リクルートグループの子会社にもなったりして、大企業の論理に流されたりし始めてもおかしくない頃合いだけど、ルールとか慣習とかを「なぁなぁ」で受け入れず、一つ一つ吟味していくのは、大事なことだと思うし、それができているカルチャーは良いな、と思う。

エンジニア立ち居振舞い: 作業の進捗をチャットに逐一報告する

お題「エンジニア立ち居振舞い」

同じく GitHub の通知はだいたい目を通してる。流量が多くてブラウザで開いてられないので Gmail で読み流して気になるやつだけ見に行くようにしてる。 GitHub の通知を見る専用のアプリを使っていないのは、 GitHub 以外のサービスからの通知とか、ごくわずかだけど外部の関係者とのメールとかもあってメールを一切見ないわけにはいかないので、だったらいっそ Gmail 一本にしたほうが楽だし見落としが無くて安心だと思ったからです（なので inbox zero を気合で実践してる）

で、気をつけてることで、まだお題で書かれて無さそうだったのがこれです↓

作業の進捗をチャットに逐一報告する

production 環境のデータを修正するとかそういう運用系のタスクというのがけっこうあって、たいてい rake タスク + Jenkins job みたいなのを用意しているんだけど、なかなかボタン一発で済むほど自動化しきれなくて、ボタン押す前後の確認作業とかがあったり、想定外のパターンがでてきてうまく処理できなかったりする。

想定どおりの手順でうまく進んでいるときも、想定外のことがおこって困っているときも、チームのメンバーに逐一状況を報告しておきたい。自分が何をやってるのか、データ修正するならどのテーブルのどのフィールドをどう変更するのか、そういうことを共有していないと、たまたま同じタイミングで同じデータを見たり処理したりしてるとお互いに困るし、後日そのデータを見た人が想定外の状態になっててびっくりしたりする（バグが原因かと思って調査したりして大事になると手間暇がもったいないし、一言言っといてよ、となる）

なのでそういう作業をするときは、「作業開始します」とか「検証環境でデータ修正するこの Jenkins job を実行します」とか「実行終わり。結果を確認します」とか、開発者みんながいるチャットのチャンネルに逐一書くようにしています。あと、これは最近試しはじめたことだけど、作業手順をまず GitHub issue に箇条書きタスクリストの形で書いて、各手順をつぶやきながら実行・終わったら √ を入れつつコメントを編集して実行時のログとか Job の Build URL とかを書き込んで、作業手順書が最終的には作業ログとして残る、みたいにしています。

分報とはちょっと違っていて、今やってる仕事の内容とか疑問点とかをチャットに書くのではなく、あくまで手順が定まっていて終わりがある一連の作業の各ステップを報告・周知する、という趣旨です（分報的なことを書くのもそれはそれでよくやります）

なお、この「逐一報告」スタイルは私のオリジナルではなく、記憶がちょっとおぼろげだけどたぶん kuroda (@lamanotrama) | Twitter さんがペパボ時代からメンテナンス作業などをする際にこういうスタイルで進めていて、開発者は実作業をしないので見てるだけなんだけど、見てれば進捗がわかるのがすごく安心感があって良いプラクティスだなと思ったので、だんだん真似するようになりました。

せっかくだから俺はこのAWAの扉を選ぶぜ

ついに日本参入した Spotify を使ってみた。が、 AWA から乗り換えるのはやめにした。

デスクトップもスマートフォンも、アプリの出来は明らかに良い（同期とか）。曲のラインナップはどっちもどっち。ひとつのプレイリストが長いとか、思想の違いはあるものの、さすがに「発見」という観点では一日の長があると感じた。

が。Spotify よ、遅すぎた。遅すぎだ。これに尽きる。入念に準備したという割には配信されてないアーティストがあったり、招待コードをリクエストして一週間待っても届かなかったり（結局コカコーラのプロモーションアプリのキャンペーンで入手した）、時間かけてこれかよ、と感じることがあってがっかりした（同じような理由で、スマートフォン（Android）への参入が遅かった au にも失望して iPhone の日本参入とともに SoftBank に鞍替えしたものだった）

一方で AWA は、競合サービスと同時期ではあるものの、先駆けてローンチした点は高く評価できるし、デスクトップアプリを公開したり、 UI なども全体的に頑張っていると思う。そして Apple/Google/Spotify などの黒船がやってきたらいかにも分が悪そうにおもえるサービスに挑戦した心意気も買いたい。

音楽ストリーミングサービスの勢力図はいま出揃ったプレイヤーでしばらく変動ないだろうから、当分は AWA ユーザーを続けることになりそうだ。

ロングテール‐「売れない商品」を宝の山に変える新戦略

Kindle Unlimited でクリス・アンダーソンの「FREE」と「MAKERS」を見つけたので、何年か前にハードカバーで挑戦して読みきれなかった「FREE」から読み始めたところ、冒頭で「ロングテール」に触れていて、そういえば読んだことがないので読んでみた。

「FREE」は邦訳が出たときけっこう話題になって、数ヶ月は経っていたものの鮮度がある間に手に取った記憶があるけど、そのときですら「フリーミアムなんてそんなにうまくいかねーよ」と斜に構えた受け取り方をしたものだった。しかし「ロングテール」は原著と最初の邦訳が出版されてから十年も経つのにまだまだ現役で通じそうというか、さほど間違ってない感じがした。

十年前と比べて、電子書籍の普及は大きな変化だと思うので、電子版も含めた本の売れ方にロングテールの傾向が強まっているのか？は気になる。たぶんデジタルデータの流通コストおよび保管コストの低下の恩恵を受けてテールが相当太くなっているんじゃないかと思うが。

一方で Eコマースも大手以外にもずいぶん普及しただろうしハンドメイドみたいな超ニッチ商品の市場も大きくなったけど、この本がいうところのニッチ、「元々テールに存在してたけど誰にも知られなかったもの」がそこそこ売れるようになってるか？というと、微妙な感じはする。個人の興味関心とレコメンドの相乗効果でテールからぽつりぽつりとたまに売れていく、という感じはあんまりしなくて、むしろテールの一部に急にスポットライトが当たって一夜にして一躍大スターになって短期間に猛烈に売れる、みたいな、結局既存の大手メディアとかのプレイヤーの構造の中で動いているだけな気がしなくもない。

インターネットの申し子みたいな本のくせに電子書籍になってなくて、 honto の店舗受け取りサービスを利用して日本橋の丸善で購入した。

ロングテール‐「売れない商品」を宝の山に変える新戦略 (ハヤカワ・ノンフィクション文庫)