この記事は 株式会社ビットキー Advent Calendar 2024 14日目の記事です。
ビットキーでモバイルアプリの開発をしている @umi18sy が担当します。
はじめに
Flutter エンジニアが集まる年に一度の祭典、 FlutterKaigi。
今年、私たちのチームはこのカンファレンスでブースを出展しました。
ただの宣伝ブースではなく、エンジニア同士が直接議論できる場を目指して企画したのが特徴です。
ブースで扱ったテーマは、「Flutter アプリのディレクトリ構成」。
一見地味に思えるかもしれませんが、これが予想以上に多くのエンジニアの関心を引き、熱い議論が繰り広げられる場となりました。
例えば、「コンポーネントはどう分割しているか？」や「feature - based パターンは必要か」など、具体的なトピックが挙がり、多くの現場の知見を吸収することができました。
この記事では、FlutterKaigi ブース企画の裏側や、得られた技術的知見、そしてカンファレンス運営から得た学びをまとめます。これからカンファレンスでブースを運営する方、Flutter アプリの開発に携わる方にとって、一助になれば幸いです。
FlutterKaigi 2024 概要
FlutterKaigi は、Flutter に特化した日本最大級の技術カンファレンスで、Flutter エンジニアや開発者が集まり、最新トピックや知見を共有する場です。
セッションやブース展示を通じて、実践的な技術情報やコミュニティのつながりを深める機会が提供されました。
ブースコンテンツ
こちらの @pauli_agile の記事 でも紹介されていましたが、ホワイトボードとマグネットを利用してディレクトリ構造について議論できるコンテンツを提供しました。
 |
 |
|---|
なぜこのコンテンツにしたのか
ブースコンテンツを考える上で、以下の理由を元に「ディレクトリ談義」という企画を行いました。
1. Flutter の特性と現状の課題
- Flutter は他のフレームワークに比べて歴史が浅く、デファクトスタンダードがまだ確立されていない
- 公式記事やドキュメントはあるものの、実際の現場での具体的な実践方法や事例が少ないと感じている ※1
2. カンファレンス特有の来場者属性
- フレームワークに特化したカンファレンスでは、深い技術的議論を求める来場者が多いことが予想されるため、技術談義を中心としたブース内容が興味を引くと考えた
- また、ビットキーはカンファレンスのブースに何人ものエンジニアが立つことが多いので、良い意見交換になると考えた
3. 企画者としての純粋な興味
- 私自身、他のエンジニアが Flutter をどのように活用しているのか知りたいという思いがあった
- 特にディレクトリ構成のような日常的な課題に関する議論は、実務に役立つ知見が得られると考えた
4. 採用やネットワーキングへの期待
- 技術的な深い話を行うことで、採用市場には出てこないような優秀なエンジニアの発掘にもつながる可能性があった
振り返り
実際にブースで参加者の方とディレクトリについて議論を行い、たくさんの知見や学びを得ることができました。
ここではその中でも気になったものをいくつか取り上げてみます。
1. ディレクトリ談義で得た学び
Flutter エンジニアとのディレクトリ構成に関する議論を通じて、以下のような重要な知見を得ました：
-
ディレクトリ構成は多くのエンジニアが悩む共通課題だった
- ブースに来てボードを見た参加者の一言目が「これ、ウチも悩んでます」という声が多かった
- 構成に関する具体的なアイデアや成功事例を共有する記事を書けば、多くの関心を集める可能性があると感じた
-
feature-based パターンやクリーンアーキテクチャを採用している人は少ない印象
- 関わっているプロダクトの大きさにもよるが、モバイルアプリにおいて厳密にやり過ぎるのは too much になってしまうとの意見が多かった
- 1つのプロダクトを複数チームで開発する上では feature パターンを採用している意見もあったが、共通領域など重複コードに対する課題感があった
-
MVVM モデルを採用している人が多い傾向
- ただし、MVVM モデルとは一言で言いつつも、人によってディレクトリ上での表現方法が異なっていることも多かった
- 例) Model 部分の細分化度合い、設定値や DB データを Model ディレクトリに含めるかなど
-
グローバルなState管理は Riverpod が主流
- 多くの参加者が Riverpod を利用しており、事実上のデファクトスタンダードになりつつある印象を受けた
-
コンポーネントの規模拡大時の課題
- 特に、サブコンポーネントの ViewModel（VM）設計に関して意見が分かれる場面があった：
- 親コンポーネントの VM にマージして関数を引数として渡す方法
- 子コンポーネント専用のVMを作成する方法
- 特に、サブコンポーネントの ViewModel（VM）設計に関して意見が分かれる場面があった：
2. コンテンツ運営に対して得た学び
カンファレンスのブース企画として実施した「技術談義形式のコンテンツ」について、以下のような発見がありました：
-
技術領域を問わず流用可能なコンテンツ設計
- ディレクトリ構成のような開発現場での共通課題は、他の技術領域にも応用可能であると感じた
- また、専門性が高くなりすぎない題材だったため、経歴を問わず議論を展開できた点は、次項の議論活性にも繋がる良いコンテンツだった
-
議論の場は楽しさと価値を生む
- 技術的な深い議論が来場者の関心を引き、ブースを運営するエンジニアもブースに来てくれた参加者も議論が白熱する様子を見ることができた
-
ホワイトボード+マグネットというフレームは議論に最適だった
- 一般的な要素をあらかじめマグネットで用意していたので、議論中の組み換えが行いやすかった
- ホワイトボードにすることで、細かい部分はペンで書き込むなど自由度も高かった
- 実際に「会社にこの仕組み持って帰って議論に使います！！」という声もあった
-
改善点
- ブースのシフトで Flutter エンジニアが1人もいない時間帯があった
- せっかく来てくれた来場者と深い話ができないタイミングもあったので、常にブースにエンジニアが1-2人いるように設計すると良さそう
- 成果物を効果的に記録し、議論の更なる材料にできるともっと良いと感じた
- 議論の成果物をスナップショットとして記録し、投影して共有することで、より効果的な議論が可能になると感じた
- 議論が進みボードが固まってきた時に、大きく消すことにかなりの抵抗があった
- 定期的にボードをリセットし、新たに議論が始めやすい状況を作った方が良いと感じた
- ブースのシフトで Flutter エンジニアが1人もいない時間帯があった
おわりに
FlutterKaigi 2024でのブース運営は、多くのエンジニアとの直接的な交流を通じて、技術的な知見を深めるだけでなく、コミュニティの可能性を再認識する貴重な体験となりました。
この経験から得た学びを日々の開発や次回のイベントに活かしていきたいと考えています。この記事が、Flutter を活用するエンジニアやカンファレンス企画を検討する方々の参考になれば幸いです。
明日の 株式会社ビットキー Advent Calendar 2024 は、@fullyou が担当します。
Discussion