Twitterのアレから考える「お気に入り」のあれこれ
140文字におさまらなかったのでブログに書くの巻
Twitterで「お気に入り」つける行為について、ふぁぼるとかそういう名称で長らく呼ばれてきた。
kw-note.com
これは2015年には お気に入り / Favorite が、いいね / Like に変わりました。
www.02320.net
Twitterは個人的に前々から
過去にふぁぼった/いいねしたツイートを遡るのがつらい。
と思っている。
変遷もありつつ、あの機能っていろんな意図（気持ち）で使われてると思ってる
- （あとでリストから見るのに）お気に入りする/いいねして自分のところに「溜めて」おく
- （あとで見返さない）「見たよ」のリアクションを相手に送る
- FB的な感覚
- （あとで見返す/見返さない関係なく）「うーん面白いからこういう話今後もしてくれ！b」のエールを相手に送る
- 単純に「同意」の意を相手に送る、の方が正しいか。
- （あとで見返す/見返さない関係なく）煽りとしてリアクションを相手に送る
パッと思いつくのを列挙してみる。
自分では2つめの「見たよ〜」でぽちることはないけどとにかくそれぞれに使いたいようにハートマークを押しているはず。
で、自分がTwitterを使う上で過去自分がふぁぼ/いいね押したツイートって結構な頻度で見返すのだけど、
日にかなりの量を溜めているのであとで「アレの話でいいねしたやつどれだっけかな...」と遡りたいときに多すぎてつらい。
目的のツイートまで辿るのに他のも満足しながら見返していつの間にかかなり時間経ってた、とかめっちゃある。
ふぁぼ/いいね一覧を見返しやすくするにはどうすればいいのか？
考えた。
- いいねするときにカテゴリ別に溜めておけるようにする（「経済」「技術」とか）
- その吟味する一手間が惜しすぎる。 ブラウザでブクマするときでさえ「後でいいや」ととりあえず適当なフォルダに突っ込んでしまう自分...
- 月別で見れるようにする
- 今よりUIが複雑になるよなああ〜〜 多少今よりは複雑になってしまう、でもUXを高めるのにはどうすれば良いのか。すごく難しい。
・・・良い案が浮かばなかった。
そういえば、（TwitterはSNSカテゴリだが）他の「お気に入り」「いいね」機能のあるアプリはお気に入りを溜め込んだあとどの程度表示方法をカスタマイズしたりできるんだろうと見てみたけど、
- メルカリ
- 商品を登録
- 登録した降順に表示されるのみ
- 商品を登録
- Retrip
- 記事を登録
- 登録した降順に表示、検索窓からタイトル・記事中の本文を全文検索することが可能と思われ
- 記事を登録
- ZOZOTOWN
- 商品を登録
- こちらも登録した降順、カテゴリや値段でのソートは不可
- 商品を登録
ざっと3つのサービスを見てみたけど、やはりどれも特別カスタムできるようにはなっていないもよう。
後追いでカスタムできるように機能改修するにも、初めから改修を見越してデータのあり方を考えるのもうーんという感じだし、そもそもココを改修して何が得られるの？ってのを見出すのが、（自分以外の目線で考えて）難しい。
でも今日びどんなサービスでもこの「お気に入り機能」って存在していて、初めて出会ったユーザにそのサービスを継続して利用してもらうための「とっかかり」の役割も担っているはず。
そういう 今あたりまえに存在してる 機能を どう突き詰めていくか、サービスの独自性を出していくか っていうの、重要な視点だよな〜というこの頃。
ほんとは何の気なしに当たり前に使ってるところでもグロースハックのヒントは転がってる・・・！という意識は持っておかないとな〜。
...書き初めから二ヶ月近く寝かせてしまった。
builderscon tokyo 2018 に行ったよ
builderscon tokyo 2018 に行ってきた。
builderscon.io
びるこん、一番最初のセッションが分からなすぎたので（これはやはりアカンかったか…）と挫けそうになったけどちゃんと頷きながら聴けるものもあってよかった…
— hikari (@_ave_h) 2018年9月7日
全体の感想は後ほどとして、いち参加者としてかなり満足度の高いカンファレンスでした。
書きたい時が書き時だ！ということで聴いたセッションについて自分なりにまとめた内容や感想を。今回は以下について。
デザイナーとうまく協働する方法
Yasuhisa👨💻 (@yhassy) | Twitter さんのセッション。
昨今の「デザイン」を取り巻く状況
UI/UXデザイナーの需要は昔に比べて今後もどんどん高まっていくだろうこと、しかしデザイナーは業界的に（慢性的に？）不足している状況。
デザイン投資するとこんなに儲かるんですよねというのも結果として出ている。
- 雇用も変わってきている
- 需要も高い
- 経営者も「デザイン経営」宣言してたりする
まさにこの世は Design Changes the World ・・・
でもデザイナーと他職種（エンジニア、営業）での認識の違いだったり、デザインの解釈の違いで距離感生まれることはよくある。
例えば「デザインは重要です」という一文をとっても、
- デザイン
- どのくらいの範囲を指すの？
- 重要
- 誰にとって、どう重要なの？
- 営業にしたら自分の儲かる範囲までなの？
とか受け取る人によって違う。
こういう discommunication はよく発生する。
どうして距離感が生まれてしまうの？
- エコーチャンバー現象に気づいていない*1
- 「デザイン」はデザイナーの中にあるという思い込みとか、当たり前という先入観
- 「察して欲しい」という受け身の態度
よくあるのとして上の3つとかがある。
同じ職種同士で意見を交わせるのみで閉じてしまっていて、そこから発展しない。「デザインはデザイナーが決めて」というお互いの範疇に入り込もうとしない。
デザイナー×エンジニアで意見を交わしても、「こちらはこれだけやった」という努力を認めて欲しいというコミュニケーションになってしまい、チームがバラバラになる。
そのような状況だとどんな新しいツールとかを使っていようがすれ違いが生まれてしまう。
どうすれば良いのか？
デザイナーでもエンジニアでも、「良いモノを作りたい」という仲間であるというのは一緒であって・・・
すれ違いを生まない、協働のためにできることは「言語化」と「明文化」。
それだけ言うと「やってるよ！」と思う人が多いけど、あくまでそれを「どのレベルまでやるか」が重要。
言語化
「言葉を合わせる」こと。
例えば某アプリのような、料理レシピに対してお気に入りをつけるようなアプリを作るとして、
料理のレシピを作るような”料理人”はプロダクトでどう表記する？英語表記はどうする？
デザイナーとエンジニアで論議の際に飛び交う言葉を合わせておかないと、それを翻訳する作業が必ずどこかで発生する。効率も悪い。
対エンジニアとしては、システム設計の際のモデリングをするときに、エンジニアだけじゃなくちゃんとデザイナーを呼び込んで議論することも大事。
デザイナーには「モデルとユーザを考慮したデザインを作る」という、モデリングをした上でデザインをして欲しいと伝える。
言葉あわせのためのモデリングも重要。
この辺、同業種に発信するのは簡単だが、異業種に対しては同じようには行かないということや
- 自分の独自言語で話してないか？
- 自分が発信している言葉は外に言って伝わるのか？
という内容も話されていて超わかる！！・・・と頷きながら聴いてた...。
また、使うユーザから見えないようなガイドラインにない言葉が飛び交うのも良くない。開発・デザイン以外の視点も考慮する必要がある。
そして互いにUIや機能の捉え方を共有・学習するのも、認識の溝を埋めるのに大事なこと。
yasuhisa.com
紹介されていたこちらの「要素名クイズ」、面白いなーと思った。
現場においてそれは正しいのか、業種を超えて認識をすり合わせするのは大事・・・。
議論があさっての方向に向かってる・・・って時も、言い方が違うだけで実はやってるのが同じってこともある。
あとこれめっちゃあるあるっていうか「そうだな」と思ったのだけど、
よく飛び交う「かっこいい」ってなに？「イケてる」ってなに？みたいなニュアンスの共有 大事。
チームにおける「良い」ってなに？を共有する。
せめて自分たちが何を基準にそれを言っているのか？はちゃんと言葉にしよう。
明文化
デザインの評価をする際、言語化された「言葉」から原則を作り、価値に基づいた評価をすることが重要とのこと。
- 課題を解決しているかどうか
- ユーザへ提供する価値は何か
- プロジェクトメンバーが納得できる施策か
それをスムーズに評価できる状態に持っていくために、
例えば「これはどうですか？」みたいな感じでいきなり成果物をエイヤ〜と出すのは良くない。
ちゃんとどうしてこういう成果になったのか？を残すこと。
「かっこいい」「イケてる！おk！」で決めるのではなく、課題解決に議論をシフトさせるために
どうシフトしてこういう結果になったのか？理由をちゃんと説明してもらって、徹底的に議論をするようにしよう。
エンジニアがシステムのドキュメントを残すのと同じで*2、明文化はデザイナーも必須。
自分たちの思考プロセスをちゃんと共有して、お互いの溝を埋めていく。
上に書いたように自分も言語化・明文化「やってるよ！」と一見思いはしたけど、それでもこうやってデザイナーの目線から聴くとまだまだ考え直して取り組まなきゃいけないとこ多いなぁ、と頷きながらのセッションだった。面白かった。
ちょっとカンファレンス自体の感想
こういうカンファレンス、今まではPHPカンファレンスくらいしか行ったことがなくて
仕事でやってる中で久々に大きなお祭りに参加してみたいな〜というのと風を取り込みたい（ニュアンスが雑）という気持ちがありワクワクドキドキしながらの参加だった。
自分が聴きに行って話分かるんだろうか・・・と尻込みしてて不安なところもあったけども。
2日行ってみてセッションも楽しく聴けたものが多かったし、会社の人がスピーカーとしてどう話してるんだろうというのも聴けた（見れた）し、主催側・スポンサー企業のイベントに対するホスピタリティも感じられて良い時間だった。
良い雑誌に出会った
実家に帰省し2日目。お盆最終日。
なんか長野の山の方までドライブしてそこでお蕎麦とか食べたいね〜となり出発したのだけど、
警報が出るくらい次第に雨が酷くなってきてもう周りも真っ白で何も見えない状態になってしまったので途中で引き返し、長野ではなく黒部のお蕎麦屋さんに入った。
鴨せいろしかも十割蕎麦！！！
とてもおいしゅうございました。（量多いけど天ぷらは2人で食べてるしノーカン！）
で蕎麦を待っている間店に置いてある雑誌を読んでいたのだけどこの雑誌がとても良かった。
雑誌・書籍の新刊情報 | エイ出版社 発行の PEAKS 。
これは登山専門誌で、私は登山好きかというと2年に一度くらいのペースで父と立山を登る程度でしかないけど
それでも山を見ることだったり、山頂から遠くを眺めてあの高揚感を味わうのはとても好き。
登山のノウハウもそうだけど山の良い写真をたくさん眺めることができるなんて最高じゃん・・・と、読むだけでわくわくする雑誌だった。
表紙から良い。
雑誌好きでジャンル問わずわりと読むのだけど、自分にドンピシャな良い雑誌に出会えることって良い人に出会えることと同じ位すごく幸せな体験だと思う。
とりあえず読んだこの2号はとても良かったので即Amazonで購入した。
うーん、読んでたらますます山に行きたくなってきたので10月くらいにスケジュール組んで槍ヶ岳登りたいなー。
夏の終わりのよき出会いでした。
memcached, Redis 何をどう使う
情けないことに、最近までRedisについてちゃんと知る（知ろうとする）機会がなかった。
自分が開発しているアプリケーション上でこれまで使ったことがないはずはないと思うのだけど、Redis? あーあれ memcached と同じようなやつなのか〜完〜 で閉じててそれ以上深く知ろうとしなかった。
まとまってる記事は山ほどあるのだけど共にKVSである memcached と Redis について改めて特徴と比較。
そもそもの話
この2つはNoSQL（Not only SQL）と呼ばれるもの
memcached
- データのレプリケーションが行えない
- GET/SET等のシンプルな操作が可能で、ディスクへの書き込みは行わない
- Expired（有効期限）を設定可能
- が、メモリが指定された容量に達すると、LRU（Least Recently Used）に基づいて利用されないキャッシュから古い順にデータが自動的に削除される
- データはメモリストレージに貯められる＝全てメモリ上にのみ存在するのでDBやOSの再起動を行った際に全てのデータが削除される
- つまり障害発生時に吹っ飛ぶ可能性高い
- 永続化についてあまり考慮されてないのは memcached 自体キャッシュのためのサーバとして設計されているから
- 文字列型しか扱えない
Redis
- データのレプリケーションが行える
- ディスクへの読み書きが可能
- Expired（有効期限）を設定しない限りは削除されない（古いデータを自動削除されない）
- データの永続化が可能
Redis でのデータ管理方法は以下の3つがあるが、下の2つで Redis を再起動してもディスクからメモリにデータを読み込み直すのでデータの永続化が図れるというもの。- メモリでデータを管理する
- 特定のタイミングでデータをディスクに保存する（snapshot機能）
- 書き込み操作を随時ディスクに保存する
- 文字列/セット/リスト/ハッシュ、幅広く複雑な種類のデータが扱える
- master/slave構成
ところでKVSは、
メモリ上にデータを格納するもの：揮発性KVS ディスク上にデータを格納するもの：永続性KVS
と分類される。
memcached と Redis は両方揮発性があるとしてKVSに分類されるが、Redis はディスク上にバックアップが可能でもあるので揮発性＆永続性を兼ね備えてるといえる模様。
比較して
だいたい memcached ができることは Redis もできるよという印象だが、
ユースケースや規模が事前にきっちり把握できるなら memcached の方がパフォーマンス的に優れている場合もあるとのこと。
メモリでキャッシュするデータの特性によって使い分けるのが大事
といった感じ？
なぜ Redis ちゃんと調べた記憶無いんだろうと思い記憶を掘り起こしてみると、
今までよく扱ってたフレームワーク(PHP)がデフォルトでは Session を Cookie に書き込みにいく構成になっており、 そのFWでドライバは Cookie, File, DB, memcached, Redis を指定することができるけどそこで memcached を設定してたことが多かったような気がするというのがあった。
あとそういやPHPは Session はデフォルトでは /var/tmp/*** の一時ディレクトリにファイル保存してた。 （デフォルトがそうとはいえ負荷を考えるときにはKVSを検討しなきゃいけないけど）
ミラーリングのはなし
以前、その当時上司だった人に教えてもらったことで
ミラーリングを仕事で人と話すときに意識的に実践してるというのがある
【人間心理学】わざと？無意識？好意が真似させるミラーリング効果とは？
ここの記載だと恋愛目線で書かれてるけど、
例えば何か説明するときに身ぶり手ぶりを使って話してくれた人に対して、
それってこういうことですよねと相手と認識を合わせるのにその人がやった身ぶり手ぶりを交えて話すとか。
どっちかというと見た目の形のことじゃなくて「話を進めるポイント」を相手と同じように意識する、という感じで
心理的に「このくらいあなたに寄り添って考えようとしている」「共感している」というのを伝える（そして安心させる）のにもいいやり方だと思う。
後輩に初めて指導する立場になったときに、
同じ目線に立って考えるよりも「気づいてないかもしれないけど、ちゃんとこっちもあんたの気持ちはわかってるよ...考えてない訳じゃないんだよ...」っていう「こっちも考えてるアピール」を相手に伝えるのって難しいな〜と苦戦した。
とくに私の場合、仕事の上で言い方が怖いって下のメンバーからしたら感じることあるよ、と上司に元々言われていて
そんなつもりで言ってないけどでもそう伝わってしまうんだなぁ... というモヤモヤもありなおそう思っていた。
でも案外意識してみると、
- どこのレイヤーで相手は困ってるのか
- 相手は自分に何を求めて相談しに来ているんだろう
というのを細分化してひとつひとつ話すことができるようになって、多分その気概(?)は前よりは伝わるようになってるとだんだん実感できてきたので
こういうエンジニアという立場で働く上でミラーリングってのはいい着眼点だなと思う。
この話を思い出したのは今日の会社の Slack で無意識に好感を上げようと同じような雰囲気の絵文字を使っていて
おっこれめっちゃミラーリングぽいやんとなったからです。
（下が私）
私がステータスに設定している絵文字（ミッフィー）を先にメッセージ中に取り入れてくれてるというのがそもそも嬉しいこの流れ！！
絵文字ひとつがもたらす効果は計り知れない。超身近なところからミラーリングはできる。
B'z LIVE-GYM 2017-2018 “LIVE DINOSAUR" BDが最高すぎる
昨年行ったLIVEのBD、フラゲしてたもののようやく視聴。
毎回B'zのLIVE BDは出るたび歴代最高を更新してると思ってるんだけど今回も本当に最高でした
今回はしかもOPからの流れが
01. 声明
02. CHAMP
03. 孤独のRunaway
04. ハルカ
05. ルーフトップ
06. FIREBALL
07. MOTEL
08. 赤い河
...
といった感じなんだけどこの声明から始まって2回目MC終わりでFIREBALL MOTEL 赤い河がくるのがほんっっっとうに最高
FIREBALL と 赤い河はたぶん自分がLIVEで見れることは無いだろうと思ってたので生でイントロ聴いた時は
陳腐な表現だけど長年の夢が叶ったようなそんな感動とか興奮が頭の中をめぐっていた。セトリ事前に見たけど...
いままでに何度聴いたか分からないこの曲を、収録時を上回るクオリティ（と思っている）でしかも生で聴ける、これだからライブにいくのはやめられない
- アーティスト: B’z
- 出版社/メーカー: BMGルームス
- 発売日: 1994/03/02
- メディア: CD
- 購入: 1人 クリック: 41回
- この商品を含むブログ (94件) を見る
- アーティスト: B’z,KOHSHI INABA,TAK MATSUMOTO,AKIHITO TOKUNAGA,DAISUKE IKEDA
- 出版社/メーカー: Rooms Records
- 発売日: 1997/11/19
- メディア: CD
- 購入: 4人 クリック: 30回
- この商品を含むブログ (99件) を見る
