越境文化は越境"される側"が土壌を作ればうまくいく

SNKRDUNK(スニダン)を開発しているSODA inc.の Advent Calendar 2025 3日目の記事です。

生成AIで領域の越境はしやすくなっているのでしょうか?
スキルの幅は広がっているのでしょうか?
正直、多少しやすくはなってますがまだハードルが高いと思っています。(個人開発で雰囲気で書くとかは別として)

SODAではFlutterへの領域越境が元々0人だったところから半年で12人に増えました。 そのおかげで施策スピード・リファクタが加速しています。

越境をしてもらうために、Flutterチーム全員で越境"される側"が土壌を作ることで組織の越境文化を加速させていきました。
この記事では、越境文化を作るために行った取り組みや、うまくいかなかったこと、モチベーションの仕組みなどについて話します。

Flutterは越境しずらい

Flutterをはじめとしたモバイル開発は特に越境の難易度が高めだと思います。
シミュレータを動かしながら開発、Figmaとピクセル単位で一致させられることを求められるため、他とはちょっと違った難しさがあります。
FlutterはiOSとAndroidどちらの環境構築が必要だったりするので、より大変です。

越境は正義なのか

越境の方法や良かったことについて話す前に、越境の良し悪しについて少し個人的な見解を述べます。

自分としても越境は全員がするべきってことはないし、強制するものでもないと思っています。
「越境せずに組織がまわるならそれが一番良い。」というこちらの記事の意見にも賛成です。
越境は目的ではなく、個人のスキルアップのための手段。そしてそれをサポートする文化を作り、組織全体で成長していく。それが自分の理想です。

もともと、SODAにはFlutterやってみたいという人がたくさんいたからこそ、うまくいったというのもあります。
もちろん自分もバックエンドにチャレンジ中です！

土壌作り

さて、本記事の趣旨であるどんな土壌について作ったのかについて書いていきます。
Flutterの土壌の話ですが、他の領域にも何か参考になる箇所はあると思います。

1.学ぶことを減らし、システムで補う(デザインシステムの構築)

Flutterに限らず、フロントエンド全般に言えることですがFigmaを見ながら実装するのって結構大変です。
たとえばTextをただGestureDetectorで囲んだだけだとタップしずらいし、サイズ固定のWidgetだと画面サイズの変化やDynamic typeに対応できなかったりしますよね。

そこのハードルを下げるために、なるべくUI実装を既存のコンポーネントで補えるように、デザイナーと連携しながらデザインシステムをつくっていってます。
実装者は、UIはデザインシステムのWidgetを使えば良い状態を目指しています。

このデザインシステムはFlutter側としてはPackageとして分離して余計なドメイン知識を入らないようにして再利用性を高めています。
特にコンポーネントやColor、TextStyleを分離しています。

デザインシステムを構築していくための、ちょっとした工夫としては、インターフェイスやコードコメントを充実させています。
例えばFigmaのVariantに対応するNamed constructorを作ることによってFigmaからFlutterの実装を探しやすくするなどです。
ドキュメンテーションコメントはanalyzeで必須にしています。

デザインシステムがしっかり作られているとFigmaMCP使えばUI実装は楽です。
これはCursorにFigmaを渡して一発でできた例です。(遊びで作ったやつなのでリリースはしてません)
これのすごいのはコンポーネントやColor、Styleが全てデザインシステムのものを使っているため、コード量も最小限かつ、UIとしてはだいぶ正しいコードになっています。

2.基礎から学ぶ勉強会

学ぶことを最小限にすると言っても、やはりDartの文法だったりFlutterの仕組みを知らないと開発になりません。
そこでFlutterエンジニアが講師の「Flutter育成コース」と言う名前の勉強会を毎週行っています。
環境構築、Flutterの基礎からSODAのアーキテクチャについてレクチャーしました。

やはり基礎が一通り終わったところで「Flutterやってみよう」という方が増えた印象でした。

勉強会のNotionページ

3.モチベーションをあげるランキング

また、知識だけではなくモチベーションを維持してもらうためにも、PRの数をランキング形式で表示しています。
また、毎週行われる開発部署全体のMTGでランキングや新しいコミットメンバーを共有することで頑張ってもらっている方を可視化していました。

PR数のランキング

うまくいかなかったこと

逆に、試したけどうまくいかなかったことを少しだけ紹介します。

Claude Code Actions

デザイナーやPMなど非エンジニアの方がもっと気楽にコミットするために環境構築すらいらない環境を作れたら良いと思い、Claude Code ActionsやDevinを導入してみました。
また、実機動作確認するためにTestFlightへの自動配信などを行いました。

ただ、ちょっとした修正をするためにClaude Code Actionsの実装を待ち(数十分)、その後配信を待ち(20分前後)となるとかなり非効率であるため運用上実現的ではなくやめました。

「非エンジニアにとって環境構築ゼロは魅力的でも、修正1回ごとの待ち時間が長すぎると続かない」
という学びがありました。

越境の文化は越境"される側"が土壌を作ればうまくいく

冒頭に説明した通り、越境は強制するものではありません。しかし、「してみたい！」というメンバーがたくさんいるなら、それは組織のスキルアップのチャンスかもしれません。
そして、「越境が頑張れ！」と見守るだけではなく、越境される側がしやすい環境を整えるほうが、チャレンジとしては楽しいです。

とは言ってもSODAの越境もまだまだスキルアップの余地はあります。もっとFlutter書ける人を増やしたいですし、我々もバックエンドへ越境しまくりたいです。

この記事の内容に少しでも共感してくれたり、「越境文化のあるチームで働いてみたい」と思ってくれるなら、ぜひカジュアル面談などでカジュアルに話しましょう！

おわり。