アプリのFlutter移行にはどのくらいのコストがかかるか

ネイティブアプリをFlutterへ移行するコストは、3つの要素に集約されます。ネイティブとFlutterをつなぐ基盤のための一度きりのセットアップコスト、主に各画面がどれだけ他とつながっているかで決まる画面ごとのコスト、そして移行が終わるまで2つの技術を並行して運用するコストです。Flutterによる削減効果（2つではなく1つのコードベースと1つのチーム）が完全に現れるのは出口を迎えた後です。したがって本当に問うべきなのは「いくらかかるか」だけでなく、「元が取れるまでにどれくらいかかるか」です。

「アプリのFlutter移行」に対して、誠実に答えられる単一の数字はありません。画面数が同じ2つのアプリでも、自己完結した画面がどれだけあり、ネイティブSDKと複雑に絡み合った画面がどれだけあるかによって、コストは大きく異なります。このページでは、私たちがプロジェクトでConvergeを使ってどのように見積もっているかを紹介します。Convergeは、AndroidとiOSのコードを読み取り、画面ごとの見積もり付きの移行計画に変換するツールです。

Flutter移行のコストを左右する要因

add-to-appの一度きりのセットアップコスト

最初のFlutter画面をリリースする前に、後続のすべての画面が依存するものを誰かが作る必要があります。両方のネイティブビルドへのモジュールの組み込み、エンジン管理、双方向のナビゲーション、エンジン間の共有状態、型付きのネイティブ–Flutter間コントラクト、デザインシステムのFlutter版、そしてCIです。どれもビジネス側からは見えないため、最初の画面がその後の画面より時間がかかる理由を事前に説明しておきましょう。フレームワークによって最も削減できるのがこの部分です。ナビゲーション、状態共有、エンジン管理は、どのadd-to-appチームも結局は手作業で作ることになる部分であり、まさにそれが私たちがInlayを作った理由です。この期間を急がず、経験豊富なFlutterエンジニアの支援を受けて初期セットアップを行うことを強くおすすめします。ここで下す判断によって、その後のすべての開発が大きく加速することも、減速することもあります。

移行する画面ごとのコスト

移行する各画面には、UIの書き直しのコスト（通常見積もられる部分）に加えて、境界に関する作業のコスト（通常見積もられない部分）がかかります。画面がネイティブから必要とするすべてのデータ、画面への出入りのすべてのナビゲーション経路、画面が呼び出すすべてのネイティブSDKです。私たちの経験では、自己完結した末端の画面はほぼUI作業だけで済みますが、ネイティブのジャーニーの途中にある画面は、UIだけから想定されるコストの数倍かかることも珍しくありません。だからこそConvergeが最初に行うのは、すべての画面と画面間のナビゲーションをマッピングすることです。これにより、誰かが見積もりを始める前に境界の作業が可視化されます。

さらに、既存の挙動に合わせるコストもあります。ネイティブ版が扱っているあらゆるエッジケース、バリデーション、分析イベント、アクセシビリティラベルを再発見する作業です。ネイティブコードのドキュメントが充実していれば、このコストは小さく済みます。そうでなければ、計画のページで紹介した「add-to-appのほうが安全だろう」というケースのように、見積もりの大半を占めることもあります。同じ画面のiOS版とAndroid版の違いは、こうした想定外の事態のよくある原因であり、Convergeはすべての画面についてその違いを指摘します。

ネイティブとFlutterを並行して運用するコスト

アプリがハイブリッドである間は、両方の世界のコストを支払うことになります。段階的なロールアウトでは、フィーチャーフラグの裏にネイティブ画面をフォールバックとして残します。これはリスク管理としては望ましいことですが、フラグが削除されネイティブコードが消されるまでは両方のバージョンをメンテナンスしテストする必要があります。そのため、フラグを有効にする時点でネイティブ版を削除する日付を決めておきましょう。基盤は二重化し（制約を参照）、ビルドやCIは遅くなります。また出口を迎えるまでは、ホストアプリ、境界、SDK連携のためにネイティブ開発者が引き続き必要です。

Flutter移行を画面ごとに見積もる方法

私たちは通常、画面ごとに見積もります。画面間の差は、どんな平均値にも表れないほど大きいからです。各画面について、次の点を確認します。

• UIの複雑さ - 状態の数、コンポーネントがどの程度カスタムか、デザインシステムですでにカバーされているか。
• アプリの他の部分とのつながり - 画面への出入りのナビゲーション経路、受け渡されるデータ、ディープリンク。それぞれが、定義しメンテナンスすべきコントラクトになります。
• ネイティブへの依存 - カメラ、地図、決済、生体認証、広告。ロジックのみのSDKは型付きAPIの裏にラップできますが、独自のビューそのものがコントラクトとなるSDKは、通常エンベディングが必要になり、最もコストのかかるケースです。
• プラットフォーム間の差異 - iOSとAndroidで挙動が異なる場合、どちらの挙動を採用するかを誰かが決めなければならず、それはしばしばプロダクトの議論になります。
• 既存コードの知識 - ネイティブの画面が何をしているかを、今でも理解している人がいるか。

数十画面程度であれば、これを手作業で確認することも可能です。しかし大規模なアプリでは、2つのコードベースを画面ごとに読み解く必要があり、その多くはとうの昔に去った人たちが書いたものです。Convergeが自動化するのはまさにこの作業です。 両方のコードベースを読み取り、すべての画面と画面間のナビゲーションをマッピングし、プラットフォーム間の差異を示したうえで、根拠を明示しながら各画面を見積もります。そのため、平均値を鵜呑みにするのではなく、すべての数字を確認できます。

これらの種類に人日の目安をあえて添えていないのは、チーム、コードベース、デザインシステムに大きく左右されるため、有用なベンチマークにならないからです。だからこそConvergeは、皆さん自身のコードから画面を見積もります。画面ごとの数字と同じくらい重要なのが順序です。1つのジャーニー全体をまとめて移行すると、画面を1つずつ移行するよりも安く済むことがよくあります。画面同士の間のコントラクトを作る必要がまったくなくなるからです。Convergeは、依存関係の最も少ない画面から始める、こうした順序を提案します。詳しくは移行の計画を参照してください。

Flutterへの移行にはどのくらいの期間がかかるか

移行は通常、4つのフェーズを経て進みます。各フェーズの長さはアプリとチームによって異なりますが、順序は同じです。

1. PoC - 1つまたはいくつかの画面を、フィーチャーフラグの裏で本番環境にリリースします。
2. 基盤づくり - 接続基盤、Flutter版のデザインシステム、CI、そしてチームが従う規約を整えます。PoCと一部並行して進みます。
3. 移行ウェーブ - ジャーニーを1つずつ、依存関係の最も少ないものからアプリの中心に向かって移行します。最も長いフェーズであり、チームの規模が期間に最も大きく影響するフェーズです。
4. 出口 - Flutterがシェルとナビゲーションを引き継ぎ、残ったネイティブ画面はその中でホストされます。

期間はコードの外にある要因にも左右されます。同時に何人の開発者がFlutterで作業できるか、ネイティブチームが並行して機能をリリースし続けるか（通常は続けます）、そしてビジネス側がどれくらいの頻度で優先順位を変えるか、といった要因です。最後の点こそ、計画を一度きりのドキュメントにできない理由です。

Flutterがモバイルアプリの開発コストを削減する仕組み

削減効果は、UIとビジネスロジックをiOSとAndroid向けに一度だけ書けることから生まれます。移行した画面はどれも、2つの実装、2組のバグ、2つのレビュープロセスを必要としなくなります。最初からFlutterで作る新機能は、置き換えるべきネイティブ版がないため、最も早く効果が出ます。

とはいえ、多くのアプリでは削減幅は「コストが半分」よりも小さくなります。ネイティブSDKとの連携、プッシュ通知、ウィジェットや拡張機能はネイティブのまま残り、QAは引き続き両プラットフォームをテストし、チームが慣れるまでには時間がかかります。実際には、セットアップの費用を払い2つの技術を並行して運用する間はコストカーブがまず上昇し、Flutterの比率が高まりネイティブコードが削除されるにつれて下がっていきます。最終的にFlutterになる部分が大きいほど、そして出口を早く迎えるほど、早く元が取れます。

Convergeで移行の見積もりを最新の状態に保つ

初日に作った移行の見積もりは、3か月目にはたいてい外れています。ネイティブアプリは変わり続け、優先順位は移り変わり、チームは境界に実際どれだけのコストがかかるかを学んでいくからです。Convergeはコードそのものを対象に動作するため、スプレッドシートを手作業でメンテナンスする代わりに、定期的に実行して、移行の進行に合わせて計画を調整させることができます。私たちは、計画をJiraのエピックとチケットに変換する機能も開発しており、移行を他の作業と同じバックログで管理できるようにする予定です。