日経電子版 for Android の技術的課題と取り組み(令和最新版)/android-20250423

2025年4月23日開催、【Androidエンジニア特集】Androidアプリ開発 開発組織が向き合う課題と戦略 という技術イベントに日本経済新聞社のAndroidチーム 尾形さんが登壇。発表スライドです。タイトルは「日経電子版 for Android の技術的課題と取り組み」です

Transcript

1. 2025/04/23 日本経済新聞社 Androidチーム 日経電子版 for Androidの 技術的課題と取り組み(令和最新版)
2. もくじ • 紹介 • 技術的課題感 • 取り組み1: 今と向き合う🔍 • 取り組み2: 未来と向き合う🔭 2
3. 紹介 • 自己紹介 • 会社紹介 • アプリ紹介 • チーム紹介 • 面白み紹介 • 技術スタッフ紹介
4. 自己紹介 • 尾形卓哉 @ogapants • 2018年入社 • Androidチームリーダー ◦ 各施策の仕様調整、開発プロセス改善、チームビルディングなど • 好きなAPI： WebViewClient.shouldOverrideUrlLoading 4
5. 会社紹介 • 日本経済新聞社 • 創刊: 1876年 • 社員数: 3,042人（2024年12月末） • 事業内容: 新聞を中核とする事業持株会社。雑誌、書籍、電子メ ディア、データベースサービス、速報、電波、映像、経済・文化事 業などを展開 5
6. アプリ紹介 6 紙面ビューアー 日経電子版 ※今回のメイン
7. アプリ機能紹介 • 最新の記事配信・通知 • フォロー・保存 • 検索 • 法人向け機能 • Think!（専門家によるニュース解説） • For You（パーソナライズ） • 🆕 Ask! NIKKEI （生成AIを使った回答サービス、開発中） 7
8. Androidチーム紹介 • 10人（社員7,業務委託3） • 直近の登壇タイトル例 ◦ 分析に裏打ちされたアプリウィジェット開発 - Jetpack Glanceとともに - (2024) ◦ iOSとAndroidで定期購入の意図しない解約を防ぐ (2023) ◦ 作って学ぶadbプロトコル (2023) ◦ 通知許諾率向上のアプローチ (2023) ◦ できる！アクセシビリティ向上 (2023) ◦ Jetpack Composeを活用した強力なUI表現の実装実例 (2023) 8
9. アプリチームのミッション • 施策案件の爆速開発 ◦ プロダクトバックログで決まった案件をデリバリーし続ける • 内部品質の向上 ◦ 持続可能性の高い開発基盤を作り安定した爆速開発を支える • 施策の立案（任意） ◦ データを元にLTV向上に繋がる機能を立案する 9
10. エンジニア主導の企画立案（例） データドリブンな文化なので大企業ながらエンジニアも立案できる • 通知許諾率の向上施策 ◦ →数値計測の結果、大幅改善！ • Wear OS対応 ◦ →Google Playで大賞に！ • アクセシビリティ対応 ◦ →多くの人に届けられるように！ • ウィジェット(Glance)対応 ◦ →タッチポイントを増やしてエンゲージUP！ 10
11. 日経電子版サービスの面白み紹介 • デカい ◦ 規模 ◦ 要件 ◦ 歴史 11
12. 日経電子版サービスの面白み紹介① • 規模がデカい ◦ 日経ID会員1100万人、有料会員101万 ◦ 閲覧ページ数 約2.2億/月(PC等含む) ◦ 訪問者数 約2900万/月(PC等含む) ※ https://marketing.nikkei.com/media/web/nikkei_online_edition/ 12
13. 日経電子版サービスの面白み紹介② • サービス要件がデカい ◦ 多種多様な記事コンテンツを安定して表示 ◦ 幅広い会員種別に応じた画面切り替え ◦ 高精度なデータ計測のため緻密なログ送信 13
14. 日経電子版サービスの面白み紹介③ • 歴史の重みがデカい ◦ 約150年の歴史ある事業 ◦ 社会的に信頼されるメディアに ▪ 信頼されるアプリを作りたい … ◦ Androidアプリの初回リリースは2011年 ▪ 2015年にリニューアル ◦ Android黎明期から様々な技術スタックの変遷 14
15. 技術スタックの紹介 • 言語: Kotlin • 設計: アプリアーキテクチャガイドのパターン • UI: Jetpack Compose • 画像: Coil • DB: Room • 非同期: Kotlin Coroutine • イベント通知: Kotlin Flow • バックグラウンド: WorkManager • マッパー: Kotlin Serialization • アサーション: kotlin-test • モック: MockK • DI: Hilt • クラッシュレポート: Firebase Crashlytics • CI: GitHub Actions 15
16. 技術スタックの変遷 (2025←2015) • 言語: Kotlin ← Java • 設計: アプリアーキテクチャガイドのパターン ← Model-View-Presenter • UI: Jetpack Compose ← ViewBinding ← Butter Knife • 画像: Coil ← Glide ← Picasso • DB: Room ← OrmLite • 非同期: Kotlin Coroutine ← RxJava ← AsyncTaskLoader • イベント通知: Kotlin Flow ← LiveData ← Otto • バックグラウンド: WorkManager ← Service • マッパー: Kotlin Serialization ← Gson • アサーション: kotlin-test ← AssertJ ← JUnit 4 • モック: MockK ← Mockito-Kotlin ← Mockito • DI: Hilt ← Dagger 2 ← Dagger • クラッシュレポート: Firebase Crashlytics ← Fabric Crashlytics ← ACRA • CI: GitHub Actions ← Circle CI 16
17. 技術的課題感
18. Android電子版の技術課題 サービス成長の裏で徐々にレガシーコードが蓄積している • サービス規模が大きく、外部品質を維持・向上することに多くのリソースを割 いている • 最新技術を導入し続けたことで技術変遷が複雑化し、移行対応が追いつか なくなってきている • 日々のタスクの中でリファクタも進めているが、目指す理想的な設計のすり 合わせや実現には至っていない • 人数も多く、意思の統一に時間がかかる 18
19. 日経電子版におけるレガシーコードとは 修正や拡張が難しく、テストも書きづらい古いコード 例： • より便利なライブラリが出たので非推奨になったライブラリ • より堅牢な設計が生まれたので非推奨になった設計 • 修正を繰り返していつの間にか当初の想定を超えた仕事をしているクラス • テストが足りない（足りなくなった） 19
20. 日経電子版におけるレガシーコードとは • 今はレガシーでも昔はモダンだった • ただ技術や要件の変化に耐えられる設計にはなっていなかった 20
21. レガシーコードの影響 • レガシーコードが多いと… ◦ 機能の追加・変更に時間がかかる ◦ デグレの配慮が大変 ◦ バグ修正時の根本対応が難しい ◦ 既存画面をCompose化する上での事前リファクタが多い →レガシーコードがさらに積み重なり開発速度が低下する恐れ 21
22. 技術的課題に対するアクション レガシーコードの排除に向け、 • 施策開発の合間に改善タスクを取る • 施策開発タスクの直前に周辺のリファクタをする を進めていたが、それだけでは根本解決には至らず… 22
23. 技術的課題に対するアクション 長く成長してきたプロダクトだからこそ、より持続的な品質向上の ために腰を据えたアプローチが必要 ➡ 今と向き合う🔍 ➡ 未来と向き合う🔭 23
24. 今と向き合う🔍
25. 今と向き合う 今起きている問題を打破しなければならない 👉[改善チーム]を新規に分離し、長期的にレガシーコードの改善 に集中できる担当者を明確化 • Androidチーム全体の20%ほどのリソース • 現在も元気に営業中 25
26. 改善チームの目標 • 改善チームが不要な状態をつくる ◦ 全画面においてCompose化を進めていける状態にする ◦ 全員が改善タスクに継続的に取り組める状態にする →レガシーコードは改善チームが完全消滅させるのではなく、全員が日常的に排除 し、自然消滅していけるような体制にしたい →新しいレガシーコードが生まれても都度改善チームを立ち上げなくていいように 26
27. 改善チームのやること • 目標に沿って消すべきレガシーコードを整理 ◦ 改善チームが集中して消すもの ◦ 全員で日常的に消していくもの • ひたすらリファクタしてレガシーコード削減 ◦ あくまでCompose化の障壁になるものに絞る • レガシーコードの削減状況が分かるよう可視化 ◦ 定期的に全員でチェックし全体での改善も促す 27
28. 改善指標の可視化 28
29. 改善指標の可視化 • レガシーコードの利用ファイル数をカウントしてjsonlに書き出し • GitHub Actionsで定期実行してBigQueryにインポート • Redashで可視化 29
30. 可視化の目的 • 課題感を改めてAndroidチーム全体の共通認識に • 削減進捗が見えるのでモチベーションUP • 逆に減ってないものがある場合は再度周知 • 実績が明確になり対外的にも改善活動の正当性アピールに 30
31. やってよかったこと • 今の状況を改めて再認識し、改善方針が掴めた • 当初のレガシーコードがかなり減った • いくつかCompose化を進められている • 将来AIに任せる際にも理解しやすいコードに ※改善チーム発足時の詳細: https://speakerdeck.com/nikkei_engineer_recruiting/nikkei-tech-talk8-3 31
32. 未来と向き合う🔭
33. 未来と向き合う 未来に起きうる問題を打破しなければならない • 今のレガシーも昔はモダンだったことから、今モダンにしてもそのうちま たレガシーになりうる • 今後も常に技術トレンドを追って導入していく文化を醸成する必要がある • レガシーコードの削減は改善チームの役割だが、今以上のモダンさを維持 ・追求するのはチーム全員で実施するべき 33
34. 未来と向き合う モダン技術の共有と知識の平準化をチームで行いたい 👉モブプロで学習時間を作る試み 34
35. モブプロの実施方法 • 1台のPCをチーム全員で操作しながら開発(モブプログラミング) • 週1回・15分交代制・7人で実施 • Google Meetで画面共有 ◦ 在宅勤務中心だが出社して集まることも 35
36. モブプロでやっていること 実プロダクトのとある機能を切り出し、完全新規アプリとして作っ ていく • Googleの”Now in Android”アプリとアーキテクチャガイド がベース • CopilotなどAIツールも利用してナレッジ共有 • 学習メインなのでプロダクトにはマージしない想定 36
37. • 今後の全体設計をどうするべきか全員が考えられるようにする • Google推奨の設計がなぜ良いとされるか”書いて”理解する • 技術トレンドを追って導入の心理的ハードルをなくし、誰でも日 常的にモダンさを取り入れられるようにする モブプロの目的 37
38. やってよかったこと • 日々の開発でも「モブプロで試した技術を使ってみよう」と言え るようになった ◦ 「これモブプロでやったところだ！」という共通認識も • 既存の改善タスクを早くやりきりたいという意欲が向上した • 未検討だった技術の理解が進んだ ◦ Convention Plugin、Fakeでのテスト、Roomの多対多リレーションなど • 今後の我々の設計はどうあるべきかと考える習慣ができた 38
39. まとめ
40. まとめ • 日経での開発は大規模ながらデータドリブンでやりがいあり • 内部改善の課題があるが、集中解決するチームを作り積極的に 改善を進めている • モブプロを通じてモダン技術と今後の理想的な設計をチームで 議論している 40
41. まとめ サービス成長も内部改善もやっていき💪ある方お待ちしてます！ 41
42. ありがとうございました