今年も FlutterKaigi 2025 に参加してきました
今年で 5 回目の開催となる FlutterKaigi に今年もスピーカーとして参加してきました。
オフライン開催も 3 回目ということで、毎年参加している自分としては「お久しぶり」な方も多く、ワクワクというよりはむしろ「今年も帰ってきた」感のあるイベントではありましたが、一方でセッションの内容は幅広く深く新しい話ばかりでどれも面白く勉強になりました。
自分の登壇の冒頭にも言いましたが、思い返せば Flutter もバージョン 1 がリリースされてはや 6 年、ずっと触って深いところまで知って発信できる方もいれば、最近初めたところという方もいらっしゃいます。同じセッションを聞いても受け取り方はさまざまだと思います。そんなことを考えながら今年も参加させていただきました。
今回はスピーカーとしての登壇に加えて前夜祭のパネルディスカッションにもお声がけいただき、ルーカスさん、わかみやさん、韓国から参加のジェチャンさんさんとご一緒しながら、ビール片手に好き勝手に話させていただきました。普段の登壇とはまた違った雰囲気でいろいろな話題について話したり他の方の意見を聞けたりでき、今までにない体験ができました。
さてこの記事では、パネルディスカッションでいただいた質問への自分の回答を改めて整理しつつ、自身の登壇内容と、今回のイベント全体を通じて感じたことをまとめてみたいと思います。
パネルディスカッションで回答した内容について
前夜祭のパネルディスカッションではさまざまな質問をいただきましたが、特に印象に残っているものをいくつか振り返ってみたいと思います。
状態管理パッケージについて
まずは「状態管理パッケージ、どれ使ってますか？どれ使えば良いですか？」という質問です。Flutter 界隈では当然のように頻繁に上がる話題ではありますが、これに関しては常々思うところもあり、まっさきにマイクを借りてしゃべらせていただきました。
私は現在参加しているいくつかのプロジェクトのいずれでも Riverpod を使っています。ただしそれは「Riverpod が好きだから使っている」というわけではなく[1]、数ある状態管理パッケージの中で要件に最も適していると判断した結果として使っている、という立場です。
そのため「Riverpod を使うべきかどうか」と聞かれたらそれは「プロジェクト次第」と答えますし、そのプロジェクトの要件やチームの状況によって最適解は変わる、という意見です。[2] Riverpod 以外にも BLoC や signals といった海外でよく使われるパッケージもありますし、Provider は Flutter の考えに最も寄り添ったパッケージという点が強いですし、嫌われがちな GetX も「Flutter を知らなくてもそこそこのアプリが最速でつくれる」という点で採用理由になると思っています。[3]
ズバッと正解を言ってくれなくてなんだよという感じかもしれませんが、「時と場合によるからちゃんと比較検討できるようにひとつずつ調べて理解し、同時に自分のプロジェクトの要件や特性も把握して各々が合理的な結論を出すべき」というのが自分の回答です。
登壇について
もうひとつ、個人的に引っかかった質問が「登壇するくらいになるにはどのように勉強すればよいか」というものでした。
これはおそらく「登壇するにはたくさん勉強しなければならない」「登壇者はみんな『強い』人だ」という前提が頭にあるのだと思いますが、実際に登壇している立場からするとその前提自体に少し認識のズレがあるのではないかと思っています。つまり、登壇できるかどうかと、その人が「強い」かどうかは、実はほとんど関係がありません。
実際には登壇のために必要だと自分が思っているのは、「自分が興味を持ったテーマを深掘りすること」と、「そのテーマをプロポーザルにまとめて提出してみる行動力」です。Flutter という技術そのものに対して幅広い知識が必要かというと必ずしもそうではないですし[4]、実際にルーカスさんのキーノートでも、ルーカスさんの初めての Fluttercon での登壇は Flutter を触り初めてすぐと話されていた記憶です。
私自身も登壇で話している内容以外についてはそこまで詳しいわけではありませんし、なんならその登壇テーマについても「登壇したり記事を書いたりする気質ではないけどもっと詳しい方」が世の中には数多くいらっしゃると思っています。登壇内容についてどんなツッコミが来るのかいつもヒヤヒヤですし、同時にもっと詳しい方が登壇の後に話しかけてくれたら知らない話も聞けて楽しいだろうな、と思ったりもしています。
ひとたび登壇の機会を得ると、その準備の中で自然とさらに深掘りが必要になり、結果として理解も深まる、というサイクルが生まれます。
「十分に勉強したら登壇できる」という一方向の話ではなく、「興味を持つ → 調べる → 登壇する → さらに理解を深める」という循環を繰り返す中で地震の知見が蓄積されていくと私は考えています。
考える前にとりあえずプロポーザルを出してみましょう。勉強会に参加するときは「LT登壇」の選択肢をとりあえずポチりましょう。自分もそしているうちに気づくと FlutterKaigi の登壇も 4 回目になっていました。
自分の登壇について
今年の登壇では、「RenderObject とは何か？animated_to に学ぶレイアウト計算と描画の仕組み」というタイトルで RenderObject の仕組みと animated_to を用いたアニメーション実装についてお話ししました。
一応発表資料は こちら に公開していますが、いかんせん自分で動かしながら話す前提の Flutter アプリで作った資料のため、これだけみてもあまりよくわからない気がします。
例年通りであれば後日 Youtube で録画が公開されると思いますので、そちらを観ていただくのが良いと思います。
ともあれ、このテーマはベルリンでの Fluttercon、ソウルでの Flutter Alliance に続き 3 回目の発表となりまして、回数を重ねたことで自分の中で内容が整理されてきたこともあり、比較的落ち着いて話すことができたのではないかと感じています。今回は英語ではなく日本語での発表だったことも大きかったです。
発表後の懇親会でも「面白かった」というポジティブな声を多くいただき、幅広い方にうまく内容を伝えられた気がしています。一方で、発表準備に時間を割いた分、animated_to そのものの改善や追加実装の時間を十分に確保できなかったため、今後はそちらに取り組む時間を多く確保しようと思います。[5]
そういえば、RenderObject の役割を説明する際に Semantics について触れずに終わってしまった点に気がつきました。Semantics も RenderObject のとても重要な役割ですので、これを読んだ方はぜひ頭に置いておくと良いと思います。Semantics の詳細については kuno さん の「アクセシビリティ、まだ完璧じゃないけど──"今から"できること」のセッションがおすすめです。
まとめと参加して考えたことなど
まずは運営の方々に改めて感謝です。特に今年は Flutter Seoul の ジェチャンさん や Flutter Tokyo の 青木さん、 iOSDC などの sugiyさん、そして FlutterKaigi のみなさんご存知 kikuchyさん などカンファレンスの運営に深く関わっている方々と直接お話しする機会が多く、ここまでイベントを形にする裏側でどれほどの苦労や判断が重ねられているのかを多少なりとも伺うことができました。このようなイベントが定期的に開催されるのは当たり前ではなく、毎回毎回試行錯誤と労力の末に成り立っていることを忘れずに自分にできることを今後もやっていこうと思います。よしなに使ってください。
また今年は FlutterKaigi の他にも 1000 人規模の Fluttercon EU や 100 人規模の Flutter Alliance、20〜30 人規模の Flutter Tokyo などさまざまな規模のイベントに参加させていただく中で、「規模が大きければ良いというわけでもないな」ということを考えたりしています。FlutterKaigi や Fluttercon EU のような大規模なイベントは勢いも盛り上がりも情報量も多い一方で、他の参加者とゆっくり話すような機会はなかなかとれません。参加者ごとに聞いたセッションもイベントの過ごし方も人によって異なるため、会話を合わせるのも一苦労な悩みがあったりします。
一方で、Flutter Tokyo なんかではすべての参加者が同じ部屋で同じ LT を聞き、同じピザを囲んで懇親会をするため同じ時間でもより深いコミュニケーションが楽しめます。どちらが良いという話ではなく、規模によって得られる体験の質が変わるということが実感できましたので、今後もさまざまなイベントに積極的に参加していろんな楽しみ方をしたいと思っています。
来年に向けて引き続き新しい発表ネタも探していきたいところですが、例年「探そう」と意気込んで見つけるよりも日々の開発やふとした瞬間に面白いテーマが見つかることが多いため、アンテナは張りつつあまり無理やり考え出さなくても良いかなと思っています。animated_to もちょうど 1 年前の FlutterKaigi の後に仕事で必要だったから作ってみた感じでした。
ということで、また何かのイベントでお会いすることがあればよろしくお願いいたします。
-
というより「好きかどうか」で言えば自分は Riverpod に対して特に好きも嫌いもありません。よく使われるからよく調べるし、よく発信する、くらいの感覚です。 ↩︎
-
とはいえ日本では「ほとんどの開発者が知ってて使える」という一点で Riverpod 採用の強い理由にはなるのも現実と思いますが。 ↩︎
-
「雑に作ってなんとなく触れる」レベルのアプリをさくっと作りたい需要も世の中には結構あると思っています。 ↩︎
-
そりゃ知識は広く深くあった方が話に面白みが出るとは思いますが、必須ではないと思います。 ↩︎
-
animated_to に興味を持っていただいた方、たぶん使ってみるとよくわからない挙動することがあると思いますがその時は issue をください。プルリクも大歓迎です。 ↩︎
Discussion