2024~2025年の振り返り
2025年もあと数日を残すばかりとなりました。
ふと空き時間ができたので、ここ2年くらいの振り返りを書いてみます。
仕事
業務面はあまり立ち入ったことは書かないのでさらっと。
チームリーダーになった
今年の10月にチームリーダーになりました。聞くところによると新卒入社では最短との噂です。
もともと四六時中コーディングや技術を触っていたいタイプではないので、仕様策定やPdM系のタスクなどにも手を広げることができて楽しくやってます。とはいえスタートアップあるあるだと思いますが、めちゃめちゃコードも書いています。
印象的なこと
昨年11月に、社内で代々続いているTechTalk（隔週開催のLT会）の司会を引き継ぎました。
隔週でLT会の司会をしたりちょくちょくスケジュール調整なんかをしていますが、社内のほとんどの方に名前を覚えてもらえているので嬉しいです。
https://www.m3tech.blog/entry/2024/12/21/120000#view-changed（前任の方の記事）
今月に、エンジニア版シャッフルティータイムというのを勝手に立ち上げました。毎月ランダムに組まれた4人で雑談会をするという趣旨のものですが、もともと他の方が会社全体で実施されていたもので、そのエンジニアローカライズ版を作った形です。
そのほか、長らく放置状態になっていた社内Slackの #frontend チャンネルを活性化させるべく、ちょいちょい投稿したりしています。
イベント系では、 採用イベント に出たりサポーターズさんのイベントに登壇したりしました。後者は自分以外の登壇者が全員CTOというなかなか面白い状況でした。
あとはTypeScriptのクワインプログラムを書いたらクリアファイルになりました。
https://x.com/vaaaaanquish/status/1977281909685416439?s=20
カンファレンス（TSKaigi）
立ち上げ期から関わっているTSKaigiですが、今年の10月に正式にコアスタッフになりました。
今年はTSKaigiにめちゃめちゃコミットしていて、TSKaigiがやっているイベントのほとんどで中心的に関わっています。
この中でも、地域版である京都開催・金沢開催ではチームリーダー、サブイベントであるMashupは運営代表的な立ち位置で関わっています。
TSKaigiは東京と地域版を半年おきに開催しており、さらにその間にMashupを開催していますので、ほぼ年中何かしらやっています。
最近は「TSKaigiで話していた人ですよね？」と声をかけていただくこともあり非常にありがたい限りです。
スタッフをやる理由
楽しいからです。
あとは、カンファレンスの場は素晴らしいです。
登壇経験のあるスタッフとして思うことは、カンファレンスの登壇が憧れの場になり、たくさんの人が登壇したいと思える場所になると良いなと思っています。
初登壇の方がいたらめちゃくちゃ拍手をします。プロポーザルを出すのは勇気がいるし、それなりの作文や言語化が求められます。採択までもハードルがあり、採択されてからも発表内容を練り資料を作り練習をして、いよいよ本番で話します。TSKaigiでは100人近く、あるいはそれ以上の人の前で発表するわけです。すごく大変な分、とても素晴らしい体験です。ぜひたくさんの人にこの場に立って欲しいと心から思っています。そして、その場を提供するのが運営の役割だと思います。
登壇
今年はたくさん登壇するぞ、と意気込んでいましたが、宣言通りたくさん登壇することができました。
- TSKaigi Kansai 2024 「複雑なフロントエンド（ノーコード）を堅牢に作る」（スライドリンク、トーク概要ページ）
- LayerX Web Frontend Night 「Reactに依存しない状態管理のアプローチ」（スライドリンク、イベントページ）
- サポーターズColab 「開発現場への生成AIコーディング実践投入」（イベントページ）
- TSKaigi 2025 「ts-morphで、人間も編集できるコード生成を実現しよう！」（スライドリンク）
- TSKaigi 2025 本編で話せなかったこと、話したりなかったこと 「型レベル四則演算」（ スライドリンク、イベントページ ）
- フロントエンドカンファレンス東京 「メディアクエリだけではない、レスポンシブ対応の考え方と実装」（スライドリンク）
- 非公開イベント「Slack Workflow 使いこなし術」
- JSConf JP 2025 「自作して理解する、ディレクティブとビルドシステムの役割」（YouTubeリンク、トーク概要ページ）
- TSKaigi Hokuriku 2025 クロージング（登壇ではないけど）（ツイートリンク）
- フロントエンドカンファレンス関西 「ソースマップはどのように元コードへの参照を保持するか」（スライドリンク、トーク概要ページ）
来年は勉強会にも積極的に参加していきたいと思っています。
TSKaigi Kansai 2024
初めてのカンファレンス登壇でした。採択テーマが非常にニッチ、かつアグレッシブな主張だったので、非常に不安が大きかったのですが、選考をしていた方に「採択されたってことは、少なくとも選考した人はあなたの話を聞きたいって言っているってことだから自信持って」という言葉（うろ覚え）にとても救われたのを覚えています。
LayerX Web Frontend Night
状態管理の話をしました。実は1年前に上京して初めて参加したイベントがWeb Frontend Nightだったので、1年経って登壇する側でお誘いいただき少しエモい気持ちになりました。フロントエンドのエキスパートな方々に囲まれて発表するという非常にレアな経験でした。
TSKaigi 2025
今年の登壇で一番難産だったのはTSKaigi
2025でした。スタッフをやりながらの登壇という部分もありましたが、何より30分という長い時間にプレッシャーを感じており、何度も登壇資料を作り直しました。最終バージョンは登壇直前まで作業しており、散らかった資料になってしまったと反省しています。
そんな中でも発表自体は無事終えることができ、よかったです。
フロカン関西
TSKaigiの反省点をうまく活かせたのはフロカン関西で、こちらは5分の中で「発表内容に興味を持ってもらう」ことをメインにしました。ソースマップに関する発表でしたが、最初に「ソースマップとは何か」から導入し、「普段の開発でどこでソースマップが使われているか」の具体例を見せ、最後に「ソースマップの生成ロジック」に触れるという流れでした。
最後のロジックの部分が一番伝えたい部分ではあるものの全て紹介するのは不可能です。そこで「ソースマップの容量削減の工夫」という切り口で、アルゴリズムの特徴をピックアップして紹介する形式としました。
以前は教科書的な解説をメインとしていたのですが、同じ内容を話すとしても私なりの切り口を設定して説明した方が楽しんでもらえるんだな、と気づきました。
この辺りはばんくしさんにもアドバイスをいただいたことがあり、うまく自分の中で落とし込むことができました。
JSConf JP
なんとなくガチ勢が多そうで戦々恐々としていたのですが、蓋を開けてみれば温かいコメントをたくさんいただき嬉しかったです。
実は同じチームの方もLTで採択されており、タイムテーブル上で私と連続するというミラクルがありました。
登壇が確定して以降、vercel/workflow の公開を発端としてdirective論争が盛り上がっていたので、図らずホットな話題になりました。
来年も登壇していきたい
引き続きやっていきたいと思っています。自分の中で発表の型ができてきたので、次は長めのセッションも話したいですね。（やはりLTは短い）
未踏
昨年の1番のトピックは未踏ITでした。自分の中では心残りもあり、仕事やカンファレンス業と並行して進める難しさも感じていました。
途中メンタルブレイクしかけていたときは、特にPM（メンター）のに助けていただきました。曾川さんとは未踏のプロジェクトに限らず色々な話ができて、実は一番勉強になったのはこれかもしれません。
また、凄すぎる同期たちが凄すぎました。技術で名をあげる人のはこういう人たちなんだな、ということを感じました。
プロジェクト自体も落ち着いたタイミングで形にしたいと思っています。ただ時間が...
技術記事
毎年何か書きたいなぁと思いながらなかなか筆が乗らずにいます。この2年で書いたのはこの4本です。
- 【React】useStateの乱用を避ける（リンク）
- TSKaigiのスポンサーです、リフレッシュクイズの解答解説をお送りします（リンク）
- TypeScriptで型レベル四則演算（リンク）
- Server Functions っぽい仕組みを自作して Lambda 関数呼び出しに適用してみた（リンク）
書きたいことはたくさんあります、Branded Type、React Fiber の話、フレームワークとの付き合い方、@tanstack/react-startを実務投入している話、etc...
OSS
今年後半にかけて、いくつかOSSにissueを立てたりPRを出したりしました。 来年も積極的に続けていきたいです。
初めてマージされたPRはprisma-lintでした（リンク）
興味関心
実はTSKaigiの打ち上げで「池奥さんは堅牢性と型の表現力あたりが好きそうですよね」と言われて以来、本当にその通りだなぁと思っています。
実は私は学生時代にハッカソンで無双していたことがあるくらいには、プロダクトを作るのが好きな人間です。先述しましたが、プログラミングそれ自体に大きなこだわりがあるわけではなく、ものづくりをしたいタイプです。
ですので、「どうやって早く開発するか」という点に一番関心があります。これは堅牢性と相反するように感じますが、私の中では同じ方向を向いています。
例えばあるプロダクトに機能を追加するときに「まず今の仕様を調べます」ではとても時間がかかります。理想的には「コードを流し読めば仕様が手に取るようにわかる」状況ですし、もっと言えば「コードのどこを読めば良いか直感的に分かる」状況です。前者は必要十分な抽象化とテスト、後者は適切な命名やアーキテクチャ、ドキュメンテーションによって解決される分野です。
さらに、複雑なコードであればあるほどデバッグや動作確認、QAに時間がかかります。コードを簡潔に保つことでこれらの時間を大きく削ることができます。
つまり、「堅牢なコードであれば開発が高速に回る」ということです。
ただ理想論な部分もあるので、ぜひ色々探求していきたいなと思っています。
来年も頑張ります
実は個人的な目標の1つにJSConf JP登壇があったのですが、早々に達成することができました。次はPMConfかな...笑
入社直後はよくポストしていたのですが、たくさんの方に目をかけていただき、すごく恵まれている環境にあると常々思っています。お世話になったかた、本当にありがとうございました。引き続きよろしくお願いします。