はじめに

タイミーでAndroidエンジニアをしているふなちです。

まだPart 1を読んでないよ！と言う方は、ぜひPart 1も読んでいただけると嬉しいです。

本記事（Part 2）では、Part 1から続いてエンジニアメンバーによるセッションレポートと、タイミーのブース出展の様子をお届けします 📣

エンジニアによるセッションレポート

紹介するセッション：Gemini エージェントで Android Studio 開発を高速化

タイミーではdroidkaigiでブースを出しており、多く方に足を止めていただくことができました。

ブースに立っている中で初日にどこか見覚えのある方がいらっしゃり、「お会いしたことありましたっけ？」と聞いてみたら、特に面識はないとのこと… 翌日に聴講したセッションでその方が登壇しており、その時に気づきました。

「あの人、YouTubeのGeminiでE2Eテストの動画に出てた人だ！！」

セッションではYouTubeで見て未来に思いを馳せていたGeminiが自然言語で記述されたテストを実行するJourneyのライブデモを見ることができ、ちょうど当日にAndroid Studio Canaryでリリースされたばかりとのことでした。

デモでは日本語で記述して実行結果のスクリーンショットとその結果とその根拠をテキストで出力しており、メンテナンスコストが低いE2Eテストの実装ができそうだと感じました。

後にAsk the speakerに質問をしにいき、見覚えがあった理由の話もしたのですが、「彼はYouTube Famousだからね」と一緒に登壇されていたMandaさんも笑っていました。

「CIで動くようになるのはいつですか？」と伺ったところ、絶賛開発中とのことでした、期待です。

DroidKaigiから帰ってさっそくタイミーのプロジェクトで試してみましたが、まだ動かなそう…？Build Logic使っているせいか、まだうまく読めてないような気がしていますが、まだしっかりとは見れていません。安定的に使えるようになったら実際の運用で使えるか試してみたいと思いました。

紹介するセッション：Cache Me If You Can

RyuNen344さんによる「Cache Me If You Can」は、多くのAndroid開発者が"何となく"で使ってしまいがちなGradleのキャッシュ機構に深く迫るセッションでした。

私自身、Gradleはブラックボックス同然で、ビルドエラーが起きるたびにStack Overflowを彷徨う…そんな場当たり的な対応を繰り返していました。このセッションは、そんな私のGradleに対する苦手意識を打ち破る、まさに目から鱗の内容でした！

セッションで得た知識を元にさっそくプロジェクトのGradle設定を見直したところ、ビルドパフォーマンスにつながる以下の改善を実現できました。

Configuration Cacheと並列実行の有効化 （org.gradle.configuration-cache.parallel=true）
環境変数を参照していた System.env() を Provider API に置き換え
通常のビルドでは不要なタスクを提供するプラグインの適用方法を最適化

これまではConfiguration Cacheが効かずに頭を悩ませることも多々ありましたが、今ではこのセッションで学んだ知識を武器に、自信を持って原因を調査できる気がしています👍

「Gradleのビルド遅いな…でもよくらからないから後回し！」となっている、そこのあなた！ぜひ本セッションのアーカイブ動画を視聴して、一緒にGradleの世界を切り拓いてみませんか？😊

DevRelのみーた（@earlgrayMK）です。

今回タイミーではゴールドスポンサーとしてブースを出展しました。

多くの方にお立ち寄りいただき、ありがとうございます！

スキマバイトとしてアンケートのお仕事をみなさんにお願いし、たくさんの回答をいただいたのでご紹介します。

この根深い課題に対して、タイミーのAndroidエンジニアがどのように向き合っているのか、具体的な取り組みをまとめました。

1. OSバージョン・デバイスの多様性への対応

自動テストの活用
- テスト自動化ツール「MagicPod」を導入し、サポート対象OSの上下限バージョンで毎日テストを実行。広範囲の環境を効率的にカバーしています。
多様な物理デバイスでの検証
- 外部のQAチームや、クラウド型検証サービス「RemoteTestKit」を活用。さらに、社内Slackで特定端末を持つメンバーに協力を仰ぐなど、物理デバイスでの実機検証を徹底しています。個人的に折りたたみスマホを購入し、検証に活かす開発者もいます。

2. 既存コードベースの保守・改善

進捗の「見える化」と「仕組み化」
- リファクタリングの進捗をLinterのwarning数やモジュールの分割状況などで定量的に可視化し、チーム全体で課題意識を共有する仕組みを重視しています。デザインシステムの構築やEdge-to-Edge対応もその一環です。
プロダクトオーナー（PO）との共通理解
- 技術的負債の解消がプロダクトの価値向上に不可欠であるという点をPOと共有。これにより、計画的なリファクタリングを実現しています。
適切なエンジニアリソースの確保
- リソース不足が負債の蓄積と開発の悪循環を招かないよう、Androidエンジニアの適切なリソース確保に努めています。
バランスの取れた技術選定
- 新技術の導入時は、必ずその妥当性をチームで議論し、合意形成を図ります。これにより、将来の負債化を防ぎ、技術的なバランスを保っています。（この領域では、特にエンジニアの村田が重要な役割を担っています。）
高いサービスレベル目標（SLO）の維持
- プロダクトの品質目標を高く設定し、それを維持する文化が、コードベースの健全性を保つ動機付けにもなっています。

両課題に共通する、タイミーの強み

厚いチーム体制
- チームメンバーが多いため、新規のプロダクト開発と並行しながら、検証やリファクタリングといった改善活動を分担して進められる体制が強みです。
「地道な努力」の文化
- メンバー全員が「地道に改善を続けるしかない」という共通認識を持っており、日々の継続的な取り組みを大切にしています。