レンティオのiOSアプリを公開した背景と技術スタック選定について
レンティオ株式会社でCTOをつとめている神谷と申します。先週の話ですが、レンティオでは待望のiOSアプリをリリースしました🎉
本記事では、アプリを作るという判断をした経緯や、技術スタックとその構成を選択した理由等について書き残してみたいと思います。何かの参考になれば幸いです！
レンティオアプリの概要
本アプリは、商品探しやレンタルの注文などができる、いわゆるECジャンルのアプリです。
サイトからの注文などはWebサイトでもできることではありますが、アプリならではの機能を活用することでよりよいユーザー体験を提供しようという狙いがあります。
たとえばレンタル品の返却日リマインドをプッシュ通知で受けたり、スマホの画面に表示したバーコードをコンビニや宅配ロッカーにかざすことで簡単に商品の返却ができたりします。
これまでアプリを作らなかった理由
これまでレンティオは創業から7年間、Web一筋で成長を続けてきたという歴史があります。以前の私自身もアプリはなくても良いじゃん派でした。
もちろんアプリもあるに越したことはないのですが、中途半端な品質でリリースすることによる評判の悪化リスクや運営コストとの天秤を考えると気軽にやるべきではないという思いがあり、それはアプリを公開した今でも変わりません。最近ではPWAがどんどん進歩してきてますし、Safariもプッシュ通知がそろそろ始まるという声もありますしね。
もう少し具体的な判断理由の話をすると、以前のレンティオのお客様は一時利用の方が多く、たとえば毎年6月にお子様の運動会のためにビデオカメラを借りるお客様が、1年後の同シーズンに再度ビデオカメラを借りるみたいなご利用が多い印象でした。年に一度しか使わないお客様にアプリを勧めても響かないですよね。
実務的な面では開発リソース問題もあります。レンティオではアプリ以外にも重要な開発案件がたくさんありますし、不透明なニーズのために貴重な開発リソースを割くべきではないと考えていました。
アプリを作ろうとした経緯
そんな中、アプリを作ろうとしたのにはビジネスのフェーズが以前と比べて大幅に進んだというのが背景として大きいです。
最近のレンティオは取り扱い商品の幅がかなり広がっており、たとえばロボット掃除機とコーヒーメーカーを借りていて、さらにスポットで一眼レフを借りるなど、ヘビーユーザーのお客様が増えてきています。
お客様へのユーザーインタビューをしていてもアプリが欲しいという要望や、また我々が想定していた以上の使い方（たとえば空き時間にレンティオを開いて気になる商品を見て回るなど）がされていることがわかり、そういった声が強い後押しとなりました。
これらのニーズにお応えするには、スマホアプリによる、さらに快適な体験を提供するべきだろうということになり、具体的な検討を開始したという経緯があります。
アプリを通して実現したかったこと
レンティオは行動指針の一番初めに「カスタマーファースト」を掲げているような会社です。今回のアプリ開発プロジェクトでもそれは念頭に置いており、アプリを通して「より洗練されたレンタル体験の提供」を実現すべくプロジェクトを進めておりました。
では「より洗練されたレンタル体験」て何？という話になるかと思いますが、商品が探しやすい注文をしやすいというのはECのアプリである以上必須条件ですね。
そのうえでひとつレンティオが特徴的なのは、一般的なWebサービスと異なりレンタル品を実際に利用したりそれを返却したりと、オフラインでの体験がサービスの大部分を担っています。このようなオフライン体験をよりスムーズにできるようにするのも本アプリの重要な役割と考えています。
たとえばレンタル中商品の一覧や返却日をサッと確認できたり、レンタル期間の延長や買い取りが手軽にできたり、商品の返却作業をスムーズにしたいという狙いがありました。
Webとアプリとの役割分担
アプリは公開しましたが、当然Webサイトのほうも今まで以上に力を入れて運営します。それぞれの役割分担としては、次のように整理しています。
- Webサイトは新規ユーザーとの接点としての役割や、ライトユーザーへのサービス提供を目的としているため、初回訪問の方にサービスについて丁寧に説明することを心がけています。
- アプリはリピーターの方向けに、より良いレンタル体験を提供したり新しい商品との出会いを促進することなどを目的としています。
アプリの構成と開発体制案
いざ開発しようにも、まずは開発の方向性を決める必要があります。アプリ開発と一言で言っても、いくつもの技術構成方針があるのでレンティオが実現したいこと、現在のレンティオを取り巻く状況を踏まえて適切な選択をする必要があります。
※もちろんこれを決める前のステップとして、カスタマージャーニーマップを作ってアプリにどんな機能を盛り込むか？を議論したり、ワイヤーフレームを引いたりといった工程もあったのですが、本記事のテーマからは外れるため今回は割愛させていただきます。
さて、アプリの構成を考えるうえで多くの方が悩まれるポイントとして、
- ネイティブ（Swift、Kotlinなど）
- クロスプラットフォーム（Flutter、React Nativeなど）
- WebViewメイン（ガワネイティブ）
と呼ばれる構成のどれにするべきか、またそれを内製するのかパートナー企業に開発をお任せするのかといった部分も決める必要がありました。それぞれの選択肢について、我々の状況と照らし合わせてどのように判断したかを書き残してみます。
[選択肢1] ネイティブ
サーバーにAPIを生やして、Swiftで構築したアプリからAPIを呼び出してUIを構築する方針です。
今回参考にした事例の中にクラシコムさんのアプリがあり、iOSアプリ開発についての事例を公開していただいています。EC+メディアというビジネスモデルや、社内の開発チームがWebメインだったことなど我々と環境が近かったこともあり、技術構成など大いに参考にさせていただきました。
こちらの事例にならい、我々もネイティブ＋オフショア開発を検討したのですが、結果的には見送る形となりました。
判断理由としては、我々の状況からすると開発規模が大きくなりすぎるという点です。アプリ部を外部に委託できたとしても各種APIの開発は社内で行いますし、委託先とのコミュニケーションコストもけっして小さくはないだろうと想像しました。
また当社の場合、ビジネスを取り巻く環境も流動的で、それに合わせてアプリケーションの内部構造もこの先大きく変化していくだろうと考えています。そのような状況に引っ張られてAPIの構成を保つことが難しくなることもありそうですし、そうなった場合のハンドリングが困難との判断も見送りの1つの要因となりました。
[選択肢2] クロスプラットフォーム
FlutterやReact Nativeといったクロスプラットフォームを使って社内の開発チームでアプリを内製する方向性です。
当社の開発チームにはプライベートでFlutter等を触ったことがある方はおりましたが、業務でスマホアプリエンジニアを経験したことのある人はいませんでした。
将来的な開発自由度の高さは魅力的でしたが、開発リソースを大きく圧迫することは明らかだったのと、開発だけでなくApp Storeの審査対応や不具合対応のことまで考えると社内のノウハウ不足感は否めなく、早い段階で見送りになりました。
[選択肢3] WebViewメイン
いわゆるガワネイティブとも呼ばれている実装で、ガワとなるネイティブアプリからWebView経由でWebサイトを表示する方向性です。
検討開始時はYappliやアプセルなどといったアプリプラットフォームを利用しながらWebViewメインのアプリを構築するというのが最も有力な候補でした。社内のアプリ開発のノウハウが薄い中、経験ある方々にサポートいただけることの安心感も魅力的でした。
なお、我々も最終的にはWebViewメインで進める選択肢を選んだのですが、アプリプラットフォームは利用せずアプリの部分はパートナー企業にSwiftで開発していただくことにしました。
判断の理由としては次の通りです。
- WebViewメインでも我々がやりたいことの大部分は実現できそう
- まだ本当に軌道に乗るかどうかがわからないため大きなコストはかけられない。この方式であれば費用的＆開発的コストが比較的小さく、ほかの開発案件への影響も小さい
- 将来的に追加開発をしていく際、最初からガワの部分だけでも内製しておいたほうがスピーディーかつ柔軟に動けそう
- 以前から付き合いのあるパートナー企業のProximoさんがアプリ開発の広い知見をお持ちだった
もちろん本構成特有のデメリットもあるのですが、我々の状況を考えると最もベストに近いだろうという判断のもと、この構成を選択しました。
実装方針
ということで、技術スタックとしてはWebViewメインでガワの部分をSwiftで構築しようということとなりました（まずはiOSのみからスタート🍎）
上記で書いているように、アプリの部分のデザインおよび開発はパートナー企業にお願いし、当社ではサーバーサイド側の実装をすることとなりました。
急遽立ち上がったプロジェクトですので当然アプリ専任者はおらず、開発側PMは私、UIUX部についてはマーケ部所属のPMMの方にお願いしました。サーバーサイドの開発についてはすでに体制が整っているので特別変わったことはなく、タスク分解してスクラム開発に乗せていくだけでしたが、次の点は常に頭の片隅においておきました。
- デバイス種別ごとのUI最適化。WebViewとはいえ体験面では極力妥協しない
- とは言えまだ軌道に乗るか不透明なので、効果は薄い割に作るのが難しい機能は盛り込まない
相反する2つの要求なので、要はうまくバランスを取りながら進めたという感じです。
ちなみにプッシュ通知にはFirebase Cloud Messagingを採用しています。まずはiOSのみのスタートですしAPNsでもよかったのですが、当社は分析基盤にBigQueryを採用しており、FCMのイベントをBigQueryに自動で書き出せる機能が魅力的に感じたためです（振り返ってもこれは良い選択だったなと思っています）
実装するうえで苦労したこと
開発面においては比較的スムーズに事が運んだと思いますが、いくつか苦労したポイントがあったので書き残してみます。
[苦労ポイント1] Amazon Pay
開発する中で一番苦労したのはAmazon Payの部分です。レンティオではレンタルの注文にAmazon Payを利用でき、Amazonに登録しているクレジットカードやギフト券を使って支払いができます。ブラウザ版では、Amazonにログインして支払い方法を選択するために、レンティオのサイトからAmazonのドメインにリダイレクトし、選択後に再度レンティオのサイトにリダイレクトで戻ってくるといった挙動となっています。
しかし、それをWebViewで実装するとなった場合、すべてWKWebView内で完結させることはセキュリティ上の理由から推奨されておらず、AmazonのサイトをSFSafariViewで開く必要があり、WKWebViewとSFSafariViewの間のデータの受け渡しのためにネイティブの実装も必要となります。
サンプルや実装方法は細かく公開されており、Amazon社のサポートも充実していたため迷うことはなかったのですが、状態遷移にWKWebview、SFSafariView、ネイティブ層と多くの箇所が関わってくるため動作確認しながらの開発が困難でした。
結果的に社内の開発チームで対応できたのですが、このように状態遷移が複雑になると開発難易度がグッとあがるため、サーバーとネイティブ間の通信はREST APIに限るなど疎結合にしておくなど設計段階で考慮しておくことの重要性を再認識しました。
[苦労ポイント2] ウォーターフォールでの開発プロセス
サーバーサイドの開発は社内、ネイティブ側の開発は社外で行うという分担をしました。
ネイティブ部分の開発の流れとしては、まずは必要な機能を洗い出し一通りの仕様をスケジュールをFIX、そのあと一気に開発するウォーターフォールを採用しました。新規開発プロジェクトで社外パートナーとの共同開発案件になるため、アジャイルでなくウォーターフォールが自然と選択された感じです。
実際の開発プロジェクトのガントチャート
そんな中、プロジェクトを進める中で次のような課題がありました。
- 登場人物が多く、また普段と異なる役割の人も多かったことで、意思決定の所在が不明確だった
- これまでレンティオでは多少時間はかかっても良いものを出したり十分に議論することが多かったが、委託先エンジニアの稼働可能期間も決まっていたためスケジュールが厳格
- ネイティブ部はウォーターフォール、サーバーサイドはアジャイルでの開発が並行して動いていたことでPM的に噛み合わないことが多かった
このあたりはPMを務めた私の責任でしかないのですが、普段と違う開発プロセスということを最初にしっかりと意識してから臨んだらもっとスムーズにプロジェクトを進められたのではないかなと思います。
[苦労ポイント3] アプリ固有のお作法
当たり前ではあるのですが、これまでWeb開発ばかり手がけてきた人がアプリ開発をやろうとすると当然前提となる知識を覚える必要がありますし、今も特別詳しいというわけではありません。
たとえばWebViewにも種類があることを知りましたし、プッシュ通知サービスの選定をするうえでも、世の中にはどんな通知サービスがあってそれぞれどのような特徴を持っているかを調べるところから始まりました。
このあたりの知識が足りない部分はパートナー企業のProximoさんにフォローいただいたり、アプリ開発を生業としている友人に教えてもらったりしながら勉強したのですが、独学だったらもっと時間がかかっていただろうなあと思います。こんな状況でもアプリを予定通りリリースできたのは社内外を問わず関係者の皆様の力あってのものと考えており、たいへん感謝しています🙇🏻
反省と今後の方向性
あらためて振り返ってみると、WebViewメインの構成を選択したのは悪くない選択だったと思います。社内の開発体制やノウハウを活かすことができますし、節約できたリソースをほかの重要案件に回すことができたためです。結果的にアプリの開発期間中もほかの重要開発案件を継続して動かすことができました（それでもやはりそれなりにリソースは圧迫されましたが）
とはいえ冒頭にあげていたよりよい体験を提供するには、WebViewよりもネイティブのほうが取れる打ち手の種類も豊富になるため、ネイティブの機能を活用できるよう優先度の高い部分からアップデートを重ねてゆきたいと考えています。
一方で課題をあげるとしたら、何もないところからのアプリ構築だったこともあり十分な運営体制がまだできていないことでしょうか。アプリ専任のPMやSwiftエンジニアもまだ社内にはいない状態です。またAndroidも初回は見送りましたが、準備やノウハウが整い次第開発を進めてゆきたいと考えています。
おわりに
さて、文中でも書いたとおりレンティオのアプリはWebサイトと比べて非常に歴史が浅く、専任のエンジニアも専任のPdMも現状おりません。
が、レンティオとしてはアプリを戦略上重要なプロダクトとして位置付けており、さらに使いやすいアプリを目指して今後も機能改善とそのための体制構築に温度感高く取り組んでゆく所存です。
そんなレンティオのアプリを我々と一緒に1から育ててくださる方を募集しています。もし興味をお持ちいただけたらご応募を検討いただけますとうれしいです！
Discussion