Tweet
Tweet

Slide 1

Slide 1 text

© asken.inc 技術選定 askenでの取り組み Kotlin Multiplatform編 25/02/20 Takuya Osawa 習慣化アプリのモバイル開発の魅力を語る asken × mikan

Slide 2

Slide 2 text

© asken.inc 2 自己紹介 Takuya Osawa 株式会社asken モバイルテックリード 主な仕事 iOS版食事管理アプリの「あすけん」の開発を担当 趣味 野球観戦

Slide 3

Slide 3 text

© asken.inc アジェンダ 3 技術選定の重要性 技術選定のフローとポイント askenでのKMPを本格運用までのフロー 導入後の課題と対策と今後 まとめ

Slide 4

Slide 4 text

© asken.inc Kotlin Multiplatform(KMP)とは 4 Android、iOS、ウェブ、およびデスクトップ間でコード を再利用するためのツールです 言語はKotlinを使います https://www.jetbrains.com/ja-jp/kotlin-multiplatform/

Slide 5

Slide 5 text

© asken.inc 5 技術選定の重要性

Slide 6

Slide 6 text

© asken.inc 6 技術選定の重要性 プロジェクトの生産性や成功確率に直結する ● 開発スピードが遅くなり、スケジュール遅延する メンテナンス性と運用コスト ● 運用・保守が難しくなり、障害が起きやすくなる ● 結果として事業の継続が難しくなる

Slide 7

Slide 7 text

© asken.inc 7 技術選定のフロー とポイント

Slide 8

Slide 8 text

© asken.inc 8 課題の特定 課題を小さく分解 技術候補の比較 PoC（概念実証）で検証 技術要件の整理と合意 小さくリリース 本格導入

Slide 9

Slide 9 text

© asken.inc 9 課題の特定 (何を解決するのか？） まず、解決すべき課題を明確にします 課題の特定を誤ると方向性を見失います 「開発スピードを上げたい」 「アプリの起動時間が遅い」など

Slide 10

Slide 10 text

© asken.inc 10 課題を小さく分解（具体的な技術的アプローチを決める） 課題を細かく分解し、技術的にどの部分を改善すればよいかを整理し ます 必要であれば、深掘りする 「開発スピードを上げたい」 「要件が複雑」 「実装のスピードが遅い」など

Slide 11

Slide 11 text

© asken.inc 11 技術候補の比較 課題解決に適した技術をリストアップし、評価基準に沿って比較します 主観での意思決定を防ぎます

Slide 12

Slide 12 text

© asken.inc 12 PoC（概念実証）で検証 選定した技術をすぐに導入せず、まずは小規模なPoCを作成して検証します。 検証結果を元に技術選定の評価の解像度を上げる

Slide 13

Slide 13 text

© asken.inc 13 技術要件の整理と合意 関係者と要件を整理し、合意形成を行います。 全体像の共有 開発期間やリリーススケジュールに影響しないか？

Slide 14

Slide 14 text

© asken.inc 14 小さくリリース いきなり本番リリースせず、Staging環境や影響の少ない画面で試す。 A/Bテストを実施し、障害が起きて戻せるようにする

Slide 15

Slide 15 text

© asken.inc 15 本格導入 PoCと小さいリリースの結果を評価し、本格導入を進めます。

Slide 16

Slide 16 text

© asken.inc 16 askenのKMPを 本格運用までのフロー

Slide 17

Slide 17 text

© asken.inc 17 課題の特定と課題を小さく分解 モバイルエンジニア全員で課題の特定と分解を実施 空雨傘のフレームワークを使い、課題の解像度を上げる 空: 空が曇っている（事実） 雨：雨が降りそうだ（解釈） 傘：傘を持っていくべきだ（行動）

Slide 18

Slide 18 text

© asken.inc 18 課題の特定と課題を小さく分解 アプリの品質担保ができていない -> iOS/ Android間での実装差分による不具合 -> 通信周りのメンテナンス性が低い 古いライブラリや設計が残っているなど

Slide 19

Slide 19 text

© asken.inc 19 技術候補の比較 項目 ネイティブ (iOS / Android) Flutter KMP(Kotlin Multiplatform) 適応範囲 UIとロジック UIとロジック ロジックのみ 開発スピード 遅い 速い 一部速くなる 学習コスト 変わらない 高い iOSエンジニアが学 習する必要 既存との整合性 変わらない 大幅変更が必要 一部修正 テスト それぞれで実装 共通 一部共通 あくまであすけん開発環境、リソースでの比較です

Slide 20

Slide 20 text

© asken.inc 20 PoC（概念実証）で検証 KMPを仮で決めて、PoCを実施 ミニアプリを実装し、課題解決に対するアプローチ 評価観点が正しいどうかを確認 本番導入時のボトルネックはないか？

Slide 21

Slide 21 text

© asken.inc 21 技術要件の整理と合意 設計や実装方針 ロードマップの作成 -> リリース時期やスケジュールなど 関係者との合意（PM、モバイルエンジニア、バックエンドエン）

Slide 22

Slide 22 text

© asken.inc 22 実際はフローを行ったり来たりする 技術候補 の比較 PoC 技術要件 の整理

Slide 23

Slide 23 text

© asken.inc 23 最終決定 KMPを選定 重複実装が減り、品質担保がしやすい 適応範囲は通信周りまでにする -> UI近い部分は課題の範囲外なので今はやらない 既存のコードの資産があるので大幅な変更はコスパが悪い バックエンドの開発言語がKotlinなのでKMPに使えるリソースが増える。 -> 相互レビュー、実装、調査なのメリットが大きい

Slide 24

Slide 24 text

© asken.inc 24 小さくリリース iOSで先行リリース。-> Androidは依存周りの問題で先送り Staging環境で安定して動くのを確認。 影響の少なくするためにA/Bテストを仕組みを活用し、段階的にリリース 2024年4月より段階的に置き換え開始

Slide 25

Slide 25 text

© asken.inc 25 本格リリース🎉

Slide 26

Slide 26 text

© asken.inc 26 導入後の課題と対策と今後

Slide 27

Slide 27 text

© asken.inc 27 導入後の課題と対策 iOSエンジニアの学習コスト -> バックエンドエンジニアやAndroidエンジニアが実装することで解消 -> 生成AIを使えば、そんなに学習コストがかからないのでハードルは下がっている バックエンドエンジニア向けの学習 -> 説明会を実施し、環境構築や実装方法を説明

Slide 28

Slide 28 text

© asken.inc 28 今後の展開 KMP適応範囲の拡大 -> Androidはまだ、リリースできていない -> iOS側の適応範囲も広げたい KMPとSwift6の対応 -> データ競合の対応方針を決める KMPの実装できるエンジニアを増やす -> iOS、バックエンドエンジニアへの学習

Slide 29

Slide 29 text

© asken.inc 29 To be continued …

Slide 30

Slide 30 text

© asken.inc 30 まとめ 技術選定はプロジェクトの成功に直結します 課題を特定すること が一番大事です 何が問題なのかを特定し、分解し、最適なものを選び出す 導入後も新しい課題が出てくるので継続的に対策を考える

Slide 31

Slide 31 text

© asken.inc 31 Thank you!