@cosme iOSアプリの開発の裏側

こんにちは。アイスタイルのアプリ開発部に所属しているチーフエンジニアの小笠原です。
普段は店頭での肌測定器による肌チェックや問診などのカウンセリングの結果を台帳に登録できるiPadアプリの開発を行っている傍、iOS版の@cosmeアプリの技術面もみています。

今回、@cosmeアプリ開発がどのように行われているかをお話しします。

@cosmeのサービスについて

もともと、@cosmeはWeb主体のサービスから始まり、5年ほど前にモバイルアプリ(iOS/Android)をリリースしています。
アプリではクチコミ、商品検索、購買などの基本的機能はWebと同等のことができ、独自の機能としてはポイントカードやユーザー固有情報に基づいたイベント契機のPush通知やアプリ内メッセージなどがあります。
Webとアプリの方向性の違いとして、大きくはWebは不特定多数を対象とし、アプリは各ユーザーに最適化したコンテンツを配信していくという違いがあります。
例えば、アプリで同じカテゴリーの記事が見る機会が多くなるとタイムラインに表示されるコンテンツがそれに近しいものになります。

プロジェクト開発について

@cosmeアプリ開発の大きな流れとしては所属部署内で企画書を作成し、概算工数を出した上で稟議にかけて、決裁が下りた企画が案件となり開発が始まります。
企画書の作成には主にプロデューサー・ディレクター・デザイナーが関わり、ある程度形になってきた段階でエンジニアが入り、システム観点での提案や見積もりを行っています。
ただ、全て稟議を通すフローだとテンポよくPDCAのサイクルが回せないので、稟議にあげるものは比較的影響が大きいものに絞り、小規模の開発はチーム内で判断して進めています。

ビジネス要件以外では将来を見越して安定した品質と開発速度を維持できるように積極的にエンジニアからリファクタリングなどを発案し、しっかり工数を確保した上で進めていますので、ビジネス要件ばかりを優先して、技術的負債を返さないという極端な偏りはありません。

また、アプリ開発の特殊な所としてアプリ内の全ての機能についてチームに決定権があるというわけではなく、広告や課金などは別部署の管轄になるため、その場合には事業部とアプリディレクターが入り、企画・仕様決めを行っていきます。

各工程の役割について

大きく二つの流れがあるので、それぞれアプリ案件と事業部側案件の工程と役割を図にしました。
わかりやすく図にすると完全なウォーターフォールに見えてしまうのですが、実際はウォーターフォール+アジャイルのハイブリッド形式で他方のデメリットを補う形で取り入れています。

なぜハイブリッド形式をとっているかというと、アイスタイル で提供しているサービスはさまざまな部署、プロジェクト、システムが関わっており、アプリ開発のスケジュールを元に各々所属しているスケジュールを作成するため、あらかじめこれぐらいの期間と規模というのがわかっていると調整しやすく、稟議で実施可否の意思決定も下しやすくなるからです。

ただ、ウォーターフォールだと開発前の見積もり精度が低い状態で期間を取ってしまうので、余剰工数のような必要以上に時間をかけて開発してしまい、本来は早く終わるものが時間を使い切って完了が遅くなりがちになるので、そこはアジャイル要素を取り入れて、短いスパンでPDCAが行えるように調整しています。

アプリ案件フロー

事業部案件フロー

開発チームについて

開発チームは主にディレクター3名、デザイナー2名、iOS7名、Android4名、アプリ用APIゲートウェイ3名(Androidと兼務)のメンバーで構成されています。

スクラム開発の導入はしていませんが、日々チーム内朝会とディレクター朝会を二階層でしています。エンジニア朝会では開発内部に閉じる話をし、ディレクターが入る朝会ではチーム間・部署間にまたがる作業がないか確認しながら連携して進めています。

他には週一でエンジニアだけのゆるいKPTもしています。ここでは雑談のようなゆるさと決め事にはしっかり取り組むという形式をとっています。

開発についてはエンジニアの裁量に任されている部分が大きく、導入する技術や解決すべき技術問題について、開発チーム内で相談して決めています。

システムアーキテクチャ

アットコスメではマイクロサービスアーキテクチャを採用しており、各用途ごとにシステムを分けていますが、歴史の長い一部のシステムはモノリシックであったりと部分的に混在しています。

アプリ開発では画面に必要な情報を各サービスAPIから取得するケースとアプリ用APIゲートウェイから一括取得するケースがあります。
アプリ用APIゲートウェイの導入は1年ほど前に行い、それまではiOS/Androidそれぞれで各サービスAPIから取得し、画面に最適なデータ構造に変換していたのですが、以下の課題があったので、それを解決するために導入しています。

  • Webとアプリと各サービスのAPIが密結合している
  • アプリから行うAPIリクエストの複雑化

アプリ用APIゲートウェイ導入時の開発については、@cosme￰アプリ用APIゲートウェイを作っている話が詳しいので、こちらをご参照ください。

プラットフォームAPIは@cosmeの商品情報取得や、クチコミの投稿/削除などの共通機能を提供するための旧来の集約APIで、現在はマイクロサービス化に伴い、役割ごとに各サービスに機能を分散させています。内部では各サービスのDBと一部APIからデータを収集しています。

アプリの使用するアーキテクチャ・言語・ツール・フレームワーク

アプリでは解決したい領域ごとに責務分割やどこに何を書くべきかを判断しやすいようにClean ArchitectureとMVVMを組み合わせたアーキテクチャを採用しています。
具体的にビジネスロジックやUIをどのように落とし込んでいるかについてはアイスタイル的 iOS設計ベストプラクティスが詳しいので、こちらをご参照ください。

言語 Swift
設計 Clean Architecture、MVVM
主要ライブラリ RxSwift、RxCocoa、Alamofire、SwiftLint、R.swift、SwiftyJSON など
ライブラリ管理 CocoaPods、Carthage
CI/CD環境 Bamboo、CircleCI, Deploygate
分析 Firebase Crashlytics、Firebase Analytics、BigQuery、Redash
ソースコード管理 GitHub、GitLab
プロジェクト管理 JIRA
チャットツール Slack
情報共有 Confluence

大規模ならではの難しさ

アプリ開発ではiOS/Androidの技術力があっても、複雑なビジネス要件を最適な形で実現できる設計力や幅広いドメイン知識が必要なところに難しさがあると感じています。
例えば、アプリの商品画面では16種類ほどのAPIを非同期取得して実現しているのですが、これらは単一のサービスAPIから全て取得できるわけではなく、会員/商品/アクション/フィード/購買/クチコミ/タグ/画像/広告などの各サービスAPIから取得しています。
そのため、あるレイアウトを組む際にはどこのサービスでなんのデータが取得でき、どのタイミングで更新されるかなど各サービスAPIの仕様を知っておく必要があります。
このような特性があるので、特定のエンジニアしか知らない、触れないという状況が顕著化して属人化する前になるべく上流工程の仕様書はConfluenceにまとめ、1ヶ月単位でリリースした機能の紹介とバックエンドの仕組みを共有する会を設けてカバーしています。
また、これほどのAPIリクエストを単純に実装してしまうと非同期制御が複雑になってしまうので、Rxのzipやcombinelatestで非同期制御を簡単に書くようにしています。

技術以外では開発に関わる人が多いので、初対面の人と仕事をする機会も多く、コミュニケーション能力や調整力も必要になってきます。

最後に

今回は@cosme iOSアプリの開発の裏側ということで開発の全体像などをご紹介しました。
開発側ではこうした複雑なビジネス要件をなるべくシンプルな形で解決していくエンジニアを募集しています。
興味のある方、iOSエンジニアと直接話してみたい方はぜひご応募ください。お待ちしています。

iOS @cosmeの開発とマネージャー的な役を兼務しています。

コメントを残す