出前館でエンドユーザ向けアプリ（コンシューマ向けアプリ）の開発を担当している橋本です。
2025年11月13日に開催された Flutter Kaigi 2025 にて、
「Flutterにしてよかった？ 出前館アプリを2年運用して気づいたこと全部話します」というテーマで登壇しました。
広い会場で少し緊張もありましたが、Flutterコミュニティの皆さんの温かい雰囲気に支えられながら、出前館アプリをFlutterで2年間運用してきたリアルをお伝えすることができました。
また、登壇後の Ask the Speaker では、特にリリーストレイン（定期リリース運用）に関して多くのご質問をいただき、大規模アプリ開発における“運用の課題と工夫”への関心の高さを改めて感じました。
本記事では、2年間 Flutter と向き合いながら試行錯誤した事例をベースに、
- リリーストレインの導入
- 状態管理の落とし穴と学び
- Flutter Web を活用したフィードバックループ改善
にフォーカスをあてて発表した内容を、簡潔にまとめます。
Recap: なぜ出前館アプリは Flutter へ全面移行したのか
出前館アプリでは、2023年11月に React Native から Flutter へ全面移行しました。
目的は、アプリ開発組織で利用する技術を Flutter に統一し、アウトプットを最大化できる開発体制をつくることです。
出前館では、エンドユーザ向けアプリの他に、レストランなどの加盟店向けアプリや配達員向けアプリも開発しています。
エンドユーザ向けアプリ以外は全てFlutter製アプリだったため、エンドユーザ向けアプリもFlutterに移行することで、社内のアプリ開発技術をFlutterに統一することにしました。
移行の詳細については過去の FlutterKaigi でもお話しましたが、今回の登壇では移行後の2年間で起きたリアルな試行錯誤とその知見について共有しました。
①：リリーストレインの導入
アプリリリースの理想は、好きな任意のタイミングでリリースすることで、ユーザに価値を素早く提供できることです。
しかし、出前館ではリリースができる条件の変数(※)が多く、リリース調整にコストがかかっていました。
（※ 複数プロジェクトの同時開発、BFFをWebと共有している設計、加盟店・配達員アプリとの連携など）
さらに、React NativeからFlutterに移行したことで、CodePushリリースからストア申請が必須になるという大きなリリース運用の変化もあり、安定したリリースプロセスを構築するための打ち手として、リリーストレインの導入に踏み切りました。
現在、出前館アプリのリリーストレインはリリース予定日前週の木曜・金曜にQAとストア申請を行い、リリースは段階的にロールアウトしています。（iOS: 段階的リリース, android: 20%からロールアウト）
月に２回を定常の"運行ダイヤ"として、事前にリリース計画をスケジュールしています。
ただし、セキュリティリスクのある緊急度の高い修正や、ユーザーにできるだけ早く価値を届けたい機能などがある場合は、柔軟にリリーススケジュールを調整しています。
あくまで理想は、任意のタイミングで素早くリリースできることであることを忘れず、
”定時運行”を守ることに固執しないようにすることを、チームの共通認識としてすり合わせています。
リリーストレインを導入したことで、アプリ開発のプロセスに周期的なリズムが生まれ、安定したリリース運用ができています。
また、"リリーストレイン"という概念が開発チーム内外に浸透したことで、リリース調整の連携がスムーズになったことも、プラスに働いていると感じます。
②：状態管理の移行で直面した “落とし穴”
次にお話したのは、Flutter の状態管理で想定外に苦労した話です。
Flutter移行を行なった2023年当時、出前館アプリのような大規模アプリでも安定して運用できる状態管理ライブラリとして、以下の観点からBLoC を採用しました。
- View と State を明確に分離できる
- GitHub の Star も多く、歴史的に実績豊富
- メンバーの経験もあり導入がスムーズ
しかし、リリース後にアプリを運用をしている中、注文画面で "配達の待ち時間が更新されない" 不具合が発覚しました。
原因は、特定ケースで状態を更新するイベントをBLoC 側で発火し忘れていた、というシンプルながら致命的なものでした。
React Native（useQuery）のときにはレスポンス値を自動同期される仕組みがあり、副作用によりサーバ側で変化する値をアプリ側が意識する必要はありませんでした。
以下は、アプリから支払い方法を変更するときに、サーバ側では支払い方法の変更だけでなく最新の待ち時間も取得していた事例です。
アプリ開発者が意識せずとも、サーバからのレスポンス値に変更があれば、UIが自動更新される仕組みでした。
しかしBLoCは手動でイベントを発火する必要があります。
React Native時代にアプリ側が意識していなかった状態更新の移植が漏れてしまったことで、待ち時間が更新されない不具合が発生してしまいました。
状態管理に対する認識のギャップが状態管理の更新漏れに繋がってしまった…という失敗事例でした。
③：Flutter Web を活用したフィードバックループ改善
最後に、Flutter Webを出前館アプリの開発プロセスのなかで活用している話をしました。
Flutterは公式がWeb版アプリのビルドをサポートしていることもあり、出前館でもWeb版アプリのビルドにトライしました。結果、以下のようにiOS, android版とほぼ遜色ないUIを、Webブラウザ上で確認できるようになりました。
ブラウザ上で気軽にアプリの動作が確認できるようになったことで、新機能の実装フェーズ中のフィードバックが増え、iOS, Androidの出前館アプリ本体の品質向上に寄与しています。
また、開発以外メンバーからも(企画、QA）、資料作成やテストケース確認のためにさっとアプリを見たい時などにWeb版アプリが便利、と好評です。
まとめ
Flutter へ移行してからの2年間、大小さまざまな課題に向き合う場面がありましたが、改善を積み重ねることで安定した運用を続けることができました。
今回の登壇で紹介した取り組みは、その過程で得られた現場のリアルです。
いま Flutter で大規模アプリを運用している方や、これからFlutterの採用を検討している方にとって、同じような課題に直面したときのヒントになれば嬉しく思います。
登壇内容にフォーカスした本記事とは別に、
Flutter Kaigi 2025 のイベント当日の様子をまとめた記事もnoteで公開しています。
会場の雰囲気や他登壇者のトピックに興味がある方は、ぜひこちらもご覧ください。
https://note.com/demae_can/n/na1d9133c3a5b
今後も引き続き、出前館アプリを通じてお客さまにより良い体験を届けられるよう、Flutterと向き合いながら改善を続けていきます！
