技術選定 askenでの取り組み Kotlin Multiplatform編

https://asken.connpass.com/event/343700/

Transcript

1. © asken.inc 技術選定 askenでの取り組み Kotlin Multiplatform編 25/02/20 Takuya Osawa 習慣化アプリのモバイル開発の魅力を語る asken × mikan
2. © asken.inc 2 自己紹介 Takuya Osawa 株式会社asken モバイルテックリード 主な仕事 iOS版食事管理アプリの「あすけん」の開発を担当 趣味 野球観戦
3. © asken.inc アジェンダ 3 技術選定の重要性 技術選定のフローとポイント askenでのKMPを本格運用までのフロー 導入後の課題と対策と今後 まとめ
4. © asken.inc Kotlin Multiplatform(KMP)とは 4 Android、iOS、ウェブ、およびデスクトップ間でコード を再利用するためのツールです 言語はKotlinを使います https://www.jetbrains.com/ja-jp/kotlin-multiplatform/
5. © asken.inc 5 技術選定の重要性
6. © asken.inc 6 技術選定の重要性 プロジェクトの生産性や成功確率に直結する • 開発スピードが遅くなり、スケジュール遅延する メンテナンス性と運用コスト • 運用・保守が難しくなり、障害が起きやすくなる • 結果として事業の継続が難しくなる
7. © asken.inc 7 技術選定のフロー とポイント
8. © asken.inc 8 課題の特定 課題を小さく分解 技術候補の比較 PoC（概念実証）で検証 技術要件の整理と合意 小さくリリース 本格導入
9. © asken.inc 9 課題の特定 (何を解決するのか？） まず、解決すべき課題を明確にします 課題の特定を誤ると方向性を見失います 「開発スピードを上げたい」 「アプリの起動時間が遅い」など
10. © asken.inc 10 課題を小さく分解（具体的な技術的アプローチを決める） 課題を細かく分解し、技術的にどの部分を改善すればよいかを整理し ます 必要であれば、深掘りする 「開発スピードを上げたい」 「要件が複雑」 「実装のスピードが遅い」など
11. © asken.inc 11 技術候補の比較 課題解決に適した技術をリストアップし、評価基準に沿って比較します 主観での意思決定を防ぎます
12. © asken.inc 12 PoC（概念実証）で検証 選定した技術をすぐに導入せず、まずは小規模なPoCを作成して検証します。 検証結果を元に技術選定の評価の解像度を上げる
13. © asken.inc 13 技術要件の整理と合意 関係者と要件を整理し、合意形成を行います。 全体像の共有 開発期間やリリーススケジュールに影響しないか？
14. © asken.inc 14 小さくリリース いきなり本番リリースせず、Staging環境や影響の少ない画面で試す。 A/Bテストを実施し、障害が起きて戻せるようにする
15. © asken.inc 15 本格導入 PoCと小さいリリースの結果を評価し、本格導入を進めます。
16. © asken.inc 16 askenのKMPを 本格運用までのフロー
17. © asken.inc 17 課題の特定と課題を小さく分解 モバイルエンジニア全員で課題の特定と分解を実施 空雨傘のフレームワークを使い、課題の解像度を上げる 空: 空が曇っている（事実） 雨：雨が降りそうだ（解釈） 傘：傘を持っていくべきだ（行動）
18. © asken.inc 18 課題の特定と課題を小さく分解 アプリの品質担保ができていない -> iOS/ Android間での実装差分による不具合 -> 通信周りのメンテナンス性が低い 古いライブラリや設計が残っているなど
19. © asken.inc 19 技術候補の比較 項目 ネイティブ (iOS / Android) Flutter KMP(Kotlin Multiplatform) 適応範囲 UIとロジック UIとロジック ロジックのみ 開発スピード 遅い 速い 一部速くなる 学習コスト 変わらない 高い iOSエンジニアが学 習する必要 既存との整合性 変わらない 大幅変更が必要 一部修正 テスト それぞれで実装 共通 一部共通 あくまであすけん開発環境、リソースでの比較です
20. © asken.inc 20 PoC（概念実証）で検証 KMPを仮で決めて、PoCを実施 ミニアプリを実装し、課題解決に対するアプローチ 評価観点が正しいどうかを確認 本番導入時のボトルネックはないか？
21. © asken.inc 21 技術要件の整理と合意 設計や実装方針 ロードマップの作成 -> リリース時期やスケジュールなど 関係者との合意（PM、モバイルエンジニア、バックエンドエン）
22. © asken.inc 22 実際はフローを行ったり来たりする 技術候補 の比較 PoC 技術要件 の整理
23. © asken.inc 23 最終決定 KMPを選定 重複実装が減り、品質担保がしやすい 適応範囲は通信周りまでにする -> UI近い部分は課題の範囲外なので今はやらない 既存のコードの資産があるので大幅な変更はコスパが悪い バックエンドの開発言語がKotlinなのでKMPに使えるリソースが増える。 -> 相互レビュー、実装、調査なのメリットが大きい
24. © asken.inc 24 小さくリリース iOSで先行リリース。-> Androidは依存周りの問題で先送り Staging環境で安定して動くのを確認。 影響の少なくするためにA/Bテストを仕組みを活用し、段階的にリリース 2024年4月より段階的に置き換え開始
25. © asken.inc 25 本格リリース🎉
26. © asken.inc 26 導入後の課題と対策と今後
27. © asken.inc 27 導入後の課題と対策 iOSエンジニアの学習コスト -> バックエンドエンジニアやAndroidエンジニアが実装することで解消 -> 生成AIを使えば、そんなに学習コストがかからないのでハードルは下がっている バックエンドエンジニア向けの学習 -> 説明会を実施し、環境構築や実装方法を説明
28. © asken.inc 28 今後の展開 KMP適応範囲の拡大 -> Androidはまだ、リリースできていない -> iOS側の適応範囲も広げたい KMPとSwift6の対応 -> データ競合の対応方針を決める KMPの実装できるエンジニアを増やす -> iOS、バックエンドエンジニアへの学習
29. © asken.inc 29 To be continued …
30. © asken.inc 30 まとめ 技術選定はプロジェクトの成功に直結します 課題を特定すること が一番大事です 何が問題なのかを特定し、分解し、最適なものを選び出す 導入後も新しい課題が出てくるので継続的に対策を考える
31. © asken.inc 31 Thank you!