STORES Product Blog

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

入社後の3ヶ月を振り返る

はじめに

STORES 予約 でモバイルアプリの開発を行なっているnekoと申します。

私は2022年の3月にheyに入社し、まもなく5ヶ月が経過しました。

STORES 予約 のモバイルアプリチームは、私が入社した時点ではエンジニアが1人しらおらず、私が入社して2人になりました。

さらにその時点で、翌月にはもう1人の入社が決まっており、当面はその3人で開発を進める体制に移行するというタイミングでした。

その中で、入社当初から今まで、メインの開発タスクと並行し、プロジェクト構成の変更や、CI/CD周りのフロー構築など、複数人でのチーム開発に移行する準備を進めてきました。

今回はその中で主だったものについて、概要を振り返っていきたいと思います。

プロジェクト構成の整備

まず、メインタスクとして保守運用を行っていた STORES 予約 のiOSアプリについて、プロジェクト設計の見直しを行いました。

既存のプロジェクトはPresentation層はMVVM構成を取りつつ、Data層やDomain層を持たずに、APIリクエストなどはViewModelから直接行っていました。

今後複数のエンジニアが同時に開発を行うようになるにあたり、下記2点を目的にレイヤードアーキテクチャーへの全体的な刷新を行いました。

・どこに何を記述すれば良いのか明確にする

・どこに何が書かれているのか推測しやすくする

構成としては特段変わったものではなく、Data層とDomain層を追加し、Data層の配下にAPIとRepositoryを、Domain層の配下にModelとTranslator、UseCaseを配置するようにしました。

APIやModel周りの実装を上記のレイヤー各所に配置し直すことで、それぞれの役割が明確化し、コード全体の見通しが良くなりました。

またリファクタリングするにあたっては、ViewModelに対してのユニットテストを導入し、リファクタリングによる不具合の発生防止を担保しました。

CI/CD環境の整備

CI/CD環境については、ツールとしてすでに Bitrise が導入されていたものの、しっかりとした運用ができておらず、あらためて必要なワークフローの整備と実行環境の構築を行いました。

また、すでにいくつかの処理が fastlane で書かれていたこともあり、追加分についても fastlane 側に処理を追加し、Bitrise から lane を実行する方向で進めました。

既存あったものも加え、最終的には以下のような処理は自動で実行できる仕組みになりました。

fastlane match を使った証明書の管理

Firebase App Distribution へのベータ版アップロード

・Test Flight へのベータ版アップロード *1

App Store Connect へのリリース版アップロード

ユニットテストの実行

・Firebase へのdSYMファイルのアップロード

また、ベータ版のアップロードやリリース処理、dSYMファイルのアップロードなどは、Slack のワークフローから Bitrise 経由で実行できるようにしました。

特にQA期間中などは、フィードバック箇所を修正し、再度ベータ版をアップロードする作業が頻繁に発生するため、Slack からコマンド1つで実行できる仕組みは非常に重宝しています。

コードフォーマットの整備

複数のエンジニアが開発に関わるにあたり、コーディングのぶれを少なくしたり、コードレビューをしやすくする目的で、フォーマット周りの整備も進めました。

フォーマットについては、すでに SwiftFormat が導入されていましたが、最小限のルール設定のみであったため、ルール全体の見直しを行いました。

また、あわせて SwiftLint も導入し、コーディングルールの統一を進めました。

Lint に関しては Danger を導入し、PR作成時にCI経由で監視する仕組みにしました。

フォーマットや Lint のルールについては、チーム内でディスカッションを行い決定しましたが、こうした議論を新しいメンバーが加わるタイミングで行うことは、チームビルディングの一環としてもよい体験だったかなと思います。

エラーハンドリングの整備

チーム化するにあたって進めたものとは少し方向性が異なりますが、API通信の失敗など、アプリにとって非致命的なエラーについて、ハンドリングが曖昧になっている箇所があったため、全体的な見直しを行いました。

必要なエラーはその内容をユーザに表示させるように処理を見直し、あわせて Firebase Crashlytics に送信するようにしました。

こうしたログは大きなエラーが発生する前触れを検知したり、ユーザ体験を見直す中で重要な情報となることがあると思っています。

また、新しくプロジェクトにジョインしたタイミングでこの辺りの処理を見ていくことは、プロジェクト全体の流れを掴むために非常に役立ったのではないかと思っています。

実際にこの見直しの中で、他にリファクタリングしたほうが良い箇所を見つけることもできました。

おわりに

やりたいことはまだまだ他にもあるのですが、スモールチーム化するにあたって、メインの開発タスクと並行しつつ、必要最低限の範囲で何が必要かを考えながら実行してきました。

今回はそれぞれ詳細な内容までは触れませんでしたが、機会があればそれらも記事にしていきたいと考えています。

STORES 予約 のモバイルアプリチームは、全員がiOSAndroidどちらも担当しており、技術スタックとしてはSwiftUIやJetpack Composeなど、モダンな技術を積極的に取り入れています。

今後はその辺りのノウハウも逐次発信していけたらと考えています。

*1:ベータ版アップロード先の Firebase App Distribution と Test Flight は、当初配布先に応じて使い分けていましたが、現在はすべて Test Flight に集約しています