STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

hey3ヶ月生による STORES 決済 モバイルアプリチームのご紹介!後編

heyに入社して3ヶ月になりました、iOSアプリエンジニア・ととです。 heyのモバイルエンジニアってどんなことをしているのか、というお話を前編・後編に分けて書いています。 前編では、わたしが STORES モバイル本部決済グループで、エンジニアとして立ち上がるまでのお話を書きました。 今回は、STORES 決済 モバイルアプリの開発体制やiOSアプリ開発における採用技術についてご紹介します。

開発体制

f:id:totokit4:20211223150039j:plain

STORES 決済 モバイルチームには、iOS3名、Android2名+インターン1名が在籍しています。 ほぼフルリモートで開発をしており、なんとインターン生は大阪から参画しています。 チームにはお子さんのいるパパが2名おり、子どもの事情で早めに仕事を始めたり上がったり柔軟に仕事をしています。 (写真は STORES レジ のエンジニアもいます)

iOSアプリの開発言語と主要フレームワーク

STORES 決済 (当時はCoiney)は2013年から稼働している歴史が長いアプリでして、元々はObjective-Cで書かれたアプリでした。 2年前からフルスクラッチでのSwift化プロジェクトがスタートしていて、近々リリース予定です。 新規開発はSwiftで実装しています。 その際のリファクタリング手法はiOSDC Japan 2021に寄稿した記事をiOSアプリエンジニアが寄稿しておりますので、宜しければご参照ください。

iOSDC2021にて公開した「約3年続くリファクタリングを引き継いで見えたテクニック」のご紹介 - hey Product Blog

iOSアプリのアーキテクチャ

Clean Swiftを採用しています。 元々はMVCを採用しており、コードが肥大化が課題となっていたので、Clean Swiftを導入して改善しました。

CI/CD

f:id:totokit4:20211223150122p:plain

Bitrise

毎日のビルド、テスト、デプロイに利用しています。

Fastlane

テストやDangerの実行、App Store Connectへのアップロードの自動化のために利用しています。

Danger

プルリクエストのレビュアーの負担削減のため、静的チェックを任せています。

TestFlight

QAチームへのテストの配布にTestFlightを利用しています。

開発フロー

要件検討

プロダクトマネージャー(PM)、デザイナー、バックエンドエンジニア、iOSアプリエンジニア、Androidアプリエンジニア、QAエンジニアで要件を決めていきます。

f:id:totokit4:20220107104641p:plain 会議は基本的にオンラインです。

前編で書いたように、改修内容に対してエンジニアも「実現可/不可」だけでなく「ユーザーにとってはこっちの方が良いのではないか」という提案することもあります。

設計実装

コード書いてる途中で方針や仕様に悩んだら、SlackやGitHubのコメント、Google Meetで気軽に相談できます。 相談相手は、同じiOSエンジニアやAndroidエンジニアにとどまることもあれば、PMやデザイナー、QAエンジニアまで様々です。

コードレビュー

お馴染みGitHubでプルリクエストを出します。 プルリクエストにはテンプレートで、Issueのリンク、対応内容、動作確認内容を書くように促しています。 f:id:totokit4:20220105172351p:plain レビュアーは、書かれた情報を元にレビューをします。 マージの条件は、以下のようになっています。

  • 1人以上のapproved
  • 自動テストの成功
  • Lintのチェック

テスト

自動テスト

自動テストを積極的に書くようにしています。 プルリクエストを出すと自動でBitriseのジョブが走り、自動テストが動くのですが、テストが成功しないとマージはできないようになっています。

QAエンジニアによるテスト

STORES 決済 チームにはQAエンジニアがいます。 先述の通り、テストの設計、スケジューリング、実施だけでなく、要件の検討から参加しています。 エンジニアが見逃していた仕様の穴に気付いていただくこともあり、QAエンジニアの方には頭が上がりません。 QAエンジニアの取り組みについてはこちらの記事をどうぞ。

より良い品質を作り上げるためにQAチームが取り組んでいること ~QAチームのワークショップ事情~ - hey Product Blog

ブランドテスト

決済サービスならではですが、カードブランドから提示されているテストがあります。 改修内容によっては、このテストをクリアする必要があります。 サービス提供には、各種ブランドにで決められているレギュレーションに準拠していなければならないので、改修を検討する時点で様々な要件を考慮しています。

技術課題

アーキテクチャ

現在、STORES 決済 iOSアプリには、状態を持つレイヤーがありません。 データの流れや責務はあるのですが、状態の不整合が起きやすい作りになっており、改善したいと考えています。 また、採用しているClean SwiftはInteractorクラスが肥大化しがちです。 こちらは今後、Workerクラスに処理を委譲していく予定です。

自動テスト

Unitテストは書かれているのですが、新機能追加したら必ず書く、みたいなルールは特に決まっていません。 今後もっとテストコード周りは整備していきたいと考えているので、テストコードを増やしていく文化を作っていこうとしています。 また、STORES 決済 では、決済端末(カードリーダー)やプリンターと接続して実現できる機能があります。 自動テストで、こういったハードウェアをモックして実機を使わなくてもテストができるようにして行きたいと考えています。

まとめ

f:id:totokit4:20220107104839j:plain わたしたちのサービスは、お金の関わる緊張感のあるシステム開発です。 でも、チームの雰囲気はとても和やかで、誰でもいつでも何でも相談ができる環境です。

今回はiOSに偏った話をしましたが、決済Androidチームについては2021年のDroidKaigiの記事や、他のプロダクトブログの記事に、Androidアプリエンジニアによる記事があります。 よろしければこちらもご参照ください!

採用情報

モバイルアプリエンジニアはもちろん、他のポジションも絶賛募集中です! カジュアル面談も可能ですので、以下からぜひご確認ください。

hey | エンジニア採用

書いた人

とと

  • iOSアプリエンジニア歴4年。hey歴3ヶ月。
  • 無事試用期間が3ヶ月で終わったので、ご褒美に高級な苺を食べることにしました。
  • Twitter: totokit4