はじめに
Androidアプリの規模が大きくなると、ほぼ必ず「マルチモジュール化するべきか」という議論にぶつかります。私自身、単一モジュールで育ったアプリを段階移行した案件と、最初から過剰分割して失敗した案件の両方を経験しました。
結論から言うと、マルチモジュール化は「正義」ではなく「投資」です。投資なので、回収できる条件を満たした時だけ実施するのが最適解です。本記事では、実務で使っている判断基準と、破綻しにくい移行ロードマップをまとめます。
こういうケースなら分割の考えどきかもしれない
以下のような状態なら、マルチモジュール化を検討してみる価値があります。
- ビルド時間が開発体験を継続的に毀損している
- チームが並行開発しづらく、コンフリクトが常態化している
- 機能境界が曖昧で、影響範囲の見積もりが外れ続けている
指標の目安
- クリーンビルドが10分以上、日中インクリメンタルでも待機が頻発
- 1つのPRで無関係ファイルに波及する修正が多い
- メンバー同士が独立した機能の開発をしているはずなのにコンフリクトが頻繁に発生する
逆に、ビルド時間も保守性も問題ない段階で分割だけを先行すると、ほぼ確実にコスト先行になります。特に小規模チームでは、モジュール間の調整コストが純粋な実装速度を上回りやすいです。
分割しすぎの罠
最も多い失敗は、責務ではなく「雰囲気」でモジュールを切ることです。例えば、UI部品を細粒度で分けすぎた結果、変更1件で5モジュールのリリース調整が必要になるケースは珍しくありません。
典型的なアンチパターン
- 抽象化だけが増え、実装コストに見合う効果が出ない
- 新しいコードを追加する際、coreに入れるべきかfeatureに入れるべきか、coreに入れるとしたらどこに入れるか、毎回迷う
- モジュールを分けているのに複数のモジュールに対し同時修正が必要な状態になっている
- 共通機能モジュール側にfeatureモジュール都合の実装や命名が入り込み、再利用性が下がる
失敗を避ける原則
- モジュール分割の単位を明文化し、チームで合意する
- 共通化することにこだわりすぎず、「3回重複したら共通化」くらいにする
- モジュール数ではなく、変更の閉じ込め率を評価指標にする
段階的移行ロードマップ
1) 可視化フェーズ
まず依存関係とビルド時間を可視化します。ここを飛ばすと、移行後に「何が良くなったのか」が測れません。
- Gradle Build Scanでボトルネックタスクを特定
- 変更頻度の高いパッケージを抽出
- 依存サイクルの有無を確認
2) 境界確定フェーズ
次に、コードを動かす前に境界を合意します。
- feature, core, data などの責務を明文化
- API公開面を最小化して、内部実装は隠蔽
- 依存方向を片方向に固定
3) 抽出フェーズ
ここで初めてモジュールを切り出します。最初の対象は「変更が多いが境界が比較的明確」な領域が安全です。
// settings.gradle.kts
include(
":app",
":core:common",
":core:ui",
":core:data",
":feature:auth"
)
// feature/auth/build.gradle.kts
plugins {
id("com.android.library")
id("org.jetbrains.kotlin.android")
}
dependencies {
implementation(project(":core:common"))
implementation(project(":core:ui"))
implementation(project(":core:data"))
}
この段階では「完璧な分離」より「壊さず移す」を優先します。必要なら一時的なFacadeを置いて移行期間の差分を吸収します。
4) 最適化フェーズ
移行後に初めて最適化へ進みます。
- KSP/KAPTの配置を見直し、重い処理を局所化
- API/implementation依存を整理して再コンパイル範囲を縮小
- 不要モジュールの統合も含めて再評価
チームで運用したいこと
- 新規機能は原則feature配下に追加し、app直下を汚さない（定型的に書く必要があるコードは除く）
- モジュール公開APIはレビューで明示チェックする（
internal修飾子を適切に使う） - 月次で「分割したが価値が薄いモジュール」を棚卸しする
「分割したはいいけど、むしろ統合した方が楽じゃなかった？」ということがないか定期的に振り返り、時にはモジュールを統合する決断をとるのも大事です。
まとめ
マルチモジュール化は、規模拡大に対する万能薬ではありません。効果が出る条件を満たした時にだけ実施し、段階的に進めることで初めて投資対効果が合います。
実務での要点は次の3つです。
- 分割の開始条件を定量・定性の両面で定める
- 分割しすぎを防ぐため、責務境界から設計する
- 可視化から始める段階移行で、改善を計測しながら進める
これから着手するなら、最初の一歩は「どこを分けるか」ではなく「なぜ分けるか」の合意形成です。ここが揃うと、移行は驚くほど安定します。