Kotlin
A concise multiplatform language developed by JetBrains
Java 開発者向け Kotlin 入門ガイド
Urs Peter(シニアソフトウェアエンジニア、JetBrains 認定 Kotlin トレーナー)によるゲスト投稿です。 Urs は、より体系的な Kotlin スキルの構築を希望する開発者を対象とする Kotlin Upskill Program(Kotlin スキルアッププログラム)も Xebia Academy で開講しています。
この記事は、実際のチームにおいてある一人の開発者の好奇心をきっかけに、会社全体が変革するまでの Kotlin の導入経緯を追った「Java 主体の環境で Kotlin の導入を成功させるための究極ガイド」連載記事の第 1 回です。
「スイッチを押せば Kotlin に移行できるわけではありません。
リスクを排除し、評価し、成功を祝い、
その上でようやく Kotlin の導入を推進できるのです。」
確立した Java 環境に Kotlin を導入するには、技術的な意思決定のみならず、慎重な計画、戦略的な思考、そして何よりも周囲の心と支持を勝ち取ることが要求されます。
私は 1,000 人以上の開発者をトレーニングし、数多くの組織が Kotlin に移行するのを支援しながら、効果的なものとそうでないものを見てきました。 このガイドでは、最初の実験的なプレイグラウンドから大規模な組織的な変革に至るまで、私がこれまで集めてきた Kotlin の導入を成功させるためのレシピをご紹介します。
この連載では以下のように導入過程を展開しています。
- 火付け役はいつも自分の心です!
- 実験段階: 小さく始めてテストする
- 評価段階: プレイグラウンドでの Kotlin を脱却
- 周知活動: 周りの開発者の心と支持を勝ち取る
- 経営陣の説得: Kotlin のビジネスケースを構築する
- 大規模な Kotlin の導入を実現する成功要因
- Kotlin に移行するかしないか: どのような会社に成長したいのか?
火付け役はいつも自分の心です!

わざわざ Kotlin に切り替えようとする理由は何でしょうか? Java のまま進めてはいけないのでしょうか?
この答えは多数の要因によって変わります。 データからは複数分野での Kotlin のメリットが明確に示されている一方、意思決定は純粋に技術的に行われるものではありません。 主観的な考え(「この言語が好きだから好き」)や新しいものに対する懐疑心は概して良いものであり、重要な役割を果たします。
しかしながら、プログラミング言語の進化は開発者の好みやニーズが時間とともに変化することの現れです。 とりわけ重要なのは、どの新世代の言語にも(null)安全性、簡潔で軽量な構文、第一級オブジェクトとしての関数、豊富な標準ライブラリ、非同期の並行性、マルチプラットフォームのサポート、生成 AI 対応など、開発者や組織に決定的な優位性を与える新しいパラダイムが組み込まれていることです。
このような自然な進化がなければ、私たちは今でも COBOL や他の古典的な言語ですべてをコーディングしており、今日の要求を満たせていなかったことでしょう。 つまり、進化とは好みで選べるものではなく、この業界の歴史に組み込まれているものなのです。
ただし、このような進化が社内に根付くには、技術的なメリットだけでは不十分です。 このような新しいパラダイムの価値を実際に探求し、提唱し、示す意欲のある実現者が必要です。 私の経験では、Kotlin の導入でカタリストになれる典型的なエンジニアには以下の 3 つのタイプがいます。
- 現実的で生産性を重視する Java エンジニア: Java を信仰の対象ではなく、ツールと見なしている経験豊富な開発者。 このようなエンジニアは常により良い方法を追求し、作業をより早く完了させようとします。
- 品質志向のモダン言語愛好家: 可読性に優れ、簡潔で保守しやすいコードを優先するエンジニア。 このようなエンジニアは多くの場合、過去に Scala に移行した経験があるエンジニアでもあります。
- ジュニア開発者: 「Kotlin を使用できるのに Java を使用する理由があるのだろうか?」のような単純ながらも強烈な疑問を抱くジュニア開発者。 長年にわたって Java に固執した経験を持たないジュニア開発者にとって、Kotlin は往々にして当然の選択肢になります。
あなたはどのエンジニアですか?
このような早期採用者は、最初の段階の火付け役になります。 しかし、どのように始めればよいのでしょうか? 続きを読んでください… ;-)
実験段階: 小さく始めてテストする
Kotlin について聞いたことがある方は、すぐに決断せずに試してみたいと思っているはずです。
最初に必要となるのは、最初の Kotlin の種をまくことができる開発者ツールです。 以下のような選択肢があります。
- https://play.kotlinlang.org/ は優れたオンラインプレイグラウンドです。JVM のみならず、他の各種プラットフォーム(JS や WASM など)向けの Kotlin コードを簡単に入力して実行できます。

- Kotlin Notebook は IntelliJ IDEA 用の強力な機能です。依存関係のインポート、コードの実行、さらにはデータの操作やグラフの生成などを簡単に行えます。 以下の例では、Spring の RestClient で REST 呼び出しを簡単に行えることが分かります。

- IntelliJ IDEA には 最高水準の Kotlin のサポートが備わっています。 JetBrains は Kotlin の作成元であり、IntelliJ IDEA の大部分が Kotlin で書かれているため、これは驚くことではありません。 そのため、IntelliJ IDEA では既存の Java プロジェクトでも簡単に Kotlin の使用を開始できます。
…すると、こうなります!

- 他にもまだまだあります! JetBrains は Kotlin Language Server を最近リリースし、フル機能を使用した Kotlin 開発を IntelliJ IDEA 以外の他の IDE(VS Code など)でも体験できるようにしました。 こちらをご覧ください: https://github.com/Kotlin/kotlin-lsp
これでお気に入りの開発環境で Kotlin を書けるようになりました。 実際にはどのようにこの言語を評価し、影響を最小限に抑えながら最大限のインサイトを得ることができるのでしょうか? そのためには既存の Java プロジェクトのテストスイートを使用します!
この安全で現実的な方法で Kotlin を実験することには、以下のいくつかのメリットがあります。
- 低リスク: テストが本番環境コードに影響することはありません。
- 学習の機会: 使い慣れた環境で言語の機能を試すことができます。
- 段階的な導入: チームメンバーはプレッシャーを感じることなく、Kotlin の構文に慣れることができます。
ヒント
- Kotest + MockK を試しましょう。機能豊富なアサーション(
shouldHaveSize(...))や接中辞(value shouldBe 1)など、Kotlin のテスト DSL(ドメイン固有言語)の表現力をすぐに感じ取ることができます。 - Java のストリームではなく、簡潔で強力な Kotlin のコレクションを使用しましょう。
- null 許容型、非構造化、不変性(
val、data classes)、式コンストラクト(when、try-catch、if else)などのさまざまな言語機能を試してみましょう。
以下のようになります。
Java
@Test
void shouldGetAverageRating() {
when(productRepository.findAll()).thenReturn(products);
Map<String, Double> ratings = productService.averageRatings();
assertAll(
() -> assertThat(ratings).hasSize(4),
() -> assertEquals(ratings, products
.stream()
.collect(Collectors.groupingBy(
Product::getName,
Collectors.flatMapping(
p -> p.getRatings()
.stream()
.mapToDouble(Integer::doubleValue)
.boxed(),
Collectors.averagingDouble(Double::doubleValue)
)))
)
);
verify(productRepository).findAll();
}
Kotlin
@Test
fun `should get average rating`() { //descriptive tests using ``
every { productRepository.findAll() } returns products
val ratings = productService.averageRatings()
assertSoftly(ratings) { //powerful testing DSLs (Kotest)
shouldHaveSize(4)
this shouldBe productRepository.findAll()
.groupBy { it.name } //concise collections
.mapValues { (_, products) -> //destructuring
products.flatMap { it.ratings }.average() }
}
verify { productRepository.findAll() }
}
この連載の次の記事
Kotlin の導入は一般的に 1 人の開発者の探究に始まり、いくつかのテストによってその有用性が証明されます。 このような最初の発見は、必然的に実際のプロジェクトでの Kotlin の評価という大がかりな取り組みにつながっていきます。
この連載の次の記事では、その段階と本番環境での Kotlin のテスト方法について説明します。
オリジナル(英語)ブログ投稿記事の作者:
