Anker Soundcore Liberty Air 2 Pro x MacBook Pro (Retina, 15-inch, Mid 2015) x Pixel3

ワイヤレスイヤホンとして使っていた初代Airpodsの電池が持たなくなってきたので、Anker Soundcore Liberty Air 2 Proを買いました。

基本的な商品スペックのレビューは世の中に沢山あるので、そちらを参照してください。

www.google.com

ここらへんが分かりやすいのではないでしょうか。

macha795.com

もっとニッチなレビュー

全部書いていると内容の重複が多そうなので、この記事ではどこにも書かれていない部分について書いていきます。

筆者がAnker Soundcore Liberty Air 2 Proをペアリングする端末

以下2台です。

• 仕事用に MacBook Pro (Retina, 15-inch, Mid 2015)
• 個人用に Pixel3

痒いところに手が届かないところ

Macとペアリングしたときにバッテリー残量が表示されない

されません。

ケースのバッテリー残量が3段階しか無い

ケース外部には3つのLED電球が埋め込まれており、光でバッテリー残量を表示してくれます。

しかし、ライト1個の場合の残量が0〜33%以下というのは幅がありすぎです！

・・・と思ったところで「メモリー効果」ってリチウム電池にも当てはまるんだっけ？ということを調べると心配しなくてよかったみたいです。

style.nikkei.com

まぁ、せっかく書いたので無理やり不満を成立させると、「まだ大丈夫！」と思っていたおのに急にバッテリー切れになるのは嫌なので、1%単位で分かるといいですよね。

後勝ちペアリングができない

最後にペアリングしていた端末がPCの場合、ケースを開けるとすぐにPCに繋がります。

ここで、スマホ(Pixel3)に接続しなおす場合は、スマホ側でBluetooth設定を開いて接続処理を行って 後勝ち接続できれば良いのですが、できません。 PC側で接続解除したあと、どの端末ともペアリングされていない状態で接続処理を行わなければいけません。

別の部屋でAnker Soundcore Liberty Air 2 Proをスマホに繋ごうと思ったときにBluetooth電波が届いてしまってPCと接続されてしまうと、部屋を移動して接続解除しないといけないので非常に億劫です。さらにノートPCの場合は開いてパスワード解除して…といった作業が面倒くさいです。

逆にスマホにつながってしまった場合はいちいち設定画面に移動して接続解除し、PCで接続処理を行わなければいけないです。

いずれにせよ面倒です。現状では、部屋の移動は億劫でもできなくはないし、普段はほぼPCでしか用が無いので問題ありませんが、潜在的な問題であることは確かです。

イヤホンタップ操作が効かない場合がある（特にPC接続時）

Anker Soundcore Liberty Air 2 Proは、スマホ接続時に専用アプリでタップ操作で曲送りやノイキャンモードを設定することができます。

しかし、PCに接続されている場合はイヤホンが忘れる？のかタップ操作が効かないことがあります。

一度ケースに戻す、スマホアプリに繋ぎ直してタップできることを思い出してもらう（？）といったことをすると思い出してくれます。

正確な対処方法はよくわかりません。

PCでノイキャンモードの設定ができない

これはタップ操作さえ安定すれば必要ないのですが、PCでもノイキャンモードの設定ができるとありがたいですね。

タップ操作でノイキャンモードを切り替えると、効果音で再生中の音楽が途切れる

タップ操作でモードの切替が行われるユーザーフィードバックがあることはいいのですが、その間再生中の音楽が途切れるのはよろしくありません。

使ってみての感想

良いです。スペック上のAirPods Proの性能と実際に使ってみた性能を比べても大差無いですし、痒い所に手が届かないところも、ユースケースの99.9%困らないので十分許容できます。

• バッテリー系の問題
  • 外出していても十分持つので、現実的なバッテリーの心配は無いです。
• ペアリングの問題
  • 条件的に家にいる間しか発生しないですが、家にいる = ほとんどのケースはPCに繋ぐ、なので基本的に問題ありません
  • 困るのは家にいてスマホに繋いでノイキャンで遊びたいときくらいです
• PC接続時のノイキャンモードの切り替え問題
  • ノイズから隔離されたい or 環境音も聞きたくてノイキャンモードを切り替えたいという時もありますが、そもそも家の中なので大きな問題にはなりません。
  • ノイキャンモードが大きく使用感に関わる外出時であればスマホと接続されているので、アプリからも変更できます。
• タップでノイキャンモード切替時の音楽瞬断
  • 安定して切り替えられるコツが掴めれば、効果音をOFFにしてしまえば瞬断も起きなくて良さそうです。

ただ、比較対象をAirPods Proに置きながら実際にAirPods Pro使ったことはないレビューなのは申し訳ないです。自分はガジェオタではなく実用重視のコスパで選んでおり、コスパを鑑みて自分が良いと思った1点しか買わないので・・・（要するにケチということ）。

Anker Soundcore Liberty Air 2 Pro（ワイヤレス イヤホン Bluetooth 対応）【完全ワイヤレスイヤホン / Bluetooth5.0対応 / ウルト 価格：16908円（税込、送料無料) (2021/2/12時点)

【作業1分】トルコで買ったトルコランプを700円で日本で使えるようにする

こちらの記事を参考にしました。 www.jixiabo.com

ほぼ同じ記事ではあるけど、類似記事が多いほど、検索した人は情報が多くて安心できるかなと思うので助けになれば幸いです。

トルコでテンション上がってランプを買ったけど、いざ日本に帰ると「何をどうすれば点くの？調べるの面倒くさい！」という状況で2年も放置してしまいました。 そんな方が調べてここにたどり着いて、上の記事のように一瞬で解決できれば良いなと思います！

手っ取り早く！

２つ買って付けて点灯！終わり！

• 1. G501440C [白熱電球 ベビーボール球 E14口金 40W 50mm径 クリア]
• 2. カシムラ KASHIMURA WP-72J [国内用変換プラグ SE→A]

では、以下丁寧に。

まずは状態確認

自分はこんなランプを買いました。

• 電球が無い状態
• 電源プラグが海外仕様の状態

仕様を調べようにも、 ÖRGÜN という日本人では全く馴染みのないメーカーで、 250V という不安な文言も刻まれています。

しかし、実際にやってみたところ、日本の電球を使う限り100Vでも特に問題はないようです。 「250Vまで通電しても『ケーブル/スイッチ的には』OK」という意味であって、電球が日本製であれば日本の100Vの電圧が電球に届くだけなので問題がない、という風に解釈しましたが、電気工学には疎いので適当な解釈です。

でも、ご安心ください

必要なのは2点だけです。

まず、以下2点をお買い求めください。

1. G501440C [白熱電球 ベビーボール球 E14口金 40W 50mm径 クリア]

E14 という、口金の直径14mmが重要で、あまり電気量販店の店頭で見かけないサイズなので、通販で買っちゃった方が早いです。

• 電球の持ちを気にする方は、LEDなど別の商品をお選びください。
• うちのは14mmなのか？と思われる場合はお手数ですが計測していただければと思います。
• 他サイトで検索する場合の型番名は G501440C です。

2. カシムラ KASHIMURA WP-72J [国内用変換プラグ SE→A]

• 次に、トルコのコンセントプラグを日本用に変換するプラグを買います。私は店頭で現物に差し込んでフィットした SE から変換するものを買いました。
• 他サイトで検索する場合の型番名は WP-72J です。

プラグの型を調べる際にはこちらを参照しました。

www.arukikata.co.jp

余談: ヨドバシエクストリームサービスは凄い

私はヨドバシ.comで購入したのですが ヨドバシエクストリームサービスの配達が1品からでも送料無料 & 爆速 & 神対応 ¹ でしたので、ヨドバシ.comでのご購入をおすすめしております！ ヨドバシ.comのアフィリエイトプログラムはありませんので、上のリンク経由でお買い物をしても私の懐には1円も入りません笑

※ご自身のお住まいがヨドバシエクストリームサービス対応地域かどうかは、以下でお調べください。

image.yodobashi.com

取り付けていく

ほんの一瞬です。1分で終わると思います。

まず、ランプの外側を取り外します。上に引っ張ると中のバネが抵抗しますが、構わず引っ張って取り外し、電球を取り付けます。

変換プラグを取り付けて、電源に差し込みます。

完成

ヨドバシエクストリームサービスのおかげで材料費の688円（ほぼ700円）しかかからず、しかも最小限の手間でランプが完成しました。

---

1. E14 で検索してヒットしてしまった口金が17mmの品物を買ってしまったのですが、再配達の連絡のついでにその旨伝えると、快く返品を承ってくださいました。↩

雑談: 「許可より謝罪」って、なんかおかしくないか？

「許可より謝罪」はあまりに有名な言葉なので、広く知られているかと思います。 もし知らない人がいたら、ぜひこのタイミングでググってみてください。

www.google.com

「許可より謝罪」または「許可を求めるな謝罪せよ」と訳されるこの原文。元の文章はこれのようです ¹

It is easier to ask forgiveness than permission. With a sincere attitude toward one’s work, the chances of doing real damage or harm are small. Consequences from bad calls, in the long run, do not outweigh the time waiting to get everyone’s blessing.

そんなすばらしいコンセプト「許可より謝罪」ですが、自分としても大大大賛成で、「やりますね」「やっちゃいました」「やってみなはれ」「やっちゃいな」「エラい人のハンコ（許可）に何の意味があるんだい？」とか言っちゃうタイプです。

でもね、どうしてもやはりこの訳文が気になってしょうがなかったので、ツッコミを入れたいです。

ツッコミ1: 時間軸が揃っていない

「許可を求める」タイミングと「謝罪をする」タイミングが違います。 Badな行動様式でのやっちゃう前と、Goodな行動様式でのやっちゃったあと（失敗時）の行動を並べてるんですよね。

どっちかに揃えましょうよ、って思っちゃうんですが、どうなんでしょう。

普通に読むと「許可」が事前なので「謝罪」も事前のことかと思います。

「やっていいですか？」と聞く代わりに、事前に「申し訳ありません！XXXXX」って謝るとして、「XXXXX」って何て言うのかな？って思っちゃいます。

長い方の訳文にも触れると、「やっていいですか？」と聞いて「許可を求めるな謝罪せよ」と返されたらどう返しますか？ 「ごめん・・なさい・・・？・・・え？」 ってなりません？

このようにGoog/Badと事前/事後の2軸の対極を比較すると、パッと理解しにくいのではないでしょうか。

ツッコミ2: 結局失敗したら謝るのでは？

「許可無く果敢にやっちゃえよ」ってことだとは思うのですが、 事前に許可を取ったって結局謝るんじゃないですかね？

もちろん、失敗に関して謝ることが本質ではなくて、再発しないよう根本解決することが本質的な行いだとは思います。 けど、まず「やべ！すいません！」って言っちゃいますよね。

その点においてはGoodな行動様式でもBadな行動様式でも同じなので、「許可」>「謝罪」が成り立たないのではないでしょうか？

訳すときに「結局謝るなら、事前と事後で差分があるところで無理やり訳しちゃおう」と言う理由だったりしたら、それはちょっと違うのではと思います。

改善案: 「許可より報告（宣言）」

ここまでで、①フレーズとしての読みやすさ②事後の行いに違いが無い点に切り込み、フォーカスすべきは 事前の心意気 だと理解しました。

しかし、ここまででGoodな行動様式では「???」のままで、つまり事前になんて言えばいいのかが分からなかったので、一生懸命考えてみました。

結論: 「やっちゃいます！」で、良いんじゃないでしょうか？

正しいことを一生懸命考えている限り報告や宣言が必須だとは思わないので、「報告が必須だ！」ということを言っているわけではありません。

チームで働いている以上、ふつう「〇〇やります」という報連相は呼吸するようにやっているはずなので、標準的な行いとして例示したまでです。

所感

今までモヤモヤしていたことがやっと言語化できて、スッキリしました。

そして、ここで爆誕した「許可より報告（宣言）」このフレーズだと、より良い行動に繋がるのではないかと思いました。

「いいですか？」と他人に判断を委ねるばかりでは、自分で考えることを放棄していると言っても過言ではありません。改善の余地があります。

だからといって、代わりに「謝罪」するということがより良い方向性だとは思えません・・・。

代わりに、「やりますね」と宣言するような行動様式に変化すれば、芋づる式に「そのためにどんな確認をとるか」「失敗した場合にどうやって被害を最小限に抑えるか」などやるべきことが多く見えてきて、自立した行動を促すことに繋がると思います。

外来のコンセプトの訳文には多少「？」となることが多く ² 、これが故意なのかどうかはわかりませんが、個人的には本質を伝えるための言葉選びは変に捻らずに、できるだけストレートなほうが良いと思いました。

---

1. 出典は山ほどあるのでどれが原本か分からないので出典は割愛させて頂きました↩

2. 実例はパッと出てこなかった↩

ConfluenceのページツリーChrome拡張を公開しました

chrome.google.com

ソースコードはこちら。 github.com

開発に至った経緯

今所属している楽天では、全社的にConfluenceが広く使われていて、ラクマでもノウハウを貯めるためにスペースを作成して各プロジェクトやチーム、開発内など様々な軸でツリーを成長させています。 Confluenceはマークダウンが使えないという点ではエンジニアに優しくないのですが、ストック型ドキュメントを整理するという意味では結構使えるツールだと感じています。

一方で、この「ストック型」というのが難点にも成り得てしまい、これが今回のChrome拡張を作成する動機になりました。

• ドキュメントの場所を覚えられない
• 場所は覚えているんだけどページツリーを辿るのが大変

その結果以下のような問題が発生してしまいます。

• せっかく蓄積したノウハウが利用されない
• 類似ドキュメントを作成してしまう

Confluenceのエコシステムを利用して「スペースを限定して検索する」という解決方法もあるのですが、いくつかの問題が存在しています。

• ページ右上のグローバルサーチバーではデフォルトでスペースを絞り込めない
  • 楽天内には多くのスペースが存在していて、ビッグワードで検索すると無数の関係ないページがヒットしてしまうので、検索結果画面でスペースを絞り込むというステップが必要になる
  • インスタントサーチ結果がボックス下に表示されるが、スペースが絞り込まれていないのでかなり詳細なクエリを必要とする
• スペース内に限定する検索ボックスも設置可能だが、画面遷移してしまう・検索スピードが遅いという課題が存在する
  • こちらはインスタント検索に対応していない
• 検索精度が不十分
  • 例えばGoogleドキュメントを参照しているページを検索するために docs.google.com というクエリを打ち込んでも、実際にこのクエリを含むページが検索結果に表示されない

検索精度に関しては結果的に今回のソリューションに直接関係はなかったのですが、

検索精度を信頼できない →検索を選択肢として利用する自信が持てない →ドキュメントの場所にたどり着ける確証が持てない

なので、「せっかく蓄積したノウハウが利用されない」という問題の遠因となります。

また、上記に挙げた代替手段は相互に補完関係にあるものの、探しているページを瞬時に探すための総合的なソリューションとして利用できないです。

ConfluenceにはもともとPage Tree Macroというものが存在するのですが、場所がわかっているのに階層が深いとトップの階層から下るということが非常に苦痛になってきます。 各種検索に頼ってもなかなかヒットしない場合や、場所がわかっているのに検索結果が表示されるまでの時間が長いというストレスも増えてきました。

「場所がわかりきっている」というのをもう少し掘り下げてみると、「ページタイトルの一部を知っている」ということが大半を占めるのではないかと思いました。ここで、ソリューションがミートする範囲を「ドキュメントがあるかどうか検索する」ことよりも「既にあることが分かっているドキュメントを見つける（経験的におそらくあるだろう、も含む）」 に絞り込みました。

何があればいいのか

ここまでをまとめると

• 頭の中に情報のインデックスは張られていて、タイトルの一部は覚えている
• または、傾向的に〇〇プロジェクトの議事録的なものは「プロジェクト名 2020XXXX」というタイトルで存在している可能性が高いと分かっている
• しかしページに辿り着くまでの手段に効率的なものが存在しない

ということになりました。ということは、ページツリーの中から入力したキーワードが部分一致するページのみを表示することが実現できれば良さそうです。 ページツリーのインクリメンタルサーチです。

※実際はここまで言語化せずに「ツリー検索無いとかマジか！！！もう怒ったった！！！作るったら作る！！！」という半ば衝動的な行動でした。カッとなってしまいました。

そこで作った

こんなものを作りました。

何もしていない状態	クエリを打ち込んだ状態	親ページを開いた状態

どうやって作ったか

大まかな設計を考え、最近覚えたてのVue.jsで作ろうと考えました。

1. ページツリーデータを取得して再帰的に親子関係をレンダリングする
2. クエリをstateとして管理し、各ノードのコンポーネントがクエリの変化に応じて自身を表示するかどうかの判定ロジックを以て表示を切り替える
3. 子が開いている状態では親も開き、開いているノードは太字にして階層を認識しやすくする

まずは、 el を使って既存のツリーをVueコンポーネント化してしまうことができないか検討しましたが、早々にできないっぽいことがわかり断念しました。そうなると、既存のツリーをまるまるリプレースするしかなくなり、ツリーデータを取得するしかなくなりました。

ツリーデータの取得

既存のツリーをハックしようと、Chromeのインスペクタを開いて階層構造のハックを試みます。

• 階層構造は、初期表示時には全件取得されておらず、ツリーを開いたタイミングでXHRで取得している(レスポンスはそのまま描画できるHTML形式😇)
• XHRのページIDを変えることで、異なる親のツリーを取得できる

という事がわかり、子コンポーネントにページIDを渡して、 monted のタイミングでその更に子、孫・・・を都度取得するように実装しましたが、これだとロード回数が半端なくて、毎度開き直す度に数百のリクエストが生じるのは流石にユーザービリティ的に悪そうです。さらに、社内や果ては全世界のConfluenceユーザーに使ってもらいたいのにこの無駄なリクエストが走ってしまうのは社内のConfluence管理者たちに申し訳なさすぎます。

ということで、ツリー全体を取得できる方法が存在しないかリクエストをよく観察してみると startDepth というパラメータがあったので試しに100を設定してみると見事全階層取得できました。もしお使いのスペースで100以上の階層がある場合は・・・PRください。

この全ページ目次のHTMLを再帰的にJavascriptオブジェクトとしてパースし、子TreeNodeに渡して再帰的に描画していくとツリーの完成です。ツリーと再帰は大変相性がいいですね。

VueのscopedなCSSで、子に padding: 10px とかすれば簡単に階層構造が視覚化できます。

ツリーデータのキャッシュ

ツリーデータのサイズに応じて取得には5秒ほどかかる場合もあります。毎回ページを開くごとにこれだけの時間を要するのはちょっと効率的ではありません。 調べてみるとChrome ExtensionにはStorage機構が存在するので、これをキャッシュとして利用します。key: value形式でデータを5MBくらい保存できます（詳細は下記）

developer.chrome.com

keyにはスペースごとのID, valueにはツリーデータと最終取得日時をそれぞれ保存します。そうすることで

• 10分以内のデータであれば通信で再取得せずに使う
• 10分経過後であれば、ひとまず古いデータで描画して描画後に通信で最新のツリーデータを取得する

という制御ができ、初回データ取得後は特に大きく待ち時間が発生しないUXを実現できました。 10分以内のページであればSlackで「ページ作りました」と直接共有されそうなので即ツリーに反映されて無くても当面は問題なさそうです。

厳密性を求めるならばリフレッシュボタンでデータを強制的に最新化するという機能を追加しても良さそうです。

ここでVue.jsのデータフローによりデータを更新しさえすれば0実装で簡単にツリーを再描画できることと、Virtual DOMによって差分のみ再描画されるというエコな仕組みを利用できるのが最高ですね。

フィルタリング処理

inputとのデータバインディング方法は onInput時にイベントハンドラで event.target.value を取得してStateにセットします。

ページをフィルタリングするUIのイメージはGithubのファイル検索UIです。検索はどうやって実装されているかよくわからなかったし、調べてもないのですが「多分こんなかんじじゃね」で作ったものが意外と使い心地が良いので特に深入りしていません。

a b と入力されたら a.*b という正規表現を作成して取得できるgetterメソッドをStoreに作成して各TreeNodeコンポーネントで取得して、合致していればtrueそうでなければfalseを v-if してあげます。実装のことを説明するとだんだん日本語が喋れなくなってきますね。要は、入力した順に部分一致してればいいんでしょ、というノリで作りました。

気になったのは数百のコンポーネントが入力値をsubscribeしており、そのフィルタリング処理がUIスレッドで行われてしまっていることで、入力イベントに応じて一気に判定処理を始めるので一瞬処理が固まってしまいます。この体験が悪いのでなんとかしたいなぁと思うのですが、普段からUI周りを触っていないことからすぐにはいいアイデアが出てこないのが残念です。コントリビューションに期待しています。いちおう、inputイベントはlodashのdebounceで間引きしてはいます。

また、クエリにマッチした部分を太字にしたいけど、これは後の改善モチベーションやコントリビューションに期待します。

ツリー開閉処理

単純にTreeNodeオブジェクトでクリックイベントをハンドリングしてtoggle状態を切り替えれば良さそうです。

• v-ifで子ツリー要素の表示を切り替える
• 開閉ボタンのclass要素を切り替えて中身のシンボル + - をCSSで変える

あとは、階層の下の方のページを開いたときにツリー上のどこに存在するか確認するために、親までさかのぼって開いてあげる処理を実装しました。 今回はコンポーネントがマウントされた際に実行されるmountedメソッドで、そのコンポーネントが表示対象だった場合に親コンポーネントに openChild イベントをemitするということで実現しました。そうすることで「逆再帰的」に親にイベントが伝播し、やりたいことが少ないコード量で実装できたのでなかなか気持ちよかったです。

jp.vuejs.org

ほかのライフサイクルイベントでもっと効率的に処理できるのであればmountedでの実装を見直せるかもしれません。

jp.vuejs.org

ツリーの開閉とフィルタリングの関係

各ページの表示状態はツリーの開閉状況とクエリどちらに依存すればいいのかという問題が出てきました。ここでどういう試行錯誤とをしたのかあまり覚えてはいないのですがこういう感じで実装しました（あくまで暫定の仕様ではありますが）

1. クエリ入力中はクエリに一致すれば表示する
2. クエリが入力されていなければ親コンポーネントが子コンポーネントを開いているかどうかに依存する

上手く言語化できませんが、なんとなくこれが自分的には釈然としたのでこういうふうにしています。

この仕組みをハックすれば

1. ある親要素をクエリで検索する
2. その要素の+ボタンを押して開く
3. クエリを削除する
4. 2のサブツリーだけが開いている状態にする

ということができます。良い仕様があるかもしれませんが、それも今後のコントリビューションや自分のモチベーションに期待しようと思います。

最後に

ちょっと身の回りをハックするツールを作るとき、直感に従って対してその仕様意図を言語化せずに作ってしまうことが多いのですが、今回こうして言語化してみると意外と多くのことを考えていたのだと気づけました。同僚や部下で「改善アイデアがなかなか出ない」という人の相談に乗ることがたまにあってあまり上手な返答ができなかったのですが「なにかにペインを感じたらそこがスタートになる」ということと「直感で感じたペインを風化させずに真正面から取り組む」ということを伝えていけるのかなという気がしました。

とくにペインというのは意識しなければ多くの場合見過ごしがちで、他の代替手段で根本欲求がかき消されてしまいます。そのペインのシグナルを逃さずキャッチするというのは、ある程度訓練が必要なことかもしれません。自分は「感じる」「考える」というのを区別して捉えているのですが、直感レベルで感じたことをしっかり言語化（自分の場合は即プログラミング言語化でしたが）するということが大事だと思います。

普段からアウトプットする習慣が身についていないのに急にこの記事をアウトプットしたのもなにかの直感なのだと思いますが、おそらく「思った以上に出来が良かった」「そのプロセスを知ってもらって参考にしてもらいたかった」というモチベーションなのかもしれません。ちょっと有頂天気味なので、想定外の突っ込みがあると急に恥ずかしくなって拡張の提供をやめてしまうかもしれないのでお手柔らかにお願いします。

実務でフロントエンドの実装に携わることが無いので趣味でこの拡張を作る前にVue.jsを覚えたのですが、UIをコンポーネントとして捉えることがとても自然で生産性の高い開発方法だと気づくことができました。もともとネイティブアプリがコンポーネントとしてUIを実装するというアプローチだったと思うのですが、Vue.jsではさらにstateやcomputedといった仕組みが導入されていて、これはこれで大変便利です。それより前の既知の言葉で言うと「データをpub/subしている」つまりデータの変更にUIが「反応する」というアプローチの強力さに感動しました。

本当にUI系の界隈には不勉強で辛いのですが、たぶんReduxから始まったこういうアーキテクチャがネイティブアプリにも良い影響をもたらしてReactNativeが活発になっているんでしょうね（適当）

Slackのスレッドのつらみ11選

2021/03/24追記

ちょっと前に、久々にアクセス解析を見てみたら以下の記事からリファレンスして頂いていました。どうも読んでみると、同じことを感じた方が私の記事にたどり着いて、紹介してくださったそうです。内容の善し悪しには別として（実際に以下の記事に批判されているので）、共感を呼んで引用して頂けるというのは嬉しいものですね！

qiita.com

で一方、公開している記事を批判されるということも初めての経験でしたので興味深い体験でした。ただ、申し訳ないのが時間が経ってSlackも私も記事の当時から変わってしまい、私自身がスレッドをバリバリに使うようになってしまっていたということです。ということで、すいませんが上記記事は査読していないのが正直なところです。

話を戻すと、今のSlackのスレッド機能やその周辺からは多くのストレスが解消されており、今では全然つらみを感じません。これ、ほんとに素晴らしいことですよね！上記批判記事でも述べられている通り、私もこの記事を改善要望として投稿したので、（実際に・直接Slack社員に声が届いたのかは定かではありませんが）なんらか愛するプロダクトを良くする一助になれたのかもしれないと思うと嬉しいです。

以下、元記事

個人の意見で〜Slackには感謝しており〜みたいな余計なマクラは省略します。良識のある人だけ読んでください。

プロローグ

僕はSlackのスレッドがあまり好きではありません。そのせいで毎日ちょっとずつストレスを感じています。

しかし、スレッドというアイデアが嫌いなのではなく、 スレッドをサポートする機能があまりに不完全だからです 。Slackはスレッド機能が搭載される以前の仕様とスレッドを完全に統合しきれていなく、便利さを上回る不便が多すぎるのです（当社比）

そのような状況では、 スレッドじゃなくても事足りる会話はスレッドを避けて 使いたいと思っています。スレッドは、会話が同時多発して会話の整理がつかなくなったタイミングで初めて使えばいいんじゃないかと思っています。

👍スレッドのメリット

前述の通り。スレッドというアイデアは好きです。

• チャンネル内の会話を整理できる
• 同じチャンネルで複数の話題を同時並行できる
• スレッドは「チャンネルを作るまでもないサブトーク」を行う手段
• メンションしなくても相手に返事ができる

👎 スレッドのデメリット

スレッド機能にはいくつかのデメリットがあります。個人的にイライラすることをイライラ度順に挙げてみたいと思います。

1. [解決済み] 通知が激しい
2. メッセージが埋もれる
3. 参加してないけど気になるスレッドの更新に気づけない
4. チャンネルショートカットで探しにくい
5. スレッドを開くのにマウス操作が必要
6. モバイル版ではチャンネルとスレッドを同時に表示できない
7. スレッドを開く処理が遅い
8. 他のメンバーがUnfollowしたことに気づけない
9. 返信しづらい
10. ファイルを添付しづらい
11. スレッドの下書きがDraft一覧に現れない

1. [解決済み]通知が激しい

※同僚からのアドバイスで、以下の設定でスレッドの通知を無くすことができました。感謝。

スレッドの中でメンションされたメンバーは、スレッドに新規投稿があると通知が届きます。「対応しました」「了解しました」のような大した情報じゃない場合、 本当に相手に通知が必要なのか？ を一瞬だけ立ち止まって考えてもらいたいと思っています。

⚠スレッドはリプライではありません⚠

⚠スレッドはリプライではありません⚠

⚠スレッドはリプライではありません⚠

X replies って書いてあるからリプライなのはそうなんだが。という気持ちです。

スレッドを使わなくても、自動で展開されるリンクを共有したり「Share message」を使って返信を表現することもできます。一つ二つ前のポストであれば、わざわざ引用しなくても返事をしていることは自明でしょう。

Slackの良いところは、通知のカスタマイズ性が高いことです。通知が沢山来ても気にしない人には無用なことでしょうが、同様に重要な情報以外は通知を受け取りたくないという需要も存在します。普段からメンションが多く、一つ一つの通知に神経を尖らせざるを得ないような人です。僕は後者のタイプで、作業の瞬間的な合間を縫って自分のタイミングで未読をキャッチして返信します。

しかし、 スレッドはメンションが無くても半ば強制的に通知を送る ことから、通知のカスタマイズ性を損なってしまっています。これは送る側には意識しづらいことなので、通知される人のことを少し意識すると良いでしょう。そうすればチャンネルポストで良いという選択肢も生まれます。

極端な例ですが、例えば会社の @engineers というグループメンションは数十人もいるので、そのメンションの付いたポストでスレッドを生やして会話を続けるとどうなるか、もうお分かりかと思います。（@engineers をクリックするとそのメンションで通知が届く人数がわかる）

なので、人数が多いメンションには直接返信せずにチャンネルで返信して、そこで初めてスレッドを生やすのがお作法としては良いでしょう。

また、100も200も返信が付いて、多くの人を巻き込むような会話は、途中で通知が必要なくなる人も出てきます。そういう場合は新しいチャンネルを作ったほうが良いです。

2. メッセージが埋もれる

こういう 3 replies という返事がいくつか付いたポストをよく見かけますが、中を覗いてみるとひっそりと有用な会話が繰り広げられていることがあります。

感度が高い人はスレッドをわざわざ開いて情報を拾ってシェアしますが、興味深いスレッドを嗅ぎ当てて開くというコストはチリツモです。会話が全てスレッドだらけになってしまったら、一日何度もスレッドを開くという作業をしなければいけません。

また、スレッドになった時点で垂れ流し（=未読チャンネルを開けば目に付く）ではなくなるので、スレッドをいちいち開かない人には見えない情報となってしまいます。有益な情報が情報感度や共有力が高い人にしか伝わらないかもしれません。「沢山の人に情報を届ける」という意味でも、むやみにスレッドにしなくていいと思います。

個人的には、大量の情報が自分のタイミングで自然と視界に入る状態は良いと思っています。視覚の処理能力は非常に高いので、文字の形や並びから文脈を感じる（≠理解する）ことができるからです。

そのような状態を維持するために、敢えて情報を隠すこと無く、堂々とチャンネルで会話してほしいと思っています。

3. 参加してないけど気になるスレッドの更新に気づけない

これはメッセージが埋もれてしまうことから生じる結果でもあります。

最初から参加してないけど気になるスレッドがあったり、通知がウザくてスレッドをUnfollowしたけどその後が気になる会話ってありますよね。スレでディスカッションが始まっちゃって、しばらく静観したいときとか。しかし、参加してない未読スレッドをたどるショートカットは無いので、スターを付けておくか、チャンネルを遡ってスレッドを開くしかありません（一度でも参加していたスレッドならThreadsから辿れます）。つまり、 スレッドの未読はチャンネルの未読よりも気づきづらい ということです。

それでふとスレッドが伸びていることに気づくと、アドバイスのチャンスを逸したせいでみんな間違った方向に試行錯誤している。または、渾身のおもしろ画像を貼り付ける瞬間を逃してしまっていた。そんなガッカリを逃したくはありません。参加していないスレッドをFollowすることもできますが、最初から興味のある話ではないこともあるので、不要な会話の通知を受けて集中力を失いたくありません。

チャンネルに投稿していれば、定期的に未読が付いたそのチャンネルを見に行けばいいだけなのです。

4. チャンネルショートカットで探しにくい

⌘ + K使ってますか？（WindowsはCtrl+K）マウスを使わずにチャンネルを探せるキーボードショートカットです。かなり頻繁に使うので、覚えておいて損はありません（ショートカットの一覧は ⌘ + /で確認できます）。

ところで、このショートカットは読むべき未読が優先的に上に表示されるのですが、なぜだかThreadはこのリストに表示されません。ショートカットで探す場合は最低でも「th」は打ち込まなければいけないし、「th」は結構打ちにくいのでスレッドを開くのがいちいちストレスです。日本語化している場合はカタカナの「ス」を打ち込まなければいけないのです。これもSlackに改善して欲しい上位に入ります。

という理由もあって、スレッドをむやみに乱立させてほしくないです。

「戻る」「進む」ショートカットの対象外

⌘+[ 戻る / ⌘+] 進む ←このショートカット使ってますか？チャンネル間を高速で行き来して様々な事象を感じる（≠理解する。2回目。）のにこのショートカットは必須です。

しかし、 このショートカットはチャンネル単位の遷移にしか対応していない のです。右側にスレッドを開いたまま、他のスレッドを開いて、さっきのスレッドに戻るために半ば反射的に⌘+[をタイプすると… チャンネルが一つ前に見ていたものに戻ってしまうのです。

進行中のスレッドがたくさんあると当然行き来が増えるのに、ショートカットが対応していないせいで甚大なストレスを感じながらスレッドサーフィンしなければいけません。

このような無用なストレスを減らすためにも 「スレッドにしない」という選択肢 もアリなのではないでしょうか？

5. スレッドを開くのにマウス操作が必要

チャンネルサーフィンには先述のように便利なショートカットが存在し、簡単に慣れてしまい気づけばキーボードから手を離さずに操作できるようになります。

しかし、未だスレッドには大したショートカットが存在しません。3 replies をクリックするか、ショートカットでThreadsを開いて遡るしかありません。チャンネルを巡るのにはいくつかの簡単なショートカットを覚えるだけで良かったのに、スレッドのせいで一度キーボードから手を離す必要があるのです。

不要なスレッドさえ無ければ、こんな煩雑さは味わわなくて良いのです。

6. モバイル版ではチャンネルとスレッドを同時に表示できない

モバイル版のSlackでは、チャンネルをスクロールして眺めながら気になるスレッドを開く必要があります。すると、チャンネルは表示されなくなります。そのスレッドに至るまでの文脈をおさらいするには（Androidでは）戻るボタンを押す必要があります。

チャンネルであれば上にスクロールすれば良いだけなのに、チャンネルの情報を追うために通信をしてまでスレッドを開き、他のポストを追いかけ直すために何度も戻らなければいけないのです。

通信環境の悪い場所でローディングを経て表示されたスレッドに「うける卍」としか書いていなかったとき、どう思いますか？（そんなスレッドは見たことがないけど）

7. スレッドを開く処理が遅い

チャンネル移動よりもスレッドを開く処理は明らかに遅いです。モバイル版は（？）通信処理が挟まるので、なおさら遅いです。一日に何十回もスレッドを開くので、この遅さは無視できません。なのに、通知が来てせっかく開いて「了解です！」みたいな大した情報量もないときの残念さといったら…。

急ぎじゃないならチャンネルにポストしましょう。

8. 他のメンバーがUnfollowしたことに気づけない

通知の仕様理解を誤った故に通知爆撃が届き始めたら、Unfollowボタンで通知が届く本人の意志で通知を止めることができます。

しかしながら、Unfollowしたことは他の人には分からないので、スレッドで会話をしている人はあなたがまだそこにいると思ってしまうでしょう。これは認識の非対称を生むのであまり好ましくありません。あなたが通知爆撃から解放された安堵と引き換えに、誰かの「読んでくれているだろう」という期待を知らずしらずのうちにないがしろにしてしまっているかもしれないのです。

これはスレッドの改善して欲しいポイント上位に入る不便ですが、Unfollowしないといけない状況を避ける、つまり スレッドを避ける努力 も望まれます。

9. 返信しづらい

僕は横長ディスプレイを右側に配置しているので、右の最果てを見ながらタイプしています。すると首が痛いんです。「ディスプレイを左に置けばいいじゃん？」と思うんでしょう？でもディスプレイ配置はSlackのためだけじゃないんですよ！！！！！（憤死）

また、モバイル版Slackではチャンネルとスレッドを同時に表示できないので、スレッドにいくつか過去の発言を引用したい場合は

1. 過去の発言のリンクをコピー
2. スレッドに戻って返信したいメッセージを探す
3. 入力欄に貼り付ける
4. 戻る
5. チャンネルを検索する
6. 遡ってメッセージを探す（1に戻る）

という大変に時間・集中力を必要とする作業が必要になります。以前はスレッドの下書きメッセージが消えてしまうことがあったので、更に不便でした。

（しかし、よく考えれば直接スレッド返信フィールドを使うよりもメモ帳を使えば少しは楽になりそうです）

10. ファイルを添付しづらい

スレッドは、スレッド一覧を開いた時だけファイルをドロップできないんです。

右ペインにスレッドを開くには、一度スレッドからチャンネル名をクリックして 3 replies をクリックして右側にスレッドを開き、首を右に傾けながらファイルをドラッグ・アンド・ドロップしないといけないんです。しかも、僕の場合はデスクトップのファイルが見えるのは左側のディスプレイなので、ドラッグ距離が長いんです。

そもそもSlackを使うのにキーボードから手を離したくない。ファイル添付だけならいざしらず、ちっこいリンク文字にカーソルを当てるという極限集中作業を2回もしないといけないのはなぜ？ それはスレッドを使っているからです。 不要なスレッドさえ無ければこのストレスはないはずなのです。

11. スレッドの下書きがDraft一覧に現れない

Slackには、チャンネルに投稿していない下書きメッセージがあると「Drafts」という項目に現れる仕様があります。

しかし、まだスレッドにはこの仕様が統合が行われていないのでしょう。渾身のギャグを投下するために画像探しの旅に出てその間に他の用事で忘れてしまい、他の誰かが対して面白くないギャグでバカウケしていたとしたら、悔やんでも悔やみきれないでしょう。

うん。このへんは重要じゃないのであまりイライラしない。

まとめ

スレッドの機能コンセプト自体に文句はありません。しかしながら、スレッドをサポートする機能の数々には改善が望まれます。

1. [解決済み]通知が激しい
2. メッセージが埋もれる
3. 参加してないけど気になるスレッドの更新に気づけない
4. チャンネルショートカットで探しにくい
5. スレッドを開くのにマウス操作が必要
6. モバイル版ではチャンネルとスレッドを同時に表示できない
7. スレッドを開く処理が遅い
8. 他のメンバーがUnfollowしたことに気づけない
9. 返信しづらい
10. ファイルを添付しづらい
11. スレッドの下書きがDraft一覧に現れない

また、Slackはチャンネルの出入りが自由だったり拡散しやすいという仕組みから 情報をスムーズにする というコアなコンセプトがある（と思う）にも関わらず、スレッドの使い方次第でそのコンセプトから逆行してしまうのも、気になる点の一つです。

スレッドの本来の使い方は「チャンネルを作るまでもないサブトークを行う手段」だと思います。同じチャンネルで複数の会話が同時進行し初めたとき、または、予め長い会話が予想される場面で「〇〇スレ」と名付けておくと、有効にログが残せることが多い気がします。ライブ議事録や勉強会・障害実況など。

一方で、スレッドというのは本当に難しい機能で、通知設計やショートカットによるナビゲーションまで含めたUIが大変に設計しづらいものだと感じました。その要因は以下のようなものだと感じました。

• チャンネル名のように、ユーザーが指定できる識別子がない。
• 同時多発的に自然発生するのですべてを追うのが不可能。
• invite/join/leaveが暗黙的なので通知の基準を設定しづらい。
• PCではチャンネルタイムラインと同列に共存してしまう。

革新的なアイデアを出してSlackメンバーの参考にしてもらおう、と思ってもなかなか解決策が出てこない難問です。自分ができるのは、ペインをより生々しくフィードバックすることかなと。

Slackメンバーの皆様、日々Slackを便利に使わせていただいており、応援しております！ これからも頑張ってください！

考え始める勇気

日報や議事録のTODOにある「どのようなことをすればよいか調査する」のような一文にモヤモヤを抱いたことはないでしょうか？ 最近、やっとこのモヤモヤを言語化することに成功しました。

これはズバリ 「誰でも分かる方向性だけ示して具体性がない」 ということだと思います。

方向性というのは割と誰の目にも明らかであり、「調査する」ことに異論は無いはずです。しかし、そのみんなが知りたいのはその具体的な調査内容や調査結果なので、あなたが先陣を切るのであれば「〇〇ができるかどうかを調査する」の〇〇をできるだけ具体的にすべきでしょう。

では、なぜ「どのようなことをすればよいか調査する」と、誰でも分かることを言ってその場を濁してしまうのでしょうか。

人間というのはわかりきっていることをするのは簡単なので大好きです。一方で、まだ何をすればよいか分からない・成功するかどうかも分からない不確実なものは非常に億劫に感じられるのです。そんな億劫に感じる自分を自覚して克服できなければ、可能な限り長くうやむやに放置してしまいます。頭を使うことが大きなコストに感じられるから、一見まっとうに見える事を言ってやり過ごしているだけなのです。それが「どのようなことをすればよいか調査する」の正体だと僕は思います。

一方で、進捗を期待する他者にとってはより具体的な方向性が見えていないと不安ですし、信用して任せることができません。鋭い人は「何をどう調査するの？」と追求してくるでしょう。そのようにお互いストレスを抱えたくなければ「考え始める勇気」を振り絞り、頭を使って方向性を具体的にしましょう。

そうすれば、信用してもらうだけでなく、有益なアドバイスをもらうこともできて一気に物事が加速するようになるでしょう。

方向性を具体的にする・しっかり考えるということを終えた後に気づくことがあると思います。

それは意外と簡単だった ということです。

しかし喉元を過ぎればの逆で、次に同じシチュエーションに遭遇したときには「めんどくさそう・・・」と思ってしまうのが常です。

では、この「めんどくさそう」「意外と簡単だった」の正体を図解してみましょう。

考え始める前には考えること自体が億劫で、大変な作業だと思っているかもしれません。そして先延ばしにして期限に迫られて実際に考えてやってみると意外と簡単だった。

これは結果だけ見れ先延ばしにしたぶんの時間はただの「考えたくないというストレス」だったということになります。しかし、この無駄さえなければ他のメンバーにどれだけの時間が生まれたでしょう。

もちろん、このような経験が身に沁みるのは極限状態に置かれて有無を言わさず考える・実行するの連続を経て体（脳筋？）がクセ付けされて初めて体験として覚えることだとは思います。しかし、できるだけ早くこういうテクニックを身につければ、簡単に仕事量を何倍にも伸ばせるような気がします。

「考え始める勇気」を持てば、自分にも周りにも多くの時間を生み出すことができ、それがひいては大きな生産性につながるのだと思います。

メッセージに色を付ける

2つの封筒が届きました。

どちらのほうがメッセージをより強く感じたでしょうか？言わずもがな、後者でしょう。

• 期限までに納付してなかったんだ😱
• やばい、納付しないとまずい😣

さらに、メッセージのほぼ全てが伝わったところで、次にすべきアクションを想起させられるでしょう。 早く中身を確認して、取るべきアクションを明確化させるパワーが後者にはあります。

• 期限すぎると罰金とかあるのかな？💸
• 期限とか、振込先は書いてあるかな？
• 税務署に行かないといけないと、行ける時間が限られちゃうな・・・

仕事上のメッセージ

あることを伝えたくて、それについて詳しい文献を見つけ、チャットで共有しました。 このリンクCTRは果たして何%でしょうか？

つ https://docs.ruby-lang.org/ja/latest/class/Array.html#I_FLATTEN

多少ゆとりがある時でなければ、開こうとは思わないのではないでしょうか？ ただでさえ業務は毎日多忙。その中でもしかしたらロードの遅いページなんかだとイライラして最悪です。

では以下だとどうでしょう。何を伝えたいのかコアメッセージが抽出されています。

Array#flatten の使い方

flatten は自身を再帰的に平坦化した配列を生成して返します。 lv が指定された場合、lv の深さまで再帰的に平坦化します。 https://example.com/article/12345678

内容に興味を持ってくれ、その人が抱える課題にミートすることが分かれば自然とコアメッセージの周辺まで興味を持って読んでくれ、あなたが伝えたかったメッセージを十分に咀嚼してくれるのではないでしょうか？

もう一つの例。「○○について」はよくありがちなメールやドキュメントのタイトルです。 このタイトルからどのようなメッセージを受け取るでしょうか？

2019年度健康診断について

では次に、以下のようなタイトルではいかがでしょうか。

【9/11 18:00〆切】【所要3分】健康診断の希望日時アンケートの回答をお願いします

先程のタイトルが視力0.3の視界だとすれば、視力が1.5くらいに上がった気がしないでしょうか。

発信者がコストを負担する

ここまでの例は、タイトルの通り「メッセージに色を付ける」ということの例でした。 しかしもう一つの大事な側面は、発信者がコストを負担しなければ、メッセージには色が付かないということです。

こと教育という観点では教える側はすでに知っている情報をわざわざ再言語化することは直ちにはコストです。「教えてもらう側が必死に吸収すべき」という努力の期待もあるでしょう。

しかし、教育の本来の目的が、スキルや知識を伝搬することによって能力をスケールさせることがであれば、効率よく伝わることが総合的に最もコストの低いスケーリング道ではないでしょうか。抜粋を加えたり、タイトルをちょっと長くするくらい、読み解く方のコストからすれば安いものです。

もちろん、情報を提供される側は、期待された程度・あるいはそれ以上の吸収を望まれているわけなので、こうした工夫にかけられたコストに感謝すべきなのは言うまでもないでしょう。