CROOZ TECH BLOG

~読んだらわかるSHOPLISTの裏側~

CROOZ TECH BLOGとはクルーズ株式会社の開発チームが技術について共有するブログです
開発の中での発見や知識を広めてオモシロカッコイイ〇〇をツクリます。

今後を見据えてFlutterの検証を始めた話

こんにちは。クルーズ株式会社CTOの鈴木です。

今回はFlutter の検証を始めましたという話です。もちろんSHOPLIST.com by CROOZのアプリをリプレイスすることが目的での検証です。決して趣味の話じゃないです(笑)

背景

実はSHOPLISTのインフラ構成を変える構想を今考えています。要点でいうと

・MVCアーキテクチャ、特にテンプレートエンジンの利用をやめる

・サーバはAPIの結果のみを返し、そのAPIはブラウザ、アプリ共通とする。

・ブラウザの場合はフロントエンドフレームワークがHTMLを組み立てブラウザに返す。

・ネイティブはiOS/Androidを統一言語で実装して開発生産性を上げる。

今回はこの最後のiOS/Androidの実装言語統一の話です。

言語統一の目的については以前の投稿であげた「SHOPLIST.com のシステムをモダンなアーキテクチャに変えようとしたら予想以上に闇が深かった話」の課題の部分でもあげたiOSの場合SwiftとObject-C、Androidの場合JavaとKotlinが機能毎に混在して開発していることと、アプリ開発の社内の技術スタックをFlutterに統一することでアプリ開発の生産性を上げることです。

まず、iOSの場合SwiftとObject-C、Androidの場合JavaとKotlinが機能毎に混在していることについて、実はそこまで顕在化した課題というのはないです。もちろん多少は非効率な部分はあるのですが、新規実装はSwift、Kotlinで行い、既存部分の改修の時に直せるものは書き直す、そうでないものはObject-CとJavaで書くということができる状況でiOSのエンジニアであれば両言語対応できたため生産性が低くなっているというわけではないです。

潜在的なリスクとしてはObject-CやJavaの実装をこのまま続けていると、どこかのタイミングでAppleGoogleにリリース申請した際に、そのリリース申請が通らないんじゃないかという漠然としたリスクがあることです。このように現在そこまで非生産的な状況でないことと、リスクとしてはかなり抽象的だったため、レガシーシステムを脱却することとして2020年中に行う事柄には含めなかったのですが、今回は対応を検討することにしました。

もう一つの理由の社内の技術スタックの統合の話です。

こちらの方がやる意義としては重要だと考えています。今当社のネイティブエンジニアは主にiOSを担当する人、Androidを担当する人に分かれていて個別のラインで開発を行っています。また過去の経緯で内部的な設計も異なっている箇所があり、ちょっと古いたとえにはなってしまうのですがXamarinのようなクロスプラットフォーム言語で開発するようにしてしまった方がアプリ製造にかかわるトータル工数が削減できるのではと考えました。またこれを機に各OSごと2言語で開発している状況もなくせれば一石二鳥なのでクロスプラットフォーム言語の検証を始めたというのが今回の背景です。

Flutterを検討するに至った背景

前提として、社内にFlutter経験者がいない中での検証スタートであるため、まずはネット文献で調査し、そのあと実際に1~2カ月ほど特定機能を実装して導入の意思決定をするという形で計画しました。

まず以下の記事のようにすでに比較をされている方の情報を複数集め、Flutter、React Nativeの2つにまで候補をしぼりました。

qiita.com


その後、文献を見ながらトライアンドエラーを繰り返して進めていく形で検証を進めていく形となるため、文献の量を調査しました。調べ方としては極めてシンプルでGoogle トレンドでの検索状況で比較しています。

 

f:id:croozblog:20210810205608p:plain

Googleトレンド

上記のように、ここ1年で見ると圧倒的にFlutterのほうが情報量が多いです。

もう一つの側面としてはReact Nativeの開発元である Facebookとコミュニティのライセンスについても純粋なBSDライセンスではなく、独自にBSDライセンスに特許条項が付帯されており、営利目的のサービスを運営するにあたりリスクとなりうる内容を含んでいるように見受けられたため、今回はFlutterを検証の対象としました。

FaceBookコミュニティの独自のライセンスの話はこのサイトに詳しく解説があります。

検証の進めかた

繰り返しですが社内にFlutter経験者がいないため、ネット文献で調査し、そのあと実際に1~2カ月ほど特定機能を実装して課題の有無を評価していくという形で検証を進めています。

具体的な評価の項目としては

・現在使用しているSDKやライブラリで利用できないものはないか?

・実装していて生産性が悪くなる要素はないか?

・実装をしていて機能的に実現ができないなど、制約になることは無いか?

・アプリでの動作でレスポンスやCPU使用率など劣化する部分はないか?

の大きく4項目を比較していく形で進めています。

 

現在検証を始めて約1カ月経ちますが、今の時点で分かっていることとしては

SDKで動かないものはないが、1つだけFlutterから使うと実装が複雑になるものがある。但しSDK提供元より対応バージョンの提供が受けれる。

・パフォーマンス上今のアプリとさほど変わらない。

・実装については学習コストは当然必要だけどそれ以外で生産性が著しく落ちるものはない

という評価です。

あと2週間ほどで検証対象の特定機能の実装が完了するので、その完了を待って最終的には導入の意思決定を行いたいと思っています。