14,284人の経営者がつながるSNSに、
マネタイズの仕組みがなかった。

BizOn!にとってFlutterは正しい選択だった。一つのDartコードベースから三つのデプロイターゲットへ。iOS・Android・Webで完全に同一のUIを維持する。フィード、ダイレクトメッセージ、プロフィールマッチング、イベント、通知——SNSレイヤー全体が、三つのプラットフォームに同時にビルドされる単一コードベースで管理される。このスケールのプラットフォームにとって、これは利便性ではなく構造的な優位性だ。

しかしFlutterの単一コードベースモデルは、Appleのレギュレーションとの間に特有の問題を生む。コンパイル済みのDartバンドルに含まれるあらゆるデータ——価格情報を含む——がiOSバイナリの一部になる。われわれは早い段階で設計上の決断を下した。すべての価格ロジックはPHPバックエンドにのみ存在し、Webフロントエンドにのみ提供する。Flutterアプリは価格・プラン・課金額を一切知らない。Appleの審査担当者が目にするのは、構造上、価格を表示することも処理することもできないアプリだ。これは回避策ではない。関心の分離を徹底した結果が、規制要件を完全に満たしていた。

GMOのリダイレクト型3Dセキュア認証はプラグアンドプレイではない。決済開始→3DS認証チャレンジ→コールバック→トランザクション確定というリダイレクトループは、各決済の進行状況を追跡するフルスタックのサーバーサイドステートマシンを必要とした。セッション切断・部分認証・タイムアウトのエッジケースを明示的に処理しなければならない。GMOの契約条件に対応した既製ソリューションは存在しなかったため、ゼロから構築した。

特定商取引法は有料サービスに対して、事業者情報・料金体系・解約ポリシー等の法定開示事項を求める。これを開発末期の法的チェックボックスとして扱うのではなく、開示フレームワークをデータモデルの早い段階に組み込んだ。すべての料金プラン、すべてのプランバリエーション、すべての請求書が、同一のコンプライアンスレビュー済みデータソースから自動的に値を参照する。法律がデータレベルで満たされていれば、UIがそれを違反する機会は構造的に存在しない。

iOS・Android・Webは同時にリリースしなければならなかった。段階的ロールアウトでは、先行プラットフォームのユーザーが未対応プラットフォームのユーザーに機能を説明するという、二層構造のサポート問題が発生する。Apple App Store・Google Play・Webデプロイを、単一の同期されたリリースウィンドウとして調整した。App Storeの審査だけでSteering規制のドキュメント提出が複数回必要だった。最初の審査が差し戻される可能性を織り込んだうえで、その反復工数をタイムラインに組み込んだ。