はじめに
みなさんこんにちは！
クラシルリワードでAndroidの内定者インターンをしているだっちょです！
今回は、9/10~9/12に開催されたDroidKaigiに初スポンサーとしてブース出展という形で参加してきました！
以前はスカラーシップで、今回はスポンサーとして参加したので、このレポートでは２つの視点で体験した内容を届けれたらと思います！
Day1
今年はスポンサーとして参加し、念願の初日イベント参加が叶いました！
初日は、JetBrainsのDeveloper Advocate 2名による、Kotlin Multiplatform (KMP) と Compose Multiplatform (CMP) のワークショップに参加しました。
以前から挑戦したいと思っていた分野のハンズオンに参加でき、とても楽しかったです。
このワークショップは、特に初心者や未経験の方にこそおすすめです。
ハンズオン形式なので、分からないことや理解に時間がかかる部分をその場で質問できるのが大きな魅力だと感じました。
個人的には、KMPの expect / actual のように、抽象化と具象化を記述レベルで分ける仕組みが非常に書きやすい点も新たな発見でした。
また、参加者の中には普段Androidを専門としないiOSエンジニアの方などもいらっしゃり、未経験の領域へ果敢に挑戦するその姿勢に大いに刺激を受けました。
Day2
ブース編
2日目は、自社ブースでの来場者対応と、セッションの聴講をしました。
弊社のブースでは、「AIでcode」と「X（旧Twitter）のポスト数に応じた募金企画」という2つの企画を実施しました。
「AIでcode」は、参加者にプロンプトを入力していただき、そのプロンプトで生成されたUIが、いかに完成形に近づけられるかを競うゲームです。
高得点を獲得された方には、特別な景品をお渡ししました。
もう一つの「X（旧Twitter）のポスト数に応じた募金企画」は、ハッシュタグ「#every_step_every_reward」を付けて投稿していただくと、お一人様につき100円を弊社が寄付するという取り組みです。
この活動はDroidKaigiだけでなく、iOSDCやKaigi on Railsでも継続していますので、ぜひSNSなどで検索してみてください。
弊社も初のブース出展で、本番でドタバタしてしまって色んなものが足りないなと痛感しました...
ただ、ブースに来てくださった来場者の方々に興味を持ってもらったり、楽しんでいただけたのは去年とは違った経験でとても新鮮で楽しかったです！
（次回DroidKaigiにまたブース出展する機会があれば、もっと面白い企画を組んでみたいですね！）
セッション編
共有と分離 ─ Compose Multiplatform “本番導入” の設計指針
KMPとCMPを用いて、プラットフォーム間で共通化しきれない開発による課題やその課題の見極め方法などを聞かせてもらいました！
STORESさんのキッチンディスプレイではすでに91%が共通コード（commonMain）で実装されているそうです。
かなり高い割合で実装できている方法として、プロダクトとしてプラットフォーム依存のライブラリがKMPに対応しているかどうかなどklibs.ioを確認、CMPの標準ライブラリで共通UIを作成できるかなどの判断を事前にしておくことが大切だそうです。
逆に共通化できないAPI（Map,WebView等）はネイティブ対応する必要があり、iOS側ではObjective-Cのヘッダーを元に生成しているため、Objective-Cには表現できないSwift製のAPIは対応できないなど、まだ問題点はありそうですね...
（JetBrainsさんに期待）
また、FirebaseRemoteConfigなども共通化できずに、それぞれのプラットフォーム毎に記載する必要があるのでこちらも期待
セッション全体を通して、KMPやCompose Multiplatform（CMP）の進化に驚きました！
以前と比べて機能が大幅に充実しており、開発者にとって非常に使いやすくなっている印象です。
Androidエンジニアとしてのキャリア
去年に続いてmhidakaさんのセッションを２年連続聴講しました！
今回は技術というよりも、マインドや考え方に寄ったセッションだと感じました。
- 知らなければとにかく行動をする
- 将来に対する仮説と検証を繰り返す
「知らなければとにかく行動する」 「将来に対する仮説と検証を繰り返す」 という言葉は、まさに私がこれまで実践してきたことそのものでした。
これまで多くの失敗も経験しましたが、今ではその一つ一つが今の自分の糧になっていると感じています。
そのため、このセッションは自分の考え方が肯定されるような、まるで「答え合わせ」をしているかのような感覚で、非常に興味深く聴くことができました。
- お金等価値観ではなくて、やりたいことを大切にしていく
「お金といった目先の価値ではなく、自分が本当にやりたいことを大切にする」というお話も、キャリアがまだ始まっていない自分にとって、心の底から重要だと感じました。
確かに、目先の利益は魅力的に映るかもしれません。
しかし、それ以上に長期的な視点で自分の将来を見つめることの大切さに改めて気づかされました。
(ﾌﾑﾌﾑ...)
Day3
ミートアップ編
3日目には初めてミートアップに参加しました！
ミートアップは時間帯によってテーマが分かれており、私は「AI活用」「マネジメント」「キャリアプラン」の3つのセッションに参加しました。
(時間別にテーマが変わることを初めて知ったので、次回は事前に話したいテーマを把握して参加たいですね...)
僕は「キャリアプラン」のテーマでお話をしてきました。
まだキャリアすら始まっていませんが、m.hidakaさんがおっしゃていた 「将来に対する仮説と検証を繰り返す」 を実行するチャンスだったので、貴重な経験談をたくさん聞いてきました！
特に、転職する際においても昨今のAI時代においては技術スキルという点は昔よりも重視されていない傾向にあるようです。
それよりも、「技術+XXX」という技術スキルプラス別のスキルが必要とされるらしいです。
特にどの企業でも多かったのが、当事者意識という意味での「オーナーシップ」が重要視されるらしいです。
オーナーシップは弊社のバリューにもなっているので納得ですね
セッション編
Android値受け渡し大全 〜設計を制する者が「渡す」を制す！〜
本セッションでは、アプリ開発における「値の渡し方」をテーマに、状況に応じた最適なアプローチについて学びました。
画面遷移、メソッドの引数、DI (Dependency Injection) といった具体的な手法が紹介される中で、SSOT (Single Source of Truth) や UDF (Unidirectional Data Flow) といった設計原則を守ることの重要性が強調されていました。
特に印象的だったのは、「いいね問題」を題材にしたパートです。聴講者へのアンケートを交えながら解決策を探るという参加型の形式は、他にはないユニークなもので非常に興味深く感じました。
このセッションで得た大きな学びは、技術のトレードオフを理解することの重要性です。
例えば、「いいね」の状態のように複数の画面で整合性を保つ必要があるデータに対し、画面遷移で値を渡す手法は不適切です。SSOTの原則に反し、ライフサイクルによってデータが失われるリスクがあるためです。
しかし、逆に言えば、画面をまたいで一貫性を保つ必要がない一時的なデータであれば、画面遷移時の値渡しはむしろシンプルで最適な選択肢になり得ます。
このように、本セッションは単なる技術の紹介にとどまらず、その背景にある設計原則や、状況に応じて最適な手段を判断する思考法を学ぶことができました。
Compose MultiplatformとSwiftUIで作るハイブリッドモバイルアプリ：コード共有とUI融合の実践
このセッションは、KINTOテクノロジーズ株式会社が提供する「my route」などの実プロダクトを題材に、Kotlin Multiplatform (KMP)、特にCompose Multiplatform (CMP) の導入事例を解説するものでした。
驚くべきことに、UIの80%がCMPで実装されており、残りの20%は地図などネイティブでの実装が必須な機能に限られているとのことです。CMPが正式にStable版となる以前からこの先進的な取り組みを進めていたと考えると、同社の技術的な挑戦には感銘を受けました。
セッションでは、実用例に基づいたCMPとネイティブUIの使い分けについて、明確な指標が示されました。
CMPの利点: コードの複雑性が減り、開発速度が向上する。
CMPの課題: マップのようなネイティブ機能との統合は難易度が高い。
この比較から、「マップ表示が中心となる画面では、無理にCMPを採用せずネイティブ実装を検討すべき」といった、具体的な知見を得ることができました。
さらに、FlutterとCMPの比較も非常に興味深いものでした。
ネイティブUIと統合する際、CMPはネイティブと同じ描画レイヤーにUIが埋め込まれるため、スムーズなレンダリングが可能です。
一方、FlutterはFlutter UIの上にネイティブUIを重ねて表示するため、画面のカクつきが発生しやすく、ネイティブの性能を十分に発揮できない場合があるとのことでした。
加えて、メモリー効率やアプリの起動時間といった、クロスプラットフォーム開発で重要となる性能面においても、CMPはFlutterより優れた結果を示しているというデータも共有され、技術選定における強力な根拠を得ることができました。
Navigation 2 を 3 に移行する（予定）ためにやったこと
本セッションでは、現時点（2025/10/3）でアルファ版として公開されているNavigation3の解説を中心に聴講しました。
まず、既存のNavigation2には、UIの表示状態と画面遷移の状態が別々に扱われるため、イベントのタイミングによって両者の状態が食い違う場合があるという課題がありました。
これに対しNavigation3では、UIと遷移の状態を単一の情報（State）として統一し、イベントを介さず状態を直接更新することで画面遷移を実現します。
このアプローチにより、状態の不整合が原理的に発生しなくなります。
この統一された状態は「バックスタック」によって管理され、画面描画は「NavDisplay」（Navigation ComposeにおけるNavHostに相当）が担います。
これらの基本概念は既存の知識から大きく離れておらず、理解しやすいと感じました。
また、Navigation3が目指す大きな目標として「アダプティブレイアウトへの対応」が掲げられています。
タブレットや折りたたみ式デバイスを想定し、1画面を「シーン」という単位で定義。
「シーンストラテジー」が、遷移先（エントリー）のメタデータに応じて、どのシーンに表示を振り分けるかを決定する仕組みです。
中でも特に私が注目したのは「オーバーレイシーン」という新機能です。
これはダイアログのように、他の画面の上に覆いかぶさる形で表示されるシーンです。
この機能の利点は、ダイアログを他の画面と全く同じように扱える点にあります。
- 画面遷移アニメーションの影響を受けない
- バックスタックで遷移を管理できる
- ライフサイクルに連動した、独立した状態（State Holder）を持てる
これにより、従来は同一ファイル内に実装されがちだったダイアログを、完全に独立した画面として実装でき、コードの肥大化を防ぐといった実践的なメリットが生まれます。
アルファ版のため今後仕様変更の可能性はありますが、次世代のナビゲーションライブラリの設計思想にいち早く触れることができ、非常に有意義なセッションでした。
終わり
2回目のDroidKaigiでしたが、今年はスポンサーとしてブース対応も担当し、前回とは全く違う新しい体験ができました！
初日の懇親会では少し盛り上がりすぎてしまった場面もありましたが、それも今となっては良い経験だったと、学びとして次に活かしていきたいと思います。
セッションの内容も、昨年同様に非常に面白かったです。
何より、去年は理解しきれなかった内容が今年はすんなり理解できるようになっていて、自身の成長を実感できたのが大きな収穫でした。
来年こそは登壇者としてあの場に立ちたい、という新しい目標もできました！
DroidKaigiのスタッフ、スピーカー、スポンサーの皆様、今年も最高のカンファレンスをありがとうございました！
Discussion