こんにちは。Androidエンジニアのkenzoです。
今回はAndroidチームでの取り組みや、その周辺環境の特徴をいくつかご紹介いたします。
ありがたいことに、クラシルリワードはローンチから2年程で大きなプロダクトに成長してきました。
それでもまだまだユーザーの皆様に早く届けたい機能や改善点があり、高速で開発サイクルを回していく必要があります。
また、より良いUXを目指し、アプリを意図通りに動作させることも大切です。
さらに、長期的に開発を続けるため、これらの取り組みを継続できるようチームで取り組んでいます。
速度・品質・継続の3つを達成するために、クラシルリワードのAndroidチームが取り組んでいることや環境をご紹介します。
クラシルリワードAndroidの開発環境
まず簡単に開発まわりの環境や特徴をご説明します。
フレームワーク・アーキテクチャ
- Full Jetpack Compose
- Google推奨のアーキテクチャ + Clean Architecture
開発を始めてから日が浅いため、ほぼ全ての画面をJetpack Composeで作成できています。 アーキテクチャに関してはAndroid Developersにあるガイドラインに沿った作りに加えてClean Architectureの概念も取り入れています。
プロダクトの特徴
位置情報・歩数機能や地図等の特徴的な機能を含むプロダクトを開発しています。位置情報や歩数を計測するためにバックグラウンド処理を制御したり、地図に独自のUIを表示させるために工夫したりしています。
また、リワード広告をはじめ、広告のSDKを組み込んだ開発も行っています。動画広告はメモリ消費量が多いため、その制御にも細心の注意を払っています。
開発体制
こちらの記事にあるようなスピード感のある開発体制となっています。
速度を上げるための取り組み
テスト・リリースの自動化
Github Actionsを用いて、PR作成時のテストやリリース作業を自動化しています。 チームでは週に複数回リリースを行うこともありますが、コマンドの実行のみでQAを始められるため、開発者の工数をかけずに安全にリリースを進めることができています。
小規模なブランチを素早くマージ
ブランチを小さな単位で作成し、できるだけ早くマージすることで、コンフリクトの防止やレビューの効率化を図っています。
大規模な機能を開発する場合でも、レイヤーやUIのコンポーネント単位でブランチを分けることで、特定の箇所に集中してレビューできるため問題の発見が容易になり、レビュー着手への心理的負担を軽減することにもつながっています。
また、フラグを用いて開発途中の機能の公開を制御し、準備が整ったらフラグを外してリリース、といった方法も採用しています。
直近100件のPRの追加差分(insertions)を調べたところ、平均71.41行、中央値38.5行でした。全面的にJetpack Composeを使用できていることや整ったアーキテクチャで開発できていることも、ブランチを小さく保つことに寄与していると感じています。
AIを使用した開発の高速化
Copilot, ChatGPT等のAIを活用して開発の効率化をしています。
コードの生成、セルフレビュー、ドキュメント読解の手助け等、様々な場面で利用しています。
品質を高めるための取り組み
E2Eテスト自動化
MagicPodを使用してE2Eテストを実施してアプリの基本的な動作を担保しています。
これによって改善や機能追加による既存機能への影響を検知して修正することができています。
不具合や警告の通知
上記のようなテストの失敗やLint/Detekt等の警告に加え、その他、アプリの周辺で何らかの異常が発生したと思われる場合にSlackにアラートが送られるようになっています。
例えば、RemoteConfig等のアプリ外から設定値を送る仕組みからアプリに送られた値が仕様と異なっていた場合にはエラーとしてアラートが飛び、すぐに修正することができています。
気軽にQAを依頼できる環境
リリース前はもちろん、開発中においても動作検証を依頼する仕組みがあり、自身の作成した機能をメンバーに触ってもらうことができます。
コード生成
APIの仕様やイベントログの定義からコードを生成する仕組みを取り入れることで、手作業によるミスを減らし、その分のコードレビューの工数も削減できています。
生成するためのコードも同じリポジトリ内にあり、仕様が変わった場合にもプロダクトコードと同様に誰でも修正することができます。
継続的な開発を実現するための取り組み
将来を見据えた開発
長期的に開発を続けることを前提として開発を進めています。
コードの書き方や、レビュー観点、ドキュメント等それぞれにおいて長期的な視点を取り入れています。
レビューでは、仕様通りに動作しても長期の開発の妨げになり得る場合には指摘が入ります。
また、早めに作成しておけば様々な場面での使用が想定でき、長期的に効いてくるような改善も積極的に行っています。
仕様が複雑だったり特殊な実装でコードから容易に意図が読み取れない場合には、将来の開発者が背景を理解できるよう必ずコメントやドキュメントを残すようにしています。
最近では、技術的な意思決定を遡れるようADR（Architecture Decision Record）を残す取り組みも始めました。
エンジニアも仕様作成に関わる
各チームにおいてエンジニアが仕様作成段階から参加することで、ビジネス的な観点から達成したいことと、技術的な観点から将来的な負債や開発工数とのバランスをとった仕様を作成することができています。
これにより、ミニマムに価値のある機能を最短でリリースすることが可能になっています。
おわりに
クラシルリワードにおけるAndroidチームの取り組みをご紹介いたしました。
分類してみたものの、複数の項目に関連している取り組みもありましたが、それぞれが良いプロダクトの開発に貢献していると感じています。
delyでは一緒にプロダクトを成長させてくれるAndroidエンジニアを募集しています。
本記事を読んで少しでも興味をお持ちいただいた方はぜひこちらからご応募ください。
