WantedlyでのKotlin Multiplatformの導入と課題

ウォンテッドリー株式会社でMobile Tech Leadを務めている久保出です。

本記事は、Wantedly Advent Calendar 2024の24日目の記事です。23日目は、富岡によるエンジニアが PdM ロールを兼務して意識するようになったことでした。

本記事では、Kotlin Multiplatformの簡単な説明から弊社の導入事例、導入プロセス、そして現在直面している課題について、実体験を交えてお伝えします。この記事が、KMP導入を検討している方や、モバイル開発の課題を解決したいと考えている方の参考になれば幸いです。

想定読者

Kotlin Multiplatformに興味があるモバイルエンジニア
iOS/Androidでの開発に課題を感じているモバイルチームリーダー
技術選定に関わる意思決定者

Kotlin Multiplatformとは

Kotlin Multiplatform（以下KMP）は、Kotlinを使用して複数プラットフォーム向けのコードを共有するための技術です。AndroidやiOSだけでなく、デスクトップやウェブにも対応可能です。特に、共通ロジックを共有することで、コードの重複を削減し、保守性を向上させることが期待できます。

KMPは、他のクロスプラットフォーム技術（React NativeやFlutterなど）と異なり、共通化するレイヤーを自由に決定できる点が特徴です。主にビジネスロジックやデータ層を共通化し、UI部分は各プラットフォーム固有のコードで実装する使われ方が一般的です。これにより、各プラットフォームのネイティブな体験を損なわずに、コードの再利用が可能になります。

弊社導入事例の紹介

弊社では、2020年9月にWantedly VisitアプリへKMPを導入しました。詳しくは、React Nativeをやめる話とKotlin Multiplatformをご覧ください。以下では、その背景と得られた成果について具体的に説明します。

なぜ導入したか

KMPを導入した背景は、大きく2つあります。

React Nativeの負債化

2020年以前には、アプリの一部画面でReact Nativeが使われていましたが、以下の課題がありました。

メンテナーが不在となり、モバイルエンジニアで技術スタックが異なるものをメンテナンスする必要性が生まれた
iOSとAndroidそれぞれのビルドツールと密に結合しており、ビルドツールのアップデートを困難にした
React Nativeの画面とネイティブAPIで作られた他画面とで、体験の差が生まれていた

iOSとAndroidでの動作の不一致

iOSとAndroidで、同一の機能に対して挙動が異なるという問題が頻発していました。具体的には、APIスキーマ定義が異なることによるバグや、キャッシュ設計が異なる問題、タイムスタンプのようなUIの表示ロジックが異なるといった問題です。

このような差異が原因で、品質上の問題と対処コストが増大していました。

導入で得られた成果

導入のプロセスや導入時の課題については、後述します。まずは、KMP導入によって得られた利点について説明します。

負債の返済

KMPへ置き換えを進めていくことにより、負債化していたReact Nativeを取り除くことができました。これにより、モバイルエンジニアの技術スタックでメンテナンスができるようになりました。

動作の不一致の解消

KMPを導入することで、iOSとAndroidで共通のビジネスロジックを実現しました。これにより、KMPが導入された機能では、iOSとAndroidでの動作の不一致が大幅に減少し、品質向上につながりました。

設計プロセスの改善

KMP導入にあたり、共通コードの設計が重要となり、チーム全体で設計により重点を置いて考えるようになりました。具体的には、強制的にKMPの共通ロジックがレイヤーとして切り出されるため、UIと共通ロジックとの責務の切り分けが進んだり、例外処理の責務をどこに置くかを設計時に考えるようになりました。結果として、コードベース全体の設計品質を高めるきっかけとなりました。

KMP/iOS/Android並列開発

設計プロセスが改善されたことにより、KMPとのインターフェースを先に決定するようになりました。その結果、iOSとAndroidはインターフェースをもとにSwiftUIやJetpack Composeでのプレビュー駆動開発を進め、KMPはインターフェースの実装を進めるといった並列開発を進めるようになり、開発効率を高めることができました。図で表すと次のような流れです。

さらに、設計段階での議論が活発化し、各プラットフォーム間での技術的な相互理解が進んだことも成果の一つです。

導入プロセス

チームへの共有やヒアリング

KMP導入に際して、まずはチーム内で現状の課題感を共有し、課題の解決策としてKMPを導入しようとしていることを話しました。また、導入に関する懸念や不安を個々人にヒアリングし、それらを払拭できるように解決策を模索しました。

ヒアリングでは、主にReact Nativeとの対比で懸念が多くあがりました。iOSエンジニア視点からはKotlinを学習するコストがかかること、KMPがOSやビルドツールのアップデートのネックとなる可能性、検証期間や検証方法をどうするのかなどです。

検証フェーズ

前述の懸念を少しずつ解消するために、スコープを小さく絞って検証を進めることにしました。

プロトタイプとなるアプリを作成してみるだけでは、実環境での検証にはなりません。そのため、実際に1画面分のKMPの実装をして、iOSとAndroidに導入して問題なく動作するのかを検証しました。

2020年の導入当初は、KMP自体がiOS上での動作に課題（マルチスレッドでのMutabilityの課題）があり検証が難航したものの、小さく検証することで課題を徐々に解決していきました。

説明責任を果たす

KMPは、iOSとAndroid双方の開発に影響するため、単なる技術選定ではなく、プロダクト全体の意思決定となります。チームやステークホルダーに対して、導入検討時に長期的な観点でのメリットやリスクを説明して合意形成を図り、導入途中も都度状況を共有ながら進めました。

導入当時、プロダクト責任者に対してKMPの導入を検討していることを相談し、KMPそのものや得られることについて説明したうえで、懸念や判断に必要な検証ポイントをすり合わせしました。相談を持ちかけることで、導入者である私の欠けている視点やステークホルダーの観点を得ることができました。

こういった懸念などをクリアにしていくことで、最終的には導入の合意に至ることができます。これを果たせない場合は、導入に至ることはできません。

導入後に直面した課題と対処

導入後に発覚した問題に対する定期的な振り返りの実施

導入時に検証はしたものの、導入後に発覚する課題はつきものです。技術的な課題だけではなく、チームやプロセス上の課題もあります。そういった課題に対処するため、定期的な振り返りを実施しました。それにより、KMPへのフィードバックや改善点を集めることができ、継続的な改善を続けられました。

チームメンバーの学習コスト

時間とともにチームは変化していきます。KMP自体を経験している人は少数であり、その都度学習コストを支払うと長期的なコストが増えてしまいます。この課題に対処するために、いくつかの施策に取り組みました。

ドキュメント化の推進

KMPに関連するドキュメントを整備し、新メンバーでもスムーズに理解できるようにしました。具体的には、KMPプロジェクトのREADMEを拡充し、セットアップ手順や全体的なアーキテクチャの説明、各モジュールの役割と責務について記載しました。また、よくある問題や不明点を気軽に聞けるような質問場所を用意し、その解決方法を記録として残るようにしました。

ペアプロやモブプロの実践

KMPに慣れていないメンバーをサポートするため、ペアプロやモブプロを積極的に実施しました。これにより、KMPの知識共有が進み、チーム全体のスキル向上につながりました。KMPだけでなく、全体的なアーキテクチャの理解や、iOSとAndroidの相互理解も進み、副次的な良い効果も生まれました。

現在の課題

KMPをバイナリにしている課題

KMPをバイナリ形式でiOSとAndroidへ配布しているため、変更時の影響範囲が大きく、リリースサイクルが複雑化しています。具体的には、破壊的な変更がKMPに発生したとき、iOSとAndroid双方の対応が必要になる課題があります。

この改善策は模索中ですが、バイナリ形式からソース形式への依存形態に移行することが1つの改善策として考えられます。

iOS先行開発時の課題

弊社では、新機能開発をiOSから先行して行う場合があります。そのため、本来はiOSとAndroidで共通利用されるはずのKMPが、iOSのみで使用されるケースがあります。これには、後追い開発となるAndroidの実装コストが大幅に削減できる利点はありますが、グロース施策など将来的に破棄される可能性のある機能では、iOSの実装のみで終了する場合もあります。こういったiOS先行やiOSのみの開発の場合では、KMPはボトルネックになってしまうことがあります。

これに対する改善策は、現在模索中の段階です。