PROFILE
平川 裕多
楽楽精算開発部 モバイル開発課
2021年にもっと技術力の高い会社を探しており、カンファレンスなどでも当時社名が耳に入ってきていたラクスに応募。その後期待を裏切られることなく、現在はiOSアプリのエンジニアとして主に実装やコードレビューを担当している。モバイルアプリエンジニアになる前は料理人を２年ほどやっていたのもあり休日は趣味で料理を作ってます。
平川さんが関わっているプロダクトを紹介いただけますか？
「楽楽精算」モバイルアプリと「楽楽精算ICカードリーダー」のiOSアプリに関わっています。
「楽楽精算」モバイルアプリは経費精算データの作成・申請・承認ができます。それ以外にも承認依頼等が発生した際にプッシュ通知で素早く対応できるため業務の進行がスムーズになります。特に強力な機能としてはカメラ機能を用いて領収書読み取りを行い金額などを自動入力します。取り込んだ領収書データは経費申請に利用することが可能です。これらの機能により経費精算の精度と効率が向上します。
「楽楽精算ICカードリーダー」は交通系ICカードを専用アプリにかざして送信するだけで交通費データが自動で取り込まれ、交通費申請のプロセスが簡素化されます。手入力する作業と比べて時間の削減が可能です。
楽楽精算開発体制でのモバイル開発の位置づけについて教えてください。
楽楽精算はモバイル用のWebページ版も用意されており、アプリが無くてもモバイルのブラウザから利用可能ですが、モバイル特有の機能を利用した利便性の提供ができます。例えばプッシュ通知、領収書撮影、ICリーダー読み取りなどです。そのような機能をアプリに持たせることで経費精算に素早く対応することができます。モバイルを利用する顧客も多いため楽楽精算体制の位置づけとしても重要な役割を担ってます。
これからのロードマップとしては細かい改善を行いながら、さらにユーザーインターフェースの最適化や品質強化も積極的に進めており、使い勝手と安全性を両立させながら進めて、顧客に利用して頂けるようなアプリを目指して日々励んでいます。
どんな組織体制で、どのように開発を進めているのでしょうか。
マネージャー・テックリードのリーダー３名と開発メンバー４名の体制になっています。このチームでモバイルに関わるサーバ側とiOS、Androidアプリの開発に対応しています。
iOSチームはリーダー１名と、メンバーは開発規模により変動するのですが２〜３名になっています。最近新たなiOSエンジニアの方がジョインして頂けたため１名増えています。
私の立ち位置としてはiOSの開発メンバーとして対応しており、開発前の調査や設計書作成から実装、テスト、アプリリリースに関することまで一通りやっています。他のメンバーが作成した資料やコードのレビューなども行います。また必要に応じてサーバやAndroidアプリの設計書作成やテスト、レビューに参加することもあります。
今回は「品質」をテーマに事例を紹介していただきますが、モバイル開発課の品質への考え方を教えてください。
チームとして重視しているのは、根本的な品質改善につながる対応を実直に追求することです。
例えば対応Aは時間がかからずに対応可能だが、対応方法に関する明確な根拠が無い、ただし試したら要件を満たせることを確認済み。対応Bは時間はかかるが情報源も公式の情報からのため根拠がありこの対応をすれば今後問題が発生する可能性は無い。そういった場合は対応Aは暫定対応として妥当でもない限りはすぐ対応できるとはいえ選択肢になりません。
また課題や問題があった場合も対処方法を素早く決めて進めるのではなく、原因を特定して対応方針を２〜３案出してから一番プロダクトにとって良い案を選択します。あとは定期的に良かった事や悪かった事を振り返りながら品質課題となるものは優先度を決めて対処して行っています。
今回取り組んだ事例をご紹介いただけますか？
レガシーな非同期処理をSwift Concurrencyへ移行したことをお話します。
従来iOSでの非同期処理は理解しづらいコードでしたが、Swift5.5からSwift Concurrencyが導入され非同期処理が簡潔に安全に書けるようになりました。
iOSのアプリ開発ではOSSの非同期ライブラリを利用して非同期処理が書かれていましたが、公式からSwift Concurrency等が出てきた頃から更新が止まっており、このままEOLになる可能性が高まったことがSwift Concurrencyへの移行のきっかけです。
もちろんEOL対応は必須ですが、実はそれ以上の内部改善の狙いがあったのですよね。
更新されていないOSSを利用することは品質上のリスクを伴い、EOL対応は当然必要です。Swift Concurrencyは公式に提供されているため、OSSに比べてサポート終了（EOL）のリスクが低いです。
ただ、大きな狙いは移行によって可読性・保守性を改善し、生産性を向上させ、素早く顧客価値を提供できるようにすることでした。
非同期ライブラリの機能はSwiftでPromiseを実装したものですが、Swift Concurrencyと比較して非同期ライブラリは扱いにくいという問題があり、今回のEOLは良い改善のタイミングでした。
今後大きな機能開発を控えており、そこでも非同期処理は多く記載する必要が出てきます。このまま非同期ライブラリを利用して開発すると、外すタイミングを逃し、アプリのリニューアルなど相当大きな対応をしない限り根本的な改善が不可能になるリスクがありました。
API通信に関する箇所に関してはかなり昔のコードから最近のものまで非同期ライブラリによって記載されており、コードの一貫性を考えると昔のコードも考慮して対応していく必要があるためです。
さらに非同期ライブラリは必要な知識が相対的に多いため、モバイルチームを大きくしていく上でも一つのハードルでした。
具体的にはどのように進めていったのでしょうか。
楽楽精算に比べて非同期ライブラリの影響が少ないICリーダーアプリの方から着手しました。
まず非同期ライブラリがimportされているクラスを洗い出しました。その結果主にAPI通信で利用されていたため、APIの共通処理部分と1つのAPI処理をスコープにPoCを作成し、問題なく動作することを確認しました。その際に元の共通処理は残したまま、同じ動作をするSwift Concurrencyで記載した関数を用意して、APIはそちらを呼び出すようにしました。
洗い出した一覧を元にスコープ分割を行い、PoCのコードを横展開しつつ動作確認をして１つずつ進めて行きました。そして全て対応出来たら残しておいた旧共通処理を削除して実装は完了になります。
その知見を楽楽精算アプリでも活かして、新しく開発する箇所はSwift Concurrencyを利用して記載するようにしています。並行して既存の非同期ライブラリ部分を移行する改善も進めています。
移行の際に工夫したことや、実装時に大変だったことはありますか？
前述しました通り非同期処理はAPI通信などの非常に重要な処理を担っており、こちらに手を入れるということで一つの実装で正常系と全ての異常系が既存と同じくハンドリング出来ていることをチェックリストにして漏れが無いように工夫しています。
大変だったことはSwift Concurrencyも最初に覚えなければいけないことのボリュームが想定以上にあり、それを実装に落とし込むのに苦労しました。Swift Concurrencyはasync/awaitだけではなく、ActorやSendableの知識も必要になるので慣れていないメンバーには分かりづらい点ですが、そこは先行して対応しているメンバーが徐々に伝えて行ければと思っております。
実装してみて、メリットは感じられましたか？
今回の移行によって、直感的なコードになるので実装が楽になりました。何よりコードレビューがしやすいです。
今後の展望を教えてください。
今後も顧客の課題解決に向けて機能開発や改善に取り組みたいです。今回のようなSwift Concurrency移行を行うことでより安全で効率的な開発を行えるため、結果として顧客への体験向上に繋がっていきます。
今後も平行して開発上の課題に対して技術面で最適な解決をするために、日々チームで情報共有しながらカンファレンス等に参加して技術キャッチアップを進め、チームの能力向上にも注力してプロジェクトの成功を目指します。
また今回得た知見から新しい技術やアーキテクチャに載せ替えていく対応もよりスムーズに進めることが可能になりました。これは大きな前進であり、これを機に新しい挑戦をもっと進めていきたいと思っています。
