ソフトウェア設計が分かっていても、 Android アプリが作れない理由

ソフトウェア設計が分かっている人が、必ずしも Android アプリをうまく作れるとは限らない。 これは、 Android 開発を続けてきて、何度も実感してきたことだ。

設計原則を理解している。 責務分離の重要性も分かっている。 それでも、 Android アプリとして形にしようとすると、どこかで無理が出る。

その理由は、単に Android OS の制約が強いから、というだけではない。

Android アプリの設計は「掛け算」で成立する

Android アプリの設計は、次の要素が同時に成立して初めて機能する。

  • Android OS 固有の制約
  • Kotlin という言語の前提
  • Jetpack Compose という UI モデル

どれか一つだけ分かっていても足りない。

Android OS 固有の制約

まず避けて通れないのが、 OS の制約だ。

  • ライフサイクルが複雑で、いつ破棄されるか分からない
  • プロセスは OS 都合で突然 kill される
  • バックグラウンド動作や権限には厳しい制限がある

これらを無視した「きれいな設計」は、実機上では簡単に崩れる。

Android では、 壊されることを前提に設計する 必要がある。

Kotlin を「使っている」と「使いこなしている」の差

次に重要なのが、 Kotlin という言語そのものだ。

Kotlin は書きやすいが、設計の前提として使いこなせていないと、簡単に歪みが出る。

  • 不変性を前提にした設計が、 mutable な状態で侵食される
  • nullable の扱いが曖昧になり、責務境界が崩れる
  • Coroutine のスコープやキャンセルを理解しないまま非同期設計をすると、副作用が漏れる

設計思想があっても、 言語機能を前提に設計を落とせない と、 Android アプリでは破綻しやすい。

Jetpack Composeは「 UI 実装」ではなく「設計そのもの」

Jetpack Compose は、UIフレームワークというより、 設計モデルそのもの だと感じている。

  • 状態駆動
  • 宣言的 UI
  • 再コンポーズ
  • 副作用の明示的な管理

これらを理解せずに使うと、

  • なぜ再描画されるのか分からない
  • どこで状態が変わっているのか追えない
  • UI とロジックの境界が曖昧になる

といった問題が起きる。

Compose を使うということは、 状態と副作用をどう分離するかを設計すること でもある。

「設計思想 × Android 文脈」が価値になる

ここまで書いてきて思うのは、

  • 一般的なソフトウェア設計が分かっている だけでは
  • Androidアプリは成立しない

ということだ。

Android には、

  • OS の制約
  • Kotlin の言語特性
  • Compose の UI モデル

という、強い前提条件がある。

これらを理解した上で、

  • どこに状態を置くか
  • どこで副作用を起こすか
  • 何を UI に公開し、何を隠すか

を判断できて、初めて Android アプリとしての設計 になる。

自分の強みについて

今回あらためて気づいたのは、自分の強みは

設計思想 × Android アプリ実装

の掛け算にある、ということだった。

世の中を見渡すと、

  • 設計は分かるが、 Android の文脈が分からない人
  • Androidは分かるが、設計が分からない人

は、それぞれ一定数いるように思う。

一方で、 設計と Android の両方を、深く理解している人 は、決して多くないと感じている。

  • Android という制約の強い環境で
  • 現実的に動く形まで落とし込み
  • 後から破綻しにくい設計を考える

これは、設計だけ分かっていても、 Android だけ書けても、簡単には身につかない。

これからも、「設計思想 × Android アプリ実装」を積み重ねていきたい。