こんにちは。PayPayモールのAndroidアプリを担当している松井です。
10月19日〜21日に開催されたDroidKaigi 2021の振り返りオンラインイベントを、DroidKaigi 2021に協賛している株式会社ZOZO、LINE株式会社、ヤフー株式会社の3社合同で開催いたしました。今回はその様子をご紹介します！
今回のイベントの司会はZOZOの下川さんにご担当いただきました。
LTはZOZOの山田さん、LINEの玉木さん、ヤフーから木内の3名に登壇していただきました。パネルディスカッションはZOZOの堀江さん、LINEの玉木さん、ヤフーのAndroid黒帯（ヤフー内のスキル任命制度）の森の3人で実施いたしました。
ZOZOTOWNアプリへのIn-app updatesの導入とその運用について
山田 祐介さん（株式会社ZOZO）
ZOZOTOWN Androidアプリを担当されている山田さんにユーザーにアプリ内でアップデートを通知するIn-app updatesについて、導入の経緯をメインに仕様や運用方法をご紹介いただきました。
大規模リリース時にクラッシュや不具合が発生してしまい数日以内に修正リリースを行ったが、Firebase Crashlyticsのクラッシュフリー率が元の数値に回復するまでに時間がかかったこと、不具合修正のリリースに気づいていないユーザーからの問い合わせが続いたことが紹介されました。そのことから、迅速な修正リリースだけではなく、修正したことをユーザーに伝える必要性を考えるようになったそうです。
アップデートの通知にIn-app updatesを使うことにしたのは、UIの実装の大半をライブラリが提供してくれているため、デザイナーのリソースを抑えた低コストでの開発と運用ができるからとのことでした。
またUXを妨げないためにアップデート訴求頻度をIn-app updatesのinAppUpdatePriorityを用いて制御していると説明されていました。inAppUpdatePriorityの値はリリース時に値を設定するだけなので、運用もAndroidエンジニアだけで行えます。導入した結果、「24時間に1回のみ訴求」と「訴求なし」の普及率を比較すると、リリース翌日は10％も差が出るなど大きな効果があったそうです。
エンジニアとしてはどのリリースもすぐにアップデートしてほしいところですが、目的があってアプリを起動したユーザーにとっては行動の妨げになってしまいます。UXを落とさずに効果的にアップデートをユーザーに届ける今回の発表はとても参考になりました。
巨大なプロダクトにおける技術負債と戦った成功と失敗の軌跡(途中経過)
木内 啓輔（ヤフー株式会社）
Yahoo!ファイナンス担当の木内より、技術負債返済のために取り組んだことを紹介してもらいました。
Yahoo!ファイナンスに参画してから、チームメンバーからの信頼を得ながら改善についての根回しを行った結果、毎週金曜日に技術負債返済や改善を行う「改善DAY」を定期開催できるようになったそうです。
取り組みの初期には気になる技術負債を一気に一人で改善するために実装してしまったことにより、 現行の開発と大規模なコンフリクトが発生してしまったり、チームメンバーが実装方針がわからず置いてけぼりになるなどの問題が発生してしまいました。
そこで、現行の開発に影響が出過ぎないように取捨選択を行いながらペアプロ形式でリファクタリングを行った結果、一つの画面を理想の形に置き換えられました。ただ、一つの画面のリファクタリングに1年半かかっており、全画面となると膨大な時間が必要となること、ペアプロに参加していないメンバーに実装方針が共有されないなどの問題が発生しました。
それらの問題を解決するために「改善DAY」を設けるだけではなく、開発と技術負債の返済を並行して進めるようにし、チームで同じ方向を向くために、実装方針や歴史的背景、クラスの構成図などのドキュメントやツールの整備を行いました。その結果、根本的な見直しが発生しなくなったり、メンバー個々人が設計や技術負債の返済を考える文化ができたそうです。
日々の開発に追われ、なかなか技術負債の返済ができないという課題はどのチームも持ち得るものかと思います。今回の失敗や成功を得て、チームで同じ方向を向くために行った取り組みは技術負債の返済だけではなく、現行の開発でも大切な部分だと感じました。
Glideをもっと深くまでカスタマイズしてもっと便利に
玉木 英嗣さん（LINE株式会社）
LINEのチャット部分を担当されている玉木さんに、Glideの内部構造の一部解説とLRUでない独自のディスクキャッシュの作り方を紹介していただきました。
例として、String型の画像URLからInputStreamを経由し、ImageViewに設定できるDrawableへと変換されるまでの流れを説明していただきました。Glideの内部構造はいくつかの層に分かれており、ModelLoaderとResourceDecoderの仕組みを使うことでさまざまなModelからさまざまなResourceに変換できるそうです。ModelをInputStreamに変換するModelLoader、InputStreamからResourceに変換するResourceDecoderを用意することで、コード量を少なくした上で多種多様な形式の変換をサポートできるようになるとのことでした。
そして、実際にどのようにしてLRUではない独自のディスクキャッシュを実現しているのか説明していただきました。このカスタマイズではModelLoaderの仕組みを活用しており、ディスクキャッシュがない場合は画像データをダウンロードした上でファイルに書き込むModelLoaderとDataFetcherを使用するようにし、ディスクキャッシュがある場合はインターネットに接続せずローカルの画像データを取得するModelLoaderとDataFetcherを使用するようにすることで実現しているそうです。
このLRUではないディスクキャッシュ以外にもLINEアプリではさまざまなカスタマイズをしており、ModelLoaderやResourceDecoder、DataFetcherに手を加えることで実現しているとのことでした。
Glideの内部構造をしっかりと説明していただいたおかげで、どのようにカスタマイズをしていけば良いのかがとてもわかりやすく参考になりました。ぜひ皆さんもGlideのカスタマイズに挑戦してみてはいかがでしょうか。
発表資料：https://speakerdeck.com/line_developers/lets-customize-glide-to-make-it-more-useful
パネルディスカッション
モデレーター兼パネリスト： 堀江 亮介さん（株式会社ZOZO）
パネリスト： 玉木 英嗣さん（LINE株式会社）/ 森 洋之（ヤフー株式会社）
ZOZOの堀江さんにモデレーターを兼任していただきながら、LT登壇をされたLINEの玉木さんとヤフーのAndroid黒帯である森の3人でDroidKaigiでのセッションや各社でのAndroid事情についてパネルディスカッションを実施しました。
パネリストが気になったDroidKaigiのセッションについて
堀江：今回全てのセッション素晴らしかったですが、気になったセッションはありましたか？
森：まだみていない方にはLINEさんの長く生きるコードベースの「品質」問題に向き合う がおすすめです。80人の大規模での開発でコード品質をどのように行っているのかはなかなか話が聞けないと思います。
森：すぐに役に立つものとしては25分で作るAndroid Lint が素晴らしかったです。
堀江：ZOZOでもセッションを見てから実際にAndroid Lintの実装を行いました。ライブコーディングでの発表がすごく良かったですね。
森：コーディング規約を整備するよりも、LintやCheckStyleの整備に時間をかける方が良いと思います。
玉木：LINEでもCustom Lintを実装しており、Rx2は新規で利用しないように警告を出したり、古いライブラリへの警告を出すようにしています。
玉木：動かす が素晴らしかったです。
堀江：ただただすごいとしか言えないですね。あらゆるアニメーションに対しての説明がありました。
玉木：発表スライドをアプリで作成されているところも驚きでした。
堀江：振り返り勉強になったなと思ったのがDroidKaigiカンファレンスアプリの歴史からみるアプリアーキテクチャのこれまでとこれから です。2016年から2021年の差分を見て何が変わっていて何が変わっていないのかが復習できました。
玉木：昔はみんなが実装スタイルを模索中でしたが、現在はJetpack Composeが発表されたことで落ち着きつつある時代になってきた気がします。
アーキテクチャなどの開発について
堀江：LINEさんはDroidKaigiのセッション長く生きるコードベースの「品質」問題に向き合うでお話がありましたが、チームでの開発体制がどのようになっているのか教えてください。
玉木：東京だけで7チーム、福岡や外国チームも含めるとActive Developerが80人います。
森：Androidエンジニアだけで80人ともなるとコンフリクトが発生しやすくなると思いますが、どうしていますか？
玉木：できる限りコンフリクトが発生しないように、Feature BranchではなくFeature Flagを導入してできる限りメインブランチにマージしていき、1つ1つの機能のコンフリクトを少なくしています。
森：モジュールは分割していますか？
玉木：ここ1年、モジュール分割しようとしており、数十個のモジュールが開発されてきています。
ビルド速度が遅かったこともあり、速度改善を狙ってさらにモジュールを分けていこうとしています。
堀江：ヤフーさんもいろいろなサービスでマルチモジュール化がされているのでしょうか？
森：ヤフーのサービスは独立性が高いので他のサービスのことはわかりませんが、自分の担当サービスであるPayPayフリマは比較的新しいサービスなので最初からマルチモジュールで開発を進めており、全てKotlinで実装しています。
堀江：LINEさんのKotlinとJavaの比率はどうなっていますか？
玉木：DroidKaigiでのセッションで紹介があったと思いますが、6：4か7：3でKotlinの方が高めだったと思います（※LoC（Lines of Codes）での比較で2:1）。
堀江：ZOZOの現状は5：5ですが、2022年はKotlin化をもっと進めようと頑張っています。
森：ヤフーはサービスごとに温度感が違います。ヤフオク!はKotlinが4割、Yahoo! JAPANアプリはJavaでやると決めているみたいです。
Androidアプリのアクセシビリティの対応について
堀江：今回のDroidKaigiで印象的だったのがアクセシビリティのセッションである触って学ぶAccessibilityと2021年こそアクセシビリティと向き合おう なのですが、アクセシビリティの取り組みはされていますか？
森：ヤフーはアクセシビリティ黒帯がいるのと、各サービスに対して品質やセキュリティをチェックする部署がいるので、その1つの観点としてアクセシビリティの項目があります。
玉木：LINEでは、独立した組織はありませんが、新しい機能を作るときにはプランナー側でアクセシビリティが必要かどうかや、値などの設定をしてもらっています。
ただ、古いコード部分は対応が甘い部分があるので、チェックしてやっていくところがあります。
堀江：ちなみに、ZOZOはまだまだこれからです。セッションを聞いてアクセシビリティの奥深さを感じました。
森：特にコマースは難しいですね。法務的に必ずユーザーに読んでもらわないといけない部分があるので。そういうところとの兼ね合いが難しいと思います。
おわりに
ZOZO、LINE、ヤフーの3社合同での初Androidイベントの開催となりました。
LTでは各社のAndroid開発時に行っている工夫を知ることができたと思います。また、DroidKaigiで登壇されていた内容をベースに行ったパネルディスカッションでは3社全く異なった開発スタイルであることがわかり、とても興味深い内容だったと思います。
YouTubeのアーカイブ配信 にてAfter DroidKaigi 2021を公開しておりますので、興味を持たれた方はぜひご覧ください。
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
- 松井 真子
- PayPayモールエンジニア
- PayPayモールのAndroid版アプリを開発しています。
