# 概要
某有名アパレルブランドのアプリ開発
# 規模
先方（モバイルチーム）
- PdM：6名
- エンジニアリングマネージャー1名
- iOSエンジニア：5名
- Androidエンジニア：5名
弊社
- PM：1名
- iOSエンジニア：7名
- Androidエンジニア：7名
# 担当業務
### コーダー（iOS, Android, Flutter）
- 仕様が固まっていないものは 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 側で修正バージョンを設定し忘れている場合が多かったので自分の方から再度問い合わせて今回のバージョンで修正するのか、あるいは次バージョンで修正するのかを早めに決めてもらうようにした
- 開発期間内にバグを潰しきれず次バージョンに defer されることが多かったが今では開発期間内にバグ解消できるくらいまでにバグ数を抑えることができた
- Android プロジェクトでレビューをしている際、その場しのぎの修正が多いと感じたので時間をかけても良いので根本的にそのバグを解決するようにメンバーへ促した
### その他
- 業務委託採用面談
- 契約周りの手続き