こんにちは、Androidエンジニアの冨田です。普段は新機能開発から技術改善までいろんなことをやっています。
今回は、あすけんのモバイル開発でKMP（Kotlin Multiplatform）をチームでどう活用しているか、どう効率化しているかについてご紹介します。
Before/After：開発フローがどう変わったか
KMP導入前は、同じAPIの通信層をAndroidとiOSでそれぞれ実装していました。
KMP導入後（After）、チームとしての変化は大きく3つあります。
- 実装が1回で済む：両OSで使えるので、単純に工数が減る
- OS間の仕様差異がなくなる：同じコードなので、レスポンスの扱いにズレが生じない
チーム全体で「同じことを2回やる」をやめた、というのが最初の大きな変化でした。
KMP化の条件と範囲
導入当初は「このAPIはKMPに向いてそうだからやってみよう」と慎重に選んでいましたが、知見が溜まるにつれて「これもKMPでよくない？」が自然に出るようになってきました。
現在の条件と範囲はこんな感じです。
条件
- 新規機能：基本KMPで実装
- 既存機能の改修：改修の機会になるべくKMPに寄せる
範囲
- 通信層：元々のKMP範囲
- 処理層：一部特殊なビジネスロジック（文字列検索処理など、複雑かつ独立させられるもの）
- バリデーション：簡単な入力チェック（バックエンドに届くエラーリクエストが減り、サーバー側のメンテナンスコスト削減）
KMP化しないところ
共通化の範囲を徐々に広げている一方で、現状KMPの対象に含めないと決めている領域もあります。それはUI層と処理層です。
どちらもOSごとにライフサイクルやコンポーネントの思想が大きく異なり、無理に共通化すると各OSの強みを潰し、共通化によるコストも増加してしまうと考えています。各OSのフレームワークに沿って書いたほうが、結果としてシンプルで保守しやすいコードになると考えています。
2回が1回になったが、まだ繰り返している
API仕様を見てDTO・Repository・テストを書く。通信層の実装を経験した方ならわかると思いますが、機械的な作業です。毎回繰り返しです。ここにもう1つ改善余地がありそうです。
手順書はすでにあった
実はKMP導入時から、チームで手順書を整備していました。
KMP側の実装手順、Android取り込み手順、iOS取り込み手順の３つです。
「KMP対応は詳しい人しかできない」状態にしないために、導入当初から手順書を用意してチームの誰でもできるようにしていました。
が、機械的な作業はとっても面倒です。
我々にはClaude Codeがいるじゃないか
手順書があり、作業が機械的であればAIに渡せばいいのでは？ということで、手順書をそのままClaude Codeのskillに落とし込みました。
| skill | 役割 |
|---|---|
create-kmp |
API仕様からKMPコードを自動生成 |
kmp-connect（Android） |
KMP → Androidへの取り込み |
kmp-connect（iOS） |
KMP → iOSへの取り込み |
スキルの中身は手順書そのものなので、手順書を直せばAIの出力精度も上がります。意識しているのは作業や構造をシンプルな構造に保つことです。シンプルであれば手順書にでき、手順書にできればskillにでき、skillにできれば自分の手を離れていきます。
まとめ
KMPを1年半チームで運用してきて大事だと感じているのは、個人ではなくチームの目線で運用することです。KMPを作成する作業が増えたとしても、チーム全体の作業量が減れば成功です。
Vibe Codingの時代になって、「シンプルに保つ」のメリットが大きくなってきたと感じます。シンプルな構造にはAIは正しいコードを出し、複雑な構造にはAIも複雑なコードを出します。レビューで苦しむのも、技術負債になるのも後者です。構造をシンプルに保つのがエンジニアの腕の見せ所ですね。
正しくサボるための仕組み作り、面倒なタスクからやってみてはいかがでしょうか？
私がいままで発信したテックブログ一覧
気になるタイトルがあれば、ぜひのぞいてみてください！
さいごに
askenでは、ミッションである【ひとびとの明日を今日より健康にする】を一緒に実現していくエンジニアを探しています。 ↓↓よければ、まずはカジュアルにお話しできればうれしいです！
