設計を取り入れてKMPの理解を 改善した話

Transcript

1. © 2025 Wantedly, Inc. 設計を取り入れてKMPの理解を 改善した話 KMP Ops Night - KMP導⼊後に訪れる、本当の戦いとは - November.11 2025 - 長尾 光
2. © 2025 Wantedly, Inc. 自己紹介 @hikaengineer 長尾 光 hikaru nagao hikaru_nagao_i Nagao-hikaru Mobile Growth Squad, Wantedly, Inc. Joined in April 2025
3. © 2025 Wantedly, Inc. 本日伝えたい話 / 背景 / 対象者 🚀 伝えたい話 • KMP開発を Androidエンジニア だけでなく iOSエンジニアも取り組めるようにした設計方法を紹介 🎯 対象者 • KMPを導入している、または導入を検討している方 • チーム内でKMPの理解・担当に偏りを感じている方 💡 背景 • KMP導入チームではiOSエンジニアの学習コストが高く Android メンバーに負荷が偏りやすい 　→ その課題をチームで改善したアプローチを紹介
4. © 2025 Wantedly, Inc. 目次 01 弊社が抱えていたKMPの課題 02 課題に対しての取り組み 03 まとめ
5. © 2025 Wantedly, Inc. 目次 01 弊社が抱えていたKMPの課題 02 課題に対しての取り組み 03 まとめ
6. © 2025 Wantedly, Inc. 弊社が抱えていたKMPの課題 弊社モバイルメンバーから出た一部の意見
7. © 2025 Wantedly, Inc. 弊社が抱えていたKMPの課題 • Kotlinのキャッチアップ • Stateがどのようにして変更されたか分 からない • Flowが良く分からない ⚠ iOSエンジニアの学習コスト • Androidエンジニアの⽅がKMPの対応 が早い ◦ kotlinのコードに読み慣れている • AndroidのUI実装が遅れてしまう ⚠ AndroidエンジニアがKMP対応しがち
8. © 2025 Wantedly, Inc. iOSエンジニアの学習コスト ⚠Stateがどのようにして変更されたか分からない Visit iOSアプリのアーキテクチャ Reactor • 独自の単方向データフローアーキテクチャ • ViewModelのようなもの データフロー Kotlin Multiplatform
9. © 2025 Wantedly, Inc. iOSエンジニアの学習コスト ⚠Stateがどのようにして変更されたか分からない Visit iOSアプリのアーキテクチャ • 独自の単方向データフローアーキテクチャ • ViewModelのようなもの データフロー Kotlin Multiplatform mutate() ~ reduce()まで処理を追うことが難しく、 最終的にStateがどう変化するか分かりづらい。。 Reactor
10. © 2025 Wantedly, Inc. AndroidエンジニアがKMP対応しがち AndroidのUI実装が遅れてしまう 専 ⾨ 性 Android iOS Kubode Nagao Minato Park Harada Kuronuma
11. © 2025 Wantedly, Inc. AndroidエンジニアがKMP対応しがち AndroidのUI実装が遅れてしまう KMP実装 Android UI実装 iOS UI実装
12. © 2025 Wantedly, Inc. AndroidエンジニアがKMP対応しがち AndroidのUI実装が遅れてしまう KMP実装 Android UI実装 iOS UI実装 iOS側のUI実装が先行して進みすぎてしま い、Andorid側のUI実装が遅れる
13. © 2025 Wantedly, Inc. • ⚠ Stateがどのようにして変更されたか分からない ◦ チーム全員が処理の流れを 見える化できる仕組み が必要 • ⚠ AndroidエンジニアがKMP対応しがち ◦ 役割に依存せず理解できる共通の設計が必要 • 上記の事から「KMPの設計」が必要 弊社が抱えていたKMPの課題 📝 課題を改善するために必要な仕組み
14. © 2025 Wantedly, Inc. 目次 01 弊社が抱えていたKMPの課題 02 課題に対しての取り組み 03 まとめ
15. © 2025 Wantedly, Inc. • 既存画面の修正 or 追加の場合、元々定義されている StateのAsIsを出す ◦ AsIsを出すことでKMPのキャッチアップがスムーズになる • その上でStateに追加するプロパティを明記する 課題に対しての取り組み 🚀 取り組み_1：Stateの内容がわかる設計書を作る
16. © 2025 Wantedly, Inc. 取り組み_1：Stateの内容がわかる設計書を作る 元々定義されているStateのAsIsを出す
17. © 2025 Wantedly, Inc. 取り組み_1：Stateの内容がわかる設計書を作る Stateに追加するプロパティを明記する
18. © 2025 Wantedly, Inc. 課題に対しての取り組み 🚀 取り組み_2：複雑な処理はフローチャートを作る
19. © 2025 Wantedly, Inc. • ⚠ Stateがどのようにして変更されたか分からない ◦ ✅ Stateで定義されているプロパティの役割とフローが可視化された事で、キャッチアップ が簡易になる • ⚠ AndroidエンジニアがKMP対応しがち ◦ ✅ 設計書がある事で、 iOSエンジニアでも対応しやすくなった 課題に対しての取り組み 🚀 取り組みの結果
20. © 2025 Wantedly, Inc. AndroidエンジニアがKMP対応しがち ✅ AndroidのUI実装が遅れてしまう KMP実装 Android UI実装 iOS UI実装
21. © 2025 Wantedly, Inc. • KMPはロジックを共有できても、理解の共有はできない • 設計を取り入れて構造を見える化することで、チーム全体で理解をそろえられた • 属人的だったKMP対応が、チームで支え合う開発体制に変化した • 技術よりも、理解を共有する仕組みがチームの力になる 📝 まとめ
22. © 2025 Wantedly, Inc. ご清聴ありがとうございました！！ @hikaengineer hikaru_nagao_i Nagao-hikaru