概要
Server-Side Kotlin Night 2025に参加したので、感想を記述します。
参加理由
私の技術的な関心事の 1 つに、サーバーサイド Kotlin があります。 活用事例や技術的な動向を学ぶために参加しました。
また、今回は運営側としても参加しました。
セッション感想
「ウェルスナビ会場 LT」
会場提供のウェルスナビさんからの LT でした。 ウェルスナビでは「長期・積立・分散」をコンセプトとした全自動の資産運用サービスを提供しています。 どうでも良いですが、「サービス名を聞いたときにヘルステック系かと思いました」と伝えたら、「何回も間違われます。。。」と言ってました。 Kotlin を Android 開発で活用しているとのことでした。
「Amper で Kotlin のエコシステムを簡単キャッチアップ」
ヘンリーの一円さんによる発表でした。 2025 年 6 月に参画して、サーバーサイド Kotlin、医療ドメイン、大規模コードベースという 3 つの新しい挑戦を同時に行っているとのことでした。
サーバーサイド Kotlin の最初のイメージとして挙げられていた「Gradle がややこしい」「IntelliJ 必須」「ライブラリがたくさん」という点は、私も同感です。
Amper は JetBrains 製の実験的ビルドツールです。
サーバーサイド Kotlin や Kotlin マルチプラットフォームに対応しています。
2023 年 11 月に公開され、amper init でプロジェクトを簡単に作成できます。
私は Gradle の記法にいまだに慣れていないため、Gradle を使わなくて済み、より簡潔な記法で書けるのは魅力的に感じました。
最後に、デモでは Ktor を Amper で動かす様子や、Kotlin マルチプラットフォームで ToDo アプリケーションを作成する様子が紹介されました。 パッケージ管理が楽で、補完もよい感じに効くとのことで、将来的に良い選択肢になりそうだと思いました。 しかし、Exposed の開発があまり進んでいない現状を考えると、過信は良くないなといつも考えています。
「サーバーサイド Kotlin を社内で普及させてみた」
マネーフォワードの川田さんによる発表でした。 2018 年ごろからサーバーサイド Kotlin を触り、2024 年から社内で普及活動をされているとのことです。
マネーフォワードでは Ruby がメインで Go も使われている中、Kotlin を社内技術標準として推進するために、統一した推奨技術の提供と技術サポートをしているそうです。
印象的だったのは「Kotlin の技術選択は難しい」という話でした。
- Java ベース or Pure Kotlin
- Coroutines を活用するか
- Spring WebFlux の採用判断
実際に社内から上がった意見として「Java が使いたい」「学習コストが高い」「情報が少ない」「Go の方がより AI 対応の開発体験が良い」といった声があったそうです。 これに対して、Java 経験者はすぐ覚えられること、日本の Kotlin コミュニティは成熟していることなどを説明されているとのことでした。
技術サポートとして、下記の Gradle 関連のエンジニア負荷削減に取り組まれている点が参考になりました。
- テンプレートプロジェクトや社内共通ライブラリセット
- Version Catalogs
- Convention Plugins の提供
全体を通して、サーバーサイド Kotlin を普及させるためのエンジニアリングを気合い・根性・執念を徹底して行っていたのが印象的でした。
個人的には、GraphQL Kotlin（from Expedia）が瀕死状態で Spring for GraphQL への移行を検討しているという話も興味深かったです。
「Why Kotlin? 電子カルテを Kotlin で開発する理由」
ヘンリーの縣さんによる発表でした。病院向け電子カルテには「巨大」「高密度」「変化」という 3 つの性質があり、対応するために Kotlin を選択しているとのことでした。
ヘンリーでは Java に寄せるか Kotlin に寄せるかの選択で Kotlin に寄せており、Exposed の破壊的変更に苦労した経験もあるそうです。
Kotlin を選ぶ理由として以下が挙げられていました。
- 安全性: Null Safety、リファクタリングの容易性
- 表現力: Sealed Class / Data Class、internal 修飾子
- 資産: Java & JVM の資産、採用観点（複雑なモダン開発に向き合う人が多い）
特に採用観点で「複雑なモダンに向き合う人が多い」という点は、Kotlin を選ぶエンジニアの傾向として納得感がありました。
「Kotlin でミニマルな Result 実装による関数型エラーハンドリング」
スマートラウンドのカマイルカさんによる発表でした。JVM の関数型言語の経験が長い方で、エラーがどこで発生したのかを分かりやすくするために自作の関数型の型（Result 型）を活用する話でした。
個人的な経験として、Arrow.kt または kotlin-result に任せることが多いので、自作という選択肢を取る方にはいつも驚嘆します。 一方で、書き味にこだわりすぎてもよくないと考えているので、「エラーをトレースしたかったら OpenTelemetry 計装を頑張る」というのも経験則としてあります。
「IntelliJ IDEA 以外での Kotlin 開発のリアル」
ヘンリーの nabeo さん、ログラスの yasunori さん、SanSan の髙野さんによるパネルディスカッションでした。VSCode、Neovim/Vim、Emacs での Kotlin 開発について議論されました。
各エディタの状況や IntelliJ IDEA の便利機能などを議論されていました。 「kotlin-lsp」がつらいという内容に終始していた印象もありましたが、本人たちが突破口を見い出そうとしている議論でおもしろかったです。
個人的な意見としては、vim の操作感は魅力的であるのと同様に IntelliJ IDEA の操作感も優秀です。 kotlin-lsp をきっかけに Kotlin ユーザーが増えて、IntelliJ IDEA を利用する人も増えればと考えています。
勉強会の全体的な感想
今回の勉強会を通じて、サーバーサイド Kotlin のエコシステムが着実に成熟してきていることを実感しました。
特に印象に残ったのは以下の点です。
- ビルドツールの進化: Amper について
- 社内普及の難しさ: マネーフォワードの事例から、Kotlin の技術選定はやはり難しい
- Kotlin らしさの追求: Java ベースで書くか Pure Kotlin で書くかという議論があり、各社がそれぞれの方針を持っている
- エディタ/IDE について: kotlin-lsp の登場により、選択肢が増えたが、まだまだ IntelliJ IDEA が良い状態
運営側としても参加できたことで、コミュニティの熱量を直接感じることができました。 今後も引き続き Kotlin 系コミュニティをウォッチしていきます。
