簡単にお店にキャッシュレス決済を導入できるサービス「STORES 決済」。決済という高い信頼性を求められるサービスにおいて、どのようにAndroidアプリを開発し、オーナーさんたちのお商売を支えているのか。その工夫をご紹介します。
わたしたちheyは、「Just for Fun」をミッションに、こだわりや情熱、たのしみによって駆動される経済の発展を支援しており、ネットショップ開設、POSレジ、キャッシュレス決済、オンライン予約システムなど、お商売のデジタル化を支援する「STORES プラットフォーム」を展開しています。
本記事では、その中でも簡単にお店にキャッシュレス決済を導入できるサービス「STORES 決済」について紹介します。決済という高い信頼性を求められるサービスにおいて、どのようにAndroidアプリを開発し、オーナーさんたちのお商売を支えているのか。その工夫を、一部ではありますがぜひ知っていただければと思います。
STORES 決済について
STORES 決済（ストアーズ 決済）は、お店の方（オーナーさん）向けのキャッシュレス決済サービスです。クレジットカード、電子マネー、QRコード決済に対応しており、インターネット環境があれば、屋内外問わず、いつでも、どこでも、誰でもかんたんに使えるモバイルアプリを提供しています。
また、アプリと同等の決済機能を備えた「STORES 決済 SDK」も公開しており、各ベンダーさまがSDKをアプリに組み込むことで、かんたんにキャッシュレス決済機能をアプリに導入することができます。
決済という性質上アプリとして安定性を重視するのは当然ではありますが、それと同じくらい「かんたんに」使えることを意識して開発を行っています。後述するVoice of Customer（VOC）起点のアプリ改善も、オーナーさんの業務をより快適にすることを目的とした、heyらしい開発と言えるでしょう。
Androidアプリのアーキテクチャと採用技術
次に、STORES 決済のAndroidアプリのアーキテクチャと採用技術をご紹介します。
アーキテクチャ
状態管理が複雑な決済機能などの例外はありますが、全体としてはAndroid DeveloperのGuide to app architectureで解説されている設計を踏襲しています。
異なる点は、UseCaseを設けていることです。データ層ではRepositoryパターンを用いてAPI通信、永続化などの処理を隠ぺいし、取得したデータは各UseCaseを介してUI層に渡しています。UI層ではViewModelでUIの状態を管理し、Viewを更新しています。ただし、DataBindingは利用していません。
Guide to app architectureより引用
採用技術
API通信ではRetrofitを、永続化処理にはAndroid Architecture Components（AAC）のRoomを使っています。各レイヤーの接続にはRxJavaを利用してきましたが、少しずつKotlin Coroutinesへの移行を進めています。UI層ではAACのViewModelとLiveDataを、またDependency InjectionのライブラリとしてDaggerを、それぞれ利用しています。
Bluetoothでカードリーダー端末やプリンターと通信を行っている点が、アプリの技術的な特徴です。端末との通信処理の一部では、C++で実装された社内ライブラリをiOSアプリと共同で利用しています。
STORES 決済（当時はCoiney）は2013年から稼働している歴史が長いアプリということもあり、設計上の課題はいくつかありますが、その中でも一部処理においてレイヤー間のやりとりにBroadcastが使われていることが大きな課題となっています。アプリ実装当初からの設計ではあるのですが、現在Kotlin CoroutinesのFlowによる設計変更を検討しています。
使用言語は現在KotlinとJavaが半々といったところではあるものの、Kotlinの比率が上がってきています。
BitriseというCIツールおよびDangerを利用し、Firebase App Distributionによるアプリの社内配信やPull Request時のlintチェックなどのCI/CD環境を整えています。
lintだけではなくこのような警告もコメントしています
開発事例の紹介
ここで、わたしたちが普段どのようにプロダクト開発をしているかを知っていただくため、「入金詳細」という機能が実装されたプロセスを紹介します。
オーナーさんの要望をCSチームがキャッチアップ
日頃からオーナーさん（お客さま）と直接やりとりをしているカスタマーサクセス（CS）チームの人たちが、その中でキャッチアップしたオーナーさんの困りごとや要望を積み立ててくれています。その内容を熱のこもったプレゼン資料にして、これが解決するとオーナーさんがどれだけ便利にご利用いただけるかを教えてくれます。
CSチームが管理している要望一覧
要望をもとに提案された改善案
開発チーム総出で相談
開発チームのプロダクトマネージャー（PM）、デザイナー、バックエンドエンジニア、iOSエンジニア、Androidエンジニア、QAエンジニア、メンバー総出でCSチームからプレゼンされた内容を実装機能に落とし込むために相談します。
まずはPMが要件をまとめて、それに対してデザイナーが素案を作ります。そして、開発チームの各職能が集まり、その素案をもとに機能として実装する際の実現性、メリット・デメリットを話し合います。
実装する機能を議論した際の資料
話し合いを経て「入金詳細」に関しては、
- CSチームからの要望はWebの入金詳細へのリンク設置
- これまで最低限の情報をシンプルにリスト表示していた
- オーナーさんにとって現状は「最低限の情報」に達していなかった
と判断して、詳細な情報をリストとして表示することになりました。
そして実装
いざ実装ですが、実際に手を動かしてみると解決が必要な課題や疑問点が出てくるのはどんな開発現場でも同じでしょう。heyでは、こうしたハードルに直面したときでも素早く解決できるよう、職域を超えたコミュニケーションがスムーズに行われています。
Androidエンジニアからデザイナーへの質問
iOSエンジニアからフロントエンドエンジニアへの質問
課題を解決し、疑問点を解消して実装を終えたら、GitHubでPull Requestを作成し、レビューしてもらいます。一般的なレビュープロセスを経て実装した機能は、プロダクトコードにマージされます。
QA、リリース
先にも少し書きましたが、STORES 決済チームにはQAエンジニアがいます。機能要件を相談する段階から参加していて、リリース予定の機能を含んだアプリの品質担保をしています。
品質担保に用いるテストケースは、リリース予定の機能を分析して設計しており、この分析と設計したテストケースの両方をモバイルエンジニア、QAエンジニアでレビューしています。
QAエンジニアが居てくれるだけでも安心して開発できますが、分析と設計の段階でモバイルエンジニアも参加するので、さらにもう一段階、安心の度合いが上がります。お金のやりとりを行うプロダクトなので、できるだけ多くの目でチェックすることで、大きな問題が発生しないようにしています。
こうして品質が担保されたアプリが、Google PlayストアまたはApp Storeを通じてオーナーさんの手元に届き、今日もお商売をサポートしています。
決済サービスの難しさとオンボーディングの工夫
決済という分野は専門用語も多く、慣れていない人にとっては社内で話されていることがすんなりと理解できない、ということがありえます。
ここではSTORES 決済として決済のドメイン知識にどのように向き合っているかや、オンボーディング時の工夫を紹介します。
決済の知識に触れる
上述したように、クレジットカード決済ひとつとってみても専門用語が多く、またその標準仕様の情報量は膨大なものになります。さらに、カードリーダー端末の仕様も別途存在しており、モバイルエンジニアとしてもこれら仕様書と向き合う機会がたびたびあります。
開発時に頻繁に参照する情報については社内ドキュメント化することで、必要な情報へのアクセシビリティを高めています。開発チームに閉じない決済全体の共有知として「用語集」というドキュメントが存在し、決済にまつわるさまざまな用語が解説されています。
また、決済が絡むプロジェクトではチーム内での情報共有会が実施されたり、チームをまたいだ勉強会も開催されるなど、ドメイン知識に触れる機会が増えるような工夫をしています。
オンボーディング記事
STORES 決済の開発チームでは、新しく入ったメンバーにも可能な限り素早く環境に慣れて存分にバリューを発揮してもらいたいと考えています。全社的にもオンボーディングへの意識は高く、オンボーディングに関するさまざまなドキュメントや仕組みが存在します。
たとえば、新たにジョインされるメンバー専用のオンボーディング用記事が作成されます。ここには利用ツールのアカウント作成方法やコードリポジトリへのリンクなど、開発に必要な情報がリンクされていて、この記事をハブにすることでさまざまな情報にアクセスできます。
この記事の執筆者の1人山本さん用の記事
上述した決済に関わるドキュメントのうちいくつかをオンボーディング用記事からリンクし、ジョイン後の早いタイミングで一読してもらいます。ざっくりと決済に関する用語や仕様に触れてもらうことで、将来課題に直面した際のヒントになればと考えています。
Androidアプリ開発にスムーズに入ってもらうための工夫
Android開発の観点では、アーキテクチャや一部の特殊な実装についてドキュメントが充実しているほか、既存メンバーとのペアレビューを実施してアプリの作りを俯瞰してみる時間を設けたり、ペアプログラミングや実装相談などを気軽に行える環境を作っています。
また入社してからの1ヶ月間、新メンバーとチームリーダーが毎日1 on 1をする時間を設けています。課題や困りごとの相談もそうですが、日々雑談などのコミュニケーションをとることを目的としています。
おわりに
以上、Androidアプリの現状と機能の開発事例を通してSTORES 決済を紹介しました。STORES 決済をより良いプロダクトにしていくために改善すべきところはまだまだあります。
- Broadcastを使った実装の排除
- Jetpack Composeの導入
- UIテストの自動化など品質と開発スピードを上げるための取り組み
これらのことをスピード感をもって取り組み、オーナーさんに届けていくために、さらなるメンバーを必要としています。興味のある方はぜひご応募ください。
著者紹介
上関 直人 / @n_seki_
3年ほど前にコイニーという会社に入社しましたが、気がつくとヘイが弊社になっていました。だいたいいつもヘッドフォンで音楽を聞きながらコードを書いているか、仕様書（英語）を読んで険しい顔をしています。趣味で少しHaskellを勉強中。
山本 慶 / @day_craft
息子二人、妻、猫と暮らすAndroidアプリエンジニア。プログラマ志望で新卒入社した中小ITがテスターの案件しか受注できず退職。貯金を切り崩しながら独学でAndroidアプリ開発を学び、2度目の転職でheyへ入社。子育てしながらどうやって勉強時間を捻出するかが目下の課題。
