🤔

FlutterFlowというプラットフォームについて

2024/02/08に公開

FlutterFlow

tech

この文書について

FlutterFlow（FF）の概要については、よくまとめられた他の方の文書がありますので、ここではFFについて思うことを、一般的には触れられていないことを中心に、取り留めもなくメモしています。

これから使ってみようかな？という方の参考になれば幸いです。

エクスポート機能が使える

プラットフォームを選定するときは、運営母体の今後の存続性も当然確認されると思います。

FFはY Combinatorからの支援を受けていることから投資家層からの期待は大きいと考えられ、また市場で一定の知名度・存在感も示しています。それらは一定の安心感を与えるものです。

そに加えて、ソースコードのエクスポート機能があるおかげで、ローコード／ノーコードの弱みであるロックインを防げます。最悪運営母体が破綻してしまっても、プログラム資産は守ることが出来ます。

ローコード？

ノーコードではありません。では、ローコードでしょうか。
実は、ローコードという表現も適切ではないように思えます。

というのは、ノーコードの範疇で作成しているにも関わらず、理解の出来ない挙動をするときがあります。
では、ドキュメントに書かれているかというと、ドキュメントの詳細度も乏しく、書いてありません。
そんな時、生成されたソースを読んで初めて合点がいく、という事が、ままあります。
せめてドキュメントが充実していれば、ローコードという位置づけも納得します。
しかし、あのドキュメントの粗さや製品の造りからは、「我々の製品の責任分岐点はコードを生成するまでだ」という、FF自体はそう思ってはいないのかもしれませんが、図らずともFF側が無意識に引いている見えない一線があるように思えるのです。
エクスポート可能な事も相まって、ローコードというより、Flutterコードの自動生成プラットフォームという方がしっくりくるのは、私だけではないでしょう。

人材・カントリーリスク

アメリカの会社ですが、開発陣もコミュニティもインド人が多いです。
23年12月頃に大々的に行っていた採用キャンペーンでも、募集地域はインドばかり。
インドはどの国とも付かず・離れずの外交文化なので、製品サポート体制に突然影響を及ぼすような事態に陥ることは考えづらいでしょう。
2020年にはトランプ氏がH1Bビザを厳格化したことでシリコンバレーで働く外国人エンジニアへの影響がニュースになりました。FFは基本的にリモートでの現地勤務としているようなので、同様の問題も起こりづらいでしょう。

ちなみに、FFのカスタマーエンジニアとチャットしていて、責任感やプロ意識を感じたことは一度もありません。この点、日本人はとても秀でた気質を持っていると思っています。「我こそは！」と言う方、是非内部から支えてください！

エクスポートされたコードからの再インポートは出来ない

コードを自動生成する都合上、FFでは、Flutterで出来ることのいくつかは切り捨てざるを得ないのは容易に想像がつきます。ゆえに、FlutterコードからFlutterFlowへのインポートは現時点で出来ず、これからも出来ないと思った方が良いでしょう。

FlutterFlowで一通り作ったうえでエクスポートして、その後はFlutterとして開発を続けるというやり方も考えられます。ただし、その場合はローコードであるが故のメリットを手放すことでもあります。リリース後の継続開発・サポート体制に割ける予算や人員、ロードマップと照らし、慎重に判断した方が良いでしょう。

Supabase

FFはSupabaseもサポートしていると謳っていますが、利用には注意なさってください。

エンジニアリングスキル

開発経験は少なからず必要です。
「簡単なアプリであれば経験がなくても可能」のような記事を目にすることもあるため、もう少し具体的に言うと、ユーザにログインさせるアプリであれば、エンジニア経験は必須だと思った方が良いでしょう。
何となく作れてしまったとしても、経験が伴っていないと明らかなセキュリティ上の欠陥を埋め込んでしまう製品設計になっており、ドキュメントもそこまでカバーしてくれません。

中国マーケット

中国にはネットの検問があります。

確認したわけではありませんが、FFはGoogleのエコシステムを前提にしているので、FFのアプリを作ったところで中国ではまともに動かないと思われます。中国市場をターゲットに考えていらっしゃる方は、念のため確認された方が良いでしょう。

英語

基本的に英語の文章は読める必要があります。

ドキュメントは英語
サポートも英語（だと思われます。日本語で問い合わせた事が無いのでわかりません）
公式コミュニティでもアジア人らしき方はほとんど見かけません。人口割合が多いはずの中国人も見かけないのは、おそらく前述のグレート・ファイアウォールのためだと思われます。
日本語での情報は少ない

ちなみに、なぜか日本時間でもサポートチケットを返してくれることがあります。ただし、基本はインド〜アメリカ西海岸の時間と思っていた方が良いでしょう。

プアなドキュメンテーション

公式のドキュメントは、使ったことのないユーザであれば、一通り書かれているような錯覚に陥るかもしれません。
https://docs.flutterflow.io/

しかし、いざ使ってみると、書かれていることは基本的な王道のユースケースのみであることがほとんどです。Widgetの説明であれば、そのWidgetを使って何が出来て、何が出来ないというのが網羅的に書かれていないので、コードを見ながら理解したり、背後のコード自動生成で何がされているのかをエンジニアの直感で推測しながら、おそらくこういう事は出来るだろう、出来ないだろう、と勘を頼りにせざるを得ない。勘が外れて運が悪いと（実質コード生成は出来ないが、FFとしては出来ない事としてエラーにする対象にしていない場合）、編集画面では何のエラーも出ていないのに”Builed Failed”という、コードの自動生成に失敗して出るエラーで深みにはまることになります。
エンジニアリングスキルが伴わなければ、ドキュメント頼りの開発は苦しいでしょう。

頼りないサポート

プロフェッショナルな対応は期待できません。
具体例をあげると、MarkdownWidgetの堅固生をテストしていて

![](&#x09;)

という不正な文字を入力したら落ちてしまったため、これはサポート内？と聞いたら「あなたがMarkdownのフォーマットに従っていない」という見当違いな返答で、サニタイズという概念から説明する羽目になりました。

埒が明かないので、「バグかどうか不確かならエンジニアチームに確認してください」とお願いし、数日後にバグだと思う、と回答がありました。

品質に関する考え方

上記のMarkdownWidgetの件の後日譚。カスタマーエンジニアは「FFのGitHubにIssueを上げてくれたら対応に入れる」と連絡をくれました。

オープンソースならともかく、、「It's not my business」。FF側でやるように突っぱねました。
Issueを上げるのが簡単なら協力してあげても良いのですが、FFのIssueは必須の入力項目が多くて面倒くさいんです。
それ以前に、バグだと判断しておきながら、あまりにも自分たちのプロダクトの品質に無関心という事に呆れてしまいました。良いプロダクトとは思いますし、AbelとAlex（創業者のお二人）には尊敬の念に堪えないのですが、その組織があまりにも残念過ぎます。

ローコードであること

色々と酷評が多くなってしまったので、最後は良い面をクローズアップしたいと思います。私がFFを使っている理由は、開発体制の都合、プロダクトの完成度、今後の期待、エクスポート可能であること、そして以下のローコードのメリットに尽きます。

セキュリティの信頼性

果たしてどれ程の割合のベンダーがセキュリティに対して適切に対処出来ているでしょうか。
近年はプラットフォームやライブラリも増えたため、開発者側には各問題への具体的な対処の仕方より、セキュリティ全体への体系的な知識が求められます。もしかしたら、私がこれまでの20年近くの地方のSIer人生でお付き合いした中だけなのかもしれませんが、多くない企業さんが自社だけでの知識ではキャッチアップは出来ていないと感じました。

高額なセキュリティ診断を「念のための確認」ではなく「自社だけでキャッチアップ出来ていない分の穴埋めのため」に使っている気がしてなりません。

ローコードでは作り込んでいない部分は基本的に一定のセキュリティレベルは期待出来るため、可能な限りプラットフォーム側で提供されているものを使うことで、その品質を保つことが出来ます。
※正しい使い方をすれば、という前提です。誤ったFirebaseの使い方をしてしまうと、容易にセキュリティバグを引き起こします。

プラットフォームのアップデートへの追従

プロダクトはリリースしたら終わりではなく、その後のアップデートが付き物です。追加の機能を予定なさっているかもしれませんし、基盤としているプラットフォームのアップデートへの追従も迫られます。

FFでは、OS、BaaS、Flutter、Dartパッケージの層を基盤とし、カバーしています。これらのレイヤーのどこかで破壊的なアップデートが入ったとしても、FFが自然体で吸収してくれることを期待できます。もし、これらのどこかに作り込みを入れていたら、その部分は自らの手でアップデートをしなければなりません。

もし、リリース後にも対応できる予算があれば良いのですが、可能な限りプラットフォーム側で提供されているものを使うことで、基盤のアップデートに自然体で追従でき、またFF自体の機能向上の恩恵も受けることが出来ます。

導入を決断する前に検討すること

最後に、導入する場合の推奨事項です。

出来ること・出来ないことの確認

アプリでどういった機能を必要とするかを洗い出し、FFでサポートされているかは確認すべきでしょう。ローコードプラットフォームであれば尚更です。その恩恵を受けるなら、自然体で出来ることが多く、出来ないことは無理して対応するか、諦めるか、対応を待てるかの判断をしておくことです。

まず、ドキュメントのウィジェットなど、ザッと1日かけて眺めてみるのをおすすめします。
https://docs.flutterflow.io/

コミュニティからのWishListを見ると、現状サポートされていない具体的なケースが分かります。中には、これが出来なかったの？というのもあります。
（WishListの閲覧にはログインが必要です）

個人的に出来ないことが意外だったことのメモ

「当然出来るだろう」という思い込みは危険です。

とは言え、つい思い込んでしまうのは誰しも有ることかと思います。
読者の方が注意力を持ってFFのドキュメントを事前に確認できるよう、個人的に意外だった「出来ないこと」を、以下にメモしています。

上記は、その機能に対するWishListのリンクです。もし共感いただけるのであれば、WishListに「Upvote（投票）」お願いします。対応される確率が上がります。

FFを諦めていった方の意見

FFの良い面を取り上げる記事が多いので、FFを諦めた方の意見も読んでおいた方が良いでしょう。

この方は、王道のFirestoreではなくSupabaseを使っていたように思えます。
私は幸い開発途中からFirestoreにベッドしないとシンドいと判断し、Supabaseで構築していたものをFirestoreで作り直したので、ここで述べられている意見のいくつかは潰すことができ、この方が述べられていることに概ね同意しながらも、なんとか我慢して使えています。

FFの今後のロードマップ

FFの「出来ないこと」に対して、どう折り合いをつけるのかは大切なポイントになります。

UI/UXを工夫して「出来る」範囲にする
FFの対応を待つ
自分で作る

この判断をするためにはFFのロードマップが分かればやりやすいのですが、残念ながらほとんど示されていません。ヒントになるような情報を示します。

WishListにある「Planned」タグ

What's New記事に書かれる事がある、FFチームが今取り組んでいること

あと、ここからは主観になりますが、FlutterFlowの製品設計を考えれば、今後何が対応されて、何が対応されないかは概ね推測もつきます。

FFは多くのpub.devパッケージを寄り集めてWidget群を提供しています。例えば、GoogleMapWidget（地図部品）はflutter.devの開発するgoogle_maps_flutterパッケージを使っています。

これらはFFの管轄外です。ゆえに、GoogleMapWidgetに関する要望があっても、その基盤になるパッケージ自体が対応していない、もしくは対応の予定に無い機能は対応されないでしょう。もし対応するならば、FFはgoogle_maps_flutterに任せておけば良い諸々の機能向上やバグFix、Flutterアップデートへの追従という負債を、flutter.devではなくFF自体が引き受ける事になります。これは、前述した私がローコードを使うメリットで述べた事と同じことです。合理的に判断すれば、よほどの理由が無い限り、無理に対応する事はないでしょう。

つまり、対応されやすい部分とは、

基盤となるパッケージ側では機能を備えているが、FF側の体力が伴っていないがために未提供な機能
基盤となるパッケージが今後のアップデートで取り入れる事が見込まれる、パッケージとしても需要のありそうな機能
あとは本質的ではありませんが、FFの編集機能の使いやすさといった、FF自体の持つ機能

なお、FFがどのパッケージを使っているかは、FFが生成するコードを見ればわかります。