はじめに
株式会社 WinTicket の @wadackel です。
WINTICKET では、昨年2021年から Flutter を利用したクロスプラットフォームアプリケーション開発に取り組んでいます。具体的には目下、既存 Android アプリケーションを置き換えることを目標としています。将来的には iOS アプリケーションも Flutter 製へと置き換えることを想定しています。
この記事では、どのような事業状況から Flutter を採用した開発に至ったかについてご紹介できればと思います。
※WinTicket（パスカルケース表記）が子会社名称、WINTICKET（全て大文字表記）がサービス名です
WINTICKET とは
WINTICKET（ウィンチケット）は、2019年4月にリリースした公営競技のインターネット投票サービスです。現在サービス提供している公営競技の種類は競輪、及びオートレースの2種です。AI 予想やオッズ、選手データ、レース開催日程、結果、過去レース情報など、公営競技の投票に役立つすべての情報を提供しています。現在、WINTICKET が展開するプラットフォームは Web に加えて、ネイティブアプリケーション（iOS、Android）となります。
競輪をはじめ、公営競技と聞くとネガティブな印象がつきまとうのが正直なところです。しかし、事業としてはそんな公営競技の奥深さ、面白さを広め「若者にとっての新しいエンターテイメント」にしていきたいと考え、日々挑戦を続けています。直近では、昨年末に以下の記事にあるような新たな試みを行っています。
簡単に事業紹介をさせていただきましたが、いわゆるギャンブル系のサービスとなるため、この記事をご覧になってくださる方々の中での認知率は低いものかなと思います。開発コミュニティへの露出は多くありませんが、これまでいくつかの発信を行ってきたので一部ご紹介します。
- WinTicketにおける リアルタイム性と高負荷を考慮したアーキテクチャ/WinTicket Architecture – Speaker Deck
- WinTicketにおけるライブ配信システムの実現 – Speaker Deck
- Inside Frontend 2019 – 品質と開発速度を両立させるために捨てたものと守ったもの – Google スライド
- WinTicketにおけるPWA at PWA Night vol.9 – Speaker Deck
- アクセシビリティが高いFlutterアプリケーションを開発する – Speaker Deck
以降、タイトルにもあるように WINTICKET がどのような過程で Flutter を利用した開発に至ったかについて触れていきます。
WINTICKET とネイティブアプリケーションの歴史
前述したとおり、現在 WINTICKET ではネイティブアプリケーションを iOS 及び Android で展開しています。 リリースから現在に至るまで、Android アプリケーションに関してはいくつかの変化がありました。具体的には以下のような変遷を辿っています。
- Kotlin で実装されたアプリケーションを公開
- 1 を Google Play から取り下げ
- Trusted Web Activity（以下 TWA）で実装されたアプリケーションを公開
- 現在に至る
これらの変化は Google Play の規約が大きく関わった事柄となります。
Google Play のギャンブル系アプリケーション制限と緩和
2019年のリリース当時、Google Play の規約としてギャンブル系アプリケーションは強く制限を設けられていました。この制限を受けていた初期 Android アプリケーションでは、会員登録、ログイン、投票を行えませんでした。公営競技のインターネット投票サービスを成り立たせる上で、必要となる主要機能のほとんどが制限を受けている状態でした。
リリース翌年にあたる2020年には、Android アプリケーションを利用をしてくださるお客様のサービス利用体験、事業グロースへの影響を加味し、Google Play から Android アプリケーション公開を取り下げました。主要機能の利用できない状態で公開し続けることがお客様、事業の双方に対してネガティブな結果に繋がると判断したためです。 公開取り下げに向けた動きを契機に、特に Android 利用をしているお客様に向けては Web でのサービス利用体験を向上していく流れとなりました。具体的には Progressive Web Apps（以下 PWA）へと注力し、利用を促すような流れでした。
しかし、2021年3月に Google Play の規約に大きな転機が訪れました。以下、一部抜粋です。
Google は、デベロッパーが、Play で配信するギャンブル アプリの申し込み手続きを完了し、認可を受けた公営の運営者であるか、指定国のギャンブルに関わる適切な行政機関にライセンスを持つ運営者として登録され、提供しようとしている種類のオンライン ギャンブル サービスについて指定国で有効な運営ライセンスを提示している場合に限り、制限および Google Play のすべてのポリシーを遵守することを条件として、下表に記載されている国でオンライン ギャンブルを行えるまたは促進するアプリを許可します。
デベロッパー プログラム ポリシーのプレビュー: 現金を伴うギャンブル、ゲーム、コンテスト – Play Console ヘルプ
この規約変更がきっかけとなり、事業として Android アプリケーションに対する立ち位置を再考することになります。
事業におけるクロスプラットフォーム開発の意思決定
会員登録、及び投票を行うことができる Android アプリケーションが Google Play 上で公開できる流れとなりましたが、そうなるとどのような流れで公開に向かわせるかが焦点となりました。議論の末、以下3つの手段が候補に挙がることとなりました。
- 初期リリース時で利用していたコードベースを元に Kotlin で実装
- TWA で実装（PWA をネイティブアプリケーションとして配布）
- クロスプラットフォーム技術を採用し新規実装
規約変更が適用されたタイミングですぐにアプリケーションを公開し、業界最速という競合優位性を作りたい、広告配信などのチャンスポイントを早期に探りたい、という観点からまずは TWA で実装していくこととしました。TWA の場合、これまで注力していた PWA の資産をそのまま活用することができ、リリースに向けて必要となる工期が最小限になることが決め手となりました。
そして、それらと並行するかたちで TWA よりも優れたプロダクト品質を目指すべく、クロスプラットフォーム技術を採用した新規実装を進めていくこととしました。
候補1の Kotlin での実装案は採択しませんでした。リリース当時に開発していたバージョンから、サービス仕様、UI 共に大幅に変わっているため新規で実装することと大きく差がないことに加え、今後の事業運営を考慮した結果クロスプラットフォームへの挑戦を決断しました。
Flutter の採用を決めた背景
クロスプラットフォームの開発といっても、具体的に何を採用するか様々な道筋が存在するかと思います。以下はその一例です。
- Flutter
- React Native
- Kotlin Multiplatform
結論として Flutter を採用した訳ではありますが、その理由として、それぞれの技術に対する良い悪いというよりも、WINTICKET の事業状況にマッチしていたという点が大きいです。 組織編成を素早く整えられる見込み、将来に渡ってネイティブアプリケーションをメンテナンスしていくことを考慮した結果です。
また、Flutter が市場にまだ完全に一般化されていない比較的ブルーオーシャンな領域で、開発組織の技術的なチャレンジとしても刺激的なものになるだろうという観点もありました。
開発体制整備の容易性
CyberAgent では、各職域は専任のエンジニアが担当する分業体制が多くのケースで採用されます。クライアント領域においては iOS、Android、Web と、それぞれに専任の開発メンバーが担当する状態です。
Flutter をはじめ、クロスプラットフォームの開発になると、それぞれが業務の中で経験してこなかった技術スタックに少なからず触れていくことになります。そんな中でも Flutter の場合、各領域で利用されている（又はされ始めた）宣言的 UI というパラダイムの採用（React、SwiftUI、Jetpack Compose）、Dart の言語自体の学習コストの低さもあり、開発組織の編成が現実的に行える見込みがありました。これは開発に関わるメンバーを集める際に、iOS、Android、Web と3つの職域を対象に含めることができるためです。
実際に現在開発に関わるメンバーは iOS、Android、Web エンジニアと、元々各クライアント領域を担当していたエンジニアが参画しています。バックグラウンドの異なるメンバーが同じコードベース上で開発することで、それぞれのプラットフォームが持つ技術的知見を活かすような動きがあり、開発にポジティブな影響を与えています。
人数比に対する開発規模の最大化
Flutter に限らずクロスプラットフォーム技術の採用は、人数比に対する開発規模の最大化がしやすい、という点が強みになり得ると思います。人員の確保が難しいスタートアップ企業などの現場で Flutter が採用される一つの理由かなと思います。
ネイティブアプリケーションの開発を行うにあたって iOS、Android エンジニアメンバーをそれぞれ組織することと比較して、現実的に半分とは言えないものの、多くの場合で必要となる人員を減らすことができます。チームサイズが適切な状態を維持できることで、コミュニケーションコスト、マネジメントコストの低下にも繋がり組織の柔軟性に寄与します。
これらのメリットは今後の事業計画を支える上で大きな武器になると考えています。
デザインの再現性
iOS、Android 各プラットフォームにはそれぞれの UI に対する指針が存在します。
これらを踏襲し最適化することは、実装、デザイン観点でクロスプラットフォーム開発の壁になりやすい部分かと思います。
しかし、WINTICKET では元々 iOS、Android、Web の各プラットフォーム間でナビゲーションの設計や、モーダルの利用方法などの一部しか差異がない UI 設計となっていたこともあり大きな障壁にはなりませんでした。「既存の iOS で適用されたデザインを優先はするが、完全再現を目指すことはしない」というコンセンサスがデザイナと取れたことは恵まれていると思った出来事の一つです。
具体的な調整や工夫についてはこの記事では触れませんが、また別の回にて事例の紹介ができればと思います。
Flutter の将来性
Google Play 規約変更のおよそ1年前にあたる2020年の春には、200万人を超える開発者が Flutter を使用していることが発表されています。
We continue to see fast growth in Flutter usage, with over two million developers having used Flutter in the sixteen months since we released. Despite these unprecedented circumstances, in March we saw 10% month-over-month growth, with nearly half a million developers now using Flutter each month.
Flutter Spring 2020 Update. Continued momentum and enterprise… | by Tim Sneath | Flutter | Medium
最近だと2021年末に Flutter を使用したアプリケーションが Google Play 上に37万を超える数登録されていることも発表されました。
We’re amazed to see how fast Flutter continues to grow, with a flourishing ecosystem of apps and tools that build on top of the core framework. At this year’s Google I/O event, we noted that there were already over 200,000 apps built with Flutter in the Play Store. In just over six months since that event, the number of Flutter apps has nearly doubled, with more than 375,000 Flutter apps now in the Play Store.
開発コミュニティの盛り上がり、プロダクトへの採用実績、Flutter が持つ生産性の高さなどを鑑みて、今後の事業展開を継続して支える基盤として十分実用に耐えるだろうという判断を行いました。
Flutter の採用に対する懸念
Flutter の採用可否を決めるにあたって懸念に挙がった点もありました。 大小様々な観点があったのですが、代表的なものについて触れておきたいと思います。
サービスの規模感
Flutter 自体がまだ完全に成熟した技術とは言えず、当時実際に採用したプロダクトも規模の大きなものとなると事例があまり多くありませんでした。（特に国内においては）
WINTICKET の各クライアント実装は Web の場合、200以上のページテンプレート、40万行程度のソースコード。iOS の場合は160以上のページ、25万行程度のソースコードで構成される規模感です。大規模プロダクトの定義は難しいですが、小さくないプロダクトであるとは思います。
サービス内で実現すべき主要機能であるレース情報閲覧、投票機能、LIVE 映像の視聴、多様な決済手段への対応など、事前に一定以上の複雑性を含む箇所は洗い出し技術検証を行いました。その他機能の詳細な部分に関しても、既に稼働しているソースコードを参照したりと資産として流用できる状態ではあるため、置き換えを行える見込みはありました。
それでも、ある程度の規模があるプロダクトの刷新で Flutter が通用するか、置き換え後のアプリケーションがまだ正規のリリースを迎えていない今のタイミングでは将来性に期待を寄せる一方で、不安も同時に抱えながら開発に取り組んでいる状態にあります。
ただ、前述したように、いざ軌道に乗った際のメリットも非常に大きいため、安定したリリースに向けて今も奮闘しています。
プロダクト品質と既存 iOS アプリケーション置き換えの壁
アプリケーションの置き換えにあたり、新規で実装を行えることで様々な見直しをかけることができます。 仕様変更に追従しきれず技術的負債に繋がっていた箇所、各プラットフォームで新たに取り入れられた開発トレンドの組み込み、自動テスト基盤の見直しなど、あらゆる観点で内部品質を向上させることができる見込みがありました。
一方で実際にお客様のサービス利用体験に直結する外部品質に対しては懸念が残りました。 元々 TWA を利用していた方に向けては、パフォーマンスは Web 以上にできるだろうことは想定できました。しかし、Swift で実装された既存 iOS アプリケーションのパフォーマンスと比較してしまうと、Flutter を利用した場合、頑張っても同等で基本的には下回るだろうという点です。
例えば iPhone 13 Pro などに採用されている ProMotion への対応は、本記事執筆時点では 対応していない などが挙げられます。この問題はある程度時間が解決してくれる部分ではあると思いますが、ProMotion の対応に限らず、既存 iOS アプリケーションの触り心地を上回ることは現時点で高い壁になっています。
しかし、触り心地よく、お客様に満足いただけるアプリケーションを実現するために、技術的な側面から様々な工夫を講じてもいます。詳細な部分に関してはまた別の回でご紹介できればと思います。 そして技術的な側面以外でも、UI の見直し、必要であれば仕様自体を見直したりと、できることは多くあるはずです。Android アプリケーションの置き換えを無事に終え、次のターゲットとなる iOS アプリケーションの置き換えを行うまでに試行錯誤を重ねていきたいと考えています。
Flutter 自体も開発が活発に行われ、日々改善が行われているのでその点にも期待しています。
まとめ
WINTICKET では、Flutter を採用し Android 及び iOS アプリケーションの置き換えを目指しています。詳細な KPI や事業戦略は記載できないものの、その判断に至るまでの過程についてご紹介しました。
こうした取り組みが事例として表に出ているものがまだ多くはないと思います。国内の Flutter 採用事例の一つとして発信することができれば、コミュニティ発展への貢献に繋がるだろうと思い本記事の執筆に至りました。
今後、ここでは触れることのできなかった技術的な側面や開発体制などの工夫についても回を分けて発信していければと思います。