Archives ページでチャートのカテゴリー選択とセレクトボックスのカテゴリー選択が連動していなかったのを統合して連動するようにした。以前、やり方がわからなくてチャートのカテゴリーのレジェンドをクリックしたときにクリックされたカテゴリーをチャートから非表示にしつつ色をグレーアウトさせるのもできるようになった。どのカテゴリーの記事をいつ頃どのくらい書いていたかがわかるようになってめっちゃ便利。
Archives ページは React で作っていて、チャートとセレクトボックスでそれぞれに別々にカテゴリー一覧を API から取得していたのを一本化し、非表示とするカテゴリーも同じ state として管理するようにした。こういうのがサクッとしかも高速にできて React は便利。 jQuery でやるのは大変だった。
いまの家（木造二階建て）に引っ越したときに WiFi ルーターをいいのにした。 Apple の AirMac Extreme （IEEE 802.11ac = 5GHz 帯に対応してる）を買った。 Kaizen Platform 時代にリモートワークしてたときは不満はなかったのだが、経年劣化してきたのか、家にものが増えて電波が届きにくくなったのか、最近は Zoom でミーティングしているときに調子が悪くなることがたびたびあったし、風呂場や寝室で iPhone で Netflix やアマプラビを見ているときに「モバイルネットワーク通信を利用します」という警告が出たりしてわずらわしかったので新しいルーターに変えてみることにした。
ルーターが一階にしかなく、二階の端っこの仕事スペースに電波が届きにくいのが原因ではないかと思い、メッシュネットワークに対応したものを買ってみることにした。また WiFi 6 というのもバズワードでよく耳にするので WiFi 6 + メッシュネットワークの条件に合致し、アンテナがいっぱい出てない厳つくないものにしようと思っていた。友だちが Linksys や TP Link が良いと言っていたのと、 Google Nest WiFi も良さそうだったのでこれらから選ぶことにした。
Google Nest WiFi が Google Home 機能も付いていて良さそうだったが、 Google Home 機能は拡張ポイントの方にしか付いていないようだった。うちはリビングにプロバイダーのターミナル端末があるので、リビングにルーターを置かないといけない。となるとリビングで Google Home 機能が使えず不便だ。二階の廊下で OK Google できても意味がない。またメッシュネットワークには対応していないようである。ということで候補から外れてしまった。
次に検討したのが TP Link の Deco だ。値段も手頃で良さそうだったのだが、どうしても見た目が好きになれなかったので見送ることにした。
最後に残ったのが Linksys だ。 Linksys のルーターは Apple の AirMac Extreme に外観が近いのが良かった。 Apple Store でも取り扱いがあって、 AirMac Extreme の後継的なポジションのようだ。 WiFi 6 とメッシュネットワークの条件を満たすもので一番値段が手頃なのが Atlas Pro 6 の MX5502-JP という機種だった。結論からいうと自分は良く下調べをせずに買ってしまって失敗した。
Linksys のこのシリーズは外観が同じで品番違いのものがたくさんあって選ぶのが難しい。よく分からないので値段重視で選んだところ見事に失敗してしまった。メッシュネットワークを構築するときには周波数帯クラスがトライバンドのものが良いようだが、自分が選んだ MX5502-JP はデュアルバンドだった。ルーター間の通信で一つ周波数帯を使うので、三つの周波数帯を使えるトライバンドの方が良いようだった。
加えてどうも仕事用に会社から貸与されている MacBook Pro 2020 と相性が悪いようで、ルーターの近くで人がうろうろしたりすると 5GHz 帯から 2.4GHz 帯に切り替わって転送レートが急に 144 Mbps に落ちたりする（私物の iMac 5K 2017 モデルでは起こらない）。わざわざ二階にもルーターを置いているのに遠い一階のリビングルームのルーターに 2.4GHz 帯で接続しているようだ。普通にネットしてる分には問題ないが、 Zoom ミーティング中だと途切れ途切れになったりする。これは厳しい…。
Linksys の同じデザインで WiFi 6 + トライバンド対応のものは急に高くなる。メッシュを組むために二個セットを買うと 70000 円くらいしてしまう…。 MX5502-JP 二個セットでも 3 万円近くして結構思い切って買ったのだが、ルーターに 7 万円出せるほどのお金はない。
そもそも手持ちの Mac や iPhone が WiFi 6 対応していないのだから、 WiFi 6 対応を要件に含めるべきではなかったのかもしれない。 WiFi 6 非対応でトライバンドのルーターなら二個セットで 2 万円ちょいで買えたりする。正直こっちを検討すべきだったのかも知れない。
世の中のほとんどの人は 5 千円くらいのルーター使ってると思うし、奮発して 1 万円くらい出せば自宅でも快適にインターネットができて仕事にも支障がない世の中になってほしい。
1 年ちょい前に使い始めた HEY は結局 1 年で使うのをやめた。
第一に、メールをフル活用した生活を送っていないので不要かなという判断になった。 HEY は効率的にメールを読んだり分類したりするだけでなく、メールを書く機会も多い人にとって最適化されている気がする。現在の自分はメールを書く機会はまれで読むのがもっぱらだ。 Imbox 、 The Feed 、 Papertrail という分類・仕分けは便利だしメールを効率的に処理することができるが、これがないと困るというほどではなかった。もし公私ともにメールをフル活用していて、仕事のメールも HEY で扱えるような人であればメリットはあるだろう。
第二に、Basecamp は従業員の大量離職イベントがあって個人的には魅力を感じなくなってしまった。会社を応援したくて使っていたところもあったので、会社に魅力を感じなくなるとソフトウェアにも魅力を感じなくなった。
メールを変革しようという試みは素晴らしいと思う。メールといえば広告かスパムばかりという現状はクソみたいだ。あまりにもしょうもないメールが多すぎて、こちらから誰かにメールを送ってもちゃんと返事が来ないことが多く、返事が来ればラッキーかなというほどのものに成り下がっている。
今日、大抵のコミュニケーションはどこかのプラットフォームの中で行われることが多くなっている。 Facebook Messenger だったり LINE だったり Instagram だったり WhatsApp だったり。ウクライナ侵攻関連のニュースのネタ元は大抵 Telegram で、ロシア文化圏でも何らかのプラットフォーム上でコミュニケーションが行われていることがわかる。
メールが本来の役割を果たしていればそういったプラットフォームをわざわざ使う必要はないはずなのに、簡単に送れすぎる仕様のせいで多くの人の受信箱が関係のないメール（広告やスパム）であふれかえってしまっている。その問題を HEY は解決しようとしたが、年間 $99 で普通の人が手を出すには値段が高すぎる。これでは意識が高い人しか使おうとしない。
意識が高い人が使うだけではメールのダメな部分は完全に解決されない。メールはネットワーク効果が働くから、多くの人がまともな状態でメールを使えないと価値がない。意識が高い人が HEY を使ってその人の受信箱が正常化されても、その人がコミュニケーションを取る必要がある相手が意識が低くて一般的なメールを使っていたら、その人にメールを送っても受信箱がしょうもないメールであふれていて大事なメールを読んでもらえないかも知れない。いつまで経ってもメールの復権にはつながらない。意識の高い人の問題を解決するためには、意識の低い人の問題も同時に解決してあげないとダメだということだ。
HEY は多くの人に使ってもらって初めて意味のあるものになると思う。そこからすると少々値段が高すぎる。フリーミアムにして一定は無料で使えるというモデルの方が良かったのかもしれない。 Basecamp は会社の哲学的にフリーミアムを嫌うだろうが、メインの顧客である意識の高い人たちの満足度を上げるためにはプラットフォーム自体が巨大であることが重要なので、一部は無料にして多くのユーザーを獲得する必要があったと思う。
ググってみたら、 HEY は大きくは成功しないだろうと書いている人がいた。 HEY は旧来型のメールと比べて 10 倍早くないし革新的でもない。そして Early Majority 以降のユーザーの獲得戦略がない（自分が書いてる内容に近い）。
ソフトウェアは機能が優れているだけではつくづく不十分だと感じる。ビジネスモデルと機能がカチッとフィットしていないと成功できない。
一昔前までインターネットは常に見えるものだった。 Web 1.0 の個人テキストサイトや Web 2.0 のユーザー参加型ウェブサービスでも、ベーシック認証がかけてあったり非公開コンテンツというものもあったがこれらは例外的な存在で、インターネットでは目立つこと、オープンであること、また他者の注目を引くことが善だったしメインストリームの価値観だった（少なくとも自分はそう認識していた）。しかしその構図が崩れようとしている。インターネットがみんなのものになったからだ。
多くの人はインターネットで自分の情報をさらけ出したいなんて思っていない。これまでブログが下火になってきた理由を考察することが何度かあった。手軽に個人が情報発信できる Twitter や Instagram のような SNS が登場してきたからだと思っていた。かつてブログを書いていた人が書かなくなってきた理由としてはその通りだと思う。しかしスマートフォン時代になってからインターネット活動を始めたような人達（イノベーター理論のグラフで言うと Late Majority 以降の人達）はそもそもブログを書くということは選択肢に入らなかったはずで、こういう人達が増えてきたことで相対的にブログ執筆人口が減ってしまったと考えられる。
インターネットでは誰もが情報発信できると言われた。しかしできることと実際にやることの間には大きな壁がある。仕事で関わっているサービスでは、ユーザーが作成したコンテンツを公開するかどうかはユーザー自身が選べる仕様となっている。コンテンツを公開するユーザーが増えるほどネットワーク効果が働くし、 Google の評価が高くなり SEO 上のメリットもあるのでコンテンツ公開率を上げようと努めてきた。しかし頑張ってもコンテンツ公開率はある程度のところで頭打ちとなってしまった。この結果から二つの仮説が考えられる。公開を促す努力が足りないか、そもそも誰もコンテンツを公開しようとは思っていないか、ということだ。実は最近まで後者の観点が抜けていた。というのはインターネットでは誰しもコンテンツを公開すべきだ、という先入観があったからだ。
ここ数年での成長が著しい Netflix や Spotify でユーザーはコンテンツの公開を求められることはほとんどない。 Twitter や Facebook 、 Instagram などの CGM では基本的にはコンテンツを公開することが求められたのとは対照的だ。 Netflix や Spotify でユーザーはコンテンツを消費するだけでよいのだ。消費の仕方を Netflix や Spotify は観察し、この傾向のユーザーにはこういうコンテンツがおすすめだというアルゴリズムを洗練させていく。ハチャメチャに優れた推薦アルゴリズムにより、ユーザーは自分にマッチした未知のコンテンツに出会うことができ、益々サービスの利用を深めていく。ひたすら受動的にコンテンツを受容し続ければよいだけだ。
コンテンツの投稿・公開を求められる Twitter や Instagram でも、実は見る専（ ROM ）の割合が高まってきているのではないかと推測する。 以下の記事によると、 Twitter の投稿の 97% が 25% のユーザーによって行われたものだったそうだ。
さらに驚くことに、 Reply や Retweet を差し引くと投稿されるコンテンツの 18% のみがオリジナルの投稿ということらしい。やはりコンテンツを作る人の割合というのは非常に小さく、ほとんどの人はインターネット上のコンテンツを消費しているだけなのだ。
インターネットの初期時代からインターネットにどっぷり浸かってきたインターネット老人の我々のような世代がウェブサービスを設計すると、ついつい人々はインターネットで自己表現をしたいのだという前提で考えがちだ。しかしあとの方になってからインターネットを使い始めた人々にとっては、インターネットとは自分から情報を差し出す場ではなく、情報を摂取する場なのだ。買い物をしたり、動画を見たり、音楽を聞いたりしているだけだ。自分でウェブサイトを持ってブログを作ったりしている我々は、今日のインターネットにおいて決してマジョリティではない。
受動的にインターネットを使うだけの人に、 1990 年代の終わりに我々インターネット老人が感じたのと同じような興奮や感動を与えられるのだろうか。多分、発想を転換しないと難しいだろう。我々が面白がったインターネットと彼らが欲しているインターネットは別のものなのだ。ただ受動的に使っているだけでより便利になり、快適になっていくインターネットをどうやって作っていくかが見えないインターネットの時代のテーマになると思う。
Google Photos の無料利用に制限が入るようになって写真のバックアップはやめていたのだけど、他の人と登山に行ったときの写真の共有にはやはり Google Photos が便利だし、検索が優れているのでお金を払って使うことにした。しかし Google Drive のバックアップ機能がちゃんと動いてくれなくて、 Photos.app の写真が全然バックアップされない。構成は以下。
Google Drive アプリを再インストールしたり、 Google Drive アプリの Google アカウントの接続を解除して再ログインしたりするとバックアップされることもあるが必ずそうなるとは限らないし、写真を追加する度にアプリの再インストールをするのはハチャメチャに面倒くさい。
ユーザーフォーラムを見ると、どうも外付けのドライブにフォトライブラリを配置しているとバックアップがうまくいかないようだ。昨年の 10 月から起きている問題だけどまだ解消されていない。多くの Mac ユーザーの嘆きの投稿を見ることができる↓
加入していた Google One （ストレージ追加プラン）は 100GB で月額 250 円のプランだ。節約画質でのバックアップなのでこれで十分こと足りるのだけど、肝心のバックアップができないのでニッチもサッチもいかない。
Apple の iCloud Photos であれば完璧に写真がバックアップされそうだが、 iCloud Photos の方は節約バックアップ的な思想ではなく、逆に iCloud 側にマスターデータを置いてクライアントの Mac 側に画質をおさえたコピーを保存するやり方だ（ Mac 側にオリジナルを残すこともできる）。それだとデータを人質に取られる感じだし、 2TB の月額 1300 円のプランに入らないといけない。データの同期のために毎月 1300 円払うのは厳しいのでためらってしまうし、そもそもやりたい他の人との写真共有時には結局 Google Photos を経由させる必要があっていまいちやりたいことが実現できない。自分はシンプルに以下のことがやりたい。
前も書いたことがあるが、写真の検索や自動分類は Google Photos の方が優れている（写ってる対象の識別精度が高い）。 Apple Photos はローカルでその判定をやっているので精度が低いようだ。
なので不安はあったのだが、 Google Photos の同期のされなさにイライラしてしまって Google One から iCloud+ の 2TB プランに乗り換えて iCloud Photos を利用することにしてみた。するとこれまでフォトストリーム経由で最新の 1000 件のみが同期対象だったのが全ての写真が同期されるようになった。写真の追加だけでなく削除も同期される。複数の Mac で写真を管理してると写真が重複しがちなので、削除が同期されるのは地味に嬉しい。また、 iPhone からでも標準の写真アプリで 10 年前に撮った写真を見られるのはスーパー便利だ。このために毎月 1300 円払っても惜しくないかもしれない。
今年はよくユーザーアンケートをとった。アンケート、最初は手探りだったけど最近は知見が貯まっていい感じにできるようになってきたのでノウハウをまとめたいと思う。ポイントは以下。
正しくアンケートをやってユーザーの声を聞けば、イチロー並みかそれ以上の打率で機能をリリースすることができるという気がしている。
アンケートで聞くべきは何か。いつも課題を聞くようにしている。やってはいけないのは「欲しい機能は何ですか？」と聞くことだ。良く言われることだがユーザーは自分が欲しい機能をわかっていない。だから課題に感じていることを聞く。
「課題と言っても何を聞けばいいのかわからない」と思う人もいるだろう。自分はいまある程度規模が大きくなってきたプロダクトの PM をやっているので、ユーザーの課題は何となくわかる。問い合わせやユーザー要望、ユーザーの利用データなどから何となくこの辺が課題だろうなというのは見えてくる。課題はこれらを確認することでわかってくるので課題リストにストックしておく。
次にどんな機能を開発すか検討するときに課題リストの中から「これを解決すると良いのでは（ビジネスインパクトが大きいのでは）」というのを見繕って、「〇×にどのくらい課題を感じますか？」という形でアンケートを送るようにしている。回答選択肢は三択で「とてもそう思う」「そう思う」「そう思わない」くらいにする。いくつかの課題を並べて聞き、「とてもそう思う」という回答の割合が一番高いものがペインが大きいと認定し、その課題を解決する機能の開発に取り組むようにしている。
アンケートのシステムには Google Form を使っている。一時期は自前でアンケートシステムを作ろうかと考えたが、 Google Form ほどの柔軟性を持ったアンケートシステムを作るのは工数がかかるし、マーケティングチームの人もアンケートを多用していて Google Form に慣れているので Google Form で行くことにした。
ただ、ちょっと使い方を工夫していて、ペライチのページを作って iframe で Google Form を自ドメイン内のページに埋め込むようにしている（ Google Form は iframe での埋め込みをサポートしている）。こうすることで以下のメリットがある。
Google Form はクエリパラメーター付きで https://docs.google.com/forms/d/e/XXX/viewform?entry.0000=value とすることでフォームに値を埋め込むことができる。アンケート依頼はアプリへのプッシュ通知で送ることが多いので、その場合には value の部分にユーザー ID が入るようにしていた。しかし一括送信するメールやアプリ内のバナーへリンクを設置する際にこのやり方は使えなかった。サービスのドメイン内にログイン必須のペライチページを作ってフォームを埋め込むようにしたことで、どんな導線からアンケートページに辿りついてもほぼほぼ確実にユーザー ID を取得できるようになった。
ユーザーアンケートは誰が回答しているのかを知るのが超重要だ。プロダクトのヘビーユーザーの回答なのか、ライトユーザーの回答なのかわからないと、次に作るべき機能を検討するときに判断材料として使えない。ライトユーザーの課題を解決する機能を開発しようとしているときに、誰が回答したのかわからないアンケートデータをもとに意思決定をするのは困難だ。
アンケートでユーザー ID を取得する際のデメリットとして、匿名回答ができないことでアンケートの回答率が下がることが懸念されるが、上述の通りどんな属性の人が回答したのかわからないアンケートはデータとしてあまり価値がないのでその部分は割り切ることにしている。また匿名の回答はサービスへのネガティブ感情が強い人からの回答が集まりがちで、自由入力欄の罵詈雑言で集計時に精神的にダメージを受けることもあるのでそれらを避けるという意味でもユーザー ID 必須のアンケートにしてしまって良いと思う。
集まったアンケートの回答は一旦 Google Spreadsheet 形式に変換する（ Google Form の機能を使うだけで簡単にできる）。スプレッドシートの機能を駆使すればクロス集計したりグラフを作ったりできるが、折角取得したユーザー ID との掛け合わせができない。なので Google Spreadsheet のデータを Big Query に取り込んでいる（詳しいやり方は Google スプレッドシートを BigQuery のテーブルとして扱う - べにやまぶろぐ 参照）。勤務先では Big Query にデータウェアハウスが構築されているので、 Production DB のレプリカとアンケート回答を JOIN することで、どんな属性の人がアンケートにどんな風に回答しているかがわかるようになる。さらに幸運なことに勤務先では Looker を使えているのでこの辺の分析がとてもしやすい。こんな感じでアンケート結果をビジュアライズしている。
このやり方をとるようになって、リリース後に「大きく外した」ということがなくなった。少なくとも機能をリリースするときにユーザーに受け入れられるかどうか不安に思うことがなくなった。イチローになったような気分でプロダクト開発することができるのでおすすめです。
この記事は YAMAP エンジニアのカレンダー | Advent Calendar 2021 9 日目の記事でした。明日は @t-yng さんの「僕がフロントエンドのコードレビューをする時に意識していること」です。
ぼちぼち走ってることは以前書いた。
その後一日に走る距離が伸びて、今では毎回 5km 走るようになった。タイムも速くなってきてる。
走り方を少し変えていて、フォアフットという走り方をするようになった。走るときかかとから地面に設置するのではなく、つま先から着地する走り方だ。最近チラッと読んだランニングの本によると、長く疲れず怪我せず速く走りたいならフォアフットに変えるしかないと書いてあった。速く走りたいという願望はないが、疲れず怪我せず走れるならということでフォアフット走法を始めてみた。
フォアフットに切り替えてみて、最初はふくらはぎが筋肉痛になったり、そんなにハイペースじゃないのに息が上がったりして「これで本当に長く疲れず速く走れるのか？」と思ったが、やってるうちに段々良さがわかってきた。
かかとから着地してた頃はずしんと響く感じが足全体に伝わっていたが、それがいまはない。つま先から着地することでふくらはぎの筋肉と膝のバネで衝撃を緩和してる感じ。特にベアフットシューズの Xero Shoes Mesa Trail に変えてからはソールの薄さ故に足への衝撃が気になっていたのが気にならなくなった。これまで使っていなかったふくらはぎの筋肉を酷使することで一時的に筋肉痛になるかもしれないが、慣れれば足へのダメージが少なく、「確かにこれは長く怪我せず走れるわ」と実感が持てる。
Mesa Trail で近所の山を走ってみたときも問題がなかった。フォアフットは自分の足自体がバネのようになるから、石や木の根がある山道でも衝撃が体に伝わってこない。考えれば昔の人はわらじで山に登っていたわけで、足の使い方を工夫すれば厚底の登山靴は不要なのかもしれない。
ただしフォアフットで走るためにはある程度の基礎的な脚力や心肺能力が必要だと思う。フォアフットでゆっくり走るのは難しい。必然的に体が前屈気味になり、倒れそうになるのを足を前に出して支えるような感じの走り方になる。走り初めの頃の 8分/km のようなペースで走ることはできず、 6分/km くらいのペースになってしまう。 6分/km のペースは決して速いわけではないが、ランニング初心者には（少なくとも自分には）結構きついペースだ。なのでこれまで走ってなかった人がいきなりフォアフットで走るのはやめておいた方が良いだろう。
意図していなかったフォアフットの効能としては扁平足が改善された。自分は土踏まずがのペーっとしている典型的な扁平足で、冬の寒い時期に床に足をつくと土踏まずまで満遍なく接地して足裏全体に冷たい感覚が伝わってきてた。フォアフットで走り始めて土踏まずが高くなり、いまは足の裏全体が接地するわけではなくなった。土踏まずが宙に浮いている感じは新鮮だ。
扁平足は疲れやすいと言われるけど、扁平足だから疲れやすいのではなく、かかと着地で走っていて足のバネが使えていないから疲れやすいのではないかと思う。扁平足は原因ではなく結果なのではないだろうか。
というわけで扁平足でお困りの方はフォアフットで走ってみると面白い経験ができるのでおすすめです。
