What's the recommended Flutter architecture

今新規で作るならFlutterの
アーキテクチャってなんなの？MVVMなの？
Findy Job Lunch Talk
【Flutter特集】Flutter開発の裏側 ~各社が向き合う課題と挑戦~

https://findy.connpass.com/event/370621/

Transcript

1. 今新規で作るならFlutterの ア ーキテクチャってなんなの？ MVVMなの？ Findy Job Lunch Talk Flutter開発の裏側 ~各社が向き合う課題と挑戦~ _a_akira
2. % About me 2 https://aakira.app https://aakira.studio 🐕 ✈ 📷 🎾 🤸 🚁🏠⊿ aakira.studio AAkira _a_akira M3, Inc. Akira Aratani
3. % About me 3 https://aakira.app https://aakira.studio 🐕 ✈ 📷 🎾 🤸 🚁🏠⊿ aakira.studio AAkira _a_akira M3, Inc. Akira Aratani まとめ 最近の取り組み WHITE JACKの例 デジスマの例 M3の紹介 Findy Job Lunch Talk
4. % M3, Inc. 4 https://www.m3tech.blog/ https://jobs.m3.com/engineer/ エンジニアリングの力で医療の世界を変えていく The Power of Medical Innovation m3_engineering m3_engineering https://jobs.m3.com/product
5. % インターネットを活用し 健康で楽しく長生きする人を１人でも増やし、 不必要な医療コストを１円でも減らすこと 5
6. % 6 ギークでスマートなエンジニア 社内LT回 (隔週開催 286回開催済み) 自由参加にも関わらず、 参加者が途絶えたことはない 技術ブログ (859記事) 基本的には任意 3日に1回くらいの頻度で更新されている
7. % • 偉い人 < やっちゃいましょう！ みんな < やっていき！ • 組織階層がほぼない (役員 → チームリーダー → メンバー) • チームごとに技術選定可能 • バックエンド構成はSlackの #architect で相談 • モバイルはマルチデバイスチーム(アプリ開発横断チーム)と連携して相談 • 全員フルスタックエンジニア 7 エンジニアチームのカルチャー
8. % 8
9. % 9 13Apps
10. % エムスリーのFlutterアプリ 10 Ask Doctors 医師が直接回答す 200万件以上の過 WHITE JACK 福利厚生サービス 医師や看護師にセカンドオピニオンができる デジスマ診療 予約,問診,支払い等をサポートするサービス 患者,クリニック双方に大きなメリットがある
11. % エムスリーのFlutterアプリ 11 Ask Doctors 医師が直接回答するQ&Aサービス 200万件以上の過去の質問も見れる ピニオンができる 医師キャリア 医師のためのキャリア支援サービス
12. % 12 予約・問診 通知/チャット チェックイン 診察 診察後すぐ帰宅 薬局に処方箋送付 オンライン診察 薬を自宅に配送 4.6 App Store review(7.2万件) 8分 平均院内滞在時間 28分
13. % 13 予約・問診 通知/チャット チェックイン 診察 診察後すぐ帰宅 薬局に処方箋送付 オンライン診察 薬を自宅に配送 4.6 App Store review(7.2万件) 8分 平均院内滞在時間 28分 まとめ 最近の取り組み WHITE JACKの例 デジスマの例 M3の紹介 Findy Job Lunch Talk
14. % • 開発スタートは2020年12月, 初期リリースは4月を目標 • 最初期のエンジニアは3名 バックエンド1名, Web1名, アプリ1名 途中から1名(バックエンド)追加されてリリース時は4名 • 決済, 認証, QRコード/クレカ読み取りなどのコア機能の技術検証 • アプリ開発者は一旦1人になりそう Android/iOSを出す必要があったため、ネイティブのみでは作らない判断 KMP(Kotlin Multiplatform)も検討 14 デジスマアプリの技術選定
15. % • エムスリーではフルKMPアプリが1つ、一部導入アプリが1つある • ネイティブの機能/UIを使いたい場合はKMPの方が適している • 新規で少人数(1~2名)の場合はFlutterの方が早いかも? • 既存アプリをMultiplatform化したいならKMPの方がオススメ • 最終的には、プロダクトや環境次第 • 私が開発しました😤 https://github.com/AAkira/napier https://github.com/AAkira/Kotlin-Multiplatform-Libraries 15 KMPとの比較
16. % • 2020年当時の流行り BLoC, Redux, GetX, Provider(Riverpod), MVVM • これといったデファクトスタンダードは存在していない時代 • Riverpodを使ったMVVMを採用 16 デジスマアプリの設計
17. % • 2020年当時の流行り BLoC, Redux, GetX, Provider(Riverpod), MVVM • これといったデファクトスタンダードは存在していない時代 • Riverpodを使ったMVVMを採用 17 デジスマアプリの設計 まとめ 最近の取り組み WHITE JACKの例 デジスマの例 M3の紹介 Findy Job Lunch Talk
18. % • 開発スタートは2025年1月, 初期リリースは2月を目標 • 最初期のエンジニアは2名 バックエンド1名, アプリ1名 レ ビ ューなどのアドバイスに1名 • 不安材料は認証などの技術検証のみだったので、Flutterを選択 18 WHITE JACKアプリの技術選定
19. % • Flutter公式はMVVMを推奨 • 2024年7月頃に記事が出た https://docs. fl utter.dev/app-architecture/guide 19 今新規でFlutterアプリを作るなら
20. % • 画面間での共通の処理を書きやすい - onResume/onPause - ログ - Error handling • 画面ごとに捉えるので、 1画面を前提とした モバイルアプリとの相性がいい • サンプルが多い 20 MVVMのメリデメ • 管理するプロパティが増えるごとに Stateが肥大化 - Loadingなどの状態管理が苦手 • 宣言的UIとの相性が良くない • Riverpodの思想とは異なる - StateNoti fi erがv2で非推奨に メリット デ メリット
21. % • 宣言的UIとの相性が良い UI = f(state) • 最小コン ポ ーネントごとに 状態を管理しやすい(再利用性UP) • Stateごとに単一管理になるので 処理が明確 21 Riverpodアーキテクチャのメリデメ • 画面ごとの処理は工夫が必要 • Ephemeral stateに使うと 冗長になりやすい • 1度だけの処理等が難しい • Unit testが若干複雑 • DIと状態管理の機能が混 ざ りがち メリット デ メリット ※ 設計とライブラリとしてのデメリットが混在しています
22. % • 宣言的UIの大先輩 Reactの解決策を参考にする • Riverpodの開発者RemiさんもReactの思想を参考にしている 22 Reactを参考にしてみる https://x.com/remi_rousselet/status/1896308668855161089
23. % • Ephemeral(local) stateを fl utter_hooksで管理 • App(global) stateをriverpodで管理 • WHITE JACKアプリでは fl utter_hooks + riverpod を採用 23 新規アプリで採用した設計
24. % • 宣言的UIとの相性が良い UI = f(state) • 最小コン ポ ーネントごとに 状態を管理しやすい(再利用性UP) • State呼び出しのロジックを 共通化できる 24 hooks + riverpodのメリデメ • 画面ごとの処理は工夫が必要 • (現状)ネットにあまり情報がない • hooksにロジックが入ると テストが難しい メリット デ メリット
25. % • ロジックはUseCaseに記述して、基本的にUnit testを書く 25 実際のアーキテクチャ図 https://www.m3tech.blog/entry/2025/07/31/150000
26. % 26 https://docs. fl utter.dev/app-architecture/guide#optional-domain-layer
27. % • Riverpod v3からmutationなどが追加され、よりTanstack Query Likeに • Ephemeral stateにriverpodを使うのはToo muchだったので hooksにしていたが、riverpodに統一し直すのはアリ • 画面間の共通処理の最適解がまだ思い浮かんでいない 27 改善点
28. % • Riverpod v3からmutationなどが追加され、よりTanstack Query Likeに • Ephemeral stateにriverpodを使うのはToo muchだったので hooksにしていたが、riverpodに統一し直すのはアリ • 画面間の共通処理の最適解がまだ思い浮かんでいない 28 改善点 まとめ 最近の取り組み WHITE JACKの例 デジスマの例 M3の紹介 Findy Job Lunch Talk
29. % • E2Eテスト(Maestro)をフルで導入 → 少人数チームでもQAコストを大幅削減 • Unit test & E2E test & AI code review → いつでもデグレに気がつける状態に • Figma MCP & AI coding → Figmaのコン ポ ーネント定義を、 コード上のコン ポ ーネント定義と合わせる 29 最近の取り組み
30. % • E2Eテスト(Maestro)をフルで導入 → 少人数チームでもQAコストを大幅削減 • Unit test & E2E test & AI code review → いつでもデグレに気がつける状態に • Figma MCP & AI coding → Figmaのコン ポ ーネント定義を、 コード上のコン ポ ーネント定義と合わせる 30 最近の取り組み まとめ 最近の取り組み WHITE JACKの例 デジスマの例 M3の紹介 Findy Job Lunch Talk
31. % • 2025年から新規で作るなら、(個人的には) hooks + riverpod • 2026年春くらい? = Riverpod v3が成熟してくなら 全部Riverpodに寄せるのは(個人的には)アリかも • MVVMも(個人的には) 悪くはないと思っている ※ Riverpodを使って実現するなら注意が必要 • 結局はUDF(Unidirectional Data Flow:単方向データフロー)に なってさえいればいい → Riverpodを使わずに、Providerだけでも全然アリ 31 まとめ
32. % • 2025年から新規で作るなら、(個人的には) hooks + riverpod • 2026年春くらい? = Riverpod v3が成熟してくなら 全部Riverpodに寄せるのは(個人的には)アリかも • MVVMも(個人的には) 悪くはないと思っている ※ Riverpodを使って実現するなら注意が必要 • 結局はUDF(Unidirectional Data Flow:単方向データフロー)に なってさえいればいい → Riverpodを使わずに、Providerだけでも全然アリ 32 まとめ 設計は宗教 設計はプロダクトの状況、環境によって 最適解が変わるもの。 MVVMだから絶対ダメなどはない。 理解した
33. Thank you! @_a_akira We are hiring! https://jobs.m3.com/engineer/