FlutterKaigi 2024 に参加してきました
有明セントラルタワーホールにて11月21日と22日に FlutterKaigi が開催され、オフライン参加してきました。去年に引き続き二回目の参加です。有明は品川から車で 15分くらいの位置にあり、東京湾の中にレインボーブリッジを渡って、都内の景色を海側から見ながら入っていきました。会場は、昨年よりも広いホールを貸し切っての開催となり、この一年でさらに Flutter コミュニティの拡がりと勢いを感じました。一方で、他のモバイル向けのカンファレンスである iOSDC・DroidKaigi と比較すると、規模としてはまだ小さいです。参加人数は、当日の発表によると 300人程で iOSDC の五分の一、 DroidKaigi の四分の一でした。
iOSDC と DroidKaigi のレポートは以下に別途まとめています。
筆者は普段、 Kotlin Multiplatform でモバイルアプリを開発している割合が多く、 Flutter の前提知識はほとんどない状態でこの会に参加しました。セッションやスポンサーブースでの話を聞いて、改めてモバイルアプリの開発手法の大きな転換になりそうな印象を強く持ちました。筆者が重要だと感じたトピックを紹介します。
重要トピック
次の三つのトピックが特に重要だと感じました。
チームビルド
Flutter 経験者は需要に対して供給は追いついていない現状がある
ここで言う経験者というのは、モバイルアプリ開発の経験がある程度あって、ネイティブへの理解もあることが前提としてある
そのため新たに採用するよりもチーム内で Android・iOS のメンバーが転向する方針が有力になっている
Flutter の文脈におけるテックリードの存在も不可欠で、初期からやっている人は5年くらいで人数は限られていることもあり、フルで関わってもらうというより、特にプロジェクト初期段階の設計や方針の策定、コードレビューを通しての育成に関わってもらうことでチームの成長にコミットしてもらうのが重要に感じた
注意点として、メンバーはマルチプラットフォームの Feature 単位で担当する形になるので、単位ごとの負荷は高くなる
リプレイス戦略
Add-to-app を活用して部分的に組み込むことから始める
自分たちのプロダクトにマッチしているのか小さく試して評価し、 Flutter の不採用も視野に入れて導入の実験を行う
Add-to-app の採用段階の時点でデモを作成して評価してもらう（導入決定時点ですぐに組み込みを試せる状態になっていることが採用判断を後押しする）
Android 向けの新機能から組み込む
全面置き換えできそうなら Android を置き換える
Android の置き換えができたら iOS を置き換える
プロダクトの要件に対して Flutter Web の制限が問題ないなら Web を置き換える
生成AIの活用
Flutter 開発では Cursor との相性が良い
スニペットを作成しておくことで生成 AI との連携が向上する
AI に対して要件の指示とスニペットを組み合わせると大部分の生成はできてしまう
本格的にこの開発手法が進むと最大でチームメンバーは Android・iOS・Web を合わせた三倍のコストの差が日々生まれる。マルチプラットフォームによって生じるコミュニケーションコストと生成 AI の活用も加味するとその差は三倍以上にもなるだろう。
関連セッション
スタディサプリ for SCHOOL
リプレイス戦略の成功例として、Andriod・iOS・Web の統合の実例を紹介しています。
au PAY
アプリから API まで All Flutter リプレイス戦略を紹介しています。
Omiai
生成 AI も活用したリプレイス戦略を紹介しています。
chocoZAP
iOSDC 2023 のセッションですが、Flutter からネイティブのリプレイス事例もあり、今回のリプレイス戦略を強固なものにするアンチパターンの紹介も非常に参考になります。
Flutter 入門
筆者は、 FlutterKaigi 公式アプリを手元でもビルドするために、昨年 Flutter に再入門しかけたものの、 Kotlin Multiplatform の案件に関わる割合が多くて、今年改めて再々入門しました。 FlutterKaigi 公式アプリは OSS で公開されています。
開発環境構築手順は以下を参考に進められるようになっています。
しかし、久しぶりということもあって、環境構築で躓いてしまって、昨年自分でまとめた入門記事が助けになりました。
前夜祭の LT では、 Flutter アプリ開発における実践的な課題への向き合い方が紹介されていて、このように壁にぶつかっては乗り越えて進んでいくイメージが持てて、これから Flutter アプリを開発する人にとっての入門編として相応しい内容に感じました。 Flutter コミュニティではオープンな議論がされており、困ったことがあると大体 Issue があるという話にとても好感を持ちました。
内部構造
Flutter には、ネイティブとは異なる内部構造の課題があります。次のセッションでは、それぞれ扱う領域は異なりますが、 Flutter の内部構造の理解を深めることができました。特にそれぞれの名前を知ることで、聞いた時点では理解できなくても index が作成されるので、今後自分で調べる時の大きな助けになると感じました。
難読化
Flutter では Dart・Kotlin・Swift それぞれの難読化があって、難読化解除には、それぞれに対応するシンボルが必要になります。次のセッションでは、Flutter の難読化について非常にわかやすく解説されていました。
マクロ
Flutter ではマクロを利用してコード生成が可能になっています。次のセッションでは、実演のデモを通してマクロの使い方をわかりやすく解説されていました。
Shorebird
Shorebird を利用すると Flutter 製のアプリを、より正確に言うと Dart で書かれたコードを、ストアを介さずにアプリの内容を更新できます。次のセッションでは、このサービスの詳細について紹介されていました。例えば、緊急のパッチを当てたいことを想定すると、審査を待たずにアプリを更新できることは、ビジネスの内容によっては、非常に魅力的な選択肢でした。
Figma
デザイナーとプログラマーの共同作業においてコラボレーションツールは重要です。その一つとして、 Figma を利用することは筆者も多いです。次のセッションでは、ケーススタディ形式で、より Figma を活用する方法について紹介されていました。非常に具体的でイメージのしやすい内容になっています。
Flutter 求人
Flutter 案件のジョブボードがスポンサーから用意してもらっていて、具体的にどのような求人があるのか展開してもらっています。ジョブボードをきっかけにスポンサーブースでより詳細な情報を聞けたりするのでとても良い試みだと思いました。
終わりに
前夜祭も含めて三日間 Flutter に深く触れることができて非常に充実した時間を過ごすことができました。初めてお会いする人や iOSDC・DroidKaigi で馴染みの人と対面して話すことでとても刺激も受けました。
冒頭の感想の通り、 Flutter アプリ開発手法は、モバイルアプリ開発の大きな転換の媒介となる可能性が強くあると感じつつ、そうは言ってもネイティブというのが筆者の現場の周りにはあります。次の一年でこのそうは言ってもがどれくらい減っていくのか、あるいは増えていくのか意識して動向を見て動けるようにしたいです。
前回の FlutterKaigi 2023 の後にも、各言語としての優劣は大きくなく、チームの得意とする言語が何かで開発手法を選択できるくらい成熟して来ていると感じていました。そのため、言語を軸にマルチプラットフォームを選択していくと次のようになります。
Dart → Flutter
Kotlin → Kotlin Multiplatform
JavaScript → React Native
ただ意図的にチームの得意とする言語をシフトしていくという戦略が Flutter では採用し始めています。この効果がどんな成果に結びついていくのかとても興味があります。