ザネリは列車を見送った ブログという名の備忘録

2025年振り返り(AI台頭の時代を生き延びる) はてなブックマーク - 2025年振り返り(AI台頭の時代を生き延びる) | ザネリは列車を見送った はてなブックマーク - 2025年振り返り(AI台頭の時代を生き延びる) | ザネリは列車を見送った

年１更新ブログの季節到来。

今年はChatGPTをはじめとしたAIがエンジニアの仕事だけでなく、ITエンジニア以外の人にとっても身近に使われるようになってきた。
私はというと、まだAIにコードを書かせて完全にドライバの役割を明け渡すような事にはなっていない(そうするのが望ましいのにまだそのようにできていない、と表現するべきか…)が、レビューや調べ物などに便利に使わせてもらっている。
AIの到来によって働き方そのものが変わったほどの実感はないが、いずれ望むと望まざるに関わらずそういう時が来るだろうし、その時が来るのは予想できる範囲よりずっと早いのかもしれない。

お仕事の振り返り

今年は一社終わり、空いた分は既存のお仕事先の稼働を増やしたので新しく始まったお仕事は無し。
そういう意味ではあまり動きがなかったとも言えるが、それぞれのお仕事でやった事は新しい学びも色々とあった。
そうなんだよな。
2024年12月〜2025年6月 週2日 Kotlin
Ktor, kotlin-result, jOOQなどを使ってGraphQLサーバーをガリガリ書いていた。
元々Scalaをやっていたので大きな驚きや新しい発見がそこまであったわけではないが、やはり新しい言語を触るのは楽しい。

この会社では結局採用に至らなかったが、個人的にはRefinement typesを導入するのに向いているプロダクトだったと考えていて、技術的に検討していた事柄がこちらのお仕事で日の目を見ずじまいなのが勿体なかったので外部イベントでLTをしたりもした。

Kotlinの代表的な(?)SQLライブラリとしてはExposedがあるようで、このプロジェクトでも当初はこれを使っていたが、DB定義からKotlinコードを生成する機能がおそらくなくて、それができるjOOQに乗り換えたのは良い判断だった。
kotlin-resultもエラーハンドリングにちょうど良い薄いライブラリという肌感で、Scalaをやっている身としてはArrow-KTに飛びつきたくもなるが、そこは作るものの特性やチームメンバーの習熟度なども含めて慎重に考えた方が良いのではないだろうか。
ScalaでできるアレをKotlinでもやりたいけど標準ライブラリでは実現できないから外部ライブラリで補おう、は黄色信号だと思っている。
なお、今後Rich Errorsという新機構が入る予定があるようで(まだ検討段階で入るかどうかは分からないのかも?)、これが入りエラーハンドリングをRich Errorsのやり方に沿うようにすればkotlin-resultも入れなくてよくなる予感がある。
今のKotlin標準のResult型がエラー情報を持っておらず表現力に乏しいためkotlin-resultの存在が助かってはいるが、Goをやるなら文句を言わず逐一 err != nil チェックを書くように、その言語の標準的なやり方になるべく沿うのが無難なはず。
(kotlin.Resultが成功時の型情報しか持っていないのはコルーチンでの使用を意図したものでエラー型を持たないのにも明確な設計思想があるような記事をどこかで見かけた気もするのだが、パッと探せなかった。一見イケてないと思われるものにも理由があったりするものだ)

サーバーサイドKotlin開発は手に馴染んできたので今後も機会があればやりたいと思っていたところ、来年からまた別の会社でできる事になりそうで今から楽しみだ。
2022年9月〜現在 不定期 Go
一人目サーバーサイドエンジニアとして関わり続けている。
今年になって業務委託でフルタイム稼働してくれていた方々が相次いで離任する事になり(といってもネガティブな理由ではなく、正社員として別会社で働く事になったのでフリーランスを辞める方など)、また四苦八苦しながら面談に立ち会って新しい人を探す事になった。
人生のままならなさを感じつつも、また業務委託で良い方をお迎えする事ができ、上手くワークできているように思う。
また、フルタイムではなくなったが元々長く稼働してくれていた方にも継続して副業として参画を続けてもらえる事にもなり、とりあえずは開発チームとして体制は整った。

既存プロダクトの追加機能開発や不具合修正などはフルタイムで参画しているメンバーが主に対応してくれていて、私自身はあまり手を動かしての貢献は少なくなっている。
実際何やったっけ…と振り返ってみたが、RedisからValkeyへの移行のための調査・ローカル開発のための設定準備・ダブルライトして段階的に移行するなどの細々した作業があるか。
割と長期間ひとつのプロダクトを改修し続けて今に至り、色々とほころびが出てきているのでソフトウェア式年遷宮的に一からリライト・リプレイスしようという話が持ち上がってはいるのだが、主に私が及び腰でなかなか進んでいない。
一から新しく書き直すというと魅力的に聞こえはするが、現実問題なかなか難しく技術的に乗り越えないといけない事や技術面以外でも調整しないといけない事がたくさんあると身をもって知っているので…。
とはいえ、前職から付き合いの長いエンジニアリーダーには「こういう事には乗り気になる気質だと思っていたのに、日和ってるんスか？」と発破をかけられているので、挑発に乗って期待に応えて頑張りたいところではある。
(お互いの性分を分かった上での良好な人間関係ですよ)

話は逸れるが、怖気付くという意味での「日和る」はどうやら誤用らしい。ブログを書くため単語の意味を調べなければ知らないままだっただろう。
2023年10月〜現在 週2日->週3日 Go
元々バックエンドのGraphQLサーバーを書くお手伝い程度の立ち位置だったのだが、要職の方の退任や正社員エンジニアの方の育児休暇などが重なり、動けるエンジニアが業務委託の私だけという状態になり、稼働日を1日増やして何とか留守を守るつもりで色々と担当領域を広げた一年だった。
ちょうど新サービス立ち上げのタイミングでそのような状況になったため、バックエンドだけでなくインフラやフロントエンドもあまり得意でないながらも対応する事になった。
といっても実際手を動かすのは私だけだが同社の別サービスをかつて開発して経緯に詳しい人に聞きながらではあったので0->1を完全に自分一人でやり切ったと言えるほどではなかったが。
インフラは既存の別サービスのTerraformを流用して対応し、フロントも似たような感じでコピペ…とまではいかないにせよ参考となる実装があるので何とかなった。
TypeScriptやNextはそこまで苦労する事はなく、やはり私のフロントエンドの苦手意識はCSSがあまり理解できていない事だと再認識したが、この辺はAIにずいぶん助けられて以前よりは苦労が少なかった。
ここの会社はCodeRabbitを導入していたので、まずは一通り動くものを作ってPRを出し、CodeRabbitがつけるレビューコメントに対応して何とか半人前フロントエンドエンジニアでもそれなりのところまで質を上げる事はできたのではないだろうか。

他には、Auth0やStripeとの外部連携も、従来であれば私が参画時点ではすでに実装済みであったり他のフルタイム稼働の方が担当されたりするのが常であったが自分が対応する事になり、調べながら動かしながら試しながら…となかなか大変だったものの、色々と学びになり楽しい経験になった。
とりあえず留守を守ることはできたか…育児休暇の方が戻ってくる直前にリリースまでこぎつけ、一旦上から下まで全部担当する事態ではなくなった。
来年以降は少し稼働頻度を落として継続する予定。
2024年12月〜現在 週1日->週2日 Go
元々週1稼働なので大した事はできないのでは…と不安もあったが、適宜色々とタスクを振ってもらい着実にこなし、前述のお仕事先がひとつ終わった後で双方の要望が合い1日増やす事に。

主にGoのバックエンド実装で、新規機能開発やちょっとした不具合修正、ミドルウェアバージョンアップによる影響調査、ライブラリバージョンアップ対応など大小様々やっている。
目新しいところではOpenTelemetry導入のためのGoバックエンド側修正あたりか。
対応しているライブラリを組み込むだけでいいかと思っていたが、意外と調べる事があったり既存実装を修正しないといけない範囲が多く、期待通り動いてくれた時の喜びもひとしお。

ここの会社はissueでClaude Codeにメンションすると反応するようGitHub Actionsで設定されており、とある調査系タスクのためそこそこ複雑な実装を別のプログラミング言語に書き換えるよう依頼したところかなりの精度のものを出してきて驚いた。
とはいえ「書き換え前の言語のこの機能は書き換え後の言語にありません」という回答がちゃんと調べれば大嘘だったりしたので、手放しに信じるわけにはいかないが。

その他

OSS業
仕事でElasticsearch組み込みを対応したついでに気づいて出していたPR。

個人で開発・OSS公開していたscalikejdbc-athenaというライブラリがあるのだが、改めて調べたところこのライブラリはもう使わなくてもScalikeJDBC + Athena JDBC driver だけで機能しそう、という事に気づく。
(元々Athena JDBC driverがPrepared Statementに対応しておらずランタイムエラーを投げるので、ScalikeJDBCやその他Prepared Statement利用前提のライブラリでは使えないという事情に対応するため作ったが、現在は対応されている模様)
改めて調べたきっかけはこのリポジトリにPRをもらえたからで、使っていただいていたりPRをいただけるのはありがたいが個人的にはあまり積極的に開発する気はなくなっている。
必要でなければ依存ライブラリは少ない方が望ましいと思っておりこのライブラリの役目は終わった(使わなくても機能するようになっている)と考えているが、使ってくれている方がいるようなのでリポジトリをアーカイブするまでに思い切れておらず悩ましい。
テックカンファレンス スポンサー
旅行


読書
今年読んだ中では『レッドクローバー』が圧巻の面白さだった。まさきとしかさんにはすっかりハマってしまった。
『金環日蝕』『一次元の挿し木』『行方』も良かったな…というか、読了ポストしたものはどれも良かった。
だいたい400ページくらいの文庫なら二週間くらいかけて読んでいるか。
特段速いわけでも量を読めているわけでもないが、ゆっくりペースでも習慣づいてきたので続けていきたい。
多肉植物
献血
来年も学び多き、良き年となりますように。

Copyright© 2011-2021 Shunsuke Otani All Right Reserved .