## 開発初期から方針転換によるアプリ作り直しまで
- 技術選定の為にクロスプラットフォーム技術導入検討のためにReactNativeやXamarinの調査を行ったが、メリットよりもデメリットのほうが大きいと判断してAndroid・iOSそれぞれネイティブで開発する方針に決定した。
- Androidアプリ開発自体はこのプロジェクトに入るまで未経験だったが、当時チームを組んでいたモバイルアプリエンジニアからノウハウをキャッチアップしながら開発を行っていた。
- 当時はMVPアーキテクチャを採用していたが、モデル層がデータを扱うロジックと密結合になってAPI仕様の変更に耐えきれないという問題が、サーバーサイドとのつなぎ込み時に浮き彫りになったため、APIのRequest/Responseを扱う層とアプリ内のデータを扱う層に分離することで対処していた。
- この時期の開発についての発表資料: https://speakerdeck.com/syousa1982/apurikai-fa-chu-xin-zhe-ga-androidapuriwozuo-tuteiruhua
## アプリ作り直しからサービスローンチまで
- ビジネスサイドによる大規模なサービスの方針転換があり、そのために開発中のサービスを1から作り直す事になった。
- 作り直しが決まった時に当時読んでいた本(※) の影響でAACを使用してMVVMで開発する方針に切り替えたいと進言したことにより、アーキテクチャの見直しを行うことになった。
- ※ 当時読んでいた本: Androidアプリ設計パターン入門, WEB+DB vol106
- チームメンバーとペアプロしながらMVVMをベースに「API仕様の変更にも対応しやすくDIを使用して各層が疎結合であること」を目指してアーキテクチャを模索した結果、MVVMとCleanArchitectureでアプリを設計していくことになった。
- アプリを作り直すことになるまではチームメンバーからキャッチアップしながら作っていたが、アーキテクチャを選定を決めた後はチームメンバーがiOSアプリの開発に専念し、私自身はAndroidアプリの開発をメインで担当することになった。
- サービスローンチ間近にメンバーの入れ替わりが発生し、ほぼ同時期に新メンバーが増えてベテランメンバーが抜けたことにより、新メンバーに対する技術面のフォローを行っていた。
- 具体的にはタスクの割り振りや進捗について密にコミュニケーションを取っていたり、iOSのメンバーに対してもコードレビューに参加するなどの動きをしていた。
## サービスローンチから運用開始初期
- サービスローンチ前後にアプリのパフォーマンス問題が発覚したため、実際に計測を行って原因箇所を洗い出し解決した。その当時のことについては発表資料をまとめて社外で発表した。
- https://speakerdeck.com/syousa1982/arap-osaka-1
- ローンチまでの反省を活かし開発体制を整えるためにスクラム開発を導入することになり、1週間ごとにスプリントを回し、スプリント毎にアプリのアップデートをリリースする体制になった。
- 1週間毎のリリース体制に対応できるようにするために、アプリのバージョニングルールとそれまで最低限のルールしか無かったGitHubのブランチ運用のルールをGitHub Flowをベースに考案し、モバイルアプリ開発を行うメンバーに展開して週に1回のリリースに耐えうる体制を整えた。
- 今後はローンチまでに積み上がった技術的負債を解消するために、まず手始めにAndroidアプリの自動テスト環境の整備を画策している。
## アプリチームのリーダーに近い立ち位置に
- 何度かチームに合う開発体制の模索を行う過程で、アプリエンジニアのリーダーに近い役割を行うことに。
- Androidだけでなく、iOSもコードレビューを行ったりiOSのタスクを巻き取る事が増えて来た。
- iOS特有のUI実装の仕組みやiOSでしか使ってないライブラリの使い方などキャッチアップの必要があったが、大枠のアーキテクチャはAndroidと一致させていたので、対応にはそこまで苦戦しなかった。
- 案件の性質によってはフロー効率を重視するためにモブプロ・ペアプロの導入を試みた。