ネオバンクの事例から学ぶFlutter本格導入
以前に数回に渡ってご紹介したNubankのFlutter導入について、彼らの取り組みがその後約1年が経ち、それを振り返る記事がとても興味深かったのでご紹介したいと思います。
以下は基本的にこちらの記事の内容をそのまま書き起こしたものですが、一部以前の彼らのBlogの内容と合わせて加筆している部分も有ります。
おさらい
Nubankとは？
・ブラジルのネオバンク
・ラテンアメリカで最も大きなfintech会社
・アジア外に於いて最も大きな独立系デジタルバンク
・クレジットカード以外に商品を広げ事業拡大中
Flutter導入における評価ポイント
以前にご紹介したように、彼らは評価ポイントを決めてPOCを実施しました。詳細はこちらですが、主なところは以下：
・Developer experience（開発者の生産性）
・Long-term viability（コミュニティの継続性）
・No platform specialization（OS間の差異・OS固有機能の実現等）
・Incremental abstraction cost（使い続ける上でのオーバーヘッド）
・Non-linear abstraction risk（潜在的なリスク）
その一年後、、
当初は彼らも4つの商品/機能から成る大きく複雑なアプリをFlutterに移行することにはナイーブだったようです。まだ道半ばとのことですが、フィーチャーごとに担当・タイムラインなど移行の道筋は整えたようです。
個別の機能で言えば、hot reloadやより良いl10nサポート・可観測性を高めるインフラ（開発チームへのアラート、フィーチャーやパッケージごとのアプリサイズの測定、メトリックス収集等）などが役立っていると言及されています。最近はFlutter WebもPOCしているようですね。
しかし、最も強調して言われていると感じたのは、チームについてでした。まず、彼らのモバイル開発チームの文化と非常にマッチしているようで、以前にも述べられていたエンジニアのフルスタック化・機動性向上（velocity & efficiency）・エクスペリエンス向上に一役買っているようです。
急成長を遂げているNubankはエンジニアチームも成長し続けており、常に採用を行い、新たなフィーチャーも増え続けています。そうした状況の中で、Flutterの導入は新たに参画したエンジニアのエントリバリアを下げ、オンボード後数日で戦力となることに寄与していると言われています。
導入の成果
効率性としては、ビルド時間を縮めたことが大きいようです。マージの成功率はネイティブ開発に比べて30%向上し、PRからマージまで全プラットフォームの平均は70分に対してFlutter部分の平均10分とのこと。
結果、例えば新機能/プロダクトである生命保険は3ヶ月でローンチを実現。これまでは数ヶ月〜1年ほどかかっていた。
全て薔薇色な話ではない
ま、それはそうですよね。
まずは移行期間は色々複雑となるということ。アプリのコード自体だけでなく、様々なツールやサポートを駆使して頑張っているようです。React Native・Flutter・ネイティブが混在しており、しかもブラジル・メキシコで本番稼働中、コロンビアでのローンチも告知済みということで、色々と大変出会ったようです。Dartで書いたCLIでの内製開発ツールでビルド・テスト・CDパイプラインなども行っているようです。
また、アーリーアダプターであったために、ネイティブとの統合時に様々な問題も出たようです。ここで興味深い記述が有りましたが、「重要な学びは、プロダクトチームを支援することにフォーカスするプラットフォームチームを分けて作ったこと。そのようなバグや複雑なパフォーマンス問題に対応するにとても役立った。」とのこと。原文も以下に載せています。
The key learning here was that having a platform team focused on supporting the product teams is crucial to solving these types of bugs and some of the complex performance issues.
感想
最後の部分はとても共感するところでした。実は弊社でも最近、金融サービスアプリのFlutter化をPOCするプロジェクトを行ったのですが、同じような経験と学びがありました。
新サービス開発でゼロからアプリを開発する場合は、Flutterをそのまま使えるので話はシンプルですが、既存の動いているものがある場合は、どうしても部分移行が避けられません。そうなると、ネイティブとの共存問題やネイティブ依存機能の実現など、フィージビリティをとる必要があります。ここは、まだ機能によっては不安定なパッケージがあったりバグがあったりなど、Githubイシューなどでの情報収集や解析に時間がかかりました。また、アプリアーキテクチャーに関するところなど、本格開発が始まってから検討しては問題が大きくなるような課題も見つかりました。
これらは書いてみると当たり前のことなのですが、特に大きな組織などでは、予算取りのためにPOCが必要だがPOCをするにも予算が必要、その結果、POCをプロダクトチームと切り離せずにリソース逼迫したり十分な検証ができなかったりなど、、がよくあるシーンではないでしょうか。このあたりは単なる技術論だけで終わらせず、プロダクト戦略や組織論も合わせた議論が必要になってくるのでしょう。なかなか奥深いですね。
この記事が気に入ったらサポートをしてみませんか？