2025年の抱è²

2024年はどんな年だったか

2023年の11月に現職に入社したので2024年は必死に仕事をしつつ、人生を大きく変えていこうと試みた1年だった。

3～6月くらいまで体調もあまり良くなく生きてるだけで十分くらいのペースで減速していた。（RubyKaigiにも行かなかった）でも、秋くらいからはKaigi on Railsに参加したり、勉強会に登壇したりとアクティブに動けたと思う。

プライベートだといろいろな心境の変化もあって9月から結婚相談所に入って婚活していた。（正確にはまだしている）

2025年の抱負

アウトプットを増やす

主にこのブログを書いていく。今年も登壇の機会を作る。

また、3月1日に開催予定のTokyoWemen.rbに主催として関わらせてもらう。なので、コミュニティ運営にも取り組んでいきたい。いままでいろいろなコミュニティ・勉強会でお世話になってきたので少しでも返して行けたらよいなと思っている。

仕事をきっちりやっていく

個人的に外部で登壇するなどのアウトプットを増やせば増やすほど、普段の仕事もきっちりやっていかなければなと思う。

客観的にはアウトプットしていくことそのものが良いことなのでみんな積極的にやればいいと思う。一方で、アウトプットが仕事に反映されていないとなんかかっこ悪いなという気持ちにもなってしまう。（これは自意識の問題）

というわけでアウトプットを増やした分、日ごろの業務にもプライドをもって取り組んでいきたい。より便利に使ってもらえる機能を作っているのでこれでプロダクトの価値をあげていきたい。あげていくぞ。

健康に気を付ける

具体的にはダイエットをします。

昨年食欲がない時期があって10キロ近く痩せたのだが、その後7キロ増えた。痩せよう。

食べないのは普通に良くないので毎日Fit Boxingか筋トレをする。絶対にだ。

温かい家庭を維持する

婚活していると書いたけれど、ご縁があって今年は入籍することになりそう。まだ油断する時間じゃないのだけど、予定では遠くないうちに。お互いの親に挨拶に行ったり、顔合わせの予定を決めたりしている。

人と暮らすのは友達とルームシェアしていたとき以来なのでドキドキしている。仲良く温かい家庭を維持できるように頑張る。

入社して1年、「修復」への道

この記事はSmartHR Advent Calendar 2024 11日目の記事です。

昨日はibulogさんによる Vercel REST APIとGitHub Actionsを使ってデプロイするでしたね。私はヘルプセンターのコードレビューにも関わらせてもらっていますが、ibulogさんの改善や工夫はいつも勉強になっています。

さて、本日12月11日は私の誕生日です。やったね。誕生日ということもあり（？）、昨年11月にSmartHRに入社してからやったこと・それに対して感じたことについて今回は書いていきたいと思います。

入社前の自分について

私は新卒でSIerに入社し、その後コンサルティング会社、前職の万葉（受託開発、SESでの開発支援の会社）と転職を重ねながら微妙にやることを変えながらIT業界で生き延びてきました。

ただ、一貫しているのはどの会社でもクライアントワークをしてきたということです。いわゆる自社サービスの会社ではなく、技術力を提供することで稼いできたことになります。

個人的にクライアントワークはすごく自分に向いていて、やりがいもあるし楽しかったです。ただ、だからこそコンフォートゾーンに浸かっているという気持ちが湧いてきました。一度自社でサービスを持っている会社に入って揉まれる経験をしてみたいというのが転職理由でした。

入社してからやったこと

昨年（2023年）11月に入社して、今年の9月まではSmartHR基本機能の開発を行っていました。SmartHR基本機能というのは一番古くからあるプロダクトです。

私の所属していたチームではグループ企業管理の開発を行っていました。SmartHRに今まで存在していなかったグループ企業という概念を導入し、企業グループ単位で従業員のデータを利活用できるようにするという対応です。

今年の10月からは課金基盤チームで雇用形態別課金プロジェクトというプロジェクトに挑んでいます。こちらはプラン選択を柔軟に！ 課金基盤チームの挑戦 - SmartHR Tech Blogに詳しく書いてあります。

共通しているのはどちらも新概念を長らく運用されているSmartHRのプロダクトに適用していくということでした。今動いているプロダクトを壊さずに新しい概念を導入して適応させていく。これがとにかく難しい。こんなに難しいことってあるだろうかと思う日々でした。

「修復」との出会い

毎日難しい問題に頭を悩ませていたある日、私はKaigi on Rails 2024に参加しました。2日目の島田さんの基調講演であるキーワードに出会います。それが「修復」です。

speakerdeck.com

 

元に戻すのではなく、変わった後の全体と再度調和させる作業

 

修復を続けることで変化に適応し続ける

 

私のやっていること、そしてやらなければいけないことはこれだと思いました。

 

「修復」し続けること

新しい概念を導入しようとすると、どうしても歪みが出てきます。そこをいかに既存の仕様やコードとぶつからないように作っていくのかというのか、既存のアプリケーションに溶け込ませていくのかが私の仕事だなと思っています。まるで最初期から考えらえていた機能のように設計・実装できたらいいですよね。

島田さんの発表にもありましたが、「シンプルに」作るというのが一つキーワードかもしれないと気づき始めてきました。SmartHR基本機能は9年の歴史があり、どうしても複雑化してきています。それをできるだけシンプルに修復していくというのがとても大事なことだと思います。この辺りはまだまだ模索中です。来年は一つ自分なりのメソッドを生み出したいなと思います。（今はまだひいひい言ってるところです）

「修復」し続けるという取り組みはSmartHRに入社したからこそ体験・実感できたことだと感じています。*1

まだまだ道半ばですが、この道を必死に走っていくぞ！

おわりに

この1年を振り返って感じたことの話でした。来年の抱負のようになりましたが、来年は何かしら「できた！」という実感を持ってまた「修復」の話ができたらいいなと思います。

明日は @utakahaさんです。

 

 

*1:今までも修復チャンスはあったのかもしれないけれど、その難しさに意識を払ったことがなかった

Kaigi on Rails 2024

kaigionrails.org

実はオフライン参加は初めてでした。

プロポーザルを出した

出しました。残念ながら落選。 実は去年も出していたのだけど（去年も落選です）今年は会社の人たちとレビュー会もして、かなりブラッシュアップしたので悔しい。 また来年ですね。

Day1

基調講演

「フレームワークと戦わないという」というキーワードがあった気がする。これが個人的にはしっくり来たし、よく言われるRailに乗るってことなのかなと思った。 多分みんなが知りたい痒いところに手が届くような話で非常に良かった。

RailsのPull requestsのレビューの時に私が考えていること

再現手順を書く際に、「文章を否定形で書かないようにする」というのが個人的にへえ！と思った。確かにその方がわかりやすい。 Railsに対してPRを出す際の話だったけれど、日常業務にも役立つ話だった。

推し活としてのrails new

オタクとしてはタイトルからずっと気になっていた。

頑張らない開発というのがいいなと思ったし、私も頑張らない個人開発をそろそろやりたい。モチベーションの上がる発表だった。

Sidekiqで実現する長時間非同期処理の中断と再開

同僚のhypermktさんの発表。業務で身に染みて感じている課題感とその解決方法の話なのでとても面白く聞けた。

リリース8年目のサービスの1800個のERBファイルをViewComponentに移行した方法とその結果

自動生成でViewComponentに移行したというのが興味深かった。自動生成のメリットとして変更が入っても再実行で済むというのがあってなるほどなと思った。

デプロイを任されたので、教わった通りにデプロイしたら障害になった件 〜俺のやらかしを越えてゆけ〜

「デプロイの仕組み説明できる？」という問いかけにドキッとした。 調査手順や対応方法の模索の仕方が非常にわかりやすくて面白かった。

STORES CAFE for Women at Kaigi on Rails 2024

1日目のお昼はSTORESさん主催の女性エンジニアのランチ会に参加。 10人弱と少人数でいろんな話をゆっくりできてよかった。女性エンジニアの知り合いが増えるの嬉しいですね。

懇親会

いろんな人と話をすることができてよかった。 現職や前職でお世話になって人、今までRubyKaigiで知り合った方たちはもちろんのこと、初めましての人ともたくさんお話できた。

Day2

作って理解する RDBMSのしくみ

実は去年から放送大学で勉強しているのだが、大学の授業で出てきた話だ！となって嬉しかった。B+treeって名前は知っていたけどこういう構造になっているのかーと思った。

推し活のハイトラフィックに立ち向かうRailsとアーキテクチャ

ハイトラフィックに立ち向かう実装の話。在庫テーブルをどう実装したのかという話が面白かった。「WEBアプリケーション全体の総合格闘技」というキラーワードが出てきて、周辺技術ももっと勉強しなきゃなと思った。

入門『状態』

状態をシンプルに保つの本当に大事だなと思った。リファクタリングの例が具体的で学びが多かった。

Hotwire光の道とStimulus

Hotwireで作るためのガイドとしてすごく有用な発表だと思った。私はね…controllerを画面ごとに分けてましたね…。 Hotwireいまだにベストプラクティスがなかなかわからないのだけど、その中で大場さんの発表は実際に使いこなしている人によるガイドという感じで非常に役立つ。

The One Person Framework 実践編

Railsは一人分の脳に収まるというのになるほどーと思った。

認知負荷の問題どうすればいいんだろうと思ったら会社の人から『プログラマー脳』をおすすめしてもらったので読まねば…。

Data Migration on Rails

私はrake task方式が好きだし、今まで出会ってきたのもrake task方式が圧倒的に多いなと思ったのだけど、いろんなやり方があることがわかった。それぞれのメリットやデメリットがまとめられていて、これもとても有用な発表だと思った。

Identifying User Identity

「usesテーブルにはidだけあればいい」というのにほえ〜となった。美しい設計ってこういうのを言うんだなあと思った。

基調講演

今回のKaigi on Railsで何度か聞いたフレーズ「認知負荷」の話がここでも出てきた。

システム全体の視点という話があって大事だと思いつつ、私はまだその視点が足りないなと感じた。

「変わったあとの全体と調和させる」ことで変化に適応させていくという話がすごくいいなと思って、ある程度の歴史を重ねたアプリケーションに手を加える上での一つの道しるべになるような言葉だと感じた。

事後勉強会

弊社で事後勉強会をやって登壇した。 私は会社でやったプロポーザルのレビュー会の話をした。

speakerdeck.com

まとめ

すごく楽しいカンファレンスでした。 学びになったのはもちろんのこと、単純にやる気やモチベーションが上がるのがカンファレンスのいいところだなと思う。やっていくぞ。 また来年もプロポーザルを出したいし参加したい。

ブログを作りました

元々Scrapbox（現Cosense）をやっていて、公開したいことがあればそれを公開すればいいやと思っていたのですが、Scrapboxは記事単位で公開非公開が選べないことを最近知ったのでブログを作りました。