valid,invalid

関心を持てる事柄について

エンジニアが読む『UXリサーチの活かし方 ユーザーの声を意思決定につなげるためにできること』

読書 UXリサーチ

瀧本はろかさん、『UXリサーチの活かし方 ユーザーの声を意思決定につなげるためにできること』の出版おめでとうございます。プロダクト開発に関心あるエンジニアとして、そしてスマートバンクにおける同僚として本書を拝読したので書評を書いてみます。

続きを読む

"Data Migration on Rails"という発表をKaigi on Rails 2024でしました

Ruby on Rails Ruby

表題の通りRailsにおけるdata migrationの手法や現在地についてKaigi on Rails 2024で発表してまいりました。

4年連続でスピーカーとして参加*1することができ大変光栄でした。また、後述するようにオフラインならではの稀有な体験ができ、楽しかったです。

今回の発表について

発表に用いたスライドは以下です。

今回はこれまでの発表とは違ったアプローチに挑戦してみました。これまでの発表が1つの課題やプロトコルについて深掘るスタイル（まぁ、発表って普通はこっち）だったのに対し、今回は収集する情報の幅を広くとりつつ特定テーマの現在地を半網羅的に示すというsurvery report風味な内容という感じ。

意図したアプローチではありつつも、スライドを作りながら「ちょっと浅すぎないか」「広く薄いこの内容は誰にとって面白いのか」とけっこう直前まで悩んでいた。特に一番伝えたい芯をどこ置くかは迷いどころだったものの「今回のスライドを今後の議論の土台としたい」という落とし所で突き進むことにした。

聞いてくださった方が1つでも知らなかったことを持ち帰れたり、今後data migrationを考える際に立ち返る道標的なものになれたりしたら幸いです。

発表時にXで実況的に感想をくださった方、発表後に話しかけていただいた白土さん、corocnさんありがとうございました。大変励みになります。

スポンサー

所属しているSmartBankは2年連続でスポンサーブースを出しており、僕も時折そちらで会社紹介をしたりしてました。

会社として初めてのテックイベントスポンサーが去年のKaigi on Railsであり、当時は「会社名もプロダクトも聞いたことないっすねぇ...」という感じだったのが、今年は「B/43使ってます、ユーザーです！」「RubyKaigiでもSmartBank見ました！」のような方がたくさん訪れてくれ、認知の広まりを感じました。Kaigi on Rails、YAPC、RubyKaigiと続けてスポンサーしたり毎回登壇者を送り込んだことの効果をひしひしと感じます。

一方、実態以上に良く思われてないか、人が足りてて課題が少ないと思われてないか、キラキラしてないかといった認知形成も社内で話題に上るようになり、次のステージって感じですね。

実際には登壇やブースで見えるような"輝き"以外の泥臭い課題に取り組んでいたり、そもそもRailsエンジニアは10名ちょっとの少人数で採用強化中だったりするので、認知補正をひたすらやっていました。

ひっそりとできたらかっこいいのかもしれないけど、こういうのはストレートに伝えたほうがわかりやすいだろうと思って、会う人会う人に言いまくってました。本当に採用強化中であるのと同時に、もっと実態を知ってもらうためのカジュアル面談もオープンしています。

smartbank.co.jp

転職意欲を問わず「Kaigi on Railsで配布していたアーキテクチャ図の解説をしてほしい！」「rails statsどんな感じなの？」「えっ!! Railsでカード決済システムを!?」といった純粋にテクニカルな話題のみにも対応していますので、お気軽にお声がけください。

ブースで説明したり、配布していたアーキテクチャ図

印象に残った発表

登壇者としての参加だったのであまり落ち着いて聞けた発表はなかったのですが、中でも面白かったのはがーしーさんのcXML という電子商取引の トランザクションを支える プロトコルと向きあっている話でした。世の中に存在するニッチで渋〜いプロトコルと戦う話、大好きです。懇親会でがーしーさんを捕まえてお話ししたところ、SmartBankのメンバーの去年の発表を見てこういうニッチな枠を狙ったりスライドを参考にしていただいたとのこと。これは嬉しい。いろいろ話した結果cXMLプロトコルの存在意義やメリットを受け売りで他の方に伝導できるようになった。

また、moroさんのIdentifying User Idenityもとても良かったです。昨年のSimplicity on Railsと同じく、「そうそう、そうやっている / やりたかったんです」と言いたくなる内容で、自分たちのコードベースが追認されるような心持ちになりました。

発表を見られなかったもののすごく面白そうなスライドもたくさんありました。カラム追加で増えるActiveRecordのメモリサイズ イメージできますか?、デプロイを任されたので、教わった通りにデプロイしたら障害になった件 ～俺のやらかしを越えてゆけ～、約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話はスライドだけでも興味深かったのでアーカイブも楽しみにしてます。

交流

今回は"インターネットで一方的に見知っているけど初めてお会いする方"とオフ会できて良かった。

廊下

一方的に見知っている方の筆頭がpalkanさんで、なんとDay 1の本プレゼントクイズに当選して"Layered Design for Ruby on Rails Applications"の物理本をいただいた。

緊張しながら話しかけたところにsylph01さんもいて、クイズの答えあわせしたり講演内容について質問したりした。たぶんもうネタバレ大丈夫だと思うので書くと以下が答えだった。僕がQ1正解でsylph01さんがQ2正解でどちらもhalf correctだった...。

Q1. Rails Way, or the Highwayのインスパイア元は？

A1. My Way (Limp Bizkit)

Q2. 最近見た世界最大のモノリスは？

A2. Shinjuku

講演に関するQ&A

せっかくなので講演について聞いたのは「Formレイヤーを追加するときに抽象化って必要なのか？」ということ。

Formクラスの導入はigaigaさんのRailsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミングや、過去のmoroさんのフォームオブジェクトとの向き合い方などで出てきているように、パターンとして日本のコミュニティでも広く知られている。けどいずれも抽象化を施すまでは至っていない（と思う）ので、その必要性が気になった。

palkanさんの回答（disclaimer: 乏しいリスニング力のため聞き間違いの可能性おおいにあり）は「規律を課さないレイヤー追加はいつか破綻するから抽象化が必要なのだ」というものだった。

POROのFormクラスやActiveMode::ModelをincludeしたときだけのFormはいわばレイヤーになりきれていない"intermediate state" (中間的な状態) であり、チームで統一した書き方を強制できない。モデルの操作や例外のハンドリングなどがまちまちになり、新人は思い思いに実装されたFormクラスのうち任意のコードを真似するようになる。フレームワークの作者のように考えるなら、新たなレイヤーを追加するなら抽象化による規律・規約を持ち込み、長期にわたってそれらが守られるようにすべきなのだ。

ということを言っていた気がします（9割意訳）

懇親会

そんな話をしてくれたpalkanさんが同著の「日本語版を出したいけどどうしたものか」とこぼしていたのを聞き、突然なんらかの使命感に目覚め、Day 1懇親会ではいろんな方にその意図を広めたりしていました。このことを口実にinaoさん、snoozer05さん、okuramasafumiさんたちと話す機会を持てたりもしました。しかし、翻訳書やRails本の出版事情も聞くほどになかなか大変ですねぇ...

Day 2の懇親会ではsinsokuさんハマちゃんさんらと学生さんと同じテーブルになりました。弊社は新卒採用やインターンをやっていないので学生と話す機会が非常に乏しい、実際話してみるとものすごく優秀なだけでなく、我々にはない視点での質問や話題を提供してくれて大変楽しかった。

インターネットで見知っていた桐生あんずさんも発表前の廊下で忘れられない遭遇をしただけでなく、懇親会でarimoさんakiさん交えていろいろ話せました。僕の https://scrapbox.io/ohbarye/ をちょいちょい見てくれていたことがわかり、大変嬉しかったです。

再会で言うとRubyKaigiでちゃんと話せなかったmorihiroさんともちゃんと話せて良かった。お互い瞳孔が開いてたような気もしますが個人技やマネジメントなどについて久々に熱い語りができたように思います。

Quipper時代の同僚のtricknotesさん、indigolainさんと同窓会できたのも良かった。tricknotesさんは開発以外にも挑戦しつつプライベートでコードをゴリゴリ書いていたり、indigolainさんは https://github.com/kaigionrails/conference-app にもコミットしててかっこいいですね。願わくばQuipper時代の同僚ともっとコミュニティでオフ会したいですねぇ。

振り返るとここ数年で最大級に色んな方と会話でき、オフラインイベントの良さを最も堪能できたイベントだったように思います。もっとたくさんの人と会話したのだけど名札を見る余裕がないために失礼があったらすみません。

登壇お役立ち情報

懇親会だったと思うのですが「X見てたんですが発表以外の工夫をなんか色々"やって"ますよね？参考にしたいので教えてください」と言われました。

そうですね...どれも本質じゃない小技ではありますが、いくつか"やって"はいるとは思ったので、会期中にポストしたものを並べておきます。登壇にこれから挑戦する方などに参考になれば幸いです。

マイクの持ち方

登壇日の朝の告知

発表前の資料放流

ポインター

今後

改めて30分の登壇は準備も練習も大変で、何年やっても慣れないことばかりです。とはいえ終わった後に得られるものは多いので継続可能なペースでやっていきたいものです。

宣伝

来週11/5 (火)のアフターイベントにも登壇することになりました。Kaigi on Railsではテックトークをしたので、次は「登壇のネタ探し・プロポーザルの書き方・登壇内容を磨く工夫」あたりについて話そうかなと思っています。一般的な登壇のメリットとか工夫はけっこう知られてきたと感じており、今回はあくまでohbarye個人としての体験・経験・工夫をまとめてみようかなと。

さっきまで満席でしたが増枠されたようなので未申し込みの方もぜひ以下からどうぞ。現地でお会いできること、再会できることを楽しみにしております。

smartbank.connpass.com

感謝

最後になりましたが、Kaigi on Rails 2024を開催してくれたオーガナイザーの皆様、最高のイベントをありがとうございました！

*1:オーガナイザーチームの寺井さんとも話したけど、他にはいない？

YAPC::Hakodate 2024に参加して、個人技と工芸と工学について考えた

YAPC YAPC2024 旅行

YAPC::Hakodate 2024に参加してきたので感想です。人生初の函館が良かったので観光成分も多め。

YAPCについて

前回のYAPC::Hiroshimaに続いて今回が2回目のYAPC参加です。YAPC::Hiroshimaではプロポーザルが通ったのですが今回は通らずでした。

出したプロポーザルはこちら 3Dセキュア温故知新: Web認証技術の発展が切り拓いた現在地 by ohbarye | トーク | YAPC::Hakodate 2024 #yapcjapan - fortee.jp。同僚の id:yutadayo がクレカ製造技術ネタでめちゃめちゃ強いのを出して大バズしていたので会社としては問題ない...が、個人としては悔しい！

yuta.hatenablog.com

心に残った発表たちの個人的総括

ブース担当したり廊下で人と話したりでセッションは半分ぐらいしか聞けなかったのですが、その中でも個人的に"つながり"を感じたテーマ「個人技と工芸と工学」について雑多に感想を残してみます。

まず、朝イチの深町先生による『シェルとPerlの使い分け、 そういった思考の道具は、どこから来て、どこへゆくのか？』。コンピュータ開発史の話が純粋に面白かった！

歴史哲学付近を専攻していた身としてはE.H.カーを引用されて大興奮。歴史とは事実の羅列ではなく、誰が、どんな信念の持ち主が語るのかによる過去との対話なので、深町先生のような方が何に着目して語るのか、という点がたいへん興味深く、身を乗り出して聞いていました。

コンピュータが廉価になり誰でもプログラミングに取り組めるようになり、個人の熟達や狂気が世界に影響を与えられるようになったという熱い歴史観。現代ではプログラミングは実用寄りなアート、陶芸のようなものと仰ってたのが興味深く、講演後にも少しお話しさせてもらった。

ソフトウェア開発には工芸（アート）的・職人芸的な側面はあるのは事実だし、キーノートの@moznionさんの"個人技"はまさにそのことを指摘し、研鑽のためのマインドやアプローチを自己体験を通じて語るものでありました。自分ももっと量を重ねなければ...と引き締まります。

@osyoyuさんによる『プロファイラ開発者と見る「推測するな、計測せよ」』, @chobishibaさんの『自分だけの世界を創るクリエイティブコーディング』などもまた、個人の興味や嗜好を掘り下げ、自身を磨き上げたところから生まれるものでした（2人とも同僚で、RubyKaigiやそれ以前から一貫して1つのテーマに専念してとにかく手を動かし続けており、とても尊敬しています）。

僕は短期的なゴール設定に対して全力を出すタイプの、いわば短距離走を繰り返しがちな性質があるのでそういう一点集中スタイルに憧れますね。

それはそれとして、プログラミングやソフトウェア開発においてあまりにもアートや職人芸の側面を強調しすぎる、（今回は誰もそんなふうには言ってないですが）"アート面しかないように扱う"ことには自分は否定的でいて、工学（エンジニアリング）の側面と併せ見ることが重要だと考えています。

工学と聞くと鈍重なプロセス、平均的な人々をうまく働かせる方法、といった「製造工学を無理にあてはめようとするイメージ」を持たれることもあります。しかし、設計工学、とりわけソフトウェア工学はもっと個を引き上げるためにあるものだと思います。

真のソフトウェア工学は、私たちの創造力と、高品質で役立つものを自信を持って作る能力を引き上げます。アイデアを掘り下げ、創造力を伸ばせるようになり、大規模で複雑なシステムを構築できるようになります。

『継続的デリバリーのソフトウェア工学　もっと早く、もっと良いソフトウェアを作るための秘訣』より

ベストスピーカーを受賞した@osyoyuさんの発表はプロファイラ開発という個人技の極地みたいな出発点でありながら、万人に還元できる学びや一般解を展開されており、工芸と工学のミクソロジーとして素晴らしいものでした。発表の巧みさ、テーマがリーチする広さといった表象も重要なポイントではありますが、特に個人的に刺さったのはその点です。

ソフトウェア工学とは、ソフトウェアの現実的な問題に対する効率的、経済的な解を見つけるための経験的、科学的なアプローチの応用のことである。

同書より

これ。

プロセスの第1は当て推量です！当て推量が実験と一致しなければ、それ（当て推量）は間違っているということです

同書より。これはファインマン先生の引用

実験を通じて学びを反復し、前進的な改善を測るものが工学。経験主義的でもあり、量が質に転化するという@moznionさんの話とも繋がるのではないでしょうか。

長々書きましたが、@moznionさんが言っていた「個人技の向上の再現」には教育も重要であるが、同様に工学の理解と活用も大事、という見解です。

歴戦のプログラマが「年々若者が優秀になっている」とつぶやくのを何度も聞きます。ここには教育側の進歩だけでなく業界全体としてのソフトウェア工学の進歩があり、先達が経験や学びが広まっていることの証左ではと。

懇親会や廊下でもこのテーマについて何名かと議論させてもらいました。お付き合いいただいた皆さん、ありがとうございました。最近の関心について深掘りするきっかけをもらい、とても刺激的なイベントでした。スピーカーではなく、いち参加者として臨めるカンファレンスだと、こういう思索が落ち着いてできて良いですね。

観光

あとは観光ログです。

街並み

函館の元町やベイエリア、街並みがめちゃくちゃ良い。

グルメ

イベントでの食事が中心だったのだが、写真があまりない

ラッキーピエロはYAPCのお弁当としていただいた。おいしいしボリュームもすごかった

やきとり弁当は米なしの串だけ食べたが、米のためにある"味"だった

メルカリの新サービス？

メルカリの新サービス2？

メロン

まぐろの頭肉！！！！まぐろで一番好きな部位だし、一番好きな寿司ネタの可能性ある

こっちはオオカミウオ。見た目はマジで怖いのだけど刺身はふわふわの白身。肉に例えるならホルモン系？

とうもろこしの天ぷら。甘すぎてすごい

くいだおれ太閤のたこ焼きもYAPCのお弁当

港近くの街角クレープ。クレープの写真がないのだけど、過去一番おいしいクレープだったかも

近くにあったSpecialty Coffee COCOROで淹れてもらったホンジュラスのコーヒーと一緒に食べられて最高だった

イカが不漁とのことでまったく食べる機会がなかったのが残念

歴史的建造物

いい...

動物

港で力強く餌をねだるやつ

放し飼いの猫

放し飼いの猫2

躍動する生命...

時間が足りなくて訪問できなかった場所、堪能できなかったグルメがあるのでまた行きたい

Pixel 5aがブラックアウトして動作しなくなったのでPixel 7 Proに交換してもらった

3年近く前に購入したPixel 5aを長らくメインのモバイル端末として使っていたのだが、あるとき突然ブラックアウトしてしまい、一切動かなくなってしまった。

Pixel 5a (シリーズ?) は基盤不良の問題が起きることで有名な機種らしく、公式からも2年間延長修理プログラムについての案内が出ていた。

CPUの動作温度が高い端末は熱ではんだが膨張と収縮を繰り返し、はんだクラック（割れ）が発生する確率が非常に高くなります。こちらのPixel 5aもその他の端末に比べ熱を持ちやすい傾向があるため同様の原因が考えられるかもしれません。

確かにしょっちゅう「デバイスの温度を下げる必要があります」のアラートが表示され、夏はポケットに入れていられないぐらい高熱にうなされていた。

おそらくトドメを刺したのが、ブラックアウト数日前にインストールしてやり始めた崩壊：スターレイルだ。ちょっとプレイしただけでPixel 5aがグワっと熱くなり、動作もカクつくのでまったく快適にプレイできない。続けるか迷うな〜と思っていたら先に端末が逝った。

Googleのサポートチャットに問い合わせ、先方の指示通りの操作を試したり製造番号を伝えたりすること1時間。最終的に端末の無償交換という結果になった。わりと話がスムーズだったので、不良が多く報告されていたロットだったのかもしれない。

最後の最後に「ご利用いただいていた製品 (Pixel 5a) は用意できないため代替品は7 Proとなりますがご容赦ください」というメッセージがやってきた。いつもの癖で「!?」とリプライしそうになったが、冷静に了承したところ本当に7 Proが来た。約5万円で購入した5aが3年かけて公式価格約12万円の7 Proに、"成"った。

超幸運だったか？と思いXで検索してみると同じ対応を受けた方がそこそこいるようだった。また、毎日数十〜数百件の故障報告がなされているという噂もあり、すごいですね。

到着後の新端末のセットアップについて。移行元のバックアップは故障の前日で作成されていたのでその復元は問題なかったが、移行元の端末操作を要求するタイプのアプリやサービスは非常に困った。

特にモバイルSuicaが鬼門で、おサイフケータイとSuicaアプリの間で無限ループが生じたり、Webサイトのヘルプからの動線で何がなんだかわからないうちに色々やっていたらいつの間にか復元できた。もう一度やれる気がしない。

また、良い話でいうと二要素認証のバックアップコードがいろんなところで生きて助かった。AuthyとかMetaMaskとか色々。端末をなくすような真似を自分はしないだろうとタカをくくる時もあったが、やはり重要。

NearDropでAndroidからmacOSに簡単にファイル共有

Software

同じWi-Fiネットワーク下にあるAndroidからmacOSに写真や動画を共有したいとき、NearDropが便利。AirDropみたいな体験をfrom Android to macOSでもできる。

github.com

HomebrewでインストールしたNearDropを起動しておく。

brew install --no-quarantine grishka/grishka/neardrop

macOSでNearDropを起動していれば、AndroidからQuick Share (旧Nearby Share) で共有できる。

  • Androidデバイスからファイルを選び、共有 > Quick Shareと進むとmacOSが共有先に現れるので選択する
  • macOSにデスクトップ通知が来るのでAcceptする
  • Downloadsフォルダにファイルが現れる

AirDropとほぼ同じ。

ソフトウェア開発やリサーチをしているときにめちゃめちゃ捗るようになった。

モバイルアプリのスクリーンショット、スクリーンキャストを撮ってPCに送って、検証結果として貼ったりバグレポートを書いたり。

モバイルアプリ開発者であればシミュレーターやadbでずっと苦なくできているぽいのだが、そうではない自分はこれまでAndroidデバイスで撮影したファイルをいちいちSlack等にアップロードしてから回収していた。

教えてくれた同僚の@osyoyuにgiant thank you...

2024/09/28 11:06追記

Xで Pushbullet - Your devices working better together を教えてもらった。darumaさん、ありがとうございます！

こちらはファイル共有だけでなくユニバーサルクリップボードみたいなテキスト共有や、デバイスの通知をデスクトップで確認できたりするらしい。すごい！

足の裏に埋まった髪の毛を摘出した

健康

少し前のことだが、足の裏に髪の毛が埋まって痛かった

割り箸のささくれやシャーペンの芯のように、鋭い先端を持つ髪の毛がちくっと刺さったというたまにあるレベルではなく、皮膚の下にメリっっっっと潜り込んでいた。刺さっているというより埋まっていた

▶️ここをクリックすると刺さっている様子が見られる（微閲覧注意）

完全に皮一枚の下に3cmほどの髪の毛が埋まっており、こんなことあるの...って思ってググったら、ふつうに"ある"らしかった。どうやら美容師さんたちの間でもたまに起きることらしい

毛は刺さる | 文京区小石川 もものマークのクリニック 院長ブログ

刺さった瞬間は先端だけだが、何らかの不思議な力で皮下をするするともぐっていき...このような事態になるとのこと

歩くたびに足裏がチクチクして不快で走れないレベルなのと、気づいたのが休日で皮膚科に行くまでに時間が空きそうなので自ら摘出を試みることにした

インターネットで見つかった教えの通りカミソリで薄皮が少しずつ削っていくこと10分...。ようやく埋没した髪の毛の"実体"が皮の外に出てきたのでピンセットでつまんで引っこ抜いてEND GAME。（実際はその途中で髪の毛が切れて第二ラウンドが始まったりしたのだが...）

▶️ここをクリックすると抜けたあとの様子が見られる（微閲覧注意）

むかし腰からくる坐骨神経痛をくらったことがあり、そのときも足裏に似たようなチクチク・ピリピリを感じていたのであわや再発かと思ったが、今回は表皮の問題だけでよかった

『コンビニ人間』読んだ

読書

第155回芥川賞受賞作『コンビニ人間』を読んだ。

かなり良かった。共感性のない主人公が"普通"を模索するためにとった策は「理想のコンビニ店員を演じる」というもので、コメディともとれる軽妙な読み心地で通俗小説的でありつつも、疎外論を通じた現代批判・問題提起とも取れる点が評価されたのだろうと思った。

職場において与えられた役割を徹底させられることで人間性を喪失してしまうのが労働疎外であるが、本作の主人公においては役割を与えられ全うすることで生き生きと充実した人生を送るという逆転が起きていてシニカル。

これを喜劇と見ることもできるし、日常で起きていることへの風刺と見ることもできる。労働の場でなくとも、社会集団の中で周囲から期待される役割を演じることで自己実現・満足を感じるような場面というのはありふれており、そういった人たちとコンビニ人間との違いは、その事実に自覚的であるかどうかだけにすぎないからだ。

ちょうど最近自分が書いた記事 人間をリソースと呼ぶことの何が問題なのか - valid,invalid にて、人間疎外のいち表象が"リソース"という呼称なのかもしれないと書いた。

この記事に対して「むしろ自分はリソースとして扱って欲しい。代えがきくから」といったコメントがついたのは非常に興味深かった。このコメント主がコンビニ人間のような存在であると断じたいわけではなく、むしろ自身の人間性を守るために職場での役割（リソース）と人間性をあえて分離させておく自己防衛の手段に見えたのだ。

自分もそうした防衛と無関係ではない。

コンビニ人間 (文春文庫)

コンビニ人間 (文春文庫)

Amazon