概要
「初心者も OK！3 社のリアルな活用術から学ぶ Kotlin Multiplatform Night」に参加したので、感想を記述します。
参加した理由
普段から Kotlin に関心を持っており、特にサーバーサイド Kotlin に興味があります。 最近は時間を割いていませんが、過去にはサーバーサイド Kotlin LT 大会 vol.11やKotlin Fest 2024に登壇したことがあるぐらい思い入れのある言語です。
Kotlin を開発している JetBrains が最近 Kotlin Multiplatform（KMP）に力を入れています。 KMP について個人的には、Android 開発以外で認知度が低い Kotlin が普及する一助になるのではないかと考えていましたが、まだまだ普及は先だろうと考えていました。 しかし、今回の勉強会は国内の導入事例ということで、非常に貴重な機会だと思い今回参加することにしました。
感想
各セッションごとに、メモや感想を書いて最後に全体的な感想を書きます。
LT
Kotlin Multiplatform: Present and Near Future
JetBrains の Pamela Hill さんの発表でした。 JetBrains に所属している人の発表を聞けるのは非常に貴重だと思い、今回の目玉セッションの 1 つだと考えており参加しました。
しかし、会場の入り方がわからず、遅刻してしまい、ほとんど聞けませんでした。。。。
KMP with Crashlytics の落とし穴
SanSan の鎌田さんの発表でした。
KMP 移行後にクラッシュが起きたときの集計ができず、導入の課題になってしまう可能性がありましたが、CrashKiOS によって解決したといった発表でした。
個人的に CrashKiOS は公式サポートされないかと思いましたが、Kotlin はあまりそういった機能を積極的に導入しない印象がありました。
Kotlin Multiplatform のポテンシャル -『スタディサプリ 小学・中学講座』のケース
リクルートの石田さんの発表でした。
スタディサプリにおける、KMP の導入事例、メリット、デモによる実演が説明されました。 既存のコードの流用ができやすく、KMP はクロスプラットフォームの第三の選択肢といった内容でした。
iPad OS におけるデモが実際に動く様子を見られていて、組織的な決断ができるのであれば KMP も許可されそうな技術だと思いました。
Wantedly での Kotlin Multiplatform の導入と課題
ウォンテッドリーの久保出さんの発表でした。
導入時の課題をもとに KMP を検討し、提案から過程までにやったこと、効果と今後の課題について明確に説明していただきました。
自身が言語やフレームワークのリプレイスは組織的な取り組みやプロセスの方が重要だと考えているので、それをクリアにしながら取り組んだことやそれぞれの過程が記録として残っていることに感銘しました。
パネルディスカッション
クロスプラットフォーム技術の選択として、KMP を選んだのはなぜか
Flutter、React Native、KMP の中で KMP を選んだ理由についてのディスカッションでした。
Flutter、React Native の競争の中で、KMP がどのように立場を確立できるのか、今後が気になりました。
- 石田さん:既存のコードを再利用できるため。
- 北村さん:部分的なクロスプラットフォームを作るのに KMP である必要があった
- 久保出さん:React Native の除去が課題。モバイル開発のパフォーマンスを上げるのに KMP。Flutter は early すぎたことや React Native の二の舞になる可能性があった。モバイルアプリケーションチームの持ち物も減らせる期待があった
KMP 導入にあたり、社内のステークホルダーをどのように説得したのか。
導入時のステークホルダーの説得についての発表でした。
KMP に限らず、リプレイス・リアーキテクチャといった取り組みは機能追加よりも優先されるため、ステークホルダーを説得するのが非常に困難だと考えています。 各責任者の組織的な取り組みが非常に印象に残りました。
- 北村さん:会社の OKR の 1 つに生産性を上げることがあったので、KMP を提案した。その際に合意がとれた。Android エンジニアの説得は簡単（むしろチャレンジとして受け入れられた）だったが、iOS エンジニアにはヒアリングした。経営層に共通化による開発工数の削減や難易度による工数の増加を具体的な数字から説得した
- 久保出さん:課題ベースだったので、導入そのものに対する反対はなかった。PoC などはやった。説得とやりきる
- 石田さん:最初は半信半疑だった。検証して自分が納得しつつ見えてきた。
KMP を導入して、技術面以外でどのような変化があったのか。
KMP 導入時に生まれた副次効果についてでした。 コンウェイの法則への影響が大きいと考えたので、そういった側面で良い効果があるとおもしろいと思いました。
- 北村さん:ネイティブアプリケーションのチームが 1 つのチームになった。PF ごとにリリースのずれがなくなったり、互いの敷居をまたいだチャレンジができるようになった
- 久保出さん:組織的な変化が生まれた。並列で機能開発できるようになってリリース時期がずれなくなった
- 石田さん:スタディサプリはまだリリースされていないが、開発生産性の向上やコミュニケーションコストの削減が可能になった
KMP の課題と期待する改善ポイント
技術のアーリーアダプターならでは悩みや期待についてのお話でした。
特に、Wantedly さんは 4 年も前から導入しているということで、独自に解決したものから、仕様追加によって解決したものもありそうで興味深かったです。
- 石田さん:KMP は技術的に成熟していると考えている。懸念は将来的に枯れていかないかという考えはある。それを阻止するために導入事例を出していきたい。JetBack のサポートや Swift Export に期待
- 北村さん:大きな課題は特になかった。しかし、細かい課題があり、ちょっとした工夫が点在するようになってしまった。Xcode でコードをいじるときにコード補完が効かないことの改善
- 久保出さん:課題は iOS 側の負担。KMP に問題があったときに、デバッグの手間がかかってしまう。Crashlytics をデフォルトで用意してほしい
まとめ
自身が、KMP について Arrow のコードリーディングで活用事例を知ったことぐらいで、知見がほとんどなかったため、実際に運用されている事例を知れた良い機会でした。
私は Swift を利用している iOS エンジニアが言語スイッチによる反発を買うのではないかと想像していた時期もあったのですが、懇親会でお伺いしたところ、そんなことはなかったのが意外でした。
私が業務と個人開発の両方において、ネイティブアプリケーションに対して KMP を利用する予定はありません。
しかし、Arrow.kt といったライブラリの対応や今後の Kotlin の進化を注視するためにも、ウォッチし続けようと考えています。
