こんにちは。海外事業部のnakawaiです。北米版あすけんのAndroidアプリを開発してましたが、今年の春からマネジメント領域にも関わることになり、以前にも増して手探りの日々を過ごしています。

さて本記事は、マルチプラットフォーム技術のKMM (Kotlin Multiplatform Mobile)について、今後導入の可能性を視野に入れて調べてみたものになります。これまではあまり積極的に情報収集していなかったのですが、今後のモバイル開発方針について社内で検討しはじめたことや、先日参加させていただいたAndroid開発のイベント「 Qiita Night-2022年、Androidアプリはどう作る？」で各社のKMMの導入事例が紹介されており、弊チームの価値提供スピード向上にも寄与する可能性を感じたことなどから、本記事を書くに至りました。

マルチプラットフォーム技術への期待

ネイティブアプリ開発の宿命として、「iOS/Androidそれぞれで、同じような実装をする」という状況が必然的に多く発生します。これによって単純に開発工数が二倍になるだけでなく、仕様の差異や不具合が生まれてしまったり、コミュニケーションコストが増えたりします。こういった課題は、ネイティブアプリエンジニアなら一度は感じたことのある人も多いのではないでしょうか。マルチプラットフォーム技術の導入は、そういった課題を解決する可能性を秘めています。

マルチプラットフォーム技術への懸念

しかしながら、もともと私個人としてはモバイルアプリ開発におけるマルチプラットフォーム技術の採用については慎重派でした。一番の理由は、それなりにネイティブアプリ開発経験を持つエンジニアとして「iOS/AndroidのOS差異を吸収してワンコードで書く」というアプローチ自体に、どうしても先々の辛さを感じとってしまうからです。実際「マルチプラットフォーム技術が負債化してしまい、ネイティブアプリに移行した」という事例は少なからず耳にします。(※もちろん、負債化のリスクを承知しつつ戦略としてマルチプラットフォーム技術を採用する判断は十分ありえると思います)

そういった状況を踏まえつつも、昨今のマルチプラットフォーム技術の盛り上がりもあり、モバイル開発のありたい姿の一つとして可能性を探るべき重要な領域だと考えるようになってきました。

KMMは UX/UI部分を共通化せず、ロジックのみを共通化する。部分導入も可能

KMMは「Share the logic of your iOS and Android apps while keeping the UX native」というキャッチフレーズが示す通り、「UX部分はネイティブコードのまま、ロジック部分だけを共通化する」という特徴的なコンセプトを持ちます。ここがFlutterやReact Nativeと比較したときの、KMMの大きな特徴です。このアプローチは、前述のような懸念を感じていた私としては合理的に感じました。また、スモールスタートで部分的に導入できるのもリスクヘッジの観点で好印象です。

KMM導入メリット/デメリットはプロダクトの戦略によって変わる

弊チームのプロダクトの事情で考えると、以下のような要素において相性が良さそうに感じました。

UI/Dataの詳細とビジネスロジックを分離するアーキテクチャを採用している
Android/iOSそれぞれに適切なUX/UIを設計している
すでにiOS/Androidそれぞれの、ネイティブアプリでのコード資産が多い
Androidを優先し、後追いでiOSに横展開している

1についてですが、大枠では以下のようなアーキテクチャ設計になっています。KMMを導入する場合、まずはビジネスロジックが多く記述されているDomain層が共通化の対象にしやすいと思います。また、Data層もNetworkやDBの詳細を分離しているので、キャッシュやリトライ処理などを共通化するといったことも実現できます。

実際に触ってみた所感。学習コストは少なそう

公式ページに従って、ざっと新規プロジェクト作成や既存プロジェクトへの導入を試してみました。詳細な手順は他の記事に譲りますが、印象としては想像以上に導入は簡単でした。Android StudioのPluginとして提供されるので、Androidエンジニアはとりあえず書くだけならほぼ学習コストゼロでいけそうな感触です。このあたりは、やはりあのJetBrainsが開発しているという強みを感じました。 (サラッと触った程度なので、踏み込んだ開発をする上では当然いろいろ学習コストは発生すると思います)