Flutter Kaigiに参加した感想など【Flutter Kaigi】

はじめに

2024年11月21,22日にFlutter Kaigi 2024に参加してきました。
Flutter Kaigiは、日本のFlutter技術情報の共有とコミュニケーションを目的としたカンファレンスです。
今回、参加する機会ができたのでオフラインで参加してきました。
基調講演ではGoogle Dart & Flutter Team Technical Program ManagerのKevin Chisholmが話をしてくれました。
Flutterを作っている人の話を聞いたりする機会はあまりなかったので、来てよかったなと思いました。(英語もっと勉強していれば。。)

Flutter Kaigi 2024では色々な企業や個人がFlutter開発の経験談や技術について発表されていました。
その中でもネイティブアプリをFlutterへリプレースする事例の紹介が多々あったので、それらに対して感想や学んだことを書いていきたいと思います。

Flutterによる効率的なAndroid・iOS・Webアプリケーション開発の事例

リクルート「スタディサプリ for SCHOOL」のFlutterによるリプレイスプロジェクトについての事例紹介。
リプレース前は以下のように開発されていました。

• Android: Kotlin
• iOS: Swift
• Web: Vue.js

課題

• やりたいことに時間がかかる
• 開発リソースの確保ができない

リプレース後

• アプリの機能削減なし
• Web側もFlutterでリプレイス
• 2025年4月からFlutterに１本化

感想・学んだこと

・Add-to-app

Add-to-Appは、既存のネイティブアプリケーションにFlutterを統合するための機能。
これにより、一部分の機能をFlutterでリプレイス・新機能開発することができます。

例：Android(Kotlin) ← 新機能をFlutter開発

・リプレース時のスケジュール感

1. Add-to-appで新機能追加
2. 既存アプリの開発継続 ＆ 裏でFlutterリプレース開発
3. 一部のプラットフォームをFlutterアプリに入れ替える
4. すべてのプラットフォームをFlutterアプリに入れ替える

・リプレース時に一緒にできそうなこと

• これまで対応できていなかった要望などを叶えることができそう
• 技術的負債の解消

・Flutterと開発効率

• 調査や新規開発の見積もりの負担が削減
• ホットリロードですぐ画面に反映されるので、Flutterで開発する効率も高いと思われる

・Flutter化で達成されたこと

• 複数のプラットフォームにリリースできる
• マルチプラットフォームなので、少人数開発をすることができる
• JiraやRedmineなどチケット開発駆動時に、チケットが1つでよくなる

・Flutter Web

Flutter v2.0(2021年3月)からstable状態になっています。
難点はSEOだが、業務アプリ等なら問題なさそうです。
キャッチアップやブラウザの挙動を学ぶのが大変そうだと感じました。(まずFlutter Webを採用しているとこが少ない)
アプリと同じコードで動くので、工数やリソースの削減が可能。

・まとめ

FlutterでAndroid、iOS、Webのマルチプラットフォーム開発を行うことで開発効率の向上、工数・リソースの削減ができると思いました。
また、既存アプリに対して、一部分だけFlutterを使って新機能追加やリプレースを行えるのでFlutterに徐々に移行することもできると思いました。

キャッシュレス決済アプリでのFlutterの部分的採用から全面採用まで

KDDI株式会社「au PAY アプリ」のFlutterによるリプレイスプロジェクトについての事例紹介。
Add-to-appを使って、部分的にリプレースしていました。 以下のような理由がありました。

• 大規模アプリのFlutterフルリプレースはコスト・リスクが高い
• リプレースするにあたって変更の影響範囲を小さくして実行し、Flutter知見を蓄積したかった

感想・学んだこと

・BLoC (Business Logic Component)パターン

Streamを使用した状態管理方法を採用していました。
Streamにデータを流す　→ データが流れてきたら画面更新のようにする状態管理を行います。
採用理由は

• 海外ではblocが人気が高く採用事例が多いこと
• オフショアメンバーが持つblocの既存知見を活用できる

会場で状態管理パターンのアンケートが取られていました。それでは、riverpodを採用した状態管理パターンが一番多かったです。
今回でriverpod以外でBLoCを採用していたり、独自の状態管理パターンを導入しているプロジェクトについて知ることができました。

・Add-to-appを使用して部分的採用を行った恩恵

Flutterを使って部分的に開発することで以下のような恩恵があります。

• UIに関してiOS/Androidの対応が不要になる
• AndroidやiOSのOS間の差分を吸収する
• Hot Reloadを使うことで毎回ビルドしなくていい(要素が多いリッチな画面など効果が大きい)

・バックエンドもFlutter(dart)でAll Flutter

フロントとバックエンドの記述言語をDartで統一していました。
これにより、フロントとバックの開発の垣根が低くなり、機動的な人員配置が行えます。
また記述言語が同じなので、エンジニアが全体を理解しやすいです。

・Flutter全面採用を考えるポイント

・ネイティブ依存機能
AndroidやiOSなどネイティブに依存した機能が多い場合は、Flutterとネイティブ間をやり取りをするコードが多くなり、Flutterの強みを活かしにくいので全面採用を見送ったほうがいいみたいです。

・エンジニアの確保
以下のB以上のFlutterエンジニアを確保できるかどうか。

• A: アーキテクチャ策定や技術設定ができる
• B: コードレビューが適切に行えて、適切な実装ができる
• C: 実装できる

Bのエンジニアは、定められたアーキテクチャに従って実装できたり、
既存コードの悪い実装に影響されずに改善できる実装をできるか、になります。

B以上のエンジニアがいない場合、レビューに時間がかけられずバグや技術的負債を生む可能性が高いです。
確保もしくはFlutterエンジニアの育成が十分にできない場合は、全面採用は見送りしたほうがいいみたいです。

KDDIではオフショアチームと開発することで24時間開発をしていました。
また社外の方と交流してお互いに知見を共有していました。
社内にFlutter知見がない場合は、社外の勉強会やイベントに参加して知見の蓄積を行うのも良いと思います。

実践的パッケージ戦略

サイバーエージェントが開発した「サツドラアプリ」の開発時の経験談についての発表。
ドメインやUIの各層をパッケージとして扱うようにすることで、クリーンアーキテクチャの依存方向を制御する方法が紹介されていました。
他のセッションを聞くと、各層をパッケージにして扱うことで依存方向を強制している事例も多々あったので採用しているところが多い印象を受けました。
上記のセッションを聞いて、試しに各層をパッケージ化して実装してみました。

まとめ

今回はFlutter Kaigi 2024に参加して学んだことや感想について書きました。
企業ブースがあったり、懇親会があったり外部のエンジニアと話す機会がもありました。
外部イベントへの参加は他のエンジニアと会話できるので、
他の企業の開発経験を聞いたり、使用している技術の知見を深められる良い機会だと思います。
今後も、積極的に外部イベントへの参加をしていきたいなと思いました。