portal shit!

Basecamp が始めたメールサービスの HEY に登録した。去年のリリース時にお試ししていたのだけど、踏ん切りが付かなくてお金を払わなかった。ただ、ソフトウェアにお金を払うことに対していろいろ思うところがあって、良いと思うものにはお金を払おうと思って HEY に登録してみることにした。

脱受信トレイ（ Inbox ）のお気楽なメール管理

意識高く金を払って気分が良いというだけでなく、 HEY 自体がよくできてて、これまでと違ったメール体験を提供してくれる。 HEY 以前にメインで使っていた Spark も悪くはないのだが、やはり古典的なメールソフトの概念と、 Google が発明した Gmail の「受信トレイ（ Inbox ）」と「アーカイブ」の概念を引きずっている。とにかく全部のメールに目を通してアーカイブしていく作業に疲れてしまった。

HEY は最初のオンボーディングチュートリアルで使い方を学びつつ最低限の振り分け設定を行え、 15 通くらいメールの仕分けをするとその後大体いい感じにメールが振り分けられるようになる。 Imbox 、 The Feed 、 Paper Trail という三つの箱があって、重要なメールやまだ仕分けルール付けがされていないものは Imbox に、メールマガジンなどマーケティング的なメールは The Feed に、購入時のレシート的なメールは Paper Trail に、という風にメールを仕分けて使うことが想定されている。仕分け処理をやるとメールアドレスに紐付いて設定が保存され、以後そのメールアドレスからのメールは設定した仕分け先に入るようになる。一々受信トレイに来たものをアーカイブする必要はないし、受信トレイをすっ飛ばしていきなりアーカイブに放り込んでお得情報メールを見逃すということもない。 The Feed を余裕があるときに見ればよい。メールマガジンはチラシのようなものなのだということに HEY を使って初めて気がついた。

Gmail にも「メイン」、「ソーシャル」、「プロモーション」、「新着」、「フォーラム」というカテゴリー分けのような機能は存在するが、「これはここじゃないんだけどなぁ」と思うことがよくあるし、分類先を変えたいと思ったらフィルタールールを作って移動させないといけない。一々こんな仕分け作業をやってられない。一回メールの仕分けをしたら以後は自動的に同じルールを適用して欲しい。 HEY はそれをやってくれる。

Contacts という概念

HEY には独立した Contacts がある。 iPhone の Messages などメッセージアプリだと「誰とやりとりしたか」から履歴を辿れる。「友だちのノブヒデ君とやりとりしたメールを見返したい」と思うことはあると思う。メッセージアプリで普通にできることを、メールの場合はメールアドレスなどで検索するしかなかった。 HEY の場合は Contacts にアクセスして相手の名前を選ぶだけでよい。「誰とやりとりしたか」から目的のメールを探せるのが HEY のユニークなところだ。

Contacts は自分でいい感じに整理することもできる。例えば以下のキャプチャでは、 Apple の二つのメールアドレスがある。

Apple 社としてはメールを送る部門ごとにメールアドレスを使い分けているのだろうけど、こっちからしたらどっちも Apple なので統合してしまいたい。片方を開いて、サブのメールアドレスとしてもう一方のメールアドレスを登録する。

保存すると、「このメールアドレスはすでに Contacts に存在するけど統合する？」と聞かれる。

ここで "Yes, merge them" を押すと統合され、 Contacts 一覧からメールを辿るときにも統合して表示される。めっちゃ便利。

その他の便利な機能

そのほかにも、同じような要件で別々に届いたメールをスレッドとしてひとまとまりにしたり、メールを開封したかどうかを調べる解析用の gif 画像を読み込まないようにしたりなど、これまでのメールソフトにはない機能がある。まだまだ使いこなし切れてない。

HEY はガワか？

これまで Gmail のメールアドレスをいろんな場所で登録してきたのでいまも大半のメールは Gmail に届いている。各所を変更して回るのは大変だし、死ぬまで毎年 $99 を払える自信がないので Gmail から @hey.com のメールアドレスに転送するようにしている。なのでいまの自分の HEY の使い方はガワというかメールクライアントみたいな感じだ。メール本体は Gmail にあってそれを HEY のインターフェース越しに読んでいる。これならガワとして、つまりメールクライアントとしてサービスを提供してもらった方がユーザーは自分のメールアドレスを持ち込みで使えてスイッチングコストが発生せずうれしい気がするのだけど、 Basecamp はそうしないみたいだ。 HEY のマニフェエストの先頭に、メールクライアントではなくプラットフォームであることが宣言されている。

HEY — The HEY Way

We have very strong opinions about email.

hey.com

A platform, not a client

To make significant, meaningful upgrades to email, you need to build your own platform. That’s why HEY isn’t an app that sits on top of Gmail, Outlook, iCloud, Yahoo, etc. HEY is a full email service provider. You don’t use HEY to check your Gmail account, you use HEY to check your HEY account. It’s its own platform, and it’s all you’ll need.

真に意味のある変革を E メールにもたらすためには、独自のプラットフォームを構築する必要があるということだ。スレッドの統合や検索の性能向上（サーバーサイドとクライアントサイドが連携した一気通貫の検索システム）など、確かにただのガワでは実現できない部分があるのだろう。

そのほかにも The HEY Way のページには過去のメールを HEY に移行できない理由など、「割り切り」コンセプトの理由が書かれている。まるで "Getting Real" や "Rework" からの抜粋かのようだ。

HEY の残念な点

概ねにおいてよくできているのだけど、一部で使い勝手が良くない点がある。

Rebuild のエピソード 272 でヒロシマさんも言っていたけど、アプリがネイティブ実装ではなく HTML で作られているせいで、特に Mac のクライアントが Mac らしくない。一覧から詳細に遷移し、もう一度一覧に戻るときにもっさりする。 HTML を再レンダリングしているからだと思われる。個々の画面の表示は別に遅くないのだけど、総合的な体験としては良くなくて、ヒロシマさんが「速いけど遅い」と言っているのは言い得て妙だ。この辺は DHH の思想 が反映されているのだろう。

iOS 版アプリにタブがなくて移動しづらいというのもそう。 Mac であればショートカットキーで Imbox 、 The Feed 、 Paper Trail を行き来できるけど、タッチ UI ではショートカットキーが使えないので一々 HEY メニューを経由する必要がある。

総じて

不満な点がないわけではないが、 HEY がこれまでのメール体験を刷新するものであることは間違いない。インターネットを始めたばかりの頃、メールは届くととてもうれしかった。 『 You've Got Mail 』というトム・ハンクスとメグ・ライアンの映画もあったくらいだ。それがいまではメールは面倒なもの、しょうもないもの、スパムや広告だらけのものという印象を持たれるようになってしまった。その認識をひっくり返そうという試みは面白い。死ぬまで使い続けるかはわからないけど、とりあえず一年分の料金は払ったので活用してみようと思う。

9 月頃、 Pebble Time Round 追悼のような記事を書いた。

Pebble Time Round の思い出

誕生日にもらったPebble Time Roundを愛用してきた経緯を振り返る。革ベルトの臭いや充電端子のサビに悩み、ナイロンベルトに替えて改善。Pebbleの買収とソフト更新停止の不安を抱えつ...

portalshit.net

この記事を書いた後くらいから Pebble Time Round の調子が悪くなり、 Apple Watch に買い換えた。

Pebble Time Round 、購入後半年くらいから充電されづらい問題はあったが、これまでだましだまし使ってきた。今年の秋頃から充電したのにバッテリー切れで死んだり、充電に異常に時間がかかるような症状（ 8 時間使って 16 時間充電する感じ）が出るようになり、ある日一切充電されなくなってしまった。もうこれは寿命かなと思って 10 月に嫁さんに黙って Apple Watch を買った。しばらくはばれずに過ごしていたけど、風呂に入っているときに洗濯機の上に置いていたところを発見されはちゃめちゃに怒られた。

Apple Watch でどう便利になったか

Pebble に比べ Apple Watch はよくできている。生活が便利になったところをまとめていく。

生活の利便性向上

通知の受け取り

Pebble は iPhone に通知が来たとき、 iPhone を操作中かどうかに関係なく一律にプッシュ通知を飛ばしてきて鬱陶しかった。 Apple Watch はそんなことなくて、 iPhone を使っている状態であればブルブル震えたりしない。プッシュ通知のプレビューも便利で、画像付きのプッシュ通知は画像を見ることができるのが便利だ。 iPhone との連携がとてもよくできている。

Apple Watch の通知 - Apple サポート (日本)

Apple Watch に通知が届くタイミングや通知方法をカスタマイズできます。

support.apple.com

Mac のロック解除

会社から貸してもらってる MacBook Pro はこれまで Touch ID でロック解除していたけど、 Apple Watch でロック解除できるようになった。 Apple Watch がロック解除済み（パスコードを入れて手首に装着済みの状態）であれば自動的にロック解除されるというものだ。 Touch Bar に指を伸ばすより Mac の前に座るだけで自動的にロック解除される方がはるかに便利だ。加えて、 Touch ID が付いていない私物の iMac もパスワードを入力することなくロック解除されるようになった。超便利だ。

Apple WatchでMacのロックを解除する - Apple サポート (日本)

Apple Watchを身に着けていれば、近付くだけでMacが察知し、自動的にログインできます。また、管理者パスワードの入力が必要なほかのリクエストも、Apple Watchで承認できます。 

support.apple.com

最近、 1Password が Apple Watch で認証する機能をリリースした。 Mac のロックを Apple Watch で解除できるなら 1Password の認証もできたら便利と思っていたが、 Big Sur になるまで Apple がこの API をサードパーティーには提供していなかった模様。それが Big Sur で開放されて、 1Password のロック解除を Apple Watch でできるようになった。ただし、 T1, T2 チップを搭載した Mac でのみこの機能は有効で、私物の iMac は 2017 年モデルで iMac が T2 チップを搭載するようになったのは 2020 年モデルからなので残念ながら 1Password の認証はパスワードの入力が必要だ。 T1, T2 チップ入りの Mac と Apple Watch を持っていて 1Password を使っている人は是非お試し下さい。

Use your Apple Watch to unlock 1Password on your Mac | 1Password Support

Learn how to set up and use Apple Watch to unlock 1Password on your Mac.

support.1password.com

マスクつけたままパスコードなしで Apple Pay

Apple Pay も便利になった。これまで iPhone の Apple Pay で支払っていたけどマスク時代になって Face ID でロック解除できずパスコードを入れるのが非常にわずらわしかった。いまは Apple Watch で Apple Pay を使えるようになったのでコンビニでマスクを外すことなく簡単に支払いを済ませられる。

Apple WatchでApple Payを使って非接触型決済を行う - Apple サポート (日本)

Apple Watchを使ってお店やアプリ内で買い物をします。

support.apple.com

家の中で行方不明になった iPhone の捜索

Pebble にもペアリングしているスマートフォン側で音を鳴らすソフトはあったが、誰が作ってるのかよく分からない得体の知れないソフトを購入してインストールする必要があって尻込みしていた。 Apple Watch には標準で iPhone 側の音を鳴らす機能が付いている。 Find My で音を鳴らすこともできるが、家の中でちょっと見つからないときにわざわざ Mac のところまで行って Find My をしたり、家族に頼んで他の iPhone から探したりするのは大げさすぎる。手元でちょっと操作しただけで iPhone 側の音が慣らせるのは便利だ。

Apple Watchのコントロールセンターを使う - Apple サポート (日本)

Apple Watchのコントロールセンターでは、バッテリー残量を確認したり、Apple Watchを消音にしたり、Apple Watchをフラッシュライトとして使用したり、おやすみモードや機内モードをオンにするなどの操作ができます。

support.apple.com

運動時の快適性アップ

iPhone なしでジョギング

iPhone を持たず単体でジョギングに出かけられるのがいい。ランニングのログ取りと音楽や Podcast の再生が Apple Watch だけで完結する。 Apple 製のソフトだけでなく、 Castro のようなサードパーティのソフトでも Apple Watch 内に Podcast をダウンロードしておいて iPhone なしで利用できる。 iPhone がなくても Apple Pay が使えるので、 iD などに対応している自販機で飲み物を買うこともできる。

自分が買ったのはセルラー回線なしの GPS モデルだ。 iPhone を持たずにジョギングはセルラーモデルを買えるような金持ちの専売特許かと思っていたがそうではなかった。ジョギング中に電話を受ける必要がなければ GPS モデルで十分だ。 Workout の GPS ログ取りも GPS モデルの Apple Watch 単体で全く問題ない。

ペアリングされたiPhoneなしでApple Watchを使う - Apple サポート (日本)

iPhoneが近くにないときでも、Apple Watchは役立ちます。

support.apple.com

ジョギング自体の快適性アップ

Apple Watch によってジョギング自体も快適になった。 Pebble 時代は Runkeeper を使っていて、 Runkeeper には Pebble 用のコンパニオンアプリがあった。ただ、 iPhone 側との接続があまりうまくいかず、 iPhone 側で Runkeeper をバックグラウンドに持っていくと Pebble との接続が切れてダメダメだった。 Runkeeper には 1km とか 5 分とか走ったときに教えてくれる機能あるけど、 Pebble に通知が来るわけではなく、イヤフォンを付けて iPhone 越しに音声で聞くしかなかった。マッチョな感じの外人女性の声で "Distance, 1 kilo meter" とか言われてもあまりテンション上がらなかったし、聞いてる音楽や Podcast の音量が下げられて上から覆い被さるようにしてアナウンスされるので使い勝手が良くなかった。 Apple Watch であれば 1km ごとにブルブルっと震えてラップタイムを教えてくれる。ちょうどいい。走ってる最中に現在のペースや心拍数、経過時間なども一発で確認できて便利。

走り始める前にランニング用のアプリを起動しなくて良いのも地味に便利で、とりあえず Apple 謹製の Workout を起動してランを始めれば良いというのも手軽。終わったら Apple Watch で記録を止めて、後から Strava に Workout のデータを取り込むことができる。心拍数付きでグラフが表示されて便利だ。

Just a moment...

support.strava.com

心拍数がわかることによる運動負荷の把握

これまでジョギングなどで自分の心拍数などを気にしたことがなかった。 Apple Watch で心拍数がわかるようになり、自分が結構無理していることがわかるようになってきた。 Health Care アプリの解説によると、心拍数は 220 - 年齢 が最高値らしい。この前何気なく登山をしていたら心拍数が 181 になっており、そんなに飛ばしているつもりはなかったのに最大心拍数になっていて驚いた。それでそこでしばらく休んで呼吸を整えたが、心拍数がわからなければ自分がいま無理をしていることを知らずそのままのペースでのぼってバテていたかもしれない。ジョギングはともかく登山ではバテてしまうとその場でへばってしまったり、疲れからくるふらつきで転倒、滑落したりしてしまうので侮れない。自分の偽りのない体力の限界を知れて便利だった。

Apple Watchで心拍数を確認する - Apple サポート (日本)

Apple Watchの「心拍数」を使って、1日を通じた心拍数を監視します。

support.apple.com

褒められる

活動の記録とリング

Apple Watch は運動すると褒めてくれるし、サボってたら「運動しませんか？」と促してくる。これはウザいと感じる人もいるだろうけど、自分の場合はうざくない。 Pebble にも似たような促し機能はあったがワンパターンだったし、メッセージ内容がぶっきらぼうでよく分からなかった。

Apple Watchで日々のアクティビティを追跡する - Apple サポート (日本)

Apple Watchで「アクティビティ」を使って、立ち上がった回数、活動量、エクササイズをした時間を追跡できます。

support.apple.com

睡眠の計測

リングについても最初自分はウザいと思っていたが、運動して閉じることができると気分がいい。睡眠についてもメッセージを表示してくれて、朝起きてしばらくすると「ピロピロリン♪」と音が鳴って挨拶してくれ、その日の天気も教えてくれる。体験が良い。

Apple Watchで睡眠を記録する - Apple サポート (日本)

手首に装着したApple Watchで、睡眠時間やアラームでの起床状況を記録できます。

support.apple.com

結論

Apple Watch に限らずスマートウォッチというかウェアリングデバイスの良さは、これまで記録できていなかった自分の行動を記録してくれるところだと思う。有名なプログラミングの格言「推測するな、計測せよ」を自分の体で行う感じだ。

users.ece.utexas.edu

ただし、ただ計測するだけでは次のアクションに結びつきにくい。 Apple Watch は計測した数値をライトに評価してくれるところが良いところだと思う。ログをとることはその他のウェアリングデバイスでもできる。それをどう評価するかが難しくて、 Pebble の場合はあまり評価をせず、どういうアクションを取れば良いのかがわかりづらかった（いつもよりよく寝たねとか、今日はめっちゃ歩いたじゃんみたいなローカルプッシュはあった）。 Apple Watch は、それが自分の健康にどういうインパクトを与えるのか、読みものコンテンツ込みで提示してくれるのが良い。それでいて押しつけがましくないところもいい塩梅だと思う。

ただやっぱり Apple Watch は高い。 iPhone 、 Mac と定期的に買い換えるもののサイクルに Apple Watch も加わるとかなり懐的には厳しい。コロナ禍で飲みに出かけたり昼飯代でお金使うことがなくなったせいで何とかギリギリ大丈夫だろうと買う判断ができたけど、通常の生活ではとてもではないけど手を出すことはなかったと思う。 Pebble Time Round と同等の値段（ 1.5 万円くらい）で気軽に買える Apple Watch が欲しいし、あったらもっとめっちゃ売れると思う。

買って良かった Apple Watch アクセサリー

以下はアクセサリー的なもののうち買って良かったやつです。冒頭の写真はこの二つを装着・利用した状態で撮影しています。

Apple Watch 用充電台

Apple Watch 、 Qi で充電できるものだと思っていたけど対応していないことを知って衝撃を受けた。なので付属の丸くくぼんでいる充電器で充電しないといけないのだけど、それだと机の上で収まりが悪い。というわけでこいつを買った。カチッと Apple Watch が固定されて、充電中は置き時計としても使えて便利。 Qi のスマートフォン充電台と一体型の商品もあるようなので、 Qi を持ってない人はそっちを検討してもいいかも。

液晶保護ケース

Apple Watch はアルミニウムモデルを買ったのでガラスがサファイアガラスではなく、またアルミニウムはステンレンスやチタンよりも傷つきやすいとのことだったので保護ケース的なものを買った。時計は結構いろんなところにぶつけるのでこういうのに入れておくと安心だと思う。装着しても Apple Watch がダサくならないので気に入っている。

"Your Computer Isn't Yours" という記事が先週バズってた。

sneak.berlin

概略を説明すると、 Catalina の頃から Apple が Mac ユーザーのアプリ起動ログを勝手に収集していたが、 Big Sur の公開日にログ集約サーバーがダウンしてしまい、そのせいで Mac を使えなくなる人が続出して問題が発覚したというもの。 Rebuild の Episode 288 で触れられているので興味がある人は聞いて下さい。

この記事については日本語の翻訳もあってはてブで 500 ブックマークくらいついていたが、どうも機械翻訳されただけのようだったし、一部訳が違うのではと思われるところがあったので自分でも訳してみた。訳を原著者の Jeffrey Paul 氏にメールで送ったので恐らくそのうち本家に日本語訳が追加されると思う。

2020-11-25 9:16 追記

日本語訳追加してもらいました。

sneak.berlin

起きていることをまとめると以下のような感じだ。

1. Apple は Mac ユーザーのアプリ起動データを IP 付きで Apple のサーバーに集めている（ログ送信）
   • 各アプリの署名有効期限チェックやマルウェア対策のためということになっている
   • Mac から Apple への通信は暗号化されていない
     • ISP や CDN （ Akamai ）、ネットワークを盗聴している他人が内容を確認可能
   • この通信はユーザーが自分の意思で無効化できない（「Mac解析を共有」をオフにしても送信される）
2. Mac （特に Big Sur でしか動かない Apple Silicon Mac ）を使いたければ利用ログ送信を甘受するしかない
   • Big Sur から、上述のログ送信や Apple 製のアプリは VPN やファイヤウォールを無視するようになった
   • OS の挙動を変更しようとすると Mac が起動しなくなる
3. iCloud Backup は iMessage の秘密鍵も一緒にバックアップするので Apple がメッセージの内容を読むことができる
   • 自分自身が iCloud Backup 利用していなくても、メッセージの送信相手が iCloud Backup を使っていると自分が送ったメッセージが iCloud 上に保存される
4. Apple はプライバシー保護を売りにしながらユーザープライバシーをなおざりにしている
   • iMessages/iCloud Backup のバックドアを放置している
   • 過去にアプリ開発者には HTTPS を強制しながら自分たちは OCSP の通信を平文で行っている
   • ログ送信の件について対応を発表したが、対応時期を明確にしていない

その結果、以下のような状況に陥ることが懸念されている。

• Apple が集めている情報は NSA や FBI に筒抜けになる
  • Apple はアメリカ軍の諜報機関や FBI にユーザーログデータなどの閲覧を令状なしで認める協定を結んでいる
  • iCloud Photo や iMessage の内容を Apple だけでなく軍や FBI も見られるようになっている
• ユーザー保護を隠れ蓑に Apple が力を増大させる
  • マルウェアから守る、を大義名分にして、ユーザーがどのアプリを動かせるかを Apple がコントロールできる可能性がある
  • 原理的には Apple が気に入らないアプリを起動できなくしてしまうことが可能

モバイルアプリの利用状況の収集は多分いろんなアプリがやっている。 Mac で Apple が集めている程度以上の情報を集めているアプリも多いだろう（位置情報を取得しているアプリなど）。なので最初この件については過剰に反応しすぎなのではないかと思っていたが、よくよく考えてみると自分の感覚の方が麻痺していたのかもしれない。アプリの利用履歴を IP アドレス付きで送るということは、どこで何をしているかがアプリ開発者に筒抜けだ。そしてそのログを公権力が自由に閲覧可能だとしたらいい気持ちはしない。

アプリと Apple の場合で決定的に異なるのは、アプリはそのアプリが起動している間（あるいはバックグラウンドでのログ送信を許可されている間）だけログを送信するが、 Mac に関して言うとずっーっと起動しっぱなしで使い続けるものなので、ログデータからユーザーの行動履歴・生活様式がわかってしまう。地図アプリで検索した場所の情報も送られていたということなので、 Jeffrey Paul 氏が書いているように、その人がこれから行く予定の場所もわかってしまう。

GDPR や様々なプライバシー保護は、アプリを作りサービスを運営する側としては正直厳しいなと思うところはあるけど、 Apple がアメリカ軍と結んでいる PRISM のような取り決めが存在すると、様々な個人情報が政府機関に流れてしまって、アメリカのサスペンスドラマのように個人の位置情報を携帯の使用履歴からいとも簡単に割り出せるようになってしまう。それはやはり恐ろしい世界だ。

プライバシーの侵害のみならず、プラットフォーマーである Apple の匙加減次第で、ユーザーが使えるアプリが決まるという状況も好ましくない。たびたび iOS の App Store で起こる Apple の恣意的な審査基準改変などはその一端だ。 Hey の件で Apple とやり合った DHH は痛烈に Apple を批判するとともに、かつて邪悪な Microsoft に対抗するための救いとも言えた Apple が以前の Microsoft 以上に邪悪になってしまったのが嘆かわしいと Twitter に書いていた。学生の頃、 Mac を広める活動をやって大学のクラスの半分の同級生のラップトップを Mac にしたというエピソードや、 Rails の開発でも Mac を激推ししたという話は胸熱だった。応援してきた Apple が Evil になってしまい、人一倍残念に思っているのだろう。

That's a formative experience! To have Apple be the escape pod from Microsoft and Windows. I spent so much effort in the early days evangelizing them because of that. Converted half my university class to Macs. Pushed it hard with Ruby on Rails. Team Apple through and through.

— DHH (@dhh) November 18, 2020

Apple はかつて "The computer for the rest of us" というコピーで Macintosh を宣伝していた。しかし今日、 Mac は彼らのコンピューターになってしまったのだ。

音楽のサブスクリプションは 2018 年の春頃から Apple Music を使っている。ただ最近、 Spotify のレコメンデーションが良いという話を複数の友だちや Podcast 、仕事先で立て続けに耳にしたので久々に使ってみたら、確かに Daily Mix というやつが聞いたことないけど絶対に好きな感じの曲で埋め尽くされていてビックリした。 Spotify は 4 年くらい前にお試しで 2 ヶ月使っただけで、それ以後は使っていない。そのときに自分の iTunes ライブラリや聞く音楽の傾向を解析してレコメンデーションの土台としていたのだろう。すごい。

Apple Music にも For You というやつがあって「金曜日のプレイリスト」的なやつが表示されるが、半分くらいがライブラリにある曲、半分くらいが知らないけど全然好きじゃない曲が混じってたりする。 Apple Music のレコメンデーションでは まだ知らない新しい音楽（だけど好き） との出会いがない。どっちかというと Apple Music は個人に最適化されたプレイリストよりも「2010年代 ヒップホップ ベスト」みたいなプレイリストのようなキュレーションされたものの方がまともな感じがする。パーソナライズされたレコメンデーションはダメダメだ。

また、 Spotify にはあるけど Apple Music にない曲というのが結構多い。 Spotify のプレイリストで良かった曲を Apple Music で DL しようとすると曲がなかったりする。以前、ストリーミングサービスの一ストリーミング再生ごとのアーティストへの支払額みたいなやつの比較を見てて、確か Apple Music が一番高かった。どうせ聞くならアーティストに手厚くお金を払っているサービスを使いたいと思って Apple Music を選んだのだが、意外とインディー系のアーティストは Apple Music には楽曲提供しておらず、 Spotify の方に出しているようだった。

こうなってくると Spotify に乗り換えたいなと思うのだけど、 Apple Music はファミリープランに入っているので自分の一存で Spotify に移行することができない。ファミリープランは個人用プランからすると著しく安い価格設定になっているが、その理由はチャーンの抑制にあると思う。意思決定者を複数人にすることで他サービスへの乗り換えが困難となる。よく考えられた価格設定だ。

結果としていまは広告に耐えながら Mac の Spotify で好みの曲を探し、ちまちま Apple Music でライブラリに追加して iPhone で聞くという生活をしている。スマートフォン版の Spotify は無料状態だと完全シャッフルになるしめっちゃ広告入るので厳しい。 Apple Music と Spotify に二重支払いできるくらいの金持ち¹になりたい。

インデックスページをいじって各カテゴリーの最新記事 4 件を配置するようにしてみた。最近の個人サイト復興ブームでみなさんインデックスページを工夫されているのを見ていて真似したくなってやった。

昔ながらのブログだとインデックスページというのは最新の記事 10 件くらいが表示されていて、「次へ」を押すと古い記事が出てくるという構成になっている。以前のこのブログもそうだった。

しかし自分自身が他人のブログで「次へ」を押して次々に記事を読んでいくということをやった記憶がほとんどない。自分のブログでだって何か目的があって特定のキーワードで検索したあとに引っかかった記事を読むという感じなので、時系列に本文とセットで記事が 10 件ずつ表示される UI というのは意味をなしていないと思った。そもそもインデックスという名称なのに最近の記事数件しか表示していないのはおかしい。インデックスというからにはすべての記事の目次になるべきだ。

このブログはカテゴリーがあるので、サイトマップを作るとするとこんな感じになると思う。

+----------+        +------------+        +-----------+
|          |        |            |        |           |
|   Blog   +---+--->+  Category  +------->+   Entry   |
|          |   |    |            |        |           |
+----------+   |    +------------+        +-----------+
               |
               |
               |    +------------+        +-----------+
               |    |            |        |           |
               +--->+  Category  +---+--->+   Entry   |
                    |            |   |    |           |
                    +------------+   |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                     |    |           |
                                     |    +-----------+
                                     |
                                     |
                                     |    +-----------+
                                     |    |           |
                                     +--->+   Entry   |
                                          |           |
                                          +-----------+

第一階層がインデックスページで、第二階層がカテゴリートップ、そして各記事がある。なのでインデックスページは二階層目の一覧ページになっているのが望ましいはずだ。しかし伝統的なブログはカテゴリーという記事をまとめる概念がありつつも、インデックスページから各記事ページへ直接遷移するのが主な導線だった。常に最新の記事が時系列順に並んでいるだけでは味気ないし、常連の読者ではないコンテキストを知らない訪問者には不親切だろう。

しかも SNS の隆盛で個人のブログのインデックスページが参照される機会というのはとんとなくなってしまった。個人が書いたブログ記事は SNS 経由で読まれ、個別記事だけが読まれる。インデックスページやトップページが読まれることはほとんどない。 SNS でシェアされている URL をクリックして個別記事を読んで、それ以上そのブログのほかの記事を読むことなく離脱してしまう。前後のコンテキストは無視して、一つのコンテンツだけがつまみ食いされてしまう。そんな流れにあらがいたいと思った。

これまで関連記事を記事下に表示するなどやってきたが、気に入っていくつか記事を読んで「ホーム」（ = インデックスページ）を訪れたユーザーがもう少しブログを深掘りしてみたくなるようにインデックスページを各カテゴリーの最新記事一覧とするようにしてみた。このブログは現在カテゴリーが 13 個あるので、それぞれから 4 件ずつ記事を取得すると 52 記事になる。全カテゴリーからまんべんなく 4 記事ずつ取得して表示するのは簡単なようで結構難しい。普通の SQL ではできない。 OR マッパーではまず無理だろう。

いろいろ調べてみた結果、 MySQL では GROUP_CONCAT というのが使えそうだった。以下のような SQL を書いた。

select entries.id
from entries
inner join (
  select
    category_id,
    GROUP_CONCAT(id order by created_at desc) as entry_ids,
    max(created_at) as last_created_at
  from entries
  where entries.draft = false
  group by category_id
) as grouped_entries
on grouped_entries.category_id = entries.category_id
and FIND_IN_SET(id, entry_ids) between 1 and 4
order by last_created_at desc, entries.id desc;

GROUP_CONCAT と FIND_IN_SET という関数を組み合わせることで、各カテゴリーから作成日の降順に記事を 4 件ずつ取得できた。このクエリでは記事 id のみ取得して、もう一回 DB に記事を取得するクエリを ActiveRecord で投げる。 ActiveRecord でクエリを組み立てるときは N+1 が起こらないように関連テーブルを JOIN する。

query = <<~SQL
  select entries.id
  from entries
  inner join (
    select
      category_id,
      group_concat(id order by created_at desc) as entry_ids,
      max(created_at) as last_created_at
    from entries
    where entries.draft = false
    group by category_id
  ) as grouped_entries
    on grouped_entries.category_id = entries.category_id
    and find_in_set(id, entry_ids) between 1 and 4
  inner join categories on categories.id = entries.category_id
  order by last_created_at desc, entries.id desc;
SQL
entry_ids = ActiveRecord::Base.connection.select_all(query).rows.flatten
entries = Entry.includes(:category, :user, :tags, :comments).where(id: entry_ids)

PostgreSQL のときに最初に取得した entry_ids の並び順通りに結果が受け取れるかは怪しいが、 MySQL の場合は一回目のクエリで取得した id 順に各レコードが ActiveRecord のクエリ結果として取得できた。あとはこれをカテゴリーごとにグルーピングして View でよろしくやれば良い。

なお各カテゴリーはカテゴリー内の最新の記事の作成日で降順ソートするようにしている。例えば現在のインデックスページの最下部には音楽カテゴリーがあるが、これは音楽についての記事を最後に書いたのが一年以上前だからだ。もしいま音楽の記事を書けば音楽カテゴリーがトップに浮上するようになっている。

見た目に関しては各カテゴリーの記事最新一件は大きなサイズで表示している。最も最近書かれた記事なのでより多く人の目に付いた方がよいだろうという考えだ。またすべての記事にサムネイルというか、アイキャッチ画像を表示するようにした。画像がない記事に関してはデフォルトのサイトアイコン画像を表示するようにしている。やっぱり視覚的に情報を捉えられるのは重要だ。画像がごちゃごちゃ表示されるのを嫌う人もいるかもしれないが、テキストだけでは人間の認知というのはどうしても追いつかない。

あわせて今回、インデックスページの冒頭部にこのサイトについての説明文を載せることにした。ながしまきょうさんや r7kamura さんがやっているののパクりだ。伝統的なブログのインデックスページは初めて訪れた人のことを無視しすぎていたと思う。そのブログ自体について説明するページがあるブログは少ない。最初の記事でブログを始めた経緯みたいなことが書かれたきり、そのブログは何なのか、誰が書いているのかが書かれることは希だ。きちんとブログについての説明ページと著者についての説明ページがあっても、左右のサイドバーやトップのナビゲーションの端っこに押し込まれて見られることはない。これではいけないだろう。というわけでインデックスページの一番目立つ位置にブログと自分自身の簡単な紹介を入れた。

ブログはなぜ衰退したかを考えてみると、 Facebook や Twitter の隆盛はあるにせよ、ブログ自体に初めて訪れた人に読まれるための工夫が欠けていたのだと思う。誰も自分のブログの継続率を計測したりコホート分析したりはしない。読者が前後の記事を読んでいることを前提に書かれた記事やサイト構成では初めて訪れた人はどうやっても離脱してしまう。特に書き手が芸能人でもない一般人の場合はなおさらだ。誰も RSS フィードを購読していないし、ほとんどの読者は初めて訪れる人なのだから、そういう人たちが読んでブログのテーマや著者の人となりが分かる構成にしていかなければならないのだと思う。でないと SNS でたまにバズったときだけ読んでもらえる、ソーシャルメディアの肥やしにしかならない。

この新しいインデックスページが正解なのかどうかは分からないが、ブログ衰退の流れにあらがっていきたい。

blog.8-p.info の過去記事ページの真似をして、 Archive ページにタグを表示するようにしてみた。

タグはあまり使っていなかったのだけど、一覧で記事タイトルだけ並んだときその記事にどんな内容が書いてあるのかを把握するためにはタグが便利だなと思い直し、タグを表示させてみることにした。いくつか過去のタグが付いていない記事にタグを振ってもみた。

このブログは技術情報からポエム、日々の日記まで何でもありのごった煮ブログなので、カテゴリーによる情報分類には限界がある。現在 13 個のカテゴリーがあるが、記事数にバラツキがあり、情報分類としてあまり機能していない。カテゴリーの粒度をもっと荒くして緩い分類に変更し、そこから先はタグによって超細かくラベリングすると情報の分類としてはまともになるのではないかと思った。

いま、カテゴリーの内訳がこんな感じ。

- "雑談":303
- "技術/プログラミング":272
- "映画/ドラマ/テレビ":150
- "Mac/iPhone":134
- "WWW":113
- "散財":95
- "旅行/ハイキング":70
- "ブログ":69
- "音楽":63
- "読書":34
- "写真":32
- "料理/食事":31
- "労働":27

もっと緩い分類にして以下みたいな感じにするとよさそう。

- 雑記
- パソコン・インターネット
- 見た・読んだ・聞いた
- 出かけた・撮った・食べた

カテゴリーとタグの使い分けは 10 年以上前から悩んでいる気がする。

タグはいっぱい付けないとダメですね

現在流行しているタグによる情報の分類は、とても中途半端で使い勝手が悪い。これまでのカテゴリ分類の代用として、もしくはタグクラウドを表示して自己満足に浸る以外には、あまり役に立たない。それはこのタ...

portalshit.net

情報分類の手法でありつつコンテンツの内容そのものを指し示すものでもあるからだろう。インスタグラムで #ラーメン #からの #うどん とかやってる投稿を見るととても嫌な気持ちになるのだけど、そういうことがされるくらいにタグというものは不安定なもので、正しく使おうとか気負わず、もっと緩く使えばいいのかもしれない。

もう廃れてしまったが、フォークソノミーが勢いを取り戻して、情報の発信者ではなく受け取り側がコンテンツにタグ付けできるような世の中になるとおもしろいのかもしれない。

フォークソノミー - Wikipedia

ja.wikipedia.org

リモートワークが長くなってきた。正直どのくらい自宅で仕事しているか定かではない。ほとんど外出しないので時間の感覚がおかしくなってきている。職場がリモートワークを許可するようになってもしばらくは出社していたが、二週間ほどで自分の具合が悪くなり会社に行くのを控えるようになった。その後本格的に具合が悪くなって家庭内隔離状態になり、同時に会社もリモートワークを推奨から出社禁止という状態に変わった。約 3 年ぶりのリモートワークで色々思うことがあったので雑に書きます。

リモート会議

リモートのミーティングでは前職の頃から Zoom をよく使っていた。いまの職場でも Zoom を多用している。リモートミーティングの Tips みたいなのは最近どこかで流れてきたのを読んだ気がするけど自分も思うところがあるのでまとめておく。

まず第一にはミュートだ。話さない人はとにかくミュート。 Zoom は音が鳴っているマイクの音を拾って音声ストリームに載せる。そして音声ストリームでは主として話している（音を出している）人の音声が採用されて、その他の人の音声はカットされてしまうようだ。図にするとこんなイメージ。

イヤフォン・ヘッドフォンを使う

自宅だとイヤフォンを付けずにスピーカーから音を出しがちだ。 Zoom のミーティングにもイヤフォンを付けずに参加してしまうかもしれないが、ハウリングしてしまったりするのでなるべくイヤフォンを付けてパソコンのスピーカーからは音を出さずに参加したい。

またイヤフォンを付けずに参加するとパソコンのマイクを使うことになって、会話と会話の切れ目が聞き取りにくくなる。 Zoom はハウリングが起こらないよう、ストリームで流している音と同じ音がパソコンのスピーカーから出ていたらそれを拾わないようにしているはずで、パソコンのマイクで話し始めるときに切り替え処理が必要になり、会話の始まりのあたりが拾われなかったりする。マイク付きのイヤフォンを使うことでこの問題は回避できる。

ちなみに以前も書いているけど Apple の iPhone 用イヤフォンはよくできていると思う。 2800 円くらいなのにマイクの音が良好で、相手の声もよく聞こえる。 10 倍以上の値段がする AirPods Pro を使っている人の声より、 2800 円の iPhone 用イヤフォンを使っている人の声の方が聞き取りやすい。 Lightning 端子ではなく 3.5mm ジャックのやつじゃないとパソコンにつなげないので注意。

やっとるわ感

先週、 sudoken さん（ Kaizen Platform の CEO ）が三戸正和さんという人と対談してる YouTube Live を見た。ほとんど三戸さんという方の話で sudoken さんの話はあまり聞けなかったが、「リモートワークではプロセスでの評価ができないので、アウトプットを意識的に行い、自分の成果をアピールすることまでが仕事のうち」という話が面白かった。リモートワークでは結果による評価に移行せざるを得ないということだ。

エンジニア業を止めてからつくづく感じるのが、人はしつこいほど言わないとわかってくれないということだ。伝えたいことは社内ブログに書いていたらみんな読んでくれるわけではなく、目立つような場所に掲示したり、目立つ方法で喧伝したり、何度もしつこく見せたりしないとなかなか見聞きしてもらえない。リモートワークをやっていて自分はそこそこ頑張って仕事してるつもりでも、その成果をちょっと過剰なんじゃないのと思えるくらいにアピールしないと、組織や同僚からは仕事してる風には受け取ってもらえないだろうな、と思った。リモートワークではやっとるわ感を出すところまでが仕事の範疇に入ることになる。

増えた自由に使える時間を有効に

リモートワークに移行して、毎日通勤にかかっていた 2 時間を自由に使えるようになった。前職時代は朝仕事を始めるギリギリまで寝ていたけど、いまは 7 時くらいに起きて仕事を始める 9 時半くらいまでブログを書いたり散歩したり食器を洗ったりしてる。最近、ブログの記事が増えているのはそういうわけだったりする。

コロナウイルスのせいで恐らく世界大恐慌に陥るだろうと思う。 1 ヶ月も 2 ヶ月も世界中の人が外出しなかったら経済回らなくなる。この時期にゲームしたり Netflix 見たりするだけでなく、何かしら一つ生産的なことをして自分に投資しておかないと数ヶ月後に泣きを見ることになるだろうなと思う。いまはインターネットの会社はコロナウイルスの影響をあまり受けていないか、あるいは Zoom や Slack 、そのほか EC をやっているところは逆に業績好調かもしれない。ただ、世の中が全体的に不景気になると必ずその余波が及ぶわけで、そのときをどう迎えるかはソフトウェア企業に勤める人々にも重要なテーマとなるだろう。