valid,invalid

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

SmartBank, Inc.に入社して3年経過した

キャリア エンジニア

タイトルの通りSmartBank, Inc.に入社して3年が経過したので記念に整理。

ちなみに前回書いたのは1.5年経過のタイミングで、だいぶ遅まきの入社エントリであった。

ohbarye.hatenablog.jp

やってきたこと

半年なり1年なりの区切りをトリガーに書いていれば差分を書きやすいのだけど、その習慣がついていないのでやむなく、今回は3年分まとめて書いてしまおう。3年間でやってきたこと*1のうち公にしているものたち*2を並べるとたくさんあるが、もちろんほとんどはチームでやってきたことである。

所感

いろいろやったな〜と思いつつ事業に直結する機能開発とエンジニアリング面での取り組みを両立するには、資金調達の成功や事業がしっかり成長軌道にあることが前提だと再認識した。

一つ目のプロダクトローンチ前の"立ち上げ時期-ｾﾞﾛｲﾁ-"に入社したにも関わらず、"方向転換-ﾋﾟﾎﾞｯﾄ-"することなく"成長-ｸﾞﾛｰｽ-"に繋がり、今も集中的にリソース投下できている環境はありがたい。3年前の意思決定の成功は追認しても良いだろう。

余談だが、最近アーリーステージのスタートアップの選び方なるものを知人に聞かれることが何度かあった。メガベンチャーや上場後の企業勤めで、一度はスタートアップで働いてみたいという好奇に由来することが多いようだ。経験はしてみたいけれど事業以前に組織が破茶滅茶でないか、エンジニアリングが軽視されていないか、ハードワークすぎるカルチャーでないか。等々の不安を解消できるほど情報がオープンにされている会社が少ない...という感じられているらしい。

スタートアップに限らず会社選びは何を求めているのか次第なので画一的なアドバイスはできないし、事業の良し悪しや成否の蓋然性を評価できる"眼"は自分にはないけれど、ファウンダーや経営陣に複数回の起業を経験しているメンバーがいるかどうかを評価軸に加えてはどうかと伝えている。シリアルアントレプレナーというやつだ。

そうした経営者は前回までの起業の成否や反省を踏まえて落とし穴やアンチパターンを避けることに意識的だし、事業を伸ばすには持続可能でスケーラブルな組織が必要なことも知っている可能性が高い。*3

やるべきこと・やりたいことに注力できている環境の一要因、一例として自己の経験からそんなことを思っていた。

話が逸れたけれども引き続きやっていきます。僕と同じサーバサイドエンジニアに限らず各職種を積極採用中なので気になる方はぜひお声がけください。

カジュアル面談への応募

*1:時系列はバラバラ

*2:公にしているというか、CVに記載しているようなもの

*3:もちろんこういう質問をしてみようとか、バックドアリファレンスはとろうとか、他にもたくさん言えることはある

AlfredからRaycastに移行した

社用のmac移行に伴い、ランチャーアプリをAlfredから同僚が薦めてくれたRaycastに乗り換えた。

www.raycast.com

Alfredはだいぶ前に有料課金していて、どの機能が有料のものなのかもはやわかっておらず、使いこなしていると言い難いレベルだった。なので、とりあえずRaycastの無料版でなんとかなるか試してたらなんとかなった。

移行して嬉しかったポイント

  • クリップボードあるので専用のアプリ (Clippy etc.) が不要になった
    • Alfredにある機能は使っていなかった
  • ウィンドウ管理できるので (Magnet, BetterSnapTools etc.) が不要になった
  • アプリ横断したグローバルなSnippets置き場あり
  • Night Shiftのon/off toggleができる
    • Alfredでは自作のworkflowを作ったのだがOSアップデートですぐ壊れるので途中で諦めてた
  • Confettiという賑やかしコマンドがあって画面共有時に一段"上"にいける

サブスクリプションモデルで提供される有料版機能も一度は試してみたいが、Alfred同様に使いこなす前に忘れそうな気がしておりまだ手を出していない。

設定画面のわかりやすさやデザインが圧倒的にRaycastのほうが好みなので引き続き使っていく所存。

Web API設計時に使われ方の想定を添えると良い。けどより良いやり方を知りたい

API Web OpenAPI

先日登壇したイベントにて、仕事で協業したモバイルエンジニアから「Web APIのドキュメントに使われ方の想定が添えられていてありがたかった」とフィードバックをもらった。

具体的にはX post (以下、tweet) に添付した画像のような感じで、Web API (以下、API) が呼び出される画面・タイミングの想定、レスポンスの使われ方の想定などをUIのスクショとともに記述する、というもの。

他にもこんなのとか。

APIレスポンスの使われ方の想定を書いているようす

このことについて思ったよりもイベント内外で反響があったので書く。

ドキュメントの種類、やっていること

まず、文脈を補足しつつやっていることを詳しく書いてみる。

ここでいうAPIとは特定のクライアントしか利用しない、内部にしか公開していないAPIである*1。このようなAPIを開発する過程で2種類のAPIドキュメントを書いている。

  1. RESTish APIのOpenAPIドキュメント
    • 構造的にAPIの仕様を記述
    • repositoryにコミットされるYAMLファイル
    • ストック情報
  2. プロジェクトの過程で記述するAPIドキュメント
    • 非構造的にAPIの概要・レスポンス例・使われ方を記述。変更内容やその理由・背景を添えることもある
    • Notionページであり、コードベースとは独立して存在
    • フロー情報

tweetで言及したのは2のほうのドキュメントである。

そもそも「なんでOpenAPIと二重にドキュメント作ってるの？」みたいなツッコミがありそうなので先に回答しておくと、2つのドキュメントの目的・用途は大きく異なる。

  1. OpenAPIのほうはストック情報。構造的に仕様を記述するもの。記述した仕様とコードの挙動が一致するかどうかのテスト自動化も行っている。これまでに書いてきた蓄積のうえに追記する。
  2. tweetで言及したほうはフロー情報。「今回のプロジェクトで追加/変更するAPIの一覧と説明」のようにスコープを絞ったページを新たに追加する。一時的なコミュニケーションに役立てる一過性の情報。構造化する必要はなく意思疎通や意思決定の促進のために書く。

ドキュメントへ期待してよいことと、前提

コミュニケーションツールとしてのフローAPIドキュメント

フロー情報のほうのドキュメントの必要性にもう少し言及すると、自分の場合は「自分がつくったAPIでUI上でのユースケースを満たせるか」を脳内検証するのを一義として書いている。

具体的には

💭クライアントは画面を開いた時に#GET v1/productsを呼んで商品一覧を表示。レスポンスのフィールドproducts[i].nameはそのまま、products[i].priceは,で区切って表示。ユーザーが購入ボタンを押したら#POST v1/ordersへproducts[i].idの配列を送って...

みたいに。この作業過程が「UIのスクショを貼って使われ方の想定を書く」にあたる。

成果物が結果としてクライアントサイドに役立つと企図してはいるが「この通りに使え」という意味ではなくて「こう使ったら仕様を実現できると思うけどどう？」ぐらいのノリ。

書いた後にはクライアントサイドの同僚にもレビューしてもらうので、想定質問や要議論ポイントも書く。過不足あれば当然修正する。

要議論ポイントをあらかじめ整理してぶつける

このような試行錯誤やコミュニケーションを行いたいという要求に対し、OpenAPIでは物足りない。

OpenAPIにはプロジェクトにスコープを絞ったような情報は基本的には書かない。加えて、画像を貼ったり図示したりとリッチな記述はできないし（できないと思っているけどやり方があれば知りたい）コミュニケーションツールとしてはかなり厳しい。OpenAPI編集を行うpull request上で議論を進めるプロジェクトも過去にあったが、あまりうまくいかなかった。

そう、構造化されたAPIドキュメントだけでは足りないから、やっている。

これはRESTishかどうかに関係なく、プロトコルやインタフェースによらず生じる課題だと思っているのだがどうか。

みなさんのチームではどうしてますか

とはいえ、スクショ貼ってコメント付けるって、2023年でもやっているとは思ってなかった。プロジェクトではNotionを使ったのでスクショをペタペタ貼っただけで、Figmaなりの最新のcoolなデザインツールに直接コメントしてももちろん良いのだけどあまり体験としては変わらない気がする。

引用retweet (引用repost?) にもあったけど「我々のコミュニケーションを行うためのプロトコルはコレしかないのか？」って感じです。

他に良いやり方があれば切に知りたいのですが、みなさんのチームではどうしていますか？

*1:SSKD = Small Set of Known Developersってやつ

『研鑽Rubyプログラミング』を読んだ

Ruby 読書

『研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ』を読んだ。ちょっとブームに乗り遅れたけどまぁ、本なんていつ読んでもいいものなので気にせず感想を書く。

研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ

研鑽Rubyプログラミング 実践的なコードのための原則とトレードオフ

Amazon

想定読者層はあらかじめ示されているとおり中級〜上級で、Ruby初学者には厳しめ。RubyやRailsでのアプリケーション開発にそこそこ慣れてきた自称中級者が読むと知識の広がり幅が大きくて良さそう*1。

同じようなレベルの層に対してよく推薦される図書として『メタプログラミングRuby』があると思うのだけど、そちらよりは平易かつ実践的な内容が多いと感じた。

具体的にはDSLやプラグイン機構の作り方など、ふだんのWebアプリケーション開発業務でしょっちゅう書くわけじゃないけど、書き方を知っているとライブラリの中身をすいすい読めたりして便利、という知識がふんだんに詰まっている。

このあたりは僕のぜんぜん知らないテクニックもたくさんあって学びが多かった。

互換性への考慮、ソフトな移行などは単一コードベースを触っている場合（というか実装者と利用者が同じ場合）だとあまり気にせずエイヤとやってしまうこともままあるが、ライブラリ設計者としてはそうもいかない、というあたりも当たり前なんだけど良かった。また、使いやすいインタフェースに心を砕く重要性も伝わってきた。

こういう"ライブラリ作者や言語設計者の目線や頭の中"をのぞける書籍はあまり読んでこなかったかもしれない*2。

いろんな方の感想を先に読んでいるときに議論を呼ぶコードスニペットへのツッコミとか、こんな最適化するか？といった是非への言及が見受けられたので、"極端な内容"なのか...!? とどきどきしていた。

が、蓋を開けるとタイトルの通り原則とトレードオフの解説が丁寧で、良い意味で期待を裏切られた。

いろんな選択肢を示しながらも、経験の浅いプログラマに「これが最速なのか、よっしゃ真似したろ！」みたいな特攻をさせないようブレーキがかかっていたり。

RubocopのくだりとかはRubyKaigi 2022の@nay3さんの発表 "The Better RuboCop World to enjoy Ruby" を思い起こさせるものだった。

RuboCop が「あなた自身よりもよくわかっている」と想定してデフォルトの恣意的な制限をそのままにするのはやめましょう。あなたのコードの API にど んな意味があるのかを判断するのはあなたです。

ここに限らずコードの良し悪しを自分で判断できるようになりましょう、というメッセージが通底しているのが響いた。

だいぶ最初のほうだけど「Structはもっと評価されるべき」はかなり同意した。今のRuby 3.2だとだいたいDataクラスになるけど実務でもよく使う。ビジネスロジックやアルゴリズムを簡易に表現できるようなデータ構造を見出せたときの気持ちよさはすごい。

雑感は以上。改めてまえがきを読んで以下の一節に一層の真実味を感じる。

「どんなトレードオフがあるかを知る」ことは最重要なプログラミングスキルのひとつなのです

本書は、内容について読み手が意見を表明したり議論する価値が大いにあるタイプの本。読んで終わるだけでなく、そのような活動を通じて読者やコミュニティが価値基準と判断力を獲得していくだろう...というあたりまで狙っているとしたらすごいですね。

(2023-06-11 追記) というわけで他の方々の感想も是非。

scrapbox.io

*1:僕じゃん

*2:『APIデザインケーススタディ』ぐらいか

毎日やったことをGoogle Calendarに記録してる

人生

今年に入ってから毎日やったことをGoogle Calendarに記録するようにしており、5ヶ月続いているので習慣化できてきた。

やったことを書くと言っても大それたことではなく、生活をちゃんとやっているな〜と自分で認められるようなこと、日記を書くほどでもないことを箇条書きにしているだけ。*1

  • ランニングや筋トレをした
  • RSSリーダーに溜まっている記事を消化した
  • 行ったことのない店に行った
  • コーヒー豆を買った
  • 楽器を弾いた
  • 他にもクラフトコーラを作ったとか、図書館に寄ってレコードを聞いたとか、なにか新しいことをやったとか

ほとんどはやったあとに事後で記入しているが、翌日や週末にやりたいことを前もって書くこともある。

実際のようす。Tasksとして登録している

始めたきっかけは昨年末に読んでいた2つの本で、異なる目的で似たような手法を紹介していて面白そうだと思ったから。

1つ目の本は『不老長寿メソッド 死ぬまで若いは武器になる』。タイトルはうさんくさいがかなり健康意識を高めつつHowも提供してくれるので気に入っているし知人に推薦している。

不老長寿メソッド 死ぬまで若いは武器になる

不老長寿メソッド 死ぬまで若いは武器になる

Amazon

睡眠改善のテクニックの1つとして紹介されていたブレインダンプという手法が僕のやっていることに近い。2018年の研究が紹介されており、寝る前に次のことを書き出すことで眠りにつくまでの時間が平均9分早くなったという。

  1. 明日やらなければならないこと
  2. 今日成し遂げたこと

ちなみに9分早く眠れると聞いても大したことなさそうだが睡眠薬の効果とほぼ同じらしい。

もともと睡眠難民ではないほうだけど引き続き寝つきよく過ごせている要因の1つはブレインダンプによるものかもしれない。

2つ目は『ジェームズ・クリアー式 複利で伸びる1つの習慣』で習慣トラッカーと紹介されているもの。習慣にしたい行動を決め、行動したらカレンダーに書き込むというシンプルな記録法だ。

ジェームズ・クリアー式 複利で伸びる1つの習慣

ジェームズ・クリアー式 複利で伸びる1つの習慣

Amazon

僕のやっている記録は特定の習慣にフォーカスしているわけではないので厳密には同書のやり方とは違う。だが、記録のおかげで実際に続くようになった習慣もあり、「習慣トラッカーではやったことが目に見え、前進を実感しやすく、記録すること自体が報酬となって満足度を得られる」という主張に完全に同意するところとなった。

たまに"何も記録することがない日"もあるのだが、そうした日が2日や3日連続しないように意識して生活するようになったのは、「最初の過ちはアクシデントであり、それだけであなたを駄目にするものではない。駄目にするのはそのあとに続く負のスパイラルである」という一節の影響を受けている。

僕は使っていないけど習慣トラッカーテンプレートも公開されている。

LLMの発展を目の当たりにして「なんでもいいからとにかくテキストや音声で記録を残しておく」ことの重要性をひしひし感じている。このような取り組みで残した記録もやがて面白い形で二次利用できたら良い。*2

というカッコつけた理由もありつつ、なんか最近いろんなことを忘れていってしまうんだよな。忘れてもいいけど、思い出せる外部記憶装置がほしい。

...ということをshibayu36さんの記事を読んで思い出し、目的は違えど自分も記録に残しておきたくなったのだった。

blog.shibayu36.org

*1:特にルールにしているわけではないが「仕事以外で"生の実感"を得たい」というモチベーションがあるので仕事のことは基本的に書いていない

*2:ブログや日記を使った試みはすでにあるし

ChatGPT Prompt Engineering for Developers講座を視聴した

AI

同僚が推薦していたChatGPT Prompt Engineering for Developers講座を一通りやった。*1

www.deeplearning.ai

DeepLearning.AIの提供、そして講師の1人がAndrew Ng先生ということもあり気になっていたのでさらっと視聴してみた。

Prompt Engineering Guideを読んだ人ならだいたい知っているような内容だが、よりコンパクトでわかりやすく実践的。講座で最初に提示する基本的な原則に従い、要約・変換・推論などの具体的なタスクを解く実例を見せてくれる。どの例もビジネスシーンで見られるようなものなので価値が伝わりやすい。

とりわけ気に入ったのが、最初からすべてうまくいくのではなく「企画 → 実装 → 実験 → エラー分析」を繰り返すことが重要だと強調している点。たくさんのプロンプトを暗記するよりもプロンプトの開発プロセスを確立するのが重要だと説いている。まさしく"エンジニアリング"じゃん...と思った。

体験面では、画面にJupyter Notebookがembedされており、講義動画を視聴しながら実際にプロンプトを実行できる学習体験が素晴らしい。Progateのようなプログラミング講義動画サービスは少し前からあると思うけど、実行環境が付属することで本質に集中することができて良い。オンライン講義も進化しているなぁと感じた。

ピクチャーインピクチャー便利

最強のプロンプト何十選みたいな記事を読み漁ったり暗記するよりも遥かに有用。字幕もある（＝DeepL等で翻訳しつつ視聴可能）のであらゆる人におすすめもしやすい。

視聴メモ:

scrapbox.io

*1:講座とはいうものの動画は1.5時間程度だしテストがあるわけでもないので実際には視聴してコードを実行しただけだが

ブラウザ外でもVimiumしたいのでHomerow使い始めた

HomerowはmacOSのUI操作をキーボードのみで行えるようにするツール。腰痛エンジニアを支える技術で見かけて気になったので導入したらとても良かった。

動作イメージは公式サイトの動画を見るとわかりやすい。

www.homerow.app

ショートカットを入力するとUIのclickableな箇所にラベルが付く。ブラウザ操作ではVimiumを使っており、ブラウザ外でも同じように操作したいと思っていたのが実現できて便利。

マウスやトラックパッドに手を伸ばして操作してたSystem Preference

設定

少しだけカスタマイズしている。

  • ショートカットはCtrl+f
    • Vimiumのfと近いように
  • Disable search & show all labelsをON
    • UIラベルの一部を入力すると絞り込んでくれるが面倒だしラベルなしUIも多いので

Image

ちなみにブラウザ操作やカスタマイズ性はVimiumにまだまだ利があるので、ブラウザではVimium、ブラウザ外ではHomerowというように使い分けている。

料金

今はalpha版ということでいちおう無料でも使い続けられるがちょっとした「課金してね」プロンプトが出る。そのうち制限が入りそう。

とても気に入ったし頑張ってほしいのでStandard License $39 (mac 2台まで利用可能) を購入した。私用と社用のPCでアクティベーションする。

※ 1台で十分という人はBasic License $29 (mac 1台まで利用可能) でよい。