大規模Androidアプリで、技術をどう現場に適用するか。Yahoo! JAPANアプリで挑む「アジリティとサステナビリティ」の両立
Yahoo! JAPAN アプリの Android 開発者が、大規模プロダクトにおけるアジリティとサステナビリティの両立に向け、理想設計からの逆算や Server-Driven UI の検証など具体的なアプローチを語っている。
キーポイント
理想状態からの逆算設計
既存コードへの適合か完全書き換えかの二択に陥らず、まずプロダクトの「理想の状態」を定義し、現実とのギャップを段階的に埋めるアプローチを採用している。
トレンド技術の安易な導入回避
カンファレンス等の新技術をそのまま持ち込むのではなく、自社の制約や既存資産とどうアジャストさせるかに焦点を当て、運用可能な形に落とし込んでいる。
Server-Driven UI の検証
アプリのリリースサイクルに依存しない柔軟な画面更新を実現するため、Server-Driven UI（SDUI）の導入可能性を PoC として検証中である。
理想の状態から逆算した設計
既存の制約に合わせるのではなく、まずプロダクトの「理想の状態」を定義し、現実とのギャップを段階的に埋めることで改善の方向を見失わないようにする。
技術導入は運用可能性が前提
トレンドの技術をそのまま持ち込むのではなく、品質や保守性を損なわずに継続して運用できる形へアジャストさせることが重要である。
個人技ではなく仕組みで品質を担保
個人の努力に頼らず、レビューやCIによる自動チェックなどを活用し、「システム的に外せない」状態を作ることで再現性の高い品質を保つ。
影響分析・編集コメントを表示
影響分析
この記事は、単なる新技術の紹介ではなく、大規模かつ歴史あるプロダクトにおける技術導入の現実的な難しさと、それを克服するための設計思考（理想からの逆算、段階的改善）を提示しています。開発現場において「アジリティ」と「サステナビリティ」のバランスを取るための具体的なフレームワークやマインドセットを提供しており、大規模アプリ開発に携わるエンジニアにとって非常に参考になる内容です。
編集コメント
新技術の導入において「理想と現実」のバランスをどう取るかは、多くの大規模開発現場が直面する普遍的な課題です。この記事は、抽象的な理念ではなく具体的な検証プロセス（PoC）を通じて解決を図る姿勢を示しており、実務家にとって示唆に富んでいます。
大規模なネイティブアプリの開発では、新しい技術を知っているだけでは足りません。難しいのは、それを歴史ある現場へどう適用するかです。
ユーザー影響の大きいプロダクトでは、素早く価値を届ける「アジリティ（速度）」だけを優先することも、品質を保ち長く改善し続ける「サステナビリティ（保守性）」だけを優先することもできません。いま求められているのは、その両方を成立させる設計と改善です。
今回話を聞いたのは、Yahoo! JAPANアプリのAndroid開発に携わる高橋柊蔵（以下、しゅーぞー）です。学生時代のインターンやDroidKaigiをきっかけに入社し、現在はAndroid開発を軸に、アプリ全体の設計改善や仕組み化にも取り組んでいます。
インタビューでは、大規模Androidアプリ特有の難しさ、モダンな技術を既存プロダクトへ適用するための考え方、そしてしゅーぞーさんが語る「アジリティとサステナビリティ」の両立について聞きました。
─ まず、これまでの経歴と今の業務について教えてください。
しゅーぞー：**2020年に新卒で入社しました。学生時代にインターンへ参加したことや、DroidKaigiで社員と話したことが、今の仕事につながっています。
現在はYahoo! JAPANアプリのAndroid開発に携わっています。機能開発だけでなく、アプリ全体を継続的に改善していくための設計や基盤づくりにも取り組んでいます。
─ 機能開発と全体改善、その中でも特に「全体の持続性」を意識されるようになった背景を教えてください。**
しゅーぞー：**そうですね。もともと一部分だけを見ているよりも、アプリ全体をどう持続的に良くしていくかに関心がありました。大規模なプロダクトでは、部分最適だけではすぐに限界が来ます。だからこそ、今の機能開発を進めながら、将来の改善余地も残せる形を考えるようにしています。
─ 大規模なAndroidアプリならではの難しさは、どこにありますか。**
しゅーぞー：**一番大きいのは、既存資産と新しい設計を共存させなければいけないことです。歴史のあるプロダクトでは、コードも機能も長い時間をかけて積み上がっています。
その中で新しい技術や設計を入れようとしても、きれいに置き換えられるとは限りません。既存の実装やビジネスロジック、周辺の仕組みと密接につながっているので、現場ではその接続面まで含めて考える必要があります。
理想の状態から逆算して、設計を決める
─ そうした制約のある現場で、設計判断はどのように行っていますか。**
しゅーぞー：**今あるコードに合わせるか、全部新しくするか、という二択で考えないようにしています。まずは、このプロダクトにとって理想の状態は何かを置くことを大事にしています。
その上で、現実とのギャップをどう埋めるかを考えます。制約があるから理想を捨てるのではなく、理想を先に置いたうえで、どこまでを今やるか、どこを段階的に進めるかを決めていくイメージです。
─ 「理想の状態」を先に置くことが重要なのですね。**
しゅーぞー：**はい。大規模プロダクトでは、現状に引っ張られやすいと思っています。でも、現状だけを基準にすると、改善の方向を見失いやすくなります。
理想を置いておくと、いま起きているコンフリクトや制約も、単なる障害ではなく、どこを直すべきかを教えてくれるサインになります。
モダンな技術を、そのまま持ち込まない
─ 「現実の制約を見ながら段階的に」というお話がありましたが、いわゆるトレンドのモダンな技術を、そのまま持ち込めばいいわけではない、ということでしょうか。**
しゅーぞー：**そうですね。技術カンファレンスで紹介されるような技術はもちろん参考になります。ただ、本当に難しいのは、それを自分たちのプロダクトで成立させることです。
大事なのは、新しい技術をそのまま持ち込むことではなく、いまのプロダクトにどうアジャストするかだと思っています。現実の制約に向き合いながらも、理想に近づけるやり方を探していくことに価値があります。
─ 具体的に、いま注力している取り組みはありますか。**
しゅーぞー：**1 つは、Server-Driven UI（SDUI）で課題が解決できないかを検証する PoC です。ネイティブアプリは、どうしてもアプリのリリースサイクルに画面変更のスピードが影響されます。
そこで、アプリの更新を待たずに UI をより柔軟に届けられる仕組みが成立するかを、まずは PoC として確かめています。もちろん自由度だけを上げれば良いわけではなく、品質や保守性を落とさずに成立するかまで含めて見極める必要があるので、そこが設計の難しいところでもあり、面白いところでもあります。
─ 技術的な新しさだけではなく、運用できる形にすることが前提なのですね。**
しゅーぞー：**そうです。大規模プロダクトでは、作れたかどうかよりも、継続的に使えるかどうかの方が重要です。新しい技術を導入する時も、長く維持できるか、チームで扱えるかを強く意識しています。
品質は、個人技ではなく仕組みで作る
─ そうした考え方は、日々の Android 開発にもつながっていますか。**
しゅーぞー：**かなりつながっています。大規模なアプリでは、個人の頑張りだけで品質を保つのは難しいです。だから、設計やガイドライン、共通のルールで再現性を高める必要があります。
例えば Android の技術ガイドラインでは、UI コンポーネントを特定の画面やユースケースに過度に依存させないことや、命名や責務を揃えることを重視しています。そうすることで、新しい機能を追加しても構造が崩れにくくなります。
─ ルールがあるだけでは、実際には浸透しにくい場面もありそうです。**
しゅーぞー：**その通りです。ドキュメントを書くだけでは十分ではありません。読む人によって理解の差も出ますし、忙しい現場ではどうしても運用にばらつきが出ます。
だからこそ、ルールを人に覚えてもらうだけではなく、自然と守られるような仕組みに寄せていくことが大切だと思っています。設計の意図やガイドラインを、レビューや CI（継続的インテグレーション）による自動チェックなどのツール、開発フローの中に埋め込んでいく発想です。「人が気をつける」のではなく「システム的に外せない」状態を作るイメージですね。
組織をまたいで改善を回し続ける
─ 技術改善を継続するうえで、組織面で大事だと感じていることは何ですか。**
しゅーぞー：**箱だけを作ってもうまくいかない、というのは強く感じています。横断チームや専門組織を作れば解決するわけではなく、そこにいる人たちが同じ課題意識を持っていることが重要です。
まずは現場で起きている痛みを一緒に解く。その積み重ねがあって初めて、仕組みや体制が機能するようになると思っています。
─ 実際に、うまくいかなかった経験もあったのでしょうか。**
しゅーぞー：**ありました。体制を作っただけでは役割が曖昧になったり、期待したほど前に進まなかったりすることがありました。
一方で、職種をまたいで共通の課題を持ち寄りながら改善する取り組みは、継続しやすいと感じています。重要なのは、きれいな理想図を掲げることより、現場で意味のある改善を回し続けることだと思います。
大規模プロダクトの面白さは、両立の解を探し続けること
─ しゅーぞーさんは、大規模プロダクトで働く面白さをどう捉えていますか。**
しゅーぞー：**単に規模が大きいとか、影響範囲が広いというだけではないと思っています。面白いのは、アジリティとサステナビリティの両方を成立させる解を探し続けることです。
ユーザーに価値を素早く届けるには速度が必要です。でも、速度だけを追えば壊れやすくなります。逆に守ることだけを優先すると、今度はプロダクトが進化しません。
大規模プロダクトでは、その両方を諦めずに成立させる必要があります。しかも、正解を外から持ってこられるわけではなく、自分たちで見つけて、実際の仕組みとして実装しなければいけません。そこが一番面白いところだと思います。
─ その考え方は、これから挑戦したい人へのメッセージにもつながりそうです。**
しゅーぞー：
そうですね。決まったレールの上で開発するより、自分たちでより良い形を探しながら前に進めたい人には、面白い環境だと思います。
ギャップを見つけて埋めることが好きな人、守りと攻めを分けて考えるのではなく、両立するポイントを探したい人には合っているはずです。
技術を、現実のプロダクトで生かしたい人へ
大規模な Android アプリ開発では、派手な技術導入よりも難しいことがあります。それは、現実の制約がある中で、理想の設計をあきらめずに前へ進めることです。
しゅーぞーさんの話から見えてきたのは、モダンな技術を知っていること自体よりも、それをどう現場に適用し、どう継続可能な仕組みに変えていくかが重要だということでした。
アジリティとサステナビリティ。
一見すると相反するこの 2 つを、両立できるものとして捉え、実際のプロダクトの中で解いていく。その難しさと面白さこそが、Yahoo! JAPAN アプリの Android 開発の魅力なのかもしれません。
原文を表示
大規模なネイティブアプリの開発では、新しい技術を知っているだけでは足りません。難しいのは、それを歴史ある現場へどう適用するかです。
ユーザー影響の大きいプロダクトでは、素早く価値を届ける「アジリティ（速度）」だけを優先することも、品質を保ち長く改善し続ける「サステナビリティ（保守性）」だけを優先することもできません。いま求められているのは、その両方を成立させる設計と改善です。
今回話を聞いたのは、Yahoo! JAPANアプリのAndroid開発に携わる高橋柊蔵（以下、しゅーぞー）です。学生時代のインターンやDroidKaigiをきっかけに入社し、現在はAndroid開発を軸に、アプリ全体の設計改善や仕組み化にも取り組んでいます。
インタビューでは、大規模Androidアプリ特有の難しさ、モダンな技術を既存プロダクトへ適用するための考え方、そしてしゅーぞーさんが語る「アジリティとサステナビリティ」の両立について聞きました。
─ まず、これまでの経歴と今の業務について教えてください。
しゅーぞー：**2020年に新卒で入社しました。学生時代にインターンへ参加したことや、DroidKaigiで社員と話したことが、今の仕事につながっています。
現在はYahoo! JAPANアプリのAndroid開発に携わっています。機能開発だけでなく、アプリ全体を継続的に改善していくための設計や基盤づくりにも取り組んでいます。
─ 機能開発と全体改善、その中でも特に「全体の持続性」を意識されるようになった背景を教えてください。**
しゅーぞー：**そうですね。もともと一部分だけを見ているよりも、アプリ全体をどう持続的に良くしていくかに関心がありました。大規模なプロダクトでは、部分最適だけではすぐに限界が来ます。だからこそ、今の機能開発を進めながら、将来の改善余地も残せる形を考えるようにしています。
─ 大規模なAndroidアプリならではの難しさは、どこにありますか。**
しゅーぞー：**一番大きいのは、既存資産と新しい設計を共存させなければいけないことです。歴史のあるプロダクトでは、コードも機能も長い時間をかけて積み上がっています。
その中で新しい技術や設計を入れようとしても、きれいに置き換えられるとは限りません。既存の実装やビジネスロジック、周辺の仕組みと密接につながっているので、現場ではその接続面まで含めて考える必要があります。
理想の状態から逆算して、設計を決める
─ そうした制約のある現場で、設計判断はどのように行っていますか。**
しゅーぞー：**今あるコードに合わせるか、全部新しくするか、という二択で考えないようにしています。まずは、このプロダクトにとって理想の状態は何かを置くことを大事にしています。
その上で、現実とのギャップをどう埋めるかを考えます。制約があるから理想を捨てるのではなく、理想を先に置いたうえで、どこまでを今やるか、どこを段階的に進めるかを決めていくイメージです。
─ 「理想の状態」を先に置くことが重要なのですね。**
しゅーぞー：**はい。大規模プロダクトでは、現状に引っ張られやすいと思っています。でも、現状だけを基準にすると、改善の方向を見失いやすくなります。
理想を置いておくと、いま起きているコンフリクトや制約も、単なる障害ではなく、どこを直すべきかを教えてくれるサインになります。
モダンな技術を、そのまま持ち込まない
─ 「現実の制約を見ながら段階的に」というお話がありましたが、いわゆるトレンドのモダンな技術を、そのまま持ち込めばいいわけではない、ということでしょうか。**
しゅーぞー：**そうですね。技術カンファレンスで紹介されるような技術はもちろん参考になります。ただ、本当に難しいのは、それを自分たちのプロダクトで成立させることです。
大事なのは、新しい技術をそのまま持ち込むことではなく、いまのプロダクトにどうアジャストするかだと思っています。現実の制約に向き合いながらも、理想に近づけるやり方を探していくことに価値があります。
─ 具体的に、いま注力している取り組みはありますか。**
しゅーぞー：**1つは、Server-Driven UI（SDUI）で課題が解決できないかを検証するPoCです。ネイティブアプリは、どうしてもアプリのリリースサイクルに画面変更のスピードが影響されます。
そこで、アプリの更新を待たずにUIをより柔軟に届けられる仕組みが成立するかを、まずはPoCとして確かめています。もちろん自由度だけを上げれば良いわけではなく、品質や保守性を落とさずに成立するかまで含めて見極める必要があるので、そこが設計の難しいところでもあり、面白いところでもあります。
─ 技術的な新しさだけではなく、運用できる形にすることが前提なのですね。**
しゅーぞー：**そうです。大規模プロダクトでは、作れたかどうかよりも、継続的に使えるかどうかの方が重要です。新しい技術を導入する時も、長く維持できるか、チームで扱えるかを強く意識しています。
品質は、個人技ではなく仕組みで作る
─ そうした考え方は、日々のAndroid開発にもつながっていますか。**
しゅーぞー：**かなりつながっています。大規模なアプリでは、個人の頑張りだけで品質を保つのは難しいです。だから、設計やガイドライン、共通のルールで再現性を高める必要があります。
例えばAndroidの技術ガイドラインでは、UIコンポーネントを特定の画面やユースケースに過度に依存させないことや、命名や責務を揃えることを重視しています。そうすることで、新しい機能を追加しても構造が崩れにくくなります。
─ ルールがあるだけでは、実際には浸透しにくい場面もありそうです。**
しゅーぞー：**その通りです。ドキュメントを書くだけでは十分ではありません。読む人によって理解の差も出ますし、忙しい現場ではどうしても運用にばらつきが出ます。
だからこそ、ルールを人に覚えてもらうだけではなく、自然と守られるような仕組みに寄せていくことが大切だと思っています。設計の意図やガイドラインを、レビューやCIによる自動チェックなどのツール、開発フローの中に埋め込んでいく発想です。「人が気をつける」のではなく「システム的に外せない」状態を作るイメージですね。
組織をまたいで改善を回し続ける
─ 技術改善を継続するうえで、組織面で大事だと感じていることは何ですか。**
しゅーぞー：**箱だけを作ってもうまくいかない、というのは強く感じています。横断チームや専門組織を作れば解決するわけではなく、そこにいる人たちが同じ課題意識を持っていることが重要です。
まずは現場で起きている痛みを一緒に解く。その積み重ねがあって初めて、仕組みや体制が機能するようになると思っています。
─ 実際に、うまくいかなかった経験もあったのでしょうか。**
しゅーぞー：**ありました。体制を作っただけでは役割が曖昧になったり、期待したほど前に進まなかったりすることがありました。
一方で、職種をまたいで共通の課題を持ち寄りながら改善する取り組みは、継続しやすいと感じています。重要なのは、きれいな理想図を掲げることより、現場で意味のある改善を回し続けることだと思います。
大規模プロダクトの面白さは、両立の解を探し続けること
─ しゅーぞーさんは、大規模プロダクトで働く面白さをどう捉えていますか。**
しゅーぞー：**単に規模が大きいとか、影響範囲が広いというだけではないと思っています。面白いのは、アジリティとサステナビリティの両方を成立させる解を探し続けることです。
ユーザーに価値を素早く届けるには速度が必要です。でも、速度だけを追えば壊れやすくなります。逆に守ることだけを優先すると、今度はプロダクトが進化しません。
大規模プロダクトでは、その両方を諦めずに成立させる必要があります。しかも、正解を外から持ってこられるわけではなく、自分たちで見つけて、実際の仕組みとして実装しなければいけません。そこが一番面白いところだと思います。
─ その考え方は、これから挑戦したい人へのメッセージにもつながりそうです。**
しゅーぞー：
そうですね。決まったレールの上で開発するより、自分たちでより良い形を探しながら前に進めたい人には、面白い環境だと思います。
ギャップを見つけて埋めることが好きな人、守りと攻めを分けて考えるのではなく、両立するポイントを探したい人には合っているはずです。
技術を、現実のプロダクトで生かしたい人へ
大規模なAndroidアプリ開発では、派手な技術導入よりも難しいことがあります。それは、現実の制約がある中で、理想の設計をあきらめずに前へ進めることです。
しゅーぞーさんの話から見えてきたのは、モダンな技術を知っていること自体よりも、それをどう現場に適用し、どう継続可能な仕組みに変えていくかが重要だということでした。
アジリティとサステナビリティ。
一見すると相反するこの2つを、両立できるものとして捉え、実際のプロダクトの中で解いていく。その難しさと面白さこそが、Yahoo! JAPANアプリのAndroid開発の魅力なのかもしれません。
関連記事
マイクロソフトの「Project Solara」はアプリではなくエージェント向けに設計された Android OS
マイクロソフトが Build 2026 で発表した「Project Solara」は、従来のアプリ実行を前提とせず、AI エージェントの実行に特化した新しい Android ベースのオペレーティングシステムである。
Google、AI ディープフェイクによるなりすまし詐欺対策として偽の通話検出機能を展開
Google は、AI を利用したディープフェイク音声によるなりすまし詐欺からユーザーを保護するため、偽の通話を検知する新機能を全世界に展開しました。
Google の電話アプリが、連絡先のなりすまし詐欺を検知して警告する機能を追加
Google は、AI を利用したなりすまし詐欺からユーザーを守るため、電話アプリに新機能を導入します。この機能は、詐欺師が連絡先と同じ電話番号から着信した場合に、通話内容を疑わしいものとしてフラグ付けし、ユーザーに警告を発します。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み