1. 言語選定は「設計責任の範囲」で決まる

企業システムのコードには必ず責任の重さがあります。

・障害時に即ビジネス影響が出る

・間違っても一部機能が壊れるだけ

・近い将来、仕様変更される前提

この責任が重いほど、可読性と明示性が優先され、結果としてJavaが選ばれます。

逆に、変化を前提としたコードではKotlinの生産性が活きます。

2. Javaを使うべきコードの具体条件と実コード

条件

・ビジネスルールが密集している

・挙動を明確に説明できる必要がある

・将来の保守担当が不特定

例：ドメインエンティティ（Java）

なぜJavaか

・nullチェックの責任が明確

・処理の流れを追いやすい

・「なぜ例外が出るか」を説明しやすい

Kotlinでも書けますが、コアロジックでは「分かりやすさ」が最優先されます。

3. Kotlinを使うべきコードの具体条件と実コード

条件

・データ変換・中間層

・UIやAPI向けの加工

・仕様変更が頻繁

例：DTO変換（Kotlin）

Javaで書いた場合

なぜKotlinか

・記述量が少なく意図が明確

・修正時の影響範囲が限定される

・Null安全で事故が減る

この層は「壊れても直しやすい」ことが重要です。

4. 混在プロジェクトでよくある失敗

Kotlinをコアロジックに入れすぎる

一見きれいですが、業務ロジックとしては追いづらい。レビューや障害対応時に説明できなくなります。

Java / Kotlin の境界が曖昧

・同じパッケージに混在

・ルールなしで追加

これは確実に技術的負債になります。

5. 実務で使われる設計ルール整理

守る層はJava、変える層はKotlin。このルールがあるだけで、設計レビューが非常に楽になります。

KotlinとJavaの違いは「どちらが優れているか」ではありません。企業開発では、責任が重いコードをJavaで守り、変化を受け止める部分をKotlinで書く。この設計判断をコードで説明できる開発者こそ、現場で信頼されます。言語選択は技術力ではなく、設計力そのものです。