こんにちは、Androidエンジニアのn-sekiです。STORES 決済の開発を行っています。 本記事では、先月リリースした「タッチ決済」について、我々モバイルチームがどのように対応を進めていったのかを振り返ってみようと思います。
はじめに
2022年5月11日、 STORES 決済は「タッチ決済」に対応したアプリをリリースしました！
接触の方法（ICチップを読み込ませる or カードをスワイプする方法）と比較するとカードをタッチする操作はかんたんであるだけでなく、決済端末（注: クレジットカードリーダーのこと）に触れる必要もないため、昨今の生活様式にもマッチした決済方法と言えるかと思います。
仕様的な観点では、既存の接触決済と似ている部分もありますが、タッチ決済独自の仕様も多く存在します。
実は STORES 決済に新たな決済手段が加わったのは久しぶりのことで、モバイルチームの多くのメンバーにとっては「決済手段の追加」は初めての経験でした。
クレジットカード決済という巨大な仕様に初めて向き合うメンバーが多い中で、いかにして仕様に対する解像度を上げて対応していったのか。私が所属するモバイルチームの観点から振り返るのが本記事です。
以前からの課題
モバイルチーム内では「決済や決済端末の知識・情報が属人化しがちである」という課題が以前より存在していました。今は少しづつ解消されつつある課題ですが、タッチ決済においても知識・情報の民主化を意識して立ち回ろうとしました（うまくできていたか......はチームメンバーの判断に委ねます）。
属人化と書きましたが、気がつくとチーム在籍期間が最長になっていて、決済・決済端末の仕様に比較的詳しくなっていた自分（n-seki）の頭の中から情報を外に出すことを強く意識しました。
検討期
「タッチ決済の導入は決まったが、具体的にどのような開発をすればいいか見えていない」状況から静かに調査と検証が始まりました。
STORES 決済のクレジットカード決済（の、とくにモバイルアプリ実装については）、利用している決済端末の仕様に大きく依存しているため、決済端末の仕様書を読むことが最優先でした。もちろん、必要があれば EMV*1 の膨大なドキュメントにもあたる必要があります。
進め方と工夫
今回は以下の進め方で仕様の調査検証を行っていきました。
- 仕様書を読み、必要があれば検証コードを書いたり、動作確認を行う（n-seki）
- 仕様の概要と、現在の STORES 決済の仕様に落とし込んだ仕様草案をドキュメント化する（n-seki）
- 決済モバイルチームメンバー、PdM、必要があれば他チームを巻き込んでミーティングを行ない、情報の共有と仕様の議論を行う
- ミーティングで決まった内容をベースに細かい部分を調整しながら仕様やUIを決めていく
- この流れを大きな機能ベースで何度か行ない、タッチ決済全体の仕様を固めていく
ねらい
決済／決済端末の仕様に比較的詳しい自分がまず仕様書にあたって要点をまとめることで、調査・検証にかかるトータルコストを削減する目的と、ある程度整理した情報をチームに共有することで、決済の仕様に（楽に素早く）慣れ親しんでもらいたい、という意図がありました。
ここでは調査・検証の「結果」だけを提示するのはなく、できる限り関連する仕様書の該当部分を貼り付けるなどして「一次情報」の共有も意識して行ないました。「仕様書」にはそれぞれ固有の書式みたいなものがあると思っているのですが、それに触れてもらうことで、次に各自が仕様書を読むときのハードルが下がるといいな、と考えました。
これはこれで一長一短ある進め方だとは思うのですが、暗闇の中で全員が手探りで進むよりも先ず1人が道を見つけて、その道をチームで整備する流れは、今回のタッチ決済対応では有効だったと感じています。
結果として、タッチ決済の枠に留まらない情報のドキュメント化と共有ができたと思っています。
実装期
タッチ決済に関連する各機能について仕様がほぼ固まり、画面デザインも続々とあがってきて、アプリの実装に着手できる状況になりました。 決済のAndroidチームは私含め3人（1人は当時インターン生）という体制でした。
Androidチームの進め方と工夫
Androidチームでは以下の方針で決済処理のコアな部分の実装することにしました。
- チームメンバーの@Yamaton さんをメインの実装者とする
- 頻繁にオンラインでAndroid Studioを画面共有して、2人で議論しながら実装を進めていく
- n-seki は主にレビューに回る
ねらい
前述の通り、仕様の検討では私が中心となって動いていました。仕様を最も理解している（はずの）私がレビュワーとなり、しばしばオンラインで議論をすることで決済に関する情報・知識の均一化を意識した実装体制をとってみました。
ペアプログラミングのような進め方はお互いに初めての経験でした。「仕様を実装に落とし込む」という1人でプログラミングしているとなかなか言語化する機会のないプロセスを2人で協同して行う難しさを感じる一方で、その場ですぐフィードバックを得られ、議論・修正が行える点にメリットを感じました。
リリース後の振り返りでYamatonさんからも「設計者と実装者を別人が担当することで実装時に仕様の議論ができた」とポジティブなフィードバックもいただけて、やってよかったなと思いました。
今回のタッチ決済の実装に関わらず、オンラインでの相談・壁打ちはチーム内では比較的頻繁に行われています。
また、一部の機能については当時インターン生だった @みっちゃん にも実装してもらったりもしました。
iOSチームとの協同
実装をしていると、Android/iOSのチーム間で「○○の実装についてAndroid/iOSではどうしていますか？」という質問・議論が何度か発生しました。
タッチ決済はOS間の機能差分はほぼないため「実装してみるとこの仕様は実現が難しいかもしれない」「この情報は共有しないとまずそう」と気が付いたタイミングで自発的にコミュニケーションが行われていました。
仕様の検討期において私が見落としていた点・詰めきれていなかった点が明るみになることもあり、それはそれで反省点なのですが、自ら問題提起して仕様の議論・方針決定までもっていける優秀なメンバーと開発ができて嬉しい気持ちにもなりました。
QA、そしてリリース
弊社の優秀なQAチームによるQA期間を経て、アプリがリリースできる準備が整いました。 リリースについてはPdMの id:acamalu さんが緻密なスケジュールを計画してくれたおかげで、モバイルチームは早めに審査提出を行ない、当日は公開ボタンのクリックを待つだけでした。
リリースプランについては id:acamalu さんが記事を書かれているので、そちらもぜひ読んでみてください。
リリース後、タッチ決済は安定して稼働してくれているようです。 長いプロジェクトだったこともあり個人的にはとても達成感のあるリリースとなりました。
さいごに
属人化をなるべく回避しつつ、チーム全体として複雑な仕様の解像度をどのように上げていったのかを書いてみました。 モバイルの技術に全く言及しない記事になってしまいましたが、チーム内の雰囲気なんかが伝わると幸いです。
こんなチームに興味のある方、クレジットカード決済にある方がいらっしゃれば下記ページをご覧ください！
