そごう・西武の展開するCHOOSEBASE SHIBUYA。最先端のテクノロジーを活用したRaaS業態デジタルネイティブ世代と新興ブランドの出会いを創出する次世代型のOMOストアです。ROUTE06は本ストアの開発支援を行なっており、今夏リリースされたCHOOSEBASE SHIBUYAアプリの開発も担当しました。

今回は、ソフトウェアエンジニアの海老沢 聡さん、外山智史さんのお二人にSwiftUIを使って行なったアプリ開発の裏側についてお話を伺いました。

■CHOOSEBASE SHIBUYAアプリ開発

ー お二人のバックグラウンドについて教えてください。普段からアプリ開発に携わっているのですか。

海老沢：
前職はスマホアプリを開発する会社に所属し、主にRuby on RailsやGoを使ったサーバサイドの開発に携わっていました。 途中数年間はRubyMotion, Objective-C, Swiftを使ったiOS開発もやっていましたが、今回のアプリ開発は約5年ぶりの開発となりました。

外山：
フリーランスのエンジニアとして、会社や個人のお客さまの課題をテクノロジーを使って解消するお手伝いをしています。 主にパソコンやスマートフォンのブラウザで閲覧、操作するウェブアプリケーションを作成していますが、何度かモバイルアプリを開発したこともあります。

ー CHOOSEBASE SHIBUYAアプリの特徴は。

海老沢：
CHOOSEBASE SHIBUYAは2021年9月にオープンしたOMOストアで、構想段階からそごう・西武と協業し、ROUTE06が開発支援を行なっています。 店頭／ECのシステムやオペレーションを融合させてオンラインとオフラインを自由に行き来できるOMOストアの仕組みを導入したり、百貨店業態では珍しい店舗とECの完全在庫連携を実現したりするなど、顧客目線での購買体験のあり方を追求したストアです。

今回、開発したアプリで最初に期待される役割は、CHOOSEBASE SHIBUYAの店頭でお客さまがお買い物の際に使う「カタログ兼決済アプリ」としての役割です。 CHOOSEBASE SHIBUYAでのお買い物はWebベースのカタログサイトでも可能ではありますが、ネイティブアプリならではの使い勝手の良さ、動作の軽快さが主な特徴です。

さらに、アプリならではの楽しいお買い物体験をお届けするために新しく開発された機能が、写真による商品情報検索機能です。店頭に展示されている商品をアプリのカメラ機能を使って撮影すると、機械学習を活用したAPIによってその商品の詳細情報が表示されます。Googleレンズの店舗特化版というイメージです。

ー 今回はSwiftを使って開発されたそうですが、Flutterなどのマルチプラットフォームフレームワークも検討しましたか。

海老沢：
既存のWebベースのカタログサイトのお客様の分析結果などから、まずはiOSアプリを速く開発することに今回は注力しました。

当初は将来的なAndroid展開なども見据えてドメイン層のみKMM (Kotlin Multiplatform Mobile)による開発も検討しましたが、私がKotlinの経験がなかったことからリスクが大きいと考えて見送りました。

また、今回はこのタイミングでの実装は見送りましたが、 App ClipなどのiOSならではの機能も視野に入っていました。 開発開始当時はFlutterを使うとApp Clipのアプリ容量制限をクリアできない状況であったため、そもそも要件を満たせませんでした。

App Clip以外にもiOSに備わっている機能を用いた機能実装は色々と構想に含まれており、それらを開発していく上でもSwiftで開発する方がマルチプラットフォームならではのハマりどころに引っかかってしまう可能性も低いだろうと考え、Swiftによる開発を決断しました。

ー Swiftで開発した印象を教えてください。

海老沢：
5年ぶりのSwiftでしたが、以前と比べてかなり書き心地が良くなっていた印象です。Xcode による補完も以前よりかなり良くなっていましたし、ビルド速度においてもかなり快適に開発することができました。 新規開発案件ということでCombineやSwift Concurrencyも取り入れて開発しましたが、サードパーティのライブラリを入れずとも非同期処理が書けることも開発体験が良かったです。
あと感覚的な話になりますが、Appleの標準プラットフォームに則った開発ができているということも一つ保守性を考えると一つ大きな安心材料になっています。

外山：
要件を簡潔に実装することができました。Swiftという言語の完成度が高いことはもちろんですが、開発環境のXcodeとの親和性が高いことも好印象でした。 SwiftはAppleのハードウェアで動くアプリケーションを書くために使われることがほとんどだと思うのですが、Swiftでウェブアプリケーションを実装することもできるようなので、一度やってみても良いかなと思うくらいには気に入っています。
（参考: Vapor ）

ー SwiftUIを全面採用したとのことですが、その決め手は何だったのでしょうか。

海老沢：
今回のアプリでは幸いiOS 14 以上対応という要件で開発ができたため、というのが一番大きいです。
SwiftUI自体はiOS 13から対応されていますが、正直iOS 13においてはSwiftUIは未成熟すぎてプロダクションにおいては選択しづらい印象でしたので。 今後のサービスの継続的な開発運用を考えるとやはりAppleが推奨するSwiftUIで開発していく方が安全であると思いますし、iOSエンジニアの採用やモチベーションを考えても良い選択であったと考えています。

ー 実際にSwiftUIを使ってみていかがでしたか。

海老沢：
Xcode Previewが非常に開発効率を上げてくれました。Xcode Previewを上手に活用するには、Viewのプロパティをなるべくプリミティブな値にしたり、API通信を伴うViewの表示要素はDIなどを用いてスタブ可能にするなど設計上の工夫は必要ではありましたが、そこさえできてしまえば快適にViewを作っていくことができて楽しかったです。

また、自分はReact (Web)の経験があるためコンポーネント設計などにReactで学んだ宣言的UIにおけるコンポーネント設計の考え方などが応用が効いたためスムーズに開発できたと思います。

外山：
UIを宣言的に表現できるので、 アプリ開発の経験が少なくてもReactやSvelteを実装したことがあればその経験やメンタルモデルが活かせます。これはアプリ開発の裾野を広げるテクノロジーだと思いました。

一方で。少し複雑なこと実現するためにはUIKitというAppleが提供しているUIフレームワークを使う必要があるのですが、これは専門的な知識やノウハウが必要です。 今回はUIKit周りを経験豊富で知見のある海老沢さんにお願いして、私はアプリの経験は少ないですがReactなどの経験を活かしてSwiftUI実装できる部分を進めるという役割分担ができ、それなりの成果を出すことはできたのかなと思っています。

ー 採用したアーキテクチャについて教えてください。

海老沢：
MVVMを採用しました。TCA(The Composable Architecture)も検討したのですが、前述のように5年ぶりのiOS開発でSwiftUIも初めてという状態であったため、さらに新しめのアーキテクチャを採用するのは少しリスクを取りすぎかと考えて MVVM としました。

WWDCのセッションなどでもMVVMが使われていることや、サードパーティのライブラリにあまり依存したくなかったこともTCAを採用しなかった理由です。 アプリ自体もあまり大規模なアプリではない認識であり、であればなるべくシンプルな方が良いだろうという判断です。 ただし、今後中規模・大規模なアプリを開発する機会が訪れた際にはまた改めてTCAも評価してみたいと考えています。

また、Swift Package Managerを用いたマルチパッケージ構成にもチャレンジしています。 アプリの規模があまり大きくないことから、細かく分けすぎずにドメインロジックとAPIアクセスを分離した程度ではあります。

ー 上述のアーキテクチャで実際にやってみた感想や反省点などはありますか。

海老沢：
SwiftUIにおけるMVVMについてはまだDIなどのベストプラクティスがないようで、そこが少し大変だったところです。

@EnvironmentObjectや@Environmentを活用してDIを実装してはみたものの、View Modelにどうやって渡すかという部分で試行錯誤したりするのに時間がかかってしまいました。 しかしView Modelを挟むことによりAPIアクセスなどの詳細をViewから隠すことができたため、Viewの見通しを良くすることはできたと思います。

反省点は折角MVVMにしたのに時間が取れずにView Modelのユニットテストを十分に書けなかったことです。ここは運用の中で徐々に充実させていきたいところです。

外山：
Viewの見通しが良くなり、それにより全てのViewで Xcode Preview を利用でき見た目の調整がとてもやりやすかったです。 一方でMVVMが構造的に冗長だなと思うところもあり、機会があればより良い形を模索したいなと思っています。

ー その他アプリ開発にあたって大変だった点や工夫した点は。

海老沢：
大変だったのはiOS 14でしか起きないバグの対応ですね。SwiftUIもずいぶん安定してきたとはいえ、まだ発表から3年ほどであるためにUIKitと比べるとまだまだ枯れていない印象です。 とりわけiOS 14におけるSwiftUIは予期せぬバグが思った以上に発生したために苦労しました。

工夫したところは当たり前の話かもしれませんが、開発開始からすぐにCI/CDやTestFlightなどの足回りを整えたことです。

これのおかげで早い段階からデザイナーさんを含めたチームメンバーにビルドを配布することができ、動作確認のしやすさにつなげられたと思います。 今回CI/CDにはCodemagicを採用しましたが、証明書やプロビジョニングプロファイルの管理などもスムーズにでき、良かったです。

外山：
まだ解決していなくて今後の課題だと思っているのがSwiftUIでのコンポーネントのスタイリングです。

今回のアプリはfigmaでアプリのデザインを作成してそれを元にSwiftUIで実装したのですが、オブジェクトの影の表現がfigmaとSwiftUIで異なり、同じような見た目に仕上げることができませんでした。

■ROUTE06の開発環境

ー ROUTE06のエンジニアチームの働き方について教えてください。

海老沢：
自分は正社員ですが、フルリモートかつ裁量労働制で働いているため時間に融通が効くのがとても働きやすいです。 子どもがまだ小さいのですが、保育園の送り迎えや夜のお風呂やご飯の時間などをきっちり確保できるのが良いです。 急な子どもの体調不良などでやむを得ず業務中に抜けることがあっても、ROUTE06ではそれも温かく受け入れてくれる文化があるため安心して働けています。

反面、きちんと自分で時間を管理して限られた時間でしっかり仕事を進めなければいけないのでそこは厳しいところでもあると思います。

外山：
業務委託として1年以上お仕事させてもらっていますがとても良い環境だと思います。

同期・非同期問わず目的を達成するためのコミュニケーションを大事にしながら、無駄なやり取りは積極的に削り、全員が気持ちよく開発し高い成果を出せるように取り組み続けられているなと感じます。

ー ROUTE06 で働くのが向いていそう／楽しく働けそうなエンジニアはどんな人だと思いますか。

海老沢：
やはり好奇心が強い人が楽しめる環境なのでは、と思います。 技術に対する好奇心でも良いですし、お客様のドメインに対する興味関心でも良いと思います。

また今後ゼロイチで新しく作りそして育てていく案件がたくさん始まっていくと思います。 そういう意味でも新しいものを知り、作り、そしてお客様と一緒になって育てていくという様々なプロセスを多数体験できる環境であるため、自身の成長につながる学びがたくさん得られる環境であると考えています。

外山：
私は社外の人間なので実情と違う部分があるかもしれませんが、ROUTE06は複雑で難しい問題を解決したりするには、満足のいく問題を与えてくれる会社なんじゃないかと思います。

そしてその問題に共に向き合うチームのある会社だと思います。 そのため「より難しい問題に挑戦してみたい」「一人では解ききれない大きな問題に挑戦してみたい」人は楽しく働けると思います。

ー 海老沢さん、外山さん、ありがとうございました！

＃採用に関する情報

＃ 関連記事