読者です 読者をやめる 読者になる 読者になる

inFablic

Fablic開発者ブログ

フリルのアプリ開発の歴史 - Titaniumと技術スタック選択

こちらはFablic Advent Calendar 2015の12/3の記事です。

こんにちは、エンジニアのninjinkunです。先日COOKPADと共同開催したキャリアイベントで、「フリルのアプリ開発今昔物語」というタイトルでお話しさせて頂きました。

内容としては

  • フリルのアプリ開発の歴史
    • 3度のリニューアル
    • Titaniumの話
    • 使っている技術スタックの変化
  • 今求めているエンジニア

という構成です。

この記事では発表内容の中から少し膨らませて、Titaniumからネイティブへの移行の話を書いてみます。

Titaniumからネイティブへの移行

フリルのiOS版は、2014年始めにTitaniumからネイティブへ移行を行いました。エンジニア3人とデザイナー1人で延べ4ヶ月かけてiOS版のフリルを全て書き換える仕事でした。

4万行のTitanium JavaScriptを4万行のObjective-Cへの書き換えたので、Titaniumからより抽象度が低いObjective-Cへの書き換えとしては結構がんばったと思います。チームにとっても自分にとっても、自信になったプロジェクトでした。

Titaniumという選択の妥当性

Titaniumについては様々な思いを抱いている人が居るようで、時々質問を受けることがあります。自分はこの移行プロジェクトからの入社なので選択した当事者ではないのですが、起業当初は妥当な選択であったという見解を持っています。

Titaniumは

  • Webと連携するパーツが揃っていて生産性が高い
  • デザイナーがビジュアルを弄りやすい

という点でメリットがあり、

  • Webと連携する複雑なネイティブアプリを迅速に開発し、市場に投入する
  • 使い勝手も妥協せず、かつ女性に受け入れられるビジュアルを作り込む

ということを可能にした点で、フリルの初期の成功を支えたと言えると思います。

しかしその一方、成長期には

  • 最新iOSへのキャッチアップが遅れる
    • ユーザー体験とAppStoreマーケティングに差し支えが出る
  • 外部モジュールの導入にラッパーモジュールが必要
    • 広告や計測系のSDKや画像処理ライブラリの導入をどんどん試すことができない
  • アプリエンジニア採用の障害になる
    • これは直面する前に移行して回避してしまったので推測

という点で足かせになってしまい、前述の書き換えプロジェクトに発展していきます。

適切な技術スタックの選択

この辺りの話は React Native / Alternative な開発ツールの採択についてでも少し触れられています。そしてこのnaoyaさんのスライドにもあるように、我々のネイティブ移行は技術スタック選択の事例としても見ることができると思います。

あるタイミングでは正解だった選択が、内部環境や外部環境の変化に伴い負債になってしまうことがあります。フリルの書き換えがもう少し早かったら、逆にもう少し遅かったらと考えると、そのタイミング次第で現在のフリマアプリの市場シェアが多少変わっていた可能性もあります。月並みな感想ですが、状況に応じて技術を選択するのは簡単ではないと思い知らされます*1*2

この問題に正解はなく、その時点その時点でベストな選択肢を探り続け、必要があればきちんと投資をして行くしかありません。拠って立つ技術が時代性を捉えているのか、常に疑う姿勢を持っておきたいものです。

Fablicでは技術の選択に正面から向き合うエンジニアを募集しています

*1:他の例を出すと、一昨年に主流になるかと目されたReactiveCocoaはiOS開発の主流にはなりきれず(自分はSwiftの登場が転換点だったと見ています。最近ではRxSwiftなども出てきました)、一方でRxJavaはAndroid開発コミュニティで人気を博しているように見えます。自分は両方導入したので一勝一敗です。

*2:私見ですが、開発の初速を稼ぐタイプの技術は抽象度が高いことが多いので、後々の乗り換えコストが高くなるという傾向はあるかもしれません。