メルカリグループで働くソフトウェアエンジニアに、ちょこっとお話を聞いていく本シリーズ。第50回は、メルペイiOSエンジニアの@kenmazと@takeshiが登場します。

なぜこの2人？実は、9月19日〜21日に開催される、iOSと周辺技術を題材としたカンファレンス「iOSDC Japan 2020」（以下iOSDC）に採択され、登壇が決まったのです！！気になる発表内容について、さっそく立ち話しました。

今回の聞き手は、同じくiOSエンジニアの@stamaki。なのですが、冒頭から少し緊張気味です。それには、このご時世ならではの理由があり…！

※メルカリはiOSDC Japan 2020に協賛しています。

オンライン入社メンバーの「お話いいですか？」

@stamaki：@kenmazさん、@takeshiさん、お疲れさまです！ちょっと、お2人ともお忙しいところアレなのですが…………。

@kenmaz・@takeshi：？？

@stamaki：………………………………………………………………………………
………………………………………………………………………
………………………………………ちょっと、お話いいでしょうか？

@kenmaz：はい、もちろんです！

@takeshi：僕ももちろんいいんですけど。@stamakiさん、なんか緊張してません？（笑）

@stamaki：だって僕、2020年3月にOrigamiからメルペイへ入社したばかりなんですよね。新型コロナウイルスの影響による原則在宅勤務が始まっていたこともあり、誰にも直接会うことなくオンライン入社していて…。だいぶ慣れてきましたが、お2人とはまだちゃんとお会いしていない気がして（笑）。

@kenmaz：@stamakiさんのように、オンライン入社したメンバーは直接会って話す機会がほとんどないですもんね。今日は、@stamakiさんが気になっていることを立ち話していきましょう！

@stamaki：そうですね！「エンジニアと立ち話」というタイトルのわりには、@kenmazさんだけ座っている感じですけど、気にせずいきましょう！！さっそくですが、入社時期やメルペイでの仕事を教えてください。

@kenmaz：メルペイiOSエンジニアの@kenmazです。入社したのは、2018年6月。当時からメルペイの銀行接続やiD決済、コード決済周りのほか、「使えるお店」という地図の機能を開発。最近では、売上金を送ったり受け取ったりできる「おくる・もらう」機能を担当していました。

@takeshi：同じくメルペイiOSエンジニアの@takeshiです。2019年1月から、メルペイへジョインしました。当時は、Dashboardチームでメルペイ画面を開発。今は、UIテストを導入するプロジェクトなどしています。

メルペイiOS開発が、Xcode Previewに出会ったきっかけ

@stamaki：今日、@kenmazさんと@takeshiさんにお声がけしたのは、お2人とも9月19日〜21日にオンライン開催されるiOSDCに採択され、登壇するためです。講演テーマは、いずれもメルペイ開発内での課題から発展したものだと思うので、そのあたりも含めてお話を聞きたいのです！

@kenmaz：僕はXcode Previewを使ってUIKitベースのアプリ開発を効率化させる方法について、メルペイでの事例を交えて話す予定です。

そもそもメルペイでXcode Previewを導入するに至った経緯には、ちょっとした裏話がありまして。2019年秋ごろからメルカリグループ全体でDesign Systemライブラリという全社共通のUIライブラリのようなものを使ってアプリの画面デザインを統一していこう、という動きがありました。僕はメルペイ代表としてDesign Systemをメルペイに導入する作業を担当していたんですが、ちょっとそこで作業が難航しちゃったんですよね。

というのも、メルペイのiOSチームでは、基本的にInterface Builder（以下IB）を使って画面を構築する設計にしていました。しかし一方で、Design Systemライブラリのほうはコードで画面を構築する設計になっていたんです。つまり、Design Systemをメルペイに導入するには、メルペイ側の設計を変更しないといけない。

@stamaki：板挟みだ。

@kenmaz：画面の開発はコードで記述した方がより柔軟に実装できるんですが、実際の表示を確認するにはいちいちアプリを起動しないといけないのが何より効率が悪い。メルペイが従来から使ってきたIBであれば実際の表示結果を見ながら開発できていたので、純粋に開発効率が下がっちゃうんですよね。ここをなんとか解決したかった。

どうしようかなと考えていたとき、SwiftUIのXcode PreviewがUIKitベースのアプリの開発にも使える、ということに気がつきました。Xcode Previewが使えるのであれば、コードで画面を構築する場合のデメリットであった「実際の表示を確認するにはいちいちアプリを起動しないといけない」という問題も解決します。さらにXcode Previewを使えばビューのさまざまな状態をPreview上で一括で確認できるので、むしろこれまでの開発手法よりも効率がいい。SwiftUIアプリの開発スタイルをUIKitアプリ開発にも適用できる、っていうことですね。これを発見できたとき、チーム内では結構盛り上がりましたね。この件は、TechBlogにも書きました。

@stamaki：確かに、IBでは特定の状態ごとに画面レイアウトを確認しづらいところがあります。そのためいろんな状態を確認したければ実際にアプリを操作する必要がありましたよね。さらにいうと、端末によって見え方も異なったりして…。

@kenmaz：ですよね。画面サイズ、ダークモード、文字サイズの設定の違いによって見え方も異なります。そのような動作環境の違いもプレビュー画面で一覧で確認できるので「こういう状態だったらこう見る」が比較できるところもいい。おかげで、デザイナーとも「こんなパターンがある」とすぐやりとりできますし、開発に関わっていないエンジニアも、コードを見なくてもだいたいの仕様を把握できるようになりました。

UIテストの導入は「辛いよ」

@stamaki：@takeshiさんは？

@takeshi：私は「XCUITestのつらさを乗り越えて、iOSアプリにUITestを導入する」というタイトルで発表予定です。

@stamaki：タイトルから何かにじみ出てる（笑）。

@takeshi：いやいやいや、UIテストを導入するのは本当に大変なんですよ！かくいう私も、以前UIテストをつくって導入したことがあるんですけれど、2〜3ヶ月ほど放置してしまって、再び立ち上げてみたらUIがすべて変わっていて「もう嫌だぁ！」となった過去があります。

@takeshi：でも、メルペイの開発ではQAテストの工数が逼迫し始め、UIテストの重要性が高まっています。そしてちょうど、メルペイでUIテストを自動化したいね、という話で盛り上がっていたこともあり…。そこで、半年ほどかけてUIテストを導入したのです。もちろん過去の経験を踏まえて、継続的に運用できるような仕組みにしています。

@stamaki：タイトルどおり「辛さを乗り越えて」だったんですね。

@takeshi：メルカリでは、すでにUIテストが導入されていました。XCUITestでつくられています。それに習って、メルペイでもXCUITestでUIテストをつくり始めた感じです。

UIテストの運用という意味では、CIの導入が一番の鍵ですね。メルカリ・メルペイではCircleCIを利用しています。ローカルですと、どうしてもたまにしか実行できないのですが、CIでは定期的に実行できるので「このテストいつの間にか壊れてる！直さなきゃ！」がすぐにわかるようになりました。

@stamaki：UIテストに関わらず、単体テストなども含めて修正が必要なテストを放置していると、割れ窓理論のように悪い循環ができてしまう。だからこそ、テストが壊れたことに気付ける仕組みが必要になりますよね。

@takeshi：ですね。UIテストの施策検証は、まさにこれから。今のところ、QAテスト300件中、40件は自動化できました。

「導入して終わり」じゃない現実も伝えたい

@stamaki：お2人が発表する内容はまだ発展途上なわけで、これからも改善を重ねながら開発を進めていくんですよね？

@kenmaz：実務に結びつくかどうかは、大事ですよね。僕も@takeshiさんも、業務のなかで気づいたこと、課題に思ったことが発表内容の起点になっています。今回、僕の発表は「Xcode Preview」を少し深堀りした内容になりますが、他にも、先ほどちょっと話に出てきた「Design System」など興味深い技術がいろいろ使われているので、どんどん社外に発信していきたいですね。

@takeshi：私の場合は、過去にUIテストをつくったものの、数カ月後に動かなくなってしまった経験があるので。「導入する」だけではなく、「きっちり運用する」ところまでやり遂げたいですね。

@stamaki：なるほど。今日はありがとうございました！