YAPC::Hiroshima 2024に参加しました - 感想とメモ -

yapcjapan.org

以下の理由が重なり、YAPCのイベントに初めて参加しました。

  • 去年のYAPC::Kyotoが盛り上がっているように見えたこと
  • Kaigi on Railsでオフラインのカンファレンスを久々に体験して機運が高まっていたこと
  • 会社がスポンサーしていること

会社からは僕を含めて5人の社員が参加していました。会社のブログは別途公開しようと思います。

広島に訪れたのは小学校の修学旅行以来で、広島は記憶よりも都会でした。東京から新幹線で4時間もかかり、なかなか来る機会が少ないのでこの機会に訪れられてよかったです。

前夜祭

Hono v4 by yusukebe

Honoは知っていたけれど、結局なんだかんだ使っていなかったのですが、熱量のある発表ですごく触ってみたくなりました。

ということで次の日の朝、めちゃくちゃ早く会場についてしまったので、とりあえずBunを入れてHonoを動かしてみました。

懇親会でyusukebeさんに wadafm を全部聞いてましたよ!と伝えると、「え、wadafm聞いてるのに、HonoもCloudflareも使ったことなかったんですか???」と言われてしまったので、帰りの電車でCloudflareにサインアップして Hello Worldを動かしていました。

アカウントを作って文字通り3分で初回のデプロイができたのですごい。

Cache-Control: max-age=86400 by onk / soudai1025

まずはブログの紹介、その後質問に応えていくという流れでした。

どちらのブログも事前に読んでいたので、ガッとおさらいしてくださっていて、もう一度ちゃんと読もう!という気持ちになりました。

相談会は親身でよかったです。僕も相談したくなりました。

飲み会(2次会、3次会)

しがないラジオ時代のつながりで genneiさんに話しかけてもらってmasaya_devさんとogijunさんと飲み屋に行きました。

ともに参加していた会社のメンバーも快く参加させてもらえてありがたかったです。

解散後、会社のメンバーで3次会に行きました。 「せんじがら」というホルモンを低温でゆっくりカリカリに揚げた広島のおつまみを食べました。

広島にゆかりのあるメンバーも多くて、広島で食べたほうが良いものを聞いたりしました。

本編

コミュニティと共に生きる - キャリアの螺旋と人生を変えた瞬間 by soudai1025

ワードとしてはこれまで何度か聞いたことがありましたが、計画的偶発性理論についてもう一度考えさせられました。

僕自身は自分から話しかけられない性質なので、前で喋ったり、Podcastを公開したりすることによって、話しかけてもらいやすい状況を作ってきたイメージがありました。

しかし、初心者という枠を超えたかなというあたり、ちょうどコロナに入ったという言い訳をしながら数を打てていなかった自覚があるので、もう一度立ち戻って頑張っていきたいなと思いました。

また「誰かに話かける」ということも懇親会や廊下で頑張ってみようと思いました。これが、本編の始めのトークであったのは個人的にすごく良かったです。

経営・意思・エンジニアリング by y_matsuwitter

組織も事業もソフトウェアエンジニアリング的な思想で設計していくことができ、それにまつわる要素郡や構造についてわかりやすく話してくださっていました。

短期成果への引力をはねのけるには意志の力が必要だというメッセージと、そういった意志は言語化してアウトプットしていると反芻により強くなるというメッセージがありました。

この発表を通しても、言語化するということに関しての完成度の高さがすごいなと感じました。

Blogを作り、育み、慈しむ - Blog Hacks 2024 by songmu

ブログへのエモーショナルな想いと、ブログを支える技術についてのアツいトークでした。

今回のYAPCのテーマが「お好み」でしたが、僕が当日聞いたトークの中では最も「お好み」が詰まったトークだったかなと思いました。

songmuさんとは、しがないラジオに以前出ていただいた縁もあり、懇親会で少し話かけさせていただきました。覚えていただいておりありがたかったです。

最後にお会いした頃から、状況が大きく変わられていたので、今の会社のお話を聞けて嬉しかったです。

質疑応答の中で、Podcastも検討はしているという話があったので、楽しみにしています!とお伝えしました。

また、ブログに生成AIを使うかどうかというお話で盛り上がったのも面白かったです。songmuさんは使わない、ということでしたが、僕は会社のブログには使うことが多いかもという話をしました。

(このトークはtwadaさんのトークとar_tamaさんのトークの裏番組ということですごく迷いましたが、このトークを選んでいたことをアフターイベントでar_tamaさんに見事に指摘されてしまいました...。一番現場で熱量を感じるのが大事なトークかな!と思って選びましたが、twadaさんのものもar_tamaさんのものも後で必ず動画を見るつもりです。と誰に向けているかわからないdisclaimerを残しておきます。)

PerlでつくるフルスクラッチWebAuthn/パスキー認証 by mackee_w

前半、WebAuthとパスキー認証について、ざっくりではありますが、要所をわかりやすく解説してくださっていて、技術の取っ掛かりとしてすごく良かったです。

Perlでのライブコーディングで実装をされていて、Perlを触ったことがなかったのですが逐一説明されていたので追いかけることはできました。

パスキーという技術は、デバイスが関連するので検証などがかなり難しそうだなというイメージを持ちました。

平成のエンジニアから令和のエンジニアへの遺言〜技術情報を伝達する手段の変遷〜

941さん、naoya_itoさん、yusukebeさん、twadaさんによるトークセッション。興味深い話題はいくつかあったんですが、特に印象に残っているのは、最近のコミュニケーションがみんな気を使いすぎているんじゃないか?というものでした。

実際にどういう言葉を使われていたか厳密には覚えていないんですが、ざっくりいうと最近はマサカリが少ないという事でした。

僕自身マサカリがある方がよい、と思っているわけではないですが、EMである以上自分のコミュニケーションが対象の人にどう映っていてそれがどのようにその人の働き方やキャリアに影響を及ぼすのかすごく気になっています。

特にフルリモートな環境では特に難しいなと感じており、今後折に触れて考えることになるテーマかなと思いました。

キーノート

とほほのWWW入門のとほほさんのキーノート。僕自身がめちゃくちゃお世話になったということはありませんが、僕が未就学のときから今に至るまで更新が続いているというのは素直にすごいなと思いました。

学習とアウトプットを続けられている要因として、楽しいから、好きだからということを仰っていました。

実際自分自身は、学習は好きだなと思う反面、それをアウトプットするのが大好きか、と言われるとそんなことはなく、それによって得られるものを考えてしまいます。

純粋な”好き”には敵わないものがあるなと思うことは今回だけではないです。なので、仕組みで解決する、などの方向性になるのかな、と改めて思いました。

懇親会 & アフターイベント(RIZAP Drinkup at YAPC::Hiroshima 2024)

全体を通して、いつもTwitterなどで遠巻きに見ている界隈の方々に0.5歩近づけたかなというところでした。

朝のそーだいさんのトークもあり、一方的にTwitterなどで話したことのない方とも話すことができました。

はじめましてなのに詳しいですね、と言われることが3度ほどあり少し恥ずかしかったです。

また、すでに本編の中でも触れましたが、しがないラジオを聞いていただいて繋がりのあった方々、過去にゲストで出演してくださった方々にも久しぶりにご挨拶できてよかったです。

そして、YAPCビールがめちゃめちゃ美味しかったです!

その他

企業ブース

HireRooさん

各社のコーディング面接やスキル面接についていろいろ聞くことができました。

ちょうど疲れてしまってトークをスキップした合間だったのでかなり空いており、長話をしてしまいましたが、快く応じてくださいました。

去年から試行錯誤しているスキルを見る面接についてさまざまなインサイトを得られたのですごく良かったです。

Findyさん

CTOのまさたんさんと久しぶりにお話ししました。しがないラジオに出てくださっていたことを覚えていただいており、嬉しかったです。

弊社も利用し始めたFindy Team+について、Findy社の中でのドッグフーディングの様子、その効果について聞くことができ、自分のモチベーションも上がったので良かったです。

3次会

会社のメンバーとアフターイベント後に集まりました。

初めてカンファレンスに参加したメンバーもいて、次にどういうカンファレンスにいきたいか、CfPを出すなら社内のどういう話題がよさそうか、など次に繋がりそうな話題が上がっていて会社で参加してよかったと思いました。

去年Kaigi on Railsに参加したときのブログで、会社のメンバー数人でカンファレンスに参加したいということを書いていましたが、これからもこういうことが続くと良いなと思いました。僕が言い出しっぺになって盛り上げていきたいなと思います。

宮川さんに話しかけた

最後に一番のビッグイベントでしたが、Rebuildfmの宮川さんに話しかけることができました。

めちゃくちゃ緊張して少ししか話かけられなかったけれど、もう少し自身を持って次もまたもう少し話題を持って話しかけられるようになりたいです。


楽しかったです!また行きます!!

今更リーダブルコードを読んだ、英語で

年末からリーダブルコードの英語版を読んでいました。

昨年の目標の一つに「英語で1冊本を読む」というのがあり、今年にまでさしかかっていたのですが、ようやっと1月中に読み終わりました。

これまで日本語版も読んだことがなかったので、英語で読んだ感想と気になったところを書いておきます。

The Art of Readable Code: Simple and Practical Techniques for Writing Better Code

英語で読んだ

ソフトウェアエンジニアとして仕事をしているので、英語のドキュメントやブログを読むことはありますが、メインのインプットを英語にするというレベルには至っていません。

一次情報を英語でインプットできるとよいと思い、英語を読むことに対してもっとハードルを下げたいと思っていました。そのために一冊読み切ろうというので取り上げたのが、リーダブルコードでした。

昨年の前半にも一度チャレンジして、下記のようなブログも書いたのですが、忙しさなどを言い訳に挫折していました。

blog.zuckey17.org

英単語

今回も上記のブログで構築した英単語収集ツールを利用していましたが、1冊をすべて読みきって数えると164単語追加していました。

序盤はかなり調べる回数が多かったですが、後半はかなりスムーズに読み終わったかなと思います。著者がよく使う英単語というのはある程度偏りがあるのではないかなと思います。英語の本を一冊読むとコンテキストとともに英単語をある程度まとめて抑えることができるので、よい勉強になると感じました。

また、長い英文を読むのは目が滑ってしまうので、口に出して読むことが多かったです。その際に、読み方がわからないものもあったので、Youglishというサイトを頻繁に使いました。

このサイトはYouTube上の動画で目的の単語やフレーズが利用されている部分のみをまとめて閲覧することができて便利でした。

youglish.com

内容について

リーダブルコード自体は初心者に薦められることも多い本だと思います。かなり歴史のある本でもあるのですごく目新しいなと感じるポイントはありませんでした。

しかし、普段プログラミングしたり、コードレビューをするときに意識していることが改めて言語化されており、次から上手く人に伝えられるようになったかなと思います。

例えば、プログラムを書かない同僚に「半年前に書いた自分のコードは、他人のコードのようで、全然覚えていない」みたいな話をしたことがありました。 そのままのことが本書に書かれており、リーダブルコードに書かれていることを、先輩方から聞いていて、それを受け売りとして喋っていたんだなと気づきました。

この例はプログラミングのノウハウではないですが、本書は現在のプログラマにとっての当たり前の土台になっている書籍なのだと思いました。

また、各章のサマリがそれぞれ端的によくまとまっていて、一度読めばそれ以降はそのサマリを眺めるだけで、エッセンスを思い出すことができそうでした。

特に良かったところ

良い記述はたくさんありますが、特に気になったところは、12章のサマリの以下の部分でした。

This chapter discussed the simple technique of describing your program in plain English and using that description to help you write more natural code. This technique is deceptively simple, but very powerful. Looking at the words and phrases used in your description can also help you identify which subproblems to break off.

複雑なプログラムを平易な英語で記述して、より自然なコードを書くというテクニックの紹介です。

直前の10、11章で問題を細かく分割しようということが伝えられており、12章はその具体的な手段という位置づけでした。

普段頭の中で行っているようなことですが、改めてどのように普段のプログラミングでやくに立つかが説明されており、わかりやすかったです。

また、その後の15章では実際の開発プロセスをデモアプリケーションのプログラミングを例に、このテクニックを上手く実業務に取り入れる方法が書かれていました。

おわり

リーダブルコードは比較的簡単で分量が少なめの本でしたが、初めて英語で本を一冊読み終わったのは思ったよりも達成感がありました。

今年も引き続き英語でのインプットをより自然に行えるように英語での読書を続けていきたいです。

次の候補は、最近の RSGT2024のキーノートでも話題に上がっていた、Dynamic Reteaming: The Art and Wisdom of Changing Teams です。

書斎整理 備忘録 2023-2024

年末から年明けにかけて、書斎を整理したので、何をやったかを書きます。 けっこう満足しているので、やってよかったこと、買って良かったものを書いておきます。

※ 紹介している商品のAmazonのリンクはアフィリエイトリンクになっています。今回ですべてを買ったわけではないですが、Amazonダンボールが断続的にたくさん届きすぎて妻から嫌な顔をされているので、もし商品が気になって僕を少しでも助けてやろうという方はこちらから買っていただけると嬉しいです。

Macbook ProMac mini を使い分ける

個人のMac miniと会社のMacbook Proケーブルの抜き差しなしで、いい感じに使い分けるのが今回の最も重要なポイントでした。

作業するときには、少なくともキーボード、マイク、カメラ、ペンタブという4つの入力デバイスをUSBケーブル経由で繋いでいます。

これまでは各入力デバイスをUSBハブにまとめ、ケーブルを抜き差しして、2つの端末を切り替えていました。

デスク天板裏に、それぞれの端末を収納しているので、デスクの下で手探りするか、昇降デスクをぐっと上げて抜き差しするか、と切り替えのハードルがありました。

今回、UGREENのUSB切替器を導入して、ボタンひとつで2つの端末を切り替えることができるようになりました。

モニタを1枚にたいしてHDMIはそれぞれ各端末から繋ぎっぱなしにし、入力デバイスが切り替わったら、画面も切り替わる、というふうに運用しています。

Macを使っているとCaldigitなどのドッキングステーションがおすすめされることが多いのですが、ボタン一つで切り替えみたいなところをうまく低予算で実現する、というところでこの切替機にいたりました。

切替器にはUSB type-cで給電しており、入力デバイスが多くても電力不足になることは今のところありません。

また、切替器は天板裏に貼り付けていますが、以下の両面粘着テープで貼り付けました。全く落ちる気配もなくガッチリです。

その他

この他にもいくつか変更したので書いておきます。

デスクにキャスターを取り付けた

デスクは、FLEXISPOT E7の白に、KANADEMONOさんのラバーウッドの天板を180cm*70cmでオーダして取り付けて利用しています。

THE BOARD / ラバーウッド ナチュラルkanademono.design

かなり大きく重いので、今回作業するときに動かすのがたいへんでした。

途中からキャスターを取り付けることにより自由に動かせるようになりかなり助かりました。

この際、FLEXISPOT公式のキャスターではなく、以下のキャスターを購入しました。

車輪の大きさが公式のものよりも小さく、目立ちづらいのと、キャスターをつけても昇降デスクが低くなってくれるのが良いです。そして、何より安いです。

電源タップトレー増設

元々、PREDUCTSさんのメッシュトレーを利用していたのですが、Macbook ProのACアダプターが大きすぎてうまく収まらず、よいものを探していました。

結果、サンワサプライさんの電源タップトレーを増設しました。こちらは電源タップを少し斜めにすることでACアダプター問題も解消しました。

天板が幅180cmもあったので、純粋にトレーを増設することができ、コンセントの口の数が増えて便利になりました。

デスクマット

これまでは天板に直にキーボードを置いて、マウスはマウスパッドを利用していましたが、今回デスクマットを導入しました。

macではなくiPadや別の作業するときに、デスクマットを奥にずらすと作業の場所が確保できる、ということを実現するためです。

デスクマットを調べると、Grovemade さんの1万円以上するモノがでてきてやや引くんですが、僕は以下のものを買いました。

フェルトの肌触りがよく質は十分なんですが、裏面が滑り止めになっていて当初の目的が実現できないことがわかったので、ほぼ同じサイズの以下のものを追加で買い、下に引くことにしました。

1000円以下のこちら1枚でも十分なんですが、やはりフェルトの肌触りが全然違いました。2つ合わせてもGrovemadeのものを買うよりもだいぶ安くすみました。

デスクマット、皮のものは滑らせられるのが多いんですが、フェルトのものは滑り止めがついているのが多いので注意が必要です。

照明関連

照明関連の変更はしずかなインターネットに概ね書きました。

sizu.me

sizu.me

基本テープライトで間接照明をやってみたという話です。

ついでにSwitchBotデビューしたので、ホームオートメーション欲がふつふつと湧いています。

記事にも書きましたが、読書灯の良い解が見つかっていないことと、書斎のカーテンがかなり古く気に入っていないので、今後の宿題として残っています。

ゲーム

そもそもあまり起動していませんでしたが、Switchのゲームは最近iPadをモニターにしていました。

sizu.me

もう少し大きい画面でプレイしたかったので、ビデオキャプチャカードを通してMac mini に接続し、OBSを立ち上げてMac経由で画面に映すようにしています。

少し反応が悪い気がしないでもないですが、リアルタイム性の求められるFPSや格ゲー系はやらず、フィットボクシングやリングフィットアドベンチャーゼルダFactorioくらいしかやらないので問題なさそうです。

OBSにせっかく繋いでいるしYouTube配信とかにも挑戦したいなとか思っています。

分類も難しいけど買ってよかったもの

ワゴン

よく使うケーブルやデバイス、工具などを入れるためにワゴンを買いました。これまでは本棚に入れていましたが、部屋の色調に合わなかったのと、本を整理したので、不要になり処分しました。

コンパクトと書いてありますが、収納力もわりとあり、別売りの蓋と組み合わせると簡易的なサイドテーブルにもなるので、意外と重宝しています。

また、スチールなので、側面にマグネットのものが貼り付けられるのもよいポイントです。

www.nitori-net.jp

ゲーム&ウオッチ

卓上の時計が欲しくていいのがないか探していたところ、以下の動画で紹介されていた、ゲーム&ウオッチに目が止まりました。*1

youtu.be

もともと存在は知っていたんですが、改めてみるとよさそうだなと思って衝動買いするとすごく可愛くて気に入りました。

スーパーマリオブラザーズ版ゼルダの伝説版がありますが、時計モードにしたときにマリオ版は給電しないとオートスリープになってしまい、オフにする設定もできないのが注意点です。

外出時にそれを回避するという理由をつけて両方買ってしまいました。

テーブルの上に置くのは、ミニ三脚を利用しています。コンパクトで可愛いです。

横にUSB type-cのポートがあり、これを指していると結構目立つので、U字型のアダプタで給電のためのケーブルを見えづらくしています。

ダンボールカッター

今回様々なものを購入して、多くのダンボールで届きました。そのオペレーションを支えたのはこのダンボールカッターです。

歯が短くて、中身を傷つける心配なく、スーッとダンボールを開くことができます。

マグネットにもなっているので、先述したワゴンの側面に貼り付けて利用しています。

終わり

*1:書斎の整備の情報収集でいろんなYouTuber見ていたんですが、この方がいろんな職業の方のルームデスクツアーをされている動画がすごく面白かったです。

# 2023年下半期振り返り

雑多に振り返り。

年末なので書いていきます。半年ごとになっています。前回のものはこれ。

blog.zuckey17.org

## 仕事

引き続きスタディストでエンジニアリングマネージャーとして働いています。在籍丸4年となり、過去で最長記録を日々更新中です。

入社以来新規事業に関わってきましたが、10月頃から別の事業に携わるようになりました。

10年以上続いているプロダクトで、関わる人数もかなり増えているので、これまでと違う難しさに直面しています。詳しくはもう少し時間が経過してアウトプットできればいいかなと思います。


7月にベトナムに出張に行きました。顧客事例のための取材と、商談、現地の企業の視察が目的でした。広報の方が記事にもしてくれました。

www.wantedly.com

仕事での海外は初めてでしたが、3日間過密スケジュールだったので、不自由を感じる前に終わりました。

日本と比べると路上の臭いや食べ物など気になるところはありましたが、アジアの中でも特に経済の成長が著しいということもありエネルギーを感じました。


blog.zuckey17.org

今年の目標の1つに大きめのカンファレンスに登壇する、というのがありました。Kaigi on RailsにCfPを出し通過して達成できました。

入社以降の4年間で、新規事業での開発について意識してきた内容を発表できたので、ちょうど総括になってよかったかなと思います。

規模も比較的大きく、マイクロサービスで運用されている事業においてこの考え方がどう変化していくのか、というのが来年以降の関心ごとの一つになります。


studist.tech

今年一年の開発組織全体での取り組みの総括をアドベントカレンダーで書きました。ただ、これに関しては僕がやったというよりは全体の動きを言語化したということで、僕がなにかを動かしたという実感はあまりないです。

来年は直に関わるメンバーも増えるためもう少し貢献できれば良いなと思います。

ブログにも書きましたが、オフラインのカンファレンスが盛んになる中、会社からあまりともに参加するメンバーが多くなく、Kaigi on Rails 参加でも寂しさを感じたので、興味のあるメンバーを巻き込んで参加していきたいなと思っています。

## プライベート

引き続き、息子中心の生活になっているかなと思います。

半年前と違って歩けるようになり、家のドアもだいたい開けて回れるようになったので、より目が離せなくなりました。

散歩のときに、公園で歩き回れるようになったので、かなり楽しいです。

椅子を経由してテーブルにも昇るのが危ないので、すべての椅子を倒しているんですが、その労力がけっこうつらいので他の家ではどうしているのか気になっています。

### 旅行

9月に宮古島、11月にディズニーリゾートに行きました。

撮った写真にはだいたい子供が入っているので、なかなかブログにはあげづらいですね。


9月の末に夏休みを利用して宮古島に行きました。 石垣島には行ったことがありましたが、宮古島は初めて。沖縄本島にはまだ上陸したことすらありません。

宮古島 東急ホテル&リゾートに1泊と、シギラリゾートのシギラミラージュに2泊泊まりました。

東急ホテルについては、前浜ビーチという東洋一美しいビーチと言われているビーチを目当てに泊まりました。 聞いていた通り、これまで見たどのビーチよりも綺麗に見えました。人も少なく、ゆっくりとした時間を過ごすことができてよかったです。

シギラリゾートはシギラ湾一帯がリゾートになっており、それぞれ特色のあるホテルや施設を循環バスで回るという感じでした。

シギラリゾートは、ザ・リゾートという感じで良かったですが、子供とともにベビーカーで移動しないといけないので、バスでの移動は少々都合が悪く、東急ホテルのほうがゆっくりと過ごせた気がします。

前浜ビーチ、東急ホテルからの夕暮れ


11月の平日に休みをとって、ディズニーランドに行き、その夜にディズニーランドホテルに泊まりました。

sizu.me

ディズニーランド40周年で絶対に行っておきたいという妻たっての希望で行きました。

平日に行ったにも関わらず、埼玉県民の日というのに被ってしまった&クリスマスということで、かなり混雑していました。

小さい子どもと一緒だと途中で昼寝もできるし、夜少し遅くまでいても負担が軽いということで、ランドホテルをとっておいてそこで泊まりました。

クリスマスツリー、ディズニーランドホテル

### 競技プログラミング

ほそぼそとAtCoderを続けています。

前回の振り返りブログから夏の間2ヶ月ほど止まっていましたが、9月中旬ころからABCに出ることも再開していますが、成果はあまりでていません。

入茶してからというもの、微増を繰り返しており、ちゃんとやるには止まっている鉄則本を最後までやることと、特にグラフ系の問題を理解する、DPをもう少しすっとかけるようになる、図形系の問題に慣れる、くらいを集中的にやる必要があるかなくらいに思っていますが、あまり時間を作れていません。引き続きやっていきたい。

また、12月に行われるAdvent of Codeにも意気揚々と参加していましたが、途中での会社の合宿で中断したことを経て、半分くらいで止まっています。年末年始休み中には1通り解きたいです。

Advent of Code では普段競プロに使っているGolangだけでなく、Clojureでも一部解いています。業務で関わるシステムで一部利用されているためにそれのキャッチアップで学習していますが、書くことは少しできるようになってきたものの、他人が書いたコードを全く読めないです。Lispは本当にすっと読めるようになるんだろうか、と思っています。

### キーボード

キーボードはZSAのMOONLANDAR や Ergodox EZといった分割キーボードを使っていましたが、KeychronのV8に変えました。

一つが不調になってしまったのと、値段が高すぎて気軽に遊べず、もし使えなくなったときに新調するのに勇気がいることから、別の選択肢を探していました。

blog.zuckey17.org

分割キーボードになれており、親指でdelete やenter keyなどを押す習慣がついているので、Alice配列というものを選んでいます。

$100以下で調達でき、ものとしてもかなり良いので満足しています。 会社にも同じものをおいており、会社では音を気にしてKeychronの茶軸を、家ではクリッキーなGateron Baby Kangaroo Switch Tactileでカチャカチャ言わせています。

これまで利用していた、分割キーボードたちは不調なものを除いて、メルカリで売ろうとしています。年始に重い腰を上げて売るつもりですが、今円安の影響を受けてかかなり高額で売れていそうなので、売るタイミングとしては良いかなと思っています。

### 漫画

新しく読んだ、読み始めたシリーズは以下。

Twitter などでパッと興味を引かれたら買ってしまうので、ちょっと雑多になってきています。 友人から進められたメダリストはすごく良かったです。やっぱりスポ根系が好きですね。

Dr.STONEはずっと興味があったので一気に読みました。序盤の石の時代から一気に文明が発達しているのが、マイクラのサバイバルモード感があって楽しかったです。

購読している漫画をしずかなインターネットでほそぼそと更新しています。

sizu.me

### ゲーム

引き続き友人とボードゲーム会をやりました。 今回は久々ということもあり、飲み会もやりましたが、休日の昼間から4,5時間ぶっ通しでやるボードゲームは最高です。

第4回もやりたい。

第3回にやったゲームはこれ。楽しくて自分でも買いました。

bodoge.hoobby.net

面談などの自己紹介で、アナログゲーム好きですね、って言ってるのにやってる回数は少ないので、会社などでもやれたら嬉しいなと思っています。

デジタルのゲームに関して、マイクラは下半期起動すらしなかったです。次期アプデ、マイクラの15周年で「自動作業台」が追加されて工業化がかなり進むのでめちゃくちゃ楽しみです。

minecraft.fandom.com

### しずかなインターネット

しずかなインターネットというサービスをリリース当初の11月中旬から利用しています。

sizu.me

雑に書いて出せるのでブログよりも時間をかけずにすっと出すということをしていて、すでに利用開始から今時点で39記事書いており、平均1日1記事くらい書いていることになります。

日記と、業務で考えたこと、意識したことのカンタンな言語化に使っています。

日記を書いていると、食べ物についての言及が多いことに気づきました。自分の普段考えていること、無意識の傾向に気づけると言うのは日記を書くことのメリットだな、と今更感じました。

もともと、デイリーポータルZの古賀さんの「5秒のことを200字かけて書く」というのをやりたくて、少し真似している部分もあるんですがまだまだうまくいきません。

古賀さんの本を買ってちびちび読みながら練習していくつもりです。

dailyportalz.jp

こういうのを書いていると、1on1や打ち合わせの冒頭のアイスブレイクに困らなくなるというのもいいなと思います。

三日坊主の僕ですが、引き続き続けられるといいなと思っています。


おわり

プロダクトマネジメントにも通ずる経営学の名著「ストーリーとしての競争戦略」を読んだ

この記事は 「エンジニア積読消化 Advent Calendar 2023」の10日目の記事です。

qiita.com

紙では558ページもあるほど長い本で、興味はあるけれどすっと手に取れないなと思っており、そんななか本アドベントカレンダーを見かけて意を決して読み始め、この度読了しました。

2010年に発売され、30万部も売れているロングセラーで世の中には要約やビジュアライズされた解説などもたくさん存在するため、中身の紹介はあまりせず僕の感想を中心に書きます。

中心の考え方はシンプル、事例が豊富

目次
第1章 戦略は「ストーリー」
第2章 競争戦略の基本論理
第3章 静止画から動画へ
第4章 始まりはコンセプト
第5章 「キラーパス」を組み込む
第6章 戦略ストーリーを読解する
第7章 戦略ストーリーの「骨法一〇カ条」

ページ数の多い本でしたが、中心となる考え方は2~5章にかかれており、そのほか、1章はストーリーの定義とモチベート、6章はまるまる企業の事例の読み解き、7章はまとめでした。

全編をとおして、考え方の紹介よりも事例に多くのページ数がさかれており、それが読者の理解を促してくれているように感じました。
経営学の素人の僕からすると、初見の専門用語もいくつかありましたが、事例の中で何度も何度も重要な概念がでてくるため、読み進める程に理解が進むのを感じました。このあたりがロングセラーたる所以なのかなと思います。

事例を読み解いて考え方を紹介しているので、「後づけの理屈に過ぎないのではないか」という疑問が多く寄せられるということはこの本書でも書かれています。

それに対して著者の方は

最初からストーリーの全体が細部まで出来上がっていたかというと、確かにそんなものはない。しかし、そうだとしても優れた経営者はごく初期の段階からストーリーの原型をつくっている。

と書かれています。

僕としては事例を読み解くことによって論理的な思考の訓練になっているとおもいました。
書籍の中でも、具体(過去の事例)と抽象(論理)を行き来して引き出しを増やすのが大事だ、と述べられています。
レーニングにもなりますし、読後の今はいろんな事業について考えてみたいな、という気持ちになっています。

また、2010年発売の書籍ということで「Twitter」がまだ新参のインターネットサービスで、当時の時点では収益源を見いだせていないものの、新しいサービスとして多くの人を捉えている、と紹介されており、「X」に変わった2023年からみるとおもしろかったです。

マネージャーにはストーリーテラーが求められる

僕がエンジニアリングマネージャーとして仕事を始めてからずっと、メンバーにいきいきと働いてほしいなと思って試行錯誤してきました。

そのなかで重要だと思っていることの1つが、事業全体のストーリーとそのなかの自分たちが担う役割について、僕の口から語ることです。
納得感を持ってもらえれば、ストーリーに矛盾しない範囲で裁量を持って楽しく働いてくれるんじゃないかな、と思っているからです。

これが、僕が本書を手に取ったきっかけでもあります。ストーリーテリングをうまくなりたい、という期待です。

また、本書でも以下のように書かれています。

筋の良いストーリーをつくり、それを組織に浸透させ、戦略の実行にかかわる人々を鼓舞させる力は、リーダーシップの最重要な条件としてもっと注目されてしかるべき...(中略)...人々を興奮させるようなストーリーを語り、見せてあげることが、戦略の実効性にとって何よりも大切

戦略を作るということは、ただ単に聞き心地の良いワクワクさせるモノを作るということでもありません。
環境や競合他社を見つめて違いを見出し、そこから論理的につながりそうな各種の施策について、本当に蓋然性が高いのかどうか、成功するのかどうか、をある種悲観的に検証していく必要がある、と書かれています。

これまで、ストーリーを用意するというと、いろんな情報をつまんできて組み立て、なんとなくイケてるものに仕上げる、という感じでした。 そういうことをしていると、ふわっとし過ぎたストーリーを用意してしまっているのではないか、ごまかしがあるのではないか、と少しモヤモヤしていました。

しかし、本書を読んだ後では、戦略についてステップバイステップで考えられそうで、考えることそのものも楽しめそうだな、と思いました。

プロダクトマネジメントにも通ずる

本書は経営学の本ですが、会社の戦略ではなく、事業の戦略を対象にすると明確にかかれています。
僕が所属するSaaSビジネスの文脈では、事業の戦略はほぼプロダクトマネジメントの戦略と同義と考えてもよいと思います。

プロダクトチームのあり方を記載した書籍、「EMPOWERED」でも"ナラティブ"というツールについて以下のようなことが書かれています。

解決しようとしている問題、その問題を解決することが顧客と自社に価値をもたらす理由、そして解決するための戦略をストーリー仕立てで綴る

ナラティブを用意する1つの方法として、本書の切り口が利用できそうに思いました。

本当のところ誰に何を売っているのか、どのような顧客がなぜどういうふうに喜ぶのかを明らかにすれば、自分たちはそのためになにを作り、なにを作らないのか、ということを考えることに繋がるため、この考え方はプロダクトマネジメントに通ずるものがあると感じました。

賢者の盲点

最後に、面白いと感じたのは賢者の盲点を狙っていこう、という考え方です。

賢者の盲点

一般的に非合理に見える意思決定も、部分的に非合理だというだけで、全体的なストーリーの観点では合理的になっていることもある、というものです。

成功したとみられる事業は真似されることが当たり前だと考えていたほうが良さそうです。
しかし、一見すると非合理な部分は、非合理であるがゆえに他社は真似しようとも思わないのだそうです。
また、その他の合理的なものばかりを真似されても、非合理に見える部分が伴わないと片手落ちになり、結果として自社の競争優位を確固たるものにしてくれます。

プロダクトマネジメントの文脈でも、合理的な意思決定ばかりしていると結局機能比較のマルバツ表と戦うことになりつらい、みたいなことはあるあるだと思います。
このようなあえて非合理的な意思決定をするためには「本当のところ誰になにを売るのか」というのを考えきる必要がありそうです。

まとめ

「ストーリーとしての競争戦略」を読みました。 事業、もといプロダクトのマネジメントについて考える上で、だいじな考え方が書かれていたかなとおもいます。 経営学初心者でも十分楽しく読むことができました。

Kaigi on Rails 2023に参加して登壇しました

Kaigi on Rails 2023に参加しました。

家に帰ったら即寝てしまいそうなので、熱量が冷めないうちに高田馬場のスタバで書いています。
昨年はオンラインで、しかもほとんどリアルタイムではなく後からアーカイブを追うという参加の方法でしたが、今年はオフラインで全日程参加できたので、そこそこの疲労感があります。
というので、たぶん文章にまとまりはないですが、後から修正することは無いと思います。

登壇

どこかに書いていたわけではなかったんですが、今年の目標の1つに大きめのカンファレンスに登壇する、というのがありKaigi on Railsでそれが実現できてよかったです。 初参加の去年、2023年はCfPを出してみよう、と思っていたので採択いただけて本当に嬉しかったです。

speakerdeck.com

実際の発表資料はこれ。登壇終了後に公開を急ぎ過ぎてURLをキレイにするのを忘れたのが残念です。

コロナ以降、久々に物理のイベントでの登壇でした。これまではLT会などでの発表ばかりだったので30分も話すというのは、資料づくりを含めて初めての体験でした。発表そのものだけでなく、資料作りのプロセスについても反省が多く、今後に活かしたいと思います。

トークの内容については、当初想定していたよりも柔らかめの話しになっており、大きめのテックカンファレンスでこんな感じで良いんだろうか、と思っていましたが、柔らかめの部分のほうが皆さんの反応が良かったので僕のトークとしては良かったんじゃないかなと思いました。

いくつか技術的なHowについてTwitterでもご意見いただきまして、アフターパーティーで実際にお話ができて補完ができたり、違う視点をいただけたりしたのでそれも含めて登壇してよかったです。

僕の言いたかったことは、全ての場合でテーブルを作ってみたり、同じデータを違う場所に置くのを全肯定したりするのではなく、コアのドメインがある上で、よりユーザーに近くてまだまだ固まりきらないようなコードや機能については削除しやすくしておきましょう、ということでした。
逆にコアのドメインについてはデータモデリングを用いてしっかり設計したいよね、ということだと思います。主題ではないので省きました。

発表直後は「終わったぞーーーー!」感が強かったんですが、そこから他の方々の登壇を聞いているうちに、次どこかで話すためにまたインプットして打席に立たないと、という気持ちになっているので怖いものです。モチベが高いうちに一歩目を踏み出したいです。

余談

息子を家に置いて出たわけですが、テレビで応援してたよ、と妻からLINEが入っており登壇の緊張から解放された感と相まってほっこりしました。2日間まるっと家をあけることを快く許してくれた妻には感謝。

参加者として

1日目は自分の次の日の登壇に向けて頭がいっぱいだったのと、2日目は登壇に緊張しすぎて早く起きすぎてしまい眠かったので、他の方の発表は明日にでもYouTubeで復習したいです。

そんな中でも、今の時点での個人的ベストトークは、1日目午後のmoroさんの「Simplicity on Rails」というトークでした。 イベントエンティティを見つけ出してRailsのアプリケーションをシンプルに設計するというトークで、難しい概念をうまく言語化されていたと思います。

speakerdeck.com

おそらく今後何回も見返すと思います。

あまりRuby on Railsの界隈に知り合いがいなかったので不安でしたが、1日目はluccafortさんにランチに誘っていただけたり、2日目は登壇後にお声をかけていただけたりと、オフラインでのイベントを楽しむことができました。

アフターパーティー

アフターパーティーでも、界隈にそんなに知り合いがいないので不安でしたが、運良く#textafm の_yasaichiさんに話しかけることができ、#textafmを全エピソード3回ずつ聞いてます!という気持ち悪い告白をした後、moroさんのトークがめちゃくちゃ良かった(textafm のエピソード3で言いたかったことはアレですよね!というやつ)などの話をして、すごく楽しかったです。

そして、moroさんにも個人的ベストトークでした!と伝えることができて僕としては満足でした。

さらに、ここでもluccafortさんに繋いでいただいて、twitter IDは存じ上げていた onkさんに僕の発表への共感ポイントを言っていただけて嬉しかったです。

来年も参加したい

参加者の中には同じ企業で集まって同じTシャツを着て参加されている方々もいらっしゃって、すごく羨ましかったので、そこまで目立たなくとも’次回は他の同僚のエンジニアも巻き込んで参加できたらもっと楽しめるんじゃないかと思いました。来年以降の目標にしたいなと思います。

もちろん、CfPも出したい。やっていくぞ

おわり

Raycast × Open AI API × Notion で自作英単語帳

昨年末の振り返りで、2023年こそは英語で本を読みたい、と書いたのですが、半年経ってまだ読めていなかったので易しめで軽いものを読み始めました。

The Art of Readable Code: Simple and Practical Techniques for Writing Better Code

日本語版も読んだことは無いですが、だいたい言っていることはわかるだろうと思ったし、日本語版だとだいぶ薄かった記憶があったので選びました。 しかし、読み進めていくと意外と知らない単語が多いなということに気づき、毎回ブラウザからググってメモするよりも、コマンド一発で普段使っているNotionのDBに登録してくれないかなと思ってやってみました。

動作

Raycastというランチャーアプリから登録しているスクリプトを実行することができます。 英単語を引数に与えてスクリプトを実行すると、OpenAI のAPIを呼んで英単語をもとに必要な情報をJSONで返させ、それを Notion 上に用意した英単語DBに格納するために、DBのレコード作成APIを呼ぶ、そういうスクリプトを書きました。

Raycastでなくともターミナルから同様のスクリプトを実行しても良いですが、Kindle を開きながらおもむろにスクリプトを実行するには、Raycastが便利でした。

Raycast

MacでランチャーアプリとしてRaycastを利用しています。

SpotlightやAlfredの代替として最近使われている方も多いように思います。

アプリケーションやファイルの検索、電卓、クリップボード履歴やスニペット辞書など便利な機能が沢山ありますが、今回はその中でもRaycast Script Commandという、登録しておいたスクリプトを実行できる機能を利用します。

Raycast Script Command

Raycast Script CommandにはBash, Apple Script, Swift, Python, Ruby, Node.jsで書かれたスクリプトを登録することができます。自動化したり、外部のAPIをたたいたり、何かと便利です。 登録しておいたスクリプトには、引数を最大3つまで設定することができたり、スクリプトにショートカットを割り当ててすぐに使えるようにできたりもします。

今回Rubyを利用しました。

Raycast 上で create script command とタイプし、作成ダイアログから作成すると。

お目当ての言語のファイルが作成され、ダイアログから作ったスクリプトにはメタ情報がファイル先頭に書き込まれています。

今回は、細かい Raycast Script Command の使い方は説明しません。

github.com

OpenAI

英単語帳には以下の情報がほしいなと思いました。

  • 日本語訳
  • 英英辞書的な説明
  • 類義語
  • 発音記号
  • 例文

簡単に使えそうな外部APIも見つからなかったので、OpenAI社のAPIを利用することにしました。 課金が必要ですが、LLMをはじめとしたAIモデルを利用できるAPIで、チャット/画像生成/文字起こし/テキストの分類などの機能があります。 今回は、チャットを利用して英単語から上記の情報をJSON形式で返させるということをしました。

実装

以下のようなスクリプトで OpenAI API を叩きます。

word = ARGV[0] # スクリプトの引数 = 英単語

uri = URI.parse('https://api.openai.com/v1/chat/completions')
request = Net::HTTP::Post.new(uri)
request.content_type = 'application/json'
request['Authorization'] = "Bearer #{open_ai_api_key}" # OpenAI APIのAPI key

request.body = {
  model: 'gpt-3.5-turbo',
  # 回答に至るまでのチャットを入力
  messages: [
    { role: 'system', content: system_message },
    { role: 'user', content: word },
    { role: 'system', content: '{ "additional_info":' }
  ]
}.to_json

req_options = { use_ssl: uri.scheme == 'https' }

response = Net::HTTP.start(uri.hostname, uri.port, req_options) do |http|
  http.request(request)
end

POSTパラメータには、AIモデルの指定をし、messagesというプロパティにAIが回答を出力するに至るまでのメッセージを入力します。

このメッセージは以下のような入力をしました。

## システムプロンプト

  Based on the English word entered by the user, output the "Japanese meaning", "English description", "thesaurus", "phonetic symbols", and "example sentences" in the following format (JSON).

  # Given word

  description

  # Output

  {
    "additional_info": "this is additional info",
    "ja": "記述、叙述、描写",
    "description": "a statement that represents something in words",
    "thesaurus": "account, characterization, chronicle, depiction, description, detail",
    "phonetic_symbols": "dɪskrípʃən",
    "examples": [
      "the description of the event was quite different from what had actually happened.",
      "The description of the book was accurate."
    ]
  }

## ユーザー(つまり自分)のメッセージ = 知りたい英単語

Dog

## システムプロンプト

{ "additional_info":

はじめのシステムプロンプトでは、モデルに対して「ユーザが入力した英単語をもとに、"日本語の意味"、"英語の説明"、"類語"、"発音記号"、"例文"を以下の形式(JSON)で出力してください。」という命令をしています。 その後に例として「description」という英単語と、それに対する想定する出力を ほしい形式で定義しています。 いわゆる one-shot learning というやつになっています。

最後のシステムプロンプトは、{ "additional_info":という文字列です。 レスポンスとして、JSONだけを返してほしいのですが単純にユーザーが入力するだけだと、JSONに付随して説明的な文章が返ってきてしまうことが多いです。それを防ぐための工夫として 先に{ "additional_info": を入力し、それに続けさせることで、JSONだけを出力してくれることを期待しています。返ってきた文字列の先頭に、このシステムプロンプトの文字列を繋げれば、正しい形のJSONになります。 この他にも、 ```json のようなものを入力する場合もあるようですが、僕の場合はこれがうまく行きました。

また、additional_info という key が JSONに含まれているのは、valueにその他の説明を入れるように暗に促しているという役割があります。

Notion

最後に、英単語とその情報を保存するためのNotionです。 ふだんはメモやタスク管理につかっていますが、英単語のテーブルを用意して1レコード1単語にしました。

APIによって、レコード追加や編集ができますが、こちらもAPIの利用には課金が必要です。

uri = URI.parse('https://api.notion.com/v1/pages')
request = Net::HTTP::Post.new(uri)
request.content_type = 'application/json'
request['Authorization'] = "Bearer #{notion_api_token}"
request['Notion-Version'] = '2022-06-28'

def create_content(text)
  { object: 'block', type: 'paragraph', paragraph: { rich_text: [{ type: 'text', text: { content: text } }] } }
end

request.body = {
  parent: { database_id: english_words_database_id },
  properties: {
    en: { title: [{ text: { content: ARGV[0] } }] },
    ja: { rich_text: [{ text: { content: res['ja'] } }] },
    sym: { rich_text: [{ text: { content: res['phonetic_symbols'] } }] }
  },
  children: [
    create_content(res['description']),
    create_content('## thesaurus'),
    create_content(res['thesaurus']),
    create_content('## examples')
  ].concat(res['examples'].map { |e| create_content(e) })
}.to_json

req_options = { use_ssl: uri.scheme == 'https' }

Net::HTTP.start(uri.hostname, uri.port, req_options) do |http|
  http.request(request)
end

今後

まず、OpenAI のAPIは単に遅いので2回目以降だと検索回数だけインクリメントするようにする、というのは追加しようと思います。

また、定期的に振り返りのために英単語の問題を出力するようにしたり、いくつかの英単語をピックアップして、長めの例文を生成させるみたいなのも試してみたいと思っています。

おわり

Raycast Script Commandはコードで作業を自動化できて楽しいです。

複雑なことをしたわけではないですが流行りのLLMを触ってみました。OpenAIのChat Completion APIの雰囲気はわかったのでこれから他のことにも試めせそうです。