# アプリの特徴
- ユーザー数：数千万
- 使用されている国：オーストラリア、カナダ、日本、マレーシア、フィリピン、EU、アメリカ、タイ、シンガポール、ベトナム、インド、インドネシア
- １つのプロジェクトで複数のブランドを管理している
- ブランドごとにスキームで管理している
- アパレルアプリ
# アプリの主な機能
### ホーム
- 商品の売れ行きランキングの表示
- 閲覧履歴からユーザーへのおすすめ商品の表示
- 期間限定商品、先行予約商品、値下げ商品の表示
- 特定の商品の特集などを表示
- バナーやカルーセルを用いて商品のプロモーション表示
### 検索
- 文字検索から商品を検索
- カテゴリから商品を検索することも可能
- また検索する際に商品のカラーやサイズ、値段、及び店舗などから検索結果に対してフィルタリングすることも可能
### 商品詳細
- 商品の詳細が記載されている
- 商品のレビューをチェックすることができる
- スタイリングもチェックできる
- 商品を購入することができる
- どの店舗で購入可能かも見ることができる
- その商品に関連するおすすめ商品の表示
### スキャン
- 実店舗に存在する商品のバーコードやQRコードをスキャンするとアプリでその商品の詳細を見ることができる
- またその画面から商品を購入することも可能
### Pay機能
- Pay機能を用いてオンラインでもオフラインでも決済することが可能
- クレカまたは銀行の口座情報を登録することで決済可能
### その他
- クーポン機能
- メッセージ機能
- お気に入り機能
# 担当業務
### コーダー
- iOS, Android, Flutterを担当
- Flutterは一部の画面で取り入れるような形にしており、libraryとして切り出してそれをネイティブ側からコールしていた
- 仕様が固まっていないものはPdMと相談し、またエンジニア視点から考えて改善できそうな箇所があれば都度提案していた
- home画面のリファクタ(iOS)
- 具体的にはクリーンアーキテクチャを採用し、viewは今までxibやstoryboardをメインに使用していたがそれを廃止しコードでviewを書くように統一した
- メモリリークの改善(iOS)
- アプリのパフォーマンス改善(iOS)
- 複数回呼ばれているapiを単発で呼ばれるように改善し、BFFの負荷を軽減させた
- 複数のapiを直列的に呼んでいる箇所を並列的に呼ぶようにし通信時間の削減を実現させた
- 複数の画面で共通で使用されるデータ(商品データなど)をシングルトン経由でメモリ(dictionary)に保存していたがそれを廃止し、イニシャライズ時にデータを引数で渡すことによって画面が表示されるまでの時間を短縮した
- Native BFFからEC BFFへの移行(iOS, Android)
- アプリで選択した店舗の商品の売れ筋やおすすめ、あるいはそのスタイリング方法がわかるような画面の構築(Flutter)
- 商品のカテゴリ表示部分で使用するAPIとロジック変更(Android)
- アプリのクラッシュ対応(iOS, Android)
- テストコードが書かれていない部分に対してのテストコード作成(iOS, Android)
- Flutterが使用されている画面でもプロキシツールを使用できるように改善した(iOS)
- CFNetworkCopySystemProxySettings()?.takeUnretainedValue()を使用
- プロジェクトにおいて唯一iOS、Android両方のコードを把握しているので両OS間で挙動をそろえたりロジックを同じような処理に調節したりなどの取り組みも行った
### テックリード(iOS、Android)
- コードレビュー
- メンバーのサポート
- チーム数は5~8人(月によって契約人数が変動していたので)
- 技術的な質問やチケットの質問対応
- 進捗管理
- メンバーの設計に関する理解を高めるために設計に関する本を題材に輪読会を企画した
- チケットの用意とアサイン
- 新規機能を実装する際はチケットをアサインする前にどのように実装するかを自分の方でいくつか候補をあげ、その中から適したものを採用しメンバーに共有するようにしていた
- 定期的にメンバーとの面談
- メンバーのキャリアややりたいことなどを聞き出しそれをうまく反映することができないかどうかを模索していた
- またチームの総合的なアウトプットを高めるためにメンバーには1人1人がDev Leadの自覚を持ちながら業務をこなすよう意識づけを行なっていた
- iOSチームにおいて次のテックリード候補を育成するために私の代わりにテックリード業務を1,2ヶ月こなしてもらうような施策を実施した
- その期間私はプレイヤーとして業務をこなしつつOJT的にフォローや相談を受ける立ち回りをしていた
- Androidチームのpr数がiOSと比べると常時２倍くらいあったのでそれを解消すべく色々な取り組みを行った
- prがたまらないように適切なラベリングを設定してレビュイーに対してコメントや指摘があったものはそれを優先的に対処するように促した
- レビュワー側はレビューをリクエストされたら優先的にそれを見ていくような仕組みに変えていきました
- 結果今ではiOSと同じくらいのpr数までに縮めることに成功した
- エンジニア側で起票されたチケットは大雑把な内容しか書かれていないケースが多く、それをQA側でテストするときに具体的にどのようにテストしたら良いかわからないケースが多かったのでそれを解消すべくマージされたら自分の方でどのようにテストするかチケットに記載するようにした
- Android側のバグの数がiOSと比べると比較的多かったのでそこも改善できないか色々と検討した
- バックログにバグチケットがアサインされずに放置されているものが多かったので定期的にバックログ内のチケットをフィルタリングしてなるべくバグチケットが誰かしらにアサインされている状況を作った
- QA側でテストしてその結果チケットがreopenされることが多かったのでレビュー段階からチケットの修正内容に合っているのかどうかをレビュー項目に入れるようにした
- QA側でE2Eテストやリグレッションテストが始まる前にエンジニア側でスモークテストを行い、そこで事前にバグを検知して修正していくようにした
- PdM側で修正バージョンをトリアージし忘れている場合が多かったので自分の方から再度問い合わせて今回のバージョンで修正するのか、あるいは次バージョンで修正するのかを早めに決めてもらうようにした
- レビューをしていてその場しのぎの修正が多いと感じたので時間をかけても良いので根本的にそのバグを解決するようにメンバーへ促した
- 僕がandroidチームにアサインされた頃はバグチケットが多く、開発期間内にバグを潰しきれず次バージョンにdeferされることが多かったが今では開発期間内にバグ解消できるくらいまでにバグ数を抑えることができた
### その他
- 業務委託採用面談
- 契約周りの手続き