脱React Native・KMP/CMP導入でかなえる、OS横断のアプリ開発

はじめまして。アルダグラムでAndroidアプリエンジニアを務める渡邊です。10年以上モバイルアプリの開発に従事しており、もともとAndroid/iOSの両方を開発していましたが、この7年ほどは基本的にAndroidを担当しています

アルダグラムは2019年に設立され、建設業や不動産業、製造業など、あらゆる現場の生産性向上を支援する現場DXサービス「KANNA（カンナ）」を展開しています。グローバル展開も進めており、東南アジアを中心に世界70カ国以上で提供しています。

Androidアプリの技術スタック

まずは、KANNAのAndroidアプリの技術スタックを解説します。アプリはReact Nativeで構築されていますが、React Nativeだけでは開発が難しい一部機能に関してはネイティブで実装してきました。AndroidではKotlin+Jetpack Compose、iOSではSwift+SwiftUIという形です。最近は、Kotlin Multiplatform/Compose Multiplatform（KMP/CMP）を使い、Android/iOSの両方を一つのコードベースで開発することを進めています。KMP/CMPとは、AndroidだけでなくiOSやWebなど、さまざまなプラットフォームをKotlin+Composeで開発できる技術です。

そのほか、GraphQLを採用しており、チャットなどの一部機能ではFirestoreを使ってリアルタイム通信を実現しています。アプリのアーキテクチャは、Androidの公式ドキュメントであるGuide to app architectureを参考にしており、Repository、必要に応じてUseCase、ViewModel、Compose、といった構成です。

Gradleはマルチモジュール構成としており、GoogleのNow in Androidを参考に、同じようなモジュール分けをしています。テストについては極力カバレッジを上げる方針で、JUnit 4やRobolectricといったテストフレームワークを使っています。勉強会で発表するには派手ではない構成かもしれませんが、新規メンバーでも把握しやすいよう、特殊な構成にしないように意識しています。

KANNAアプリの開発体制と機能例

当社のエンジニアは正社員・業務委託を合わせて30人ほどが在籍しており、複数の開発チームに分かれています。モバイルアプリ開発を担当するチームは現在、正社員3人、業務委託3人の6人体制です。同チームでは、Androidに強いメンバーが3人、iOSに強いメンバーが3人とバランスの良い構成だといえます。開発では、1週間のスプリントを繰り返すスクラム開発を採用しています。

機能開発では、担当エンジニアがまずDesign Docを作成し、チーム内でのレビューを経て開発に着手します。APIの改修や新規画面のデザインが必要な場合は、サーバサイドエンジニアやデザイナーの方々と密接に連携して進めます。

開発したアプリ機能の例として「写真・PDFの編集」「帳票」を紹介し、技術的なポイントや実装の工夫を解説します。

写真・PDFの編集機能

写真・PDFの編集機能では、写真やPDF上に線やテキストを書き込むことができ、書き込んだ内容に対し、移動、回転、拡大／縮小、削除などが行えます。「完了」ボタンを押すと編集内容がファイル保存される仕組みで、個人的には開発に苦労した機能の一つです。

同機能は、Composeではなく、AndroidのViewを使って構築しています。 使用しているライブラリは、写真表示に「panpf/zoomimage」、PDFの表示に「TalbotGooday/AndroidPdfViewer」、編集に「PdfBox-Android」をそれぞれ利用しています。

帳票機能

帳票機能では、Microsoft Excelで作成された帳票のひな形を取り込むと、電子帳票を作ることができます。紙で管理していた情報をペーパーレス化し、お客さまの業務効率を改善することが可能となります。

アプリでは帳票の表示・編集が可能で、文字／数値入力、ドロップダウン選択、日付入力、押印、画像挿入など、さまざまな形式での入力に対応しています。Excelで設定された関数や四則演算も部分的に利用できます。例えば「SUM関数」が組み込まれた箇所では、入力した数値を全て加算して合計額を表示する動作が可能です。

帳票ではWebViewでHTMLを表示し、TypeScriptを使ってDocument Object Model（DOM）の操作やネイティブ連携を行っています。TypeScriptをそのままAndroidアプリで使うことはできないため、JavaScriptへのトランスパイルが必要です。KANNAでは、ビルド時にwebpackを使ってTypeScriptをJavaScriptに変換し、その結果のファイルをassetsディレクトリに格納する専用のGradleプラグインを独自に作成しました。

KMP/CMPの採用背景、ネイティブ実装で生まれた新たな課題

当社の課題を説明するに当たり、アプリの開発史を振り返ります。創業当初は少数のWebエンジニアでモバイルアプリも開発しており、Reactに強いメンバーがいたことからReact Nativeを採用しました。開発が進むにつれて機能要件が高度化したことを受け、新たにアプリチームを組成したところ、同チームのエンジニアはモバイルアプリ開発は得意でもReact Nativeにそれほど精通していなかったため、ネイティブへの置き換えを検討するようになりました。

React Nativeの利用においては、既に保守されていないライブラリが原因でアップデートが困難になるという課題も抱えていました。過去にアップデートを試みた際は、あるライブラリを更新するとビルドでエラーになったり、ビルドできても画面が真っ白になったりするなどの不具合が多発し、非常に苦労しました。

アプリの動作がネイティブよりも遅いと感じる場面もありました。特に海外のAndroidユーザーが使っている端末はスペックが高くないものが多く、この課題が顕在化していました。こうした背景から、Android/iOSそれぞれにおいて、新機能開発や一部の既存画面を対象にネイティブで実装することにしました。

しかし、ネイティブでの実装を進めるにつれ、新たな問題も発生しました。AndroidとiOSで同じ機能を作る場合、それぞれで実装するため工数がかかります。細かい仕様のすり合わせや実装の差異も発生するため、エンジニア同士のやりとりも増えます。こうした工数やコミュニケーション負荷の増加によって、エンジニアが本来注力すべき機能開発や品質向上に時間を割けなくなる恐れがありました。こうした背景から、Android/iOS両方のアプリを一つのコードベースで完結できるKMPとCMPを導入することになったのです。

KMPだけでなくCMPも組み合わせることで、ユーザーインターフェース（UI）の部分まで共通化が可能となり、Android/iOSそれぞれで実装する場合と比べて工数が減ります。もし今後KMPやCMPが廃れることがあっても、Android側は資産として残る点も魅力的です。GoogleやJetBrainsがサポートしている点も、安心して導入できる要因の一つでした。一部機能を試験的に置き換えたところ、ユーザー体験（UX）を損ねることがなかったため、本格採用に至りました。

約15%を移行、27年には脱React Nativeへ

今後は、まずKMP/CMPを活用してReact Nativeのコードを置き換えていく方針です。現時点で、全画面の約15%を移行済みで、2027年ごろにはReact Nativeから完全に脱却することを目標としています。

AIを活用した開発にも注力する予定です。現状でもテストコードや簡単な画面の作成にAIを活用しており、React Nativeの画面コードからComposeへの変換などにもAIを取り入れたいと考えています。

当社では、Androidエンジニアの需要が高まっています。その背景には、KMP/CMP移行の本格化に加え、東南アジア展開の加速を視野に入れていることがあります。特に東南アジアではAndroidユーザーの比率が高く、Androidアプリの重要度が一層増しています。そのため、当社ではAndroidエンジニアを絶賛募集中です。^[1]