こんにちは、TRUSTDOCKでAndroidエンジニアをしているリキです！
今回は日本最大級のKotlinコミュニティイベントである「Kotlin Fest 2025」に参加してきました。最新のKotlin技術に触れ合うことができたので興味深かったセンションと共に現地レポートをしていきます。
TRUSTDOCKはKotlin Fest2025のスポンサーをしています♩
Kotlinコミュニティの熱気が最高潮に達した「Kotlin Fest 2025」。私たち株式会社TRUSTDOCKは、この素晴らしいイベントにスポンサーとして参加させていただきました！
各企業ブース
企業ブースがOpenしていて人が多く賑わっていました。
お菓子やミニピザ、飲み物といったものも用意されていました♩
人が多く賑わっていてとても活気があったエリアでした！
Kotlinを支える技術：言語設計と縁の下の力持ち
JetBrainsのジュラノフ・ヤンさんのセッションに参加しました！
Kotlinで今後導入検討予定の裏話を聞くことができました。
ちらっと情報をお見せするとCompanion objectが新しくなる（かも？）とのことです。
書き方が
companion object > companion
とシンプルになりcompanionは型もインスタンスもないものに変わるとのことでした。
ただあくまでも検討中のことです。
加えてKotlinを作っているエンジニアの写真も見せていただけました。
この方達によってKotlinは支えられているのですね。感謝です！
セッション後のAsk The Speakerではヤンさんとお話しすることができました！
Kotlin開発でIntelliJのバージョンアップで苦労する話など聞くことができました。
Kotlin言語仕様書への招待 〜コードの「なぜ」を読み解く〜
このセッションではKotlinの挙動を深く理解するための鍵である「言語仕様書」を学ぶことができました。
Kotlin言語仕様書とは？
Kotlin公式サイトのドキュメントよりも、言語の文法や動作がより詳細に記述された公式ドキュメントです。コードが「なぜ」そのように動くのかという疑問の答えが詰まっています。
仕様書は公式サイトで公開され、GitHubでオープンに開発・管理されています。
このセッションでは私たちが書いているKotlinのコードが意図通りに動く背後には、言語仕様書という緻密で数学的なルールがあることを強く認識しました。
Kotlinを深く愛し、コードの「なぜ」を知りたいと願う方には、ぜひ一度読んでみることをお勧めします。
せめて、ネイティブらしく - マルチプラットフォームと撤退戦略
Kotlin Multiplatform / Compose Multiplatformの技術の話だけではなく、その「終わり方」にも焦点を当てたセッションです。
技術の進化は目まぐるしく、今日最適解に見える技術も、数年後には別の技術に取って代わられている可能性は否定できません。このセッションでは、技術的な負債を最小限に抑え、スムーズな移行を可能にするための現実的なアプローチが紹介され、まさに目からウロコでした。
新しいマルチプラットフォーム技術が出てくるたびにUIも全て作り替えるのは非現実的です。
「もし明日、KMPをやめることになったら？」という視点を常に持ち、スムーズに移行できる設計、すなわち疎結合なネイティブ的な設計を意識することが、現代のマルチプラットフォーム開発における重要な「保険」であると強く感じました。
Kotlin 2.2が切り拓く：コンテキストパラメータで書く関数型DSLと新しい依存管理のかたち
このセッションは非常に興味深かったです。
Kotlinのcontext parametersについて学ぶことができました。
- パラメーターのバケツリレーを止めることができる
- 依存性注入（DI）の新しいやり方
聞いていてこの印象を受けました。
context parametersを理解するための簡単なサンプルコードを書きます。
LoggerクラスとDatabaseクラスがあってそれを関数で使う時に
context(logger: Logger, database: Database)
と書くと引数に渡さなくても使えるようになります。
class Logger() {
fun log(message: String) {
Log.d("TEEST", message)
}
}
class Database() {
fun save(data: String) {
Log.d("TEST", "Saving $data")
}
}
context(_: Logger, _: Database)
fun func1(userName: String) {
func2(userName)
}
context(logger: Logger, database: Database)
fun func2(userName: String) {
logger.log("user: $userName")
database.save(userName)
}
一番最初の呼び出しもとは下記のようになります。
val logger = Logger()
val database = Database()
with(logger) {
with(database) {
func1("Alice")
}
}
ボイラープレートを削減し、特定のコンテキストへの依存性が明確になります。
加えてコンテキストパラメーターはリフレクションを使わないので
DIライブラリによる依存の注入よりもパフォーマンスが高くなるとのことでした。
context parametersは今の実験的な段階で、将来的にStable扱いになったら是非とも使っていきたいと思っています！DIのやり方も変わっていくかもしれませんね。
最後に
私たちはより良いサービスを提供するため共に切磋琢磨できるエンジニアを積極的に募集しています！
まずは少し話を聞いてみたいという方向けに、カジュアル面談（オンライン）も随時受付しています。
TRUSTDOCKの開発環境やこれから目指すところ、チームの雰囲気などざっくばらんにお話しできたらと思います！カジュアル面談応募から気軽にお声がけください♩
TRUSTDOCKは、デジタル化していく社会において、あらゆる取引時のKYCを担保するデジタルアイデンティティのインフラ基盤を構築しています。自社や顧客企業のみの便益を超えて、社会全体をデジタル化するという視点で、真摯にものづくりを行っています。
Discussion