モブプロ活動で「未来と向き合う」 日本経済新聞社 Androidチームが挑むレガシーコード対応

日本経済新聞社でAndroidチームのリーダーを務める尾形といいます。2018年に入社し、各施策の仕様調整や開発プロセス改善、チームビルディングなどを担当しています。

日本経済新聞社は1876年の創業以来、新聞を中心として雑誌、書籍、電子メディア、データベースサービス、速報、映像など、さまざまなメディアを展開しています。

私たちのチームでは「日経電子版」「紙面ビューアー」の2つのアプリをサポートしています。日経電子版では、記事一覧や個別の記事を閲覧できます。紙面ビューアーでは、朝刊・夕刊の紙面画像を閲覧でき、キーワードのハイライト機能なども搭載しています。ここでは、主に日経電子版での取り組みについて解説します。

Androidチームのミッション

Androidチームは現在、計10人（社員7人、業務委託3人）と比較的大きな組織です。チームのミッションは大きく以下の3つです。

施策案件の爆速開発

プロダクトバックログにある案件を継続的にデリバリーする。

内部品質の向上

持続可能性の高い開発基盤を整え、安定した爆速開発を支える。

施策の立案（任意）

データを活用し、顧客生涯価値（LTV）向上につながる新機能をエンジニア自身で企画する。

こうした裁量のある活動を通じて、より良いプロダクトの提供を目指しています。

当社にはデータドリブンな文化があり、大企業では珍しくエンジニア主導で企画を立案できます。例えば、通知許諾率の向上施策やWear OS対応、アクセシビリティの改善、ウィジェット対応など、多くのLTV向上施策がエンジニアから打ち出されてきました。

日経電子版、ここが「デカい」

日経電子版の面白さを一言で表すと、「デカい」の一言に尽きます。具体的には、以下の3つが「デカい」といえます。

規模がデカい

「日経ID」の会員数は約1100万人、日経電子版の有料会員は約101万人。月間の閲覧ページ数は約2.2億、訪問者数は約2900万人です。

サービス要件がデカい

多種多様な記事コンテンツを安定して表示し、幅広い会員種別に応じた画面切り替えを実装する必要があります。データドリブンな企業文化ゆえ、精密なログ送信など大規模なデータ計測が求められます。

歴史の重みがデカい

約150年の歴史を持つメディアとして、社会的に信頼されるアプリを提供する責務があります。そのため、ユーザーに安心して使っていただける品質の維持が重要になります。

課題だったレガシーコードへの対応

Androidアプリの歴史を振り返ると、2011年に初回リリース、2015年にリニューアルされています。黎明期からさまざまな技術スタックのアップデートを重ねてきたアプリであり、現在新しく作る機能にはKotlinやJetpack Composeといったデファクトスタンダードな技術を積極的に採用しています。例えば、Composeの新しいAPIを使った実装に加え、最近ではテストアサーションでkotlin-testを導入しました。

一方、2015年以前のコードベースを振り返ると、Javaで開発されていた時代にはアプリアーキテクチャガイドもなく、Model-View-Presenter（MVP）を採用していました。ライブラリもButter KnifeやPicasso、AsyncTaskLoader、Daggerなど、当時主流だったものを使っており、時代とともに技術スタックが入れ替わってきた歴史があります。

「デカい」サービスであるがゆえ、ユーザーが求める外部品質の維持・向上に多くのリソースを割いてきた結果、徐々にレガシーコードが蓄積していることが大きな課題となっています。最新技術を積極的に導入している一方、技術の変遷が複雑化しており、移行作業が追いついていない面もあります。さらに、日々のタスクの中でリファクタリングを進めてはいるものの、理想的な設計をメンバー全員で共有し、実現するところまでは至っていません。

チームの人数が多いため意思の統一に時間がかかり、レガシーコードへの対応や方針決定がスムーズにいかない場合もあります。ここでのレガシーコードとは、修正や拡張が難しく、かつテストを書きづらい古いコードを指します。例えば、既に非推奨になっているライブラリや設計手法、想定外の責務を抱えたクラス、テストが不足して管理が行き届かないコードなどが該当します。

もちろん、今はレガシーと呼ばれるコードも当時はモダンだったケースがほとんどです。ただ、技術や要件の変化が激しい中で、適応し続けられる柔軟な設計を持っていなかった点が課題として表面化している状況です。

実際にレガシーコードが多いと、機能の追加や変更に時間がかかり、デグレードに配慮しなければいけない範囲も広がります。バグ修正でも根本的な対応が難しく、Compose化など新技術への移行の際にも事前リファクタリングが多く発生します。こうした障害が積み重なると、開発速度の低下につながるリスクがあります。

「今と向き合う」「未来と向き合う」アプローチ

技術的課題の解決に向けて、まずは施策開発の合間に改善タスクを進めたり、施策直前に周辺リファクタリングを行ったりしていましたが、それだけでは根本的な解消には至りませんでした。長く成長してきたプロダクトだからこそ、より持続的に品質を高めるために腰を据えたアプローチが必要だと感じています。

そこで「今と向き合う」「未来と向き合う」という2つのアプローチを考えました。「今と向き合う」アプローチでは、「改善チーム」を新設し、担当者を明確化することで改善に集中できるようにしています。Androidチーム全体のリソースの約20%を割き、長期的に活動し続けられる体制を整えています。

改善チームが掲げる目標は、以下の3点です。

改善チームが不要になる状態をつくる

レガシーコードを完全に一掃するというよりは、「レガシーコードが自然消滅していく流れ」を恒常化させ、将来的に専任チームを持たなくても問題ない状態を目指します。

全画面でCompose化を進められる状態にする

レガシーコードが残ることでCompose化が阻まれないよう、事前リファクタリングを進めます。

全員が日常的に改善タスクに取り組める状態にする

改善チームだけが頑張るのではなく、誰もが当たり前にレガシーコードを減らしていける文化づくりを目指します。

具体的には、改善チームがどの部分を重点的に手を入れるかを整理し、Compose化の大きな障壁となるコードを優先的にリファクタリングしています。ほかのメンバーには日常的に修正しやすい箇所を積極的に改善してもらうように連携を図っています。

レガシーコード削減の成果や進捗が分かりづらいという課題を解消するため、可視化を進めています。具体的には、レガシーコードと定義した部分の利用ファイル数をカウントし、JSON Lines（JSONL）形式で書き出し、GitHub Actionsで定期実行。そのデータをBigQueryにインポートしてRedashで可視化しています。

これにより、削減が進む様子をグラフや数値で確認できるので、チーム全体で課題を捉えやすくなりました。「この部分がまだ残っている／減った」など、データを把握できることで、モチベーションの向上にもつながります。地味に見える改善作業ですが、数字で成果を示すことができるのは大きなメリットです。

レガシーコードの削減は「今と向き合う」改善チームの役割ですが、今後の技術トレンドを追い続けていかないと、モダンだったコードもいずれレガシーになり得ます。そこで「未来と向き合う」ため、Androidチーム全体にモブプログラミング（モブプロ）の文化を根付かせ、最新技術の情報共有や設計のディスカッションをチーム全員で行っています。

週1回のモブプロでは、1台のPCに対して7人が15分交代でコードを書くスタイルを取り、Google Meetで画面共有して在宅メンバーも参加できるようにしています。実際の内容は実プロダクトの機能を切り出して完全に新規アプリとして立ち上げ、GoogleのNow in Androidアプリやアーキテクチャガイドなどを参考にしつつ、新しい技術を試しています。

モブプロを導入した目的は、今後の全体設計の在り方全員が考えられるようにすること、コードを実際に書く中でGoogle推奨の設計が良い理由を理解すること、技術トレンドを追うことで導入の心理的ハードルを下げ、誰でも日常的にモダンなものを取り入れられるようにすることです。

モブプロ自体は学習が主目的なので、完成コードを本番アプリにマージするわけではありませんが、試した新技術を実際の開発でも取り入れる提案がされるようになり、レビュアーもその共通認識を既に持てているため、導入しやすいというメリットもありました。

また、Convention PluginやFakeを使ったテスト、Roomの多対多リレーションなど、試すだけでも大きな発見があり、今後の理想的な設計をどうするかチーム全員で意識合わせできるのは大きな成果だと感じています。

アプローチで進化した、組織のいま

当社の開発現場では、大規模サービスを提供しながらデータドリブンな文化を持ち合わせ、エンジニアがやりがいを感じられる環境を整えています。内部改善への取り組みとしては、専任の改善チームによってレガシーコードを削減し、Compose化をスムーズに進められるようにリファクタリングを推進。モブプロを活用したモダン技術の共有も行い、チーム全体の知識と視点をアップデートしています。

サービスを成長させつつ、内部改善も着実に進めたいという思いを持ったエンジニアの方をお待ちしています。^[1]