FlutterKaigi 2021に登壇しました

Flutter Conference

11月29日と30日にFlutterKaigiが開催されました。 楽しかったー！

flutterkaigi.jp

プロポーザルを出したところ、30日の17時15分から登壇する機会をいただきました。

www.youtube.com

今回はセッションの準備を忘備録的に残しつつ、セッションの時間内に話せなかったことやTwitterをみていて思ったことなどをまとめます。

登壇まで

Tweetを遡ってみたところ、9月3日に2つ21日に1つプロポーザルを提出していました。

twitter.com

twitter.com

提出したプロポーザルは、下の3つです。

fortee.jp

fortee.jp

fortee.jp

順に趣味で作っているもの(flutter_auth_ui)、仕事で取り組んでいるもの(プレスリリース)、これまでのFlutterアプリ開発を振り返ってまとめたもの("デザインシステム"の過度な一般化とその対応について)となっています。 初のFlutterKaigiということで、どの辺の話が多くの人とできると楽しいだろうか、という探りも込みで用意した次第です。

毎回ブログの形でまとめてはいるのですが、なにか登壇の形で共有できればなと思ったりしています。

採択が決まったあとは、同じく登壇者である id:iganin さんとDiscordでやりとりしながら資料を作っていました。 ログを見たら10月14日にファイルを作ってたみたいです。 その後2度ほど数時間単位で通話をつなぎながら資料を作ったり、互いの資料をチェックしたりしながら収録に臨みました。

また実のところ、大きなカンファレンスに登壇をするのが今回が初めてだったので、色々と準備に手間取りました。 一応マイクは外付けのものを購入してみたりしたのですが、収録された録画を聴くとノイズが入っちゃってますね……。 想定外に良かったのは、スタンディングデスクでした。立ったままマイクに向かって喋りかけられたので、そこはリアル会場と同じノリで進められたように思います。

裏話的になってしまうのですが、動画の提出後にFlutterKaigiスタッフの方々に動画のチェックをしていただきました。 keynoteで収録した際、音声を後程追加したところから無音になってしまうことなど、あわやという問題なども……。 開催一週間前からは、登壇者とのやりとりも多く、本当に大変だったのではないかなと思います。

セッション

speakerdeck.com

モチベーションとしては「Flutterで大きなアプリを作る」という課題に挑んでいる話を、全然みないのでもっと知りたい&話したい、です。 そのため、「こんな開発はどうでしょうか？」というセッションをすることにしました。

一部の方には拾っていただけたようで嬉しかったのですが、Flutterが普及するためには"Flutterだからできること"を探さないといけないと感じています。 というのも、3年前にはまだまだ使える状況ではありませんでしたが、SwiftUIやJetpackComposeによりスマートフォンのネイティブSDKを利用して宣言的UIを活用することができるようになりました。 JetpackComposeに至っては、DesktopやWebまでは書ける状況になっています。

Flutterによるアプリケーションは、ネイティブSDKを利用したものよりも、配信するアプリケーションのサイズは肥大化します。 つまり、ユーザーに対して「より負担を強いる」アプリケーションと言えます。 また、Flutterを採用し利用し続けるためには、さまざまなコストがかかります。それらを超えて、「やはりFlutterを採用する」という意見を作りたいなと。 *1

セッションは

  1. 自己紹介
  2. (Flutterなら綺麗にスケールできるという話をするための)導入
  3. (Flutterでスケールさせるためのキーとなる)概念の紹介
  4. (Flutterでスケールできるチームに対応する)構成の紹介
  5. (Flutterでスケールするとしたらな)最小構成の紹介
  6. (セッションで紹介した事例を取り入れるための)キーポイントの紹介
  7. まとめ

になっています。

Q&Aで少し補足したのですが、セッションで紹介したものを全て当てはめることはできないと思っています。 というのも、作るアプリケーションにより複雑さや、何が複雑になるのかは異なるためです。

終わった後のTwitterや所属している会社の中での感想をもとに、2点補足しておきたいなと思います。

FlutterのElementなどのTree構造との関連

所属している会社の同僚から「図を見ていると、前日のちゅーやんさんの発表っぽい」と感想をもらいました。 こちらは意図通りのものだったりするので、今回の構想をするに至った経緯をまとめておきます。

www.youtube.com

今回の考えは「ある大きな機能を、それなりの開発期間をかけて、少人数で開発しなければならない」状況で考えたものになります。 開発期間が3ヶ月ぐらいになる話とAdd-to-Appで使う話、そしてFlutterのnull-safety対応を行わなければならない話、これらが同時にワッと襲ってきた状況をなんとかするため、でした。

このため、Flutterの構造そのものから何を切り出せるのか、というところから思考をスタートさせています。 Flutterという仕組みの部分集合であれば、Flutterが根本的な方針転換をしない限り、有効かつ課題とはならないだろうという推測をしている感じです。

Q&Aで「TextFieldのような形で状態管理を」と回答した覚えがあるのですが、本セッションは「TextFieldのような形でFluterのPackageを作っても、それは他のWidgetたちと大差なく扱える」はずだという直感の上に成り立っています。 つまりFlutterのWidgetやElementのTree構造を、構造を保ったまま、あるノードから下を「Packageとして括りだした」としても、全体の形は崩れることはないということです。 *2

なぜモノレポではないのか

へぶんさんが下記のように書き込んでくれていたので(感謝！)、少しだけツリーで補足をしました。

実のところ、本セッションの「Packageを分割する」という手法には3つの解答方法があります。

  1. ひとつのリポジトリの中で、パッケージを切って開発する
  2. 複数のリポジトリを作り、git submoduleで開発する
  3. 複数のリポジトリを作り、pabspec.yamlで開発する ⇦ 本セッションはこれ

自分なりにメリットデメリットを整理すると、下記のようになります。

手法 メリット デメリット
モノレポ リポジトリの管理が楽
ある機能の開発をまとめて管理できる 		開発期間が長いケースでリベースがつらい
2つ以上の機能追加がある場合の管理が困難
git submodule 機能ごとに開発ができる
一括で更新ができる 		参照しているコミットが人間に把握しやすいモノではない
複数のリポジトリの管理が大変
pabspec.yaml 機能ごとに開発ができる
参照しているコミットやブランチが把握しやすい 		複数のリポジトリの管理が大変

またモノレポによるパッケージ分割については、DeNAさんのカンファレンスアプリがコード付きで紹介している(日本語の)最初の事例だと思っています。 *3

github.com

speakerdeck.com

この手法はKatzさんのコメントの通り、パッケージが依存する方向の整理として非常に有用です。 この感覚は、AndroidやiOSでマルチモジュール構成を採用したケースと同じになると思っています。

まずはパッケージ間の依存関係を整理したい場合、ぜひ先駆者の資料を参考にしていただければと思います。

登壇を終えて

2日間、しかも17時から始まって21時には終わっているという短いカンファレンスでしたが、見終わった後にはぐったりするぐらい密度の濃いカンファレンスでした！ 翌日から使える知見もあれば、来年度の開発計画に組み込みたくなる考えもあり、満足以外の言葉が見つかりません。

個人的な学習としても、「プレゼンテーションを自宅で収録する時には、keynoteだけではなくZoomを利用する」などの知見も多く得ることができました。 また登壇できる機会があれば(あるといいな……)、より伝わるものを作りたいなと思っています。

最後になりますが、FlutterKaigiを運営してくださった皆様！ またスポンサーしていただいた企業様！ ありがとうございました！！！

Flutterによる開発を、楽しんでいきましょう！

*1:もちろん、「なぜReactNativeではないのか」という声にも応える必要があると思っています。

*2:多分、この話をちゃんとするとすると仮想DOMをちゃんと勉強するといいのだろうな、と思ってます。

*3:初めて見た時は「Flutterでできるのかー」と感動しました。