DroidKaigi 2026に参加しました！

テクノロジー

ryu_kobayashi / 2026.11.09

はじめに

「ニフティ不動産」アプリのiOS開発を担当している、ryu-kobayashiです。

先日（9月1日〜9月3日）開催された「DroidKaigi 2026」に現地参加してきました。

DroidKaigiは、Android技術情報の共有とコミュニケーションを目的として開催される国内最大級のカンファレンスです。今年もベルサール渋谷ガーデンにて3日間にわたりオフライン開催されました。

Androidアプリ開発の最新動向はもちろん、UI/UX、テスト、アーキテクチャなど、モバイルアプリ開発全般に関わる幅広い知見が共有される熱量の高いイベントです。

DroidKaigi への参加は初めてで、普段はiOSアプリメインでの開発なのですが、とても勉強になるカンファレンスだったので、その感想を紹介しようと思います。

DroidKaigi 2026 の開催概要

(写真：DroidKaigi 2026 Googleフォトより）

day1（Event Day）（9/1（火））
- ワークショップ
- ポスターセッション
  - 発表内容をまとめた大きなポスターを会場のボードに貼り、発表者がその前で参加者に直接説明や質問の対応をする双方向の発表形式の催しです。
day2（9/2（水） 10:30 – 19:20）
- オープニング
- 様々なスピーカーによるトーク
- 特定のテーマについて話せるMeetUp
- AfterParty
day3（9/3（木） 10:00 – 18:40）
- 様々なスピーカーによるトーク
- クロージング

特に学びのあったセッション

私は普段iOSがメインということもあり、プラットフォームに依存しないソフトスキル系のセッションを多めに聴講しました。

その中で特に印象に残った3つのセッションを紹介します。

なんとかする力〜Androidエンジニアからマネージャー、さらにその先へ？〜

このセッションでは、マネージャーとは「不確実性に向き合うポジション」であるという切り口から、日々の業務への向き合い方について解説されていました。

開発現場には「何を・いつまでに・どうやるか」が決まっている（不確実性が低い）タスクもあれば、「期日・デザインが未定」「アプリのユーザー離脱を減らしたいというフワッとした要望」といった不確実性が高いタスクも溢れています。

この不確実性に対して「どうしたら良いですか？」と他人に判断をすべて委ねてしまうのではなく、「不明な箇所を特定して関係者に確認し、やれるところから着手していく（不確実性を下げていく）」ことこそが「なんとかする力」である、というお話でした。自ら不明点を解消するための動きができている状態は、まさに「セルフマネジメントができている状態」と言えます。

この力を身につけるためには、以下のステップが重要とのことでした。

新しい経験をする
- 同じことの繰り返しから抜け出し、視点や引き出しを増やす
観測・分析する
- 「業務はどう進んでいるか」「周りは何に困っているか」「何をすれば改善できるか」を観察する
言葉にする・周囲に表明する:
- 言語化して周囲に伝えることで、進め方のすり合わせや協力を得る

「なぜここまでやらなきゃいけないのか？」という問いへの答えは、「なんとかしない（不確実性の解消を他人に委ねる）状態を続けると、自分の仕事が他人次第になってしまい、結果的に自分が一番ストレスフルになるから」というものでした。AIがどれだけ発展しても、「なんとかするべき対象（課題）」を見つけるのは人間の役割だという言葉も非常に印象的でした。

最近の業務では、事前に不明な点や話し合いが必要な箇所は洗い出して共有するように意識しているため、自身における「セルフマネジメント」は少しずつできるようになってきたと感じています。次のステップとしては周囲の状況を「観測・分析する」癖をつけていきたいです。自分のタスクをこなすだけではなく、施策全体が円滑に進むような立ち回りができるエンジニアを目指していきたいと思います。

なぜエンジニアの意見は届かないのか——エンジニアがプロダクトの意思決定に影響を与えるための実践Tips

このセッションは、「自分の意見が通らない」「なんでこの仕様に？」と諦めるのではなく、PdM（プロダクトマネージャー）と建設的に協働し、意見をプロダクトに反映させるためのマインドセットを学べるものでした。

日々の業務の中で、エンジニアの意見が届かない根本的な原因は、「エンジニアにPdMのコンテキストが不足していること」と「ステークホルダーに説明するためのロジックが不足していること」にあると解説されていました。PdMは売上などの「目的」から逆算し、経営層や他部署を含めて「網羅的」に判断します。一方でエンジニア側には、工数や技術的制約といった専門領域が見えています。このコンテキストの差を埋めるため、エンジニアから自発的に動く必要があります。

具体的な実践Tipsとして以下の4点が挙げられました。

待たずに動く
- 施策の進みが悪ければ自らたたき台を作り、小さな違和感は後で爆発する前に早期エスカレーションする。
目的を共通言語にする
- 意見が対立した時は真正面からぶつかるのではなく、「そもそもの目的」に立ち返ってフラットに議論する。
点ではなく面で伝える
- 「理論上は可能」だけで終わらせず、実装の難易度、代替案、KPIへの影響などを添えて専門領域の死角を補う。
推奨して委ねる
- 目的と網羅性を考慮した「推奨案」を提示した上で、最終的な意思決定はPdMに委ねる。

これらを実践することは、不本意な仕様や無理なスケジュールによる負債から「エンジニア自身を守る」ことにも直結します。技術的な可否を答えるだけでなく、PdMと同じ目線に立ってコミュニケーションを取ることの重要性を再認識できました。

普段の業務を振り返ると、技術的にできる・できない、工数がかかる・かからないだけを伝えてしまい、PdM側のコンテキストを踏まえた説明が不足していた場面があったと感じています。今後はPdMと同じ目線に立ち、「別のアプローチはないか」「目的を満たしつつ工数も抑えられる方法はないか」といった具体的な推奨案や代替案をセットで考えて提案することを意識していきたいと思います。

UI仕様を「見えるもの」にする〜 Compose Screenshot Testing とギャラリーで支える、AIエージェント時代のAndroid UI開発〜

このセッションは、AIエージェントを活用した並列実装が進む中でボトルネックとなる「人間によるUIの確認作業」を、Compose Screenshot Testingを用いてどのように効率化・自動化するかを学べるものでした。

AIの進化により、Issueを細かく切ってUIコンポーネント単位で並列実装を依頼できるようになりました。しかし、細かな実装が上がるたびにAndroid Studioを立ち上げてPreviewを確認するのは非常に手間です。そこで、プラグインを入れるだけで手軽に導入できるGoogle公式の「Compose Screenshot Testing」を活用し、普段書いているPreviewをそのままテスト（スクリーンショットの差分比較）として利用するアプローチが紹介されていました。

運用する中で発生した具体的な課題と、その解決策のノウハウも非常に実践的でした。

PR上での画像差分の確認
- 画像がうまく表示されないGitHubのDiff Viewに頼るのをやめ、Reference（参照画像）、Actual（実際の画像）、Diff（差分）の画像をPRの本文に直接表示させる仕組みを構築（マージ前に消す仕組みも導入）。
ネットワーク画像の表示
- Previewが白飛びしてしまう問題に対しては、プレースホルダーを描画するように対応。
命名規則のバラつき
- AIが生成する関数名やテストクラス名が揺れる問題に対し、命名規約を人間に周知するのではなく、テストを書くAI側に事前設定して制限をかける。

さらに、生成したスクリーンショットを活用して「アプリの全画面・全状態がわかるHTMLカタログ」を作成し、社内ポータルに常設しているという事例は、アプリチーム以外のメンバーも容易に仕様確認ができる素晴らしい取り組みだと感じました。

個人的に、UIテストは過去に一度導入を断念した経験があったため、実践的な運用例を聞くことができてとても良かったです。iOSでいえば、可能な限りUIをSwiftUIで細かくコンポーネント化していく必要がありそうですが、これが実現できれば開発体験が飛躍的に向上する素敵な取り組みだと感じました。

まとめ

今回初めてDroidKaigi に参加しましたが、Android特有の技術にとどまらず、AIを活用した開発・テスト・運用の最前線の知識を蓄えることができ、非常に有意義な時間となりました。

また、ソフトスキル系のセッションでは、自分がこれから伸ばして行きたい箇所をピンポイントで解説されているセッションもあり、今後の業務に向けて素晴らしい刺激きを得ることもできました。OSの垣根を超えて学べる要素が満載だったので、来年も参加したいと思います！

当社ではiOSDC JapanやDroidKaigi、AWS Summitといった最新の技術を取り扱うカンファレンスへの参加を積極的に支援しています。気になった方はぜひ採用情報をご覧ください。

掲載内容は、記事執筆時点の情報をもとにしています。