現場から生まれたKMMアプリ：DriveMate開発のリアル
〜「SwiftUI多言語化」から「KMMプロトタイプ」への一歩〜
前回の記事では、SwiftUIを使って社内向けモバイルアプリ DriveMate の多言語対応に挑戦しました。
その後も現場でのフィードバックを受けながら改良を続ける中で、次の課題が見えてきました。
「Androidでも同じ体験を届けたい」
Nusa Toyotetsuでは、ドライバーやスタッフの多くがAndroid端末を利用しています。
iOS版だけでは、現場全体のDXを進めるには限界がある。
そう感じた私は、新しい選択肢として Kotlin Multiplatform (KMM) に目を向けました。
まだプロトタイプ段階ではありますが、
DriveMateのロジックをKMMで共有し、AndroidとiOSの両方で動く構成を少しずつ試しています。
この記事では、その初期検証の記録と、現場発アプリとしての“次の一歩”を紹介します。
次の記事のテーマ：「なぜKMMを選んだのか」へ続きます 🚗💡
なぜKMMを選んだのか
DriveMateの開発を続ける中で、次第に感じたのは「チームの多様性」でした。
Nusa Toyotetsuには、日本人の管理者とインドネシア人のドライバーが共に働いています。
言語も文化も、そして使っているスマートフォンの種類も異なります。
日本ではiPhone、インドネシアではAndroid。
どちらも“現場”に欠かせない存在です。
🌏 AndroidとiOS、両方の文化を大切にしたい
FlutterのようにUIを統一する方法も検討しました。
しかし、現場のメンバーと話す中で「それぞれのデバイスに合った自然な体験を残したい」という意見が多くありました。
AndroidにはMaterial Designの心地よさがあり、
iOSにはHuman Interface Guidelineの美しさがあります。
「どちらの世界も尊重しながら、
でも中のロジックは同じ考え方で動かしたい。」
そう思ったとき、Kotlin Multiplatform (KMM) がぴったりだと感じました。
⚙️ “Shared where it matters” の考え方
KMMでは、アプリのビジネスロジックやデータ処理の部分を共通化できます。
UIはそれぞれSwiftUIとComposeでネイティブに作る。
この構成なら、両OSのユーザー体験を損なうことなく、
開発効率と保守性を両立できます。
Shared where it matters, native where it shines.
（共有すべきところは共有し、輝くところはネイティブのままに。）
この考え方は、DriveMateの開発方針とも自然に重なりました。
👣 小さな一歩から始める
初めからすべてをKMM化するのではなく、
まずはログイン機能やデータモデルといった“共通にしやすい部分”から検証しています。
一行のコードが、XcodeとAndroid Studioの両方で動いたとき、
「文化や国を越えても、ロジックは同じ言語で語れる」と感じました。
そして、ある日社長の車を運転しているとき、
「このロジックも共有できたらいいな」とふと心の中でつぶやきました。
――それが、DriveMateの“次の一歩”の始まりでした。
次の章では、DriveMateのKMM構成（プロトタイプ）と、実際に直面した課題について紹介します。 🚗💡
🧩 DriveMateのKMM構成（プロトタイプ）
DriveMateのKMMプロジェクトは、まだ試験段階ですが、**「現場で使える構成」**を目指して少しずつ形にしています。
以下は、現在検証中の基本アーキテクチャです。
⚙️ 構成のポイント
| レイヤー | 主な技術 | 説明 |
|---|---|---|
| UI Layer | SwiftUI（iOS） / Jetpack Compose（Android） | 各OSのネイティブ体験を重視。UIは完全に分離。 |
| Shared Logic (KMM) | Kotlin Multiplatform | ログイン処理・データモデル・共通ビジネスロジックを共有。expect / actualでプラットフォーム差を吸収。 |
| Firebase | Firestore / Auth / Storage | すべてのデータをFirebaseで集中管理。リアルタイムDB・認証・画像ストレージを統合。 |
| CloudKit | Apple Push Notification Service | iOS側ではデータ保存ではなく通知配信専用。 |
| Maps SDK | Google Maps SDK for iOS / Android | ドライバーのリアルタイム位置を表示。Firebaseデータと同期更新。 |
⚙️ CI/CD構成と運用の学び — DriveMateの次の挑戦
KMMによるDriveMateの共通ロジックが少しずつ形になり、
次に直面したのは「どうやって安全にリリースするか？」という課題でした。
まだチームは私ひとり。
でも、現場でのテストや社内デモのたびに、手動でビルドし、iPhoneとAndroidの両方に転送する作業は、思った以上に時間がかかります。
「自動でテスト・ビルド・配信まで流れる仕組みがあればいいのに。」
そう感じた瞬間から、DriveMateのCI/CD設計が始まりました。
🧠 現状の構成
💡 構成の概要
| 項目 | 技術 / サービス | 目的 |
|---|---|---|
| リポジトリ管理 | GitHub | DriveMateのコードを一元管理。mainブランチで安定版を運用。 |
| CI構築 | GitHub Actions | Kotlin部（KMM Shared）とAndroidビルドを自動化。 |
| iOSビルド | Xcode Cloud | SwiftUI部分を自動ビルドし、TestFlight配信まで実行。 |
| 配信 | Firebase App Distribution / TestFlight | テスター（社内スタッフ・ドライバー）に自動配信。 |
🚀 GitHub Actionsでの自動ビルド
DriveMateでは、KMMのsharedモジュールとAndroidアプリをGitHub Actionsで自動ビルドしています。
以下はその一部抜粋です。
name: Android CI
on:
push:
branches: [ main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
- name: Setup JDK
uses: actions/setup-java@v4
with:
java-version: 17
- name: Build KMM Shared and Android app
run: ./gradlew assembleDebug
これにより、Pushすると自動でビルドが走り、結果がSlack通知されます。
失敗した場合はすぐに原因を確認できるため、開発サイクルがぐっと短くなりました。
🍏 Xcode Cloudとの連携
iOS側では、Xcode Cloudを利用しています。
GitHubリポジトリと連携し、mainブランチの変更をトリガーにビルドを実行。
- Unit Test → UI Test → Build → TestFlight配信
という流れを自動化しました。
社内テスターは、リンクを開くだけで新しいビルドをインストールできます。
「ドライバーが“アップデートを待つ時間”がなくなった。」
現場からそう言われたとき、CI/CDの効果を実感しました。
💬 小さなチームだからこそ、自動化の価値がある
DriveMateの開発は、私ひとりの時間で成り立っています。
でも、「自動化」はまるで“もうひとりの仲間”のように働いてくれる存在です。
夜にGitHubへPushしておけば、
朝にはAndroidとiOSの両方で新しいビルドが届いている。
まるで、世界のどこかで一晩中働いてくれるエンジニアがいるような感覚でした。
それは孤独な開発を少しだけ温かくしてくれる仕組みでもあります。
📈 今後の改善予定
| 目標 | 内容 |
|---|---|
| 🔍 自動テストの強化 | SharedロジックにUnit Testを追加し、エラー検出を自動化。 |
| 🧩 Firebase連携 | CIでFirestoreルールのデプロイを自動化。 |
| ☁️ iOSビルド効率化 | Xcode CloudとGitHub Actionsのビルドキャッシュ共有を検討。 |
| 📦 バージョニング | Semantic Versioningに基づく自動タグ付けとリリースノート生成。 |
DriveMateのCI/CDは、まだ“手作り感”が残るものです。
でもその過程こそが、現場DXのリアルだと思っています。
次の章では、CI/CDを通じて見えてきた「チーム間の文化の違い」と
それをどうやって橋渡ししていくかを語ります。 🌏🤝
🌏 第5章 — チーム文化の橋渡しと、DriveMateのこれから
KMMによる共通ロジックと自動ビルド（CI/CD）を整えたことで、DriveMateは「動くプロトタイプ」から「チームで育てるプロダクト」へと一歩進みました。
この章では、異なる文化・プラットフォーム・働き方の間にあるギャップを、どのようにテクノロジーでつないでいくかを語ります。
🤝 “文化の違い”を越えて進む開発
DriveMateの開発に関わるメンバーは、日本人の管理層とインドネシア人の現場スタッフ。
日常的に使う言語、端末、仕事の進め方、どれを取っても違いがあります。
でも、KMMという共通言語（Kotlin）を導入してから、
開発そのものが「対話の場」になりました。
- 日本人上司はSwiftUIのデザインをレビュー
- インドネシアの仲間はAndroidのCompose実装をテスト
- 両者が同じビジネスロジック（Shared Layer）を見て意見を出す
それはまるで、技術が通訳になっているようでした。
「この仕様はAndroidでも同じ挙動になるの？」
「iOSのUIはもう少し柔らかくしても良いかも。」
そんな会話が生まれるたび、プロジェクトが“多文化コラボレーション”として成長していくのを感じます。
🧭 “Native Sovereignty”を越えた「Human Sovereignty」
DriveMateの原点は「ネイティブ主権（Native Sovereignty）」、
つまり「OSの文化を尊重する」ことでした。
しかし、開発を進める中で気づいたのは、
最も大切なのは“人の文化”を尊重することだということ。
AndroidもiOSも、技術の違いに過ぎません。
けれど、その裏には「現場で働く人たちの生活」があります。
アプリが速く動くことより、誰もが安心して使えることの方がずっと価値がある。
KMMは単にコードを共有するための技術ではなく、
文化をつなぐための橋なのだと思うようになりました。
🚗 DriveMateが目指す次の現実的ステップ
DriveMateの開発はまだ続いています。
派手なAI機能を追加するよりも、今は**「現場で確実に使われる」**ことを優先しています。
| 項目 | 内容 |
|---|---|
| 🗂️ データ同期 | FirestoreとCloudKitのハイブリッドを安定化させる |
| 🧪 テスト | Sharedロジックのユニットテスト導入 |
| 🔐 セキュリティ | Firebase Authのロールベース制御（管理者・ドライバー権限） |
| 🚀 デプロイ | CI/CDフローの軽量化と通知改善 |
| 🌐 多言語拡張 | 英語・日本語・インドネシア語 |
特にデータ同期とセキュリティの最適化は、
「現場が安心して使えるDX」を実現するための最優先テーマです。
🪶 開発を通して得た学び
DriveMateを作りながら、私はプログラマーである前に「現場の一員」であることを学びました。
KMMやSwiftUIは、そのための“言葉”にすぎません。
- コードを書くことは、人の仕事を支えること。
- 自動化することは、時間を人に返すこと。
- 共有することは、文化を尊重すること。
これが、私がDriveMateから得た一番の気づきです。
🌸 まとめ — DriveMateが示す道
DriveMateはまだ小さな社内アプリですが、
その中にはグローバルチームの未来の縮図があると思っています。
「文化が違っても、同じ目的で動ける。」
「ネイティブのままでも、共通のロジックでつながれる。」
KMMはその“証拠”になりました。
そしてDriveMateは、Nusa Toyotetsuの現場DXを象徴するプロジェクトとして、
これからも静かに、しかし確実に進化していきます。
📘 次回の記事予定
「Firestore × CloudKit ハイブリッド同期の安定化と、Shared層のエラーハンドリング設計」
もしこの記事が参考になったと思ったら、💚いいね やコメントをお願いします。
次の記事で、さらに実践的なKMMとFirebaseの連携設計を紹介します。