ComposeではないコードをCompose化する case ビズリーチ / DroidKaigi 2025 koyasai

  ComposeではないコードをCompose化する case ビズリーチ  2025/10/08 DroidKaigi 2025 後夜祭    長尾
聡一郎  1

自己紹介  氏名: 長尾聡一郎　    所属: 株式会社ビズリーチ  　　プロダクト本部   　　ビズリーチプロダクト統括部 
　　カスタマープロダクト部  　　カスタマープロダクトアプリ開発グループ    お仕事: ビズリーチ Androidアプリの開発  2 発表している人 

　　カスタマープロダクト部  　　カスタマープロダクトアプリ開発グループ    お仕事: ビズリーチ Androidアプリの開発    最近の学び: 社内Slackのプロフィール写真はちゃんとチョイスした方が良い  3 発表している人 

　　カスタマープロダクト部  　　カスタマープロダクトアプリ開発グループ    お仕事: ビズリーチ Androidアプリの開発    最近の学び: 社内Slackのプロフィール写真はちゃんとチョイスした方が良い  4

自己紹介  一旦ここでCMです  5

株式会社ビズリーチ / BizReach, Inc.  創業　　：2009年4月  代表者　：代表取締役社長　酒井哲也  グループ従業員数：2,192名（2024年7月末時点）  拠点　　：東京、大阪、名古屋、福岡、静岡、広島  資本金　：1億3,000万円 
事業内容：HR Techのプラットフォーム・SaaS事業  会社概要  6

ビズリーチのビジネスモデル  7 引用: 2025年7月期通期決算説明資料 https://www.visional.inc/ja/ir/library/presentation/main/0/teaserItems1/01114/linkList/0/link/FY25_FY_Financial%20Release_JPN.pdf 

ビズリーチのビジネスモデル  8 引用: 2025年7月期通期決算説明資料   https://www.visional.inc/ja/ir/library/presentation/main/0/teaserItems1/01114/linkList/0/link/FY25_FY_Financial%20Release_JPN.pdf  Androidアプリが担当するところ 

本日はDroidKaigi 2025 後夜祭！  「ビズリーチ」のユーザーである求職者が使う  Androidアプリについて話します！  9

ここで、皆さんに質問です  （軽い気持ちでお答えください）  10

AndroidアプリのUIを  Composeメインで書いている方🙋  11

AndroidアプリのUIを  XMLメインで書いている方󰢨  12

AndroidアプリのUIに  XMLが残っている方󰢧  13

AndroidアプリのUIに  XMLがいっぱい残っている方󰢧  14

XMLに苦しめられている方󰢨  15

悲喜交々ありますが  Composeが浸透してきていますね😊  16

ここで、Jetpack Composeの歴史を  振り返ってみましょう  17

2019/05 Google I/Oにて、新しいAndroid UIツールキットとしてJetpack Composeの最初のプレビューが発表される  2019/10 開発者向けに最初のプレビュー版が公開され、フィードバック収集とオープンな開発が開始されました  2020/08
アルファ版がリリース  2021/02 ベータ版がリリース  2021/07 Jetpack Composeの最初の安定版である1.0がリリースされ、AndroidのネイティブUIにおける推奨ツールキットとなる  2025/10 現在 Jetpack Composeは、継続的にアップデートされており、ネイティブUIのファーストチョイスとして主要な選択肢となっている  Jetpack Composeの歴史  18

ネイティブUIのファーストチョイスとして  選ばれるようになったJetpack Composeで  UIを書いていきたい📝  19

XMLを撲滅して、書きやすいComposeで開発していきたい！  20

それではやっていきましょう！！  21

BizReach Confidential DroidKaigi 2025においてこのようなセッションがありました  Kikoso  2025.09.12 / 11:20 〜 12:00 
https://2025.droidkaigi.jp/timetable/946715/        Composeを使ってUIを書いていると、しばしばComposeに対応していないコードと連携する必要があります。その一例がGoogle Maps SDKで、同ライブラリは Composeに標準対応していません。この制限を克服するために開発されたのが Android Maps Composeライブラリです。    このセッションでは、android-maps-composeの開発に用いたテクニックを紹介し、元々 Compose に対応していないライブラリに対して、どのようにして Compose のインタフェースを提供したのかを解説します。 Android Viewブリッジのような相互運用技術を活用し、非 Composeコンポーネントを安全にラップしてライフサイクルを管理し、ユーザーにとって使いやすい Compose APIをどのように設計したのかをお見せします。     レガシーなUI コードをComposeでラップしたい方や、従来の Androidライブラリに Composeのインターフェースを提供したい方にとって、様々なものを Compose化する際に役立つ実践的なツールや設計パターン、アーキテクチャの考え方を持ち帰っていただける内容となっています。   ComposeではないコードをCompose化する    22

このセッション見られた方🙋  23

見られてない方もいらっしゃると思うので、、  24 24

元々Composeに対応していないUIライブラリ（例えばMapView）に対して、どのようにしてComposeのインターフェースを提供したのかを、登壇者が作成されたライブラリで得た知見を用いて解説されたセッション。    ・Compose化したいUIを理解してやるべきことを提示  ・Stateをきちんと管理する  ・AndroidViewにライフサイクルを知らせる  ・宣言的な実装を心掛け、命令的な実装を隠す    ・移行する際に注意するべきこと 
・AndroidViewを生成することは、コストがかかりがちで、ボトルネックになりがち  ・recompositionをできる限り最小にする    ・相互運用 APIのおかげで移行するのは難しくない  「ComposeではないコードをCompose化する」の要約  25

なるほど  XMLをComposeに置き換える方法はわかった。  XMLをComposeに置き換えるのは難しくない☺  26

本当に？ 🤔  27

「ビズリーチ」は、どうなってますか？  フルCompose化できていますか？？  28

フルCompose化、まだまだ道半ば🚀です  29

少しずつXMLを置き換えています  30

フルCompose化が進行しているとはいえ、  XMLが一掃されていないということは、  道半ば(Viewシステムの並行稼働)で、  つらいこともあるんじゃないですか？  31

全然つらくないです😊（ﾄﾞﾔｯ  32

なぜ？  なぜビズリーチでは、  XMLからフルCompose化への移行作業中の並行稼働がつらくないの？？  33

前提として、  ・ビズリーチでは、一気にComposeに置き換えていく方針ではなく、XMLを必要に応じてComposeへ書き換える方針をとっています（並行稼働ありき）    ・UIにおけるXMLからComposeへの置き換え作業も、そこまで難易度が高いと判断していません  https://engineering.visional.inc/blog/699/biz-can-android-re-architecture/ 34

問い（なぜViewシステムの並行稼働が辛くないのか）にお答えするために  ビズリーチでのXML→Composeの置き換え時のコードの変遷をご紹介します  35

求人を掲示している企業の情報がまとまっている画面  Case 1: 企業詳細画面  ・企業名  ・ロゴのURL→ロゴ画像  ・各種ラベル  ・会社概要  ・アピールポイント 
などをAPIから一括で取得して表示する    XML→Compose化がスッと進んだケース  36

Case 1: 企業詳細画面 Old (XMLでの実装)  @AndroidEntryPoint class DetailFragment : Fragment(R.layout.fragment_detail)
{ private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) viewModel.getDetail(args.id) setUpSubscriber() } } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.RESUMED) { launch { viewModel.detailScreenUiState.collect { uiState -> binding.name.text = uiState.name binding.image.load(uiState.image) { error(R.drawable.ic_placeholder) } binding.summary.text = uiState.summary binding.tagTitle.isVisible = uiState.isTagTitleVisible } } } } } 37

{ private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) viewModel.getDetail(args.id) setUpSubscriber() } } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.RESUMED) { launch { viewModel.detailScreenUiState.collect { uiState -> binding.name.text = uiState.name binding.image.load(uiState.image) { error(R.drawable.ic_placeholder) } binding.summary.text = uiState.summary binding.tagTitle.isVisible = uiState.isTagTitleVisible } } } } } UiStateに表示に関する情報が集まっている  画面に表示する情報を一回Fetchする  38

Case 1: 企業詳細画面 New (Composeでの実装)  @AndroidEntryPoint class DetailFragment : Fragment()
{ private val viewModel: DetailViewModel by viewModels() private val args: DetailFragmentArgs by navArgs() override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View { return ComposeView(requireContext()).apply { setContent { DetailScreenContent() } } } @Composable private fun DetailScreenContent() { // 画面の状態を収集 val uiState by viewModel.DetailScreenUiState.collectAsStateWithLifecycle() // 初期化イベント LaunchedEffect(Unit) { viewModel.fetchDetail(args.id) } DetailScreen(uiState = uiState) } } 39

{ private val viewModel: DetailViewModel by viewModels() private val args: DetailFragmentArgs by navArgs() override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View { return ComposeView(requireContext()).apply { setContent { DetailScreenContent() } } } @Composable private fun DetailScreenContent() { // 画面の状態を収集 val uiState by viewModel.DetailScreenUiState.collectAsStateWithLifecycle() // 初期化イベント LaunchedEffect(Unit) { viewModel.fetchDetail(args.id) } DetailScreen(uiState = uiState) } } UiStateに表示に関する情報が集まっている  画面に表示する情報を一回Fetchする  40

お分かりいただけただろうか・・・  41

{ private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) viewModel.getDetail(args.id) setUpSubscriber() } } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.RESUMED) { launch { viewModel.detailScreenUiState.collect { uiState -> binding.name.text = uiState.name binding.image.load(uiState.image) { error(R.drawable.ic_placeholder) } binding.summary.text = uiState.summary binding.tagTitle.isVisible = uiState.isTagTitleVisible } } } } } UiStateに表示に関する情報が集まっている  画面に表示する情報を一回Fetchする  42

{ private val viewModel: DetailViewModel by viewModels() private val args: DetailFragmentArgs by navArgs() override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View { return ComposeView(requireContext()).apply { setContent { DetailScreenContent() } } } @Composable private fun DetailScreenContent() { // 画面の状態を収集 val uiState by viewModel.DetailScreenUiState.collectAsStateWithLifecycle() // 初期化イベント LaunchedEffect(Unit) { viewModel.fetchDetail(args.id) } DetailScreen(uiState = uiState) } } UiStateに表示に関する情報が集まっている  画面に表示する情報を一回Fetchする  43

XMLが残っていても開発がつらくない理由  44

XMLを使ったUIにおいても、Composeを使ったUIにおいても利用しやすいViewModelを作ることができているから  XMLが残っていても開発がつらくない理由  45

XMLを使ったUIにおいても、Composeを使ったUIにおいても利用しやすいViewModelを作ることができているから    →状態をViewModelでのみ管理し、表示に必要なデータ(state)をUiStateに集約し、 UI(XML/Composeに関わらず)は、UiStateを受け取ることで更新されるようにしていた  ・ViewModelが、UIに必要なデータを取得する  ・UIを更新する際は、UiStateを再生成し、UIに伝搬させて、UIを更新する  ・（基本スタンスとしてCompose化を進めていくが）XML/Composeを柔軟に選択できる  XMLが残っていても開発がつらくない理由  46

これ、どこかで見たような、、、🤔  47

API Guidelines for Jetpack Compose だ💡  48

Compose API design patterns  Prefer stateless and controlled @Composable functions（ステートレスで制御されたComposable関数を優先する） 
In this context, “stateless” refers to @Composable functions that retain no state of their own, but instead accept external state parameters that are owned and provided by the caller. “Controlled” refers to the idea that the caller has full control over the state provided to the composable.  この文脈における「ステートレス」とは、それ自体で状態を保持せず、代わりに呼び出し元が所有し提供する外部の状態パラメータを受け入れる@Composable 関数を指します。「制御された」とは、呼び出し元がコンポーザブルに提供される状態に対して完全な制御権を持っているという考え方を指します。      ステートレス：データ（状態）を引数として受け取るだけで、内部に保存しない。  制御された：データを渡す呼び出し元（親コンポーネントやViewModel）が、データの値や変更のタイミングを完全に決定・管理する。  API Guidelines for Jetpack Compose  引用: API GUidelines for Jetpack Compose https://android.googlesource.com/platform/frameworks/support/+/androidx-main/compose/docs/compose-api-guidelines. md#prefer-stateless-and-controlled-composable-functions 49

Do  API Guidelines for Jetpack Compose  @Composable fun Checkbox( isChecked:
Boolean, onToggle: () -> Unit ) { // ... // Usage: (caller mutates optIn and owns the source of truth) Checkbox( myState.optIn, onToggle = { myState.optIn = !myState.optIn } ) } Don’t  @Composable fun Checkbox( initialValue : Boolean, onChecked: (Boolean) -> Unit ) { var checkedState by remember { mutableStateOf (initialValue) } // ... // Usage: (Checkbox owns the checked state, caller notified of changes) // Caller cannot easily implement a validation policy. Checkbox(false, onToggled = { callerCheckedState = it }) } 50

XMLを使ったUIにおいても、Composeを使ったUIにおいても利用しやすいViewModelを作ることができているから    →状態をViewModelでのみ管理し、表示に必要なデータ(state)をUiStateに集約し、 UI(XML/Composeに関わらず)は、UiStateを受け取ることで更新されるようにしていた  ・ViewModelが、UIに必要なデータを取得する  ・UIを更新する際は、UiStateを再生成し、UIに伝搬させて、UIを更新する  ・（基本スタンスとしてCompose化を進めていくが）XML/Composeを柔軟に選択できる  XMLが残っていても開発がつらくない理由  51

XMLを使ったUIにおいても、Composeを使ったUIにおいても利用しやすいViewModelを作ることができているから    →状態をViewModelでのみ管理し、表示に必要なデータ(state)をUiStateに集約し、 UI(XML/Composeに関わらず)は、UiStateを受け取ることで更新されるようにしていた  ・ViewModelが、UIに必要なデータを取得する  ・UIを更新する際は、UiStateを再生成し、UIに伝搬させて、UIを更新する  ・（基本スタンスとしてCompose化を進めていくが）XML/Composeを柔軟に選択できる    その結果、XML→Composeの変更を行うにあたっても、ViewModel以下のロジックは、ほぼ修正せず、
UIのみを修正することで、作業が行えている  XMLが残っていても開発がつらくない理由  52

XMLを使ったUIにおいても、Composeを使ったUIにおいても利用しやすいViewModelを作ることができているから    →状態をViewModelでのみ管理し、表示に必要なデータ(state)をUiStateに集約し、 UI(XML/Composeに関わらず)は、UiStateを受け取ることで更新されるようにしていた  ・ViewModelが、UIに必要なデータを取得する  ・UIを更新する際は、UiStateを再生成し、UIに伝搬させて、UIを更新する  ・（基本スタンスとしてCompose化を進めていくが）XML/Composeを柔軟に選択できる    その結果、XML→Composeの変更を行うにあたっても、ViewModel以下のロジックは、ほぼ修正せず、
UIのみを修正することで、作業が行えている    逆に言えば、XML→Composeにおいてつらいのは、手続き的に書かれている箇所や、ライフサイクルが絡んでくるケース  XMLが残っていても開発がつらくない理由  53

ん？  54

XMLを使ったUIにおいても、Composeを使ったUIにおいても利用しやすいViewModelを作ることができているから    →状態をViewModelでのみ管理し、表示に必要なデータ(state)をUiStateに集約し、UIは、UiStateを受け取ることで更新されるようにしていた  ・ViewModelの生成時に、View(Screen)に必要なデータを取得する  ・UIを更新する際は、UiStateを再生成し、View(Screen)に伝搬させて、UIを更新する  ・（基本スタンスとしてCompose化を進めていくが）XML/Composeを柔軟に選択できる    その結果、XML→Composeの変更を行うにあたっても、ViewModel以下のロジックは、ほぼ修正せず、
UIのみを修正することで、作業が行えている    逆に言えば、XML→Composeにおいてつらいのは、手続き的に書かれている箇所や、ライフサイクルが絡んでくるケース  XMLが残っていても開発がつらくない理由  55

XML→Composeにおいてつらいのは、手続き的に書かれている箇所や、ライフサイクルが絡んでくるケース  56

求人情報が表示される画面  Case 2: 求人詳細画面  ・求人に関する情報が網羅  ・複数のAPIから情報を取得する  ・「もっと見る」といった画面上だけで完結する状態がある  ・求職者（ユーザー）の状態で表示が変更になる箇所がある  ・他の画面への遷移も多数存在  ・お気に入り機能もあるよ 
  57

Case 2: 求人詳細画面 Old  @AndroidEntryPoint class DetailFragment : Fragment(R.layout.fragment_detail) {
private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // – 略 setUpSubscriber() // – 略 } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.CREATED) { launch { viewModel.detailScreenUiState.collect { // – 略(たくさんの bindingへの設定 ) if (it.detail.bannerFlg == true) { setUpBanner() } else { binding.banner.isVisible = false } } } } } } private fun setUpBanner() { viewModel.bannerUiState.let { binding.banner.isVisible = it.isVisible if (it.isVisible.not()) return@let binding.banner.load(it.imageUrl.value) } } } コードはポイントを抜粋しています  58

private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // – 略 setUpSubscriber() // – 略 } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.CREATED) { launch { viewModel.detailScreenUiState.collect { // – 略(たくさんの bindingへの設定 ) if (it.detail.bannerFlg == true) { setUpBanner() } else { binding.banner.isVisible = false } } } } } } private fun setUpBanner() { viewModel.bannerUiState.let { binding.banner.isVisible = it.isVisible if (it.isVisible.not()) return@let binding.banner.load(it.imageUrl.value) } } } コードはポイントを抜粋しています  detailが特定の状態の時に呼ばれるメソッドがある  59

private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // – 略 setUpSubscriber() // – 略 } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.CREATED) { launch { viewModel.detailScreenUiState.collect { // – 略(たくさんの bindingへの設定 ) if (it.detail.bannerFlg == true) { setUpBanner() } else { binding.banner.isVisible = false } } } } } } private fun setUpBanner() { viewModel.bannerUiState.let { binding.banner.isVisible = it.isVisible if (it.isVisible.not()) return@let binding.banner.load(it.imageUrl.value) } } } コードはポイントを抜粋しています  detailが特定の状態の時に呼ばれるメソッドがある  bannerUiStat eの状態によって表示を制御したり、非同期処理をするらしい  60

private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // – 略 setUpSubscriber() // – 略 } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.CREATED) { launch { viewModel.detailScreenUiState.collect { // – 略(たくさんの bindingへの設定 ) if (it.detail.bannerFlg == true) { setUpBanner() } else { binding.banner.isVisible = false } } } } } } private fun setUpBanner() { viewModel.bannerUiState.let { binding.banner.isVisible = it.isVisible if (it.isVisible.not()) return@let binding.banner.load(it.imageUrl.value) } } } コードはポイントを抜粋しています  detailが特定の状態の時に呼ばれるメソッドがある  bannerUiStat eの状態によって表示を制御したり、非同期処理をするらしい  loadの非同期処理は適正なタイミングで呼ばれるのか？  61

private val binding: FragmentDetailBinding by dataBinding() private val viewModel by viewModels<DetailViewModel>() private val args: DetailFragmentArgs by navArgs() override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) // – 略 setUpSubscriber() // – 略 } private fun setUpSubscriber() { viewLifecycleOwner.lifecycleScope.launch { repeatOnLifecycle(Lifecycle.State.CREATED) { launch { viewModel.detailScreenUiState.collect { // – 略(たくさんの bindingへの設定 ) if (it.detail.bannerFlg == true) { setUpBanner() } else { binding.banner.isVisible = false } } } } } } private fun setUpBanner() { viewModel.bannerUiState.let { binding.banner.isVisible = it.isVisible if (it.isVisible.not()) return@let binding.banner.load(it.imageUrl.value) } } } コードはポイントを抜粋しています  detailが特定の状態の時に呼ばれるメソッドがある  bannerUiStat eの状態によって表示を制御したり、非同期処理をするらしい  loadの非同期処理は適正なタイミングで呼ばれるのか？  これ  どうなってる？？  62

Case 2: 求人詳細画面 New  if (uiState.bannerVisible) { // uiState ==
detailScreenUiState Banner(imageUrl = bannerUiState.imageUrl.value) } @Composable fun Banner(imageUrl: String?) { AsyncImage(imageUrl) // coil } 該当箇所はこんな感じになりました  ・ライフサイクルを丁寧に読み解き、ロジックを発生順序を整理  ・手続き的→宣言的に書き直すと意図が分かりやすい  63

まとめ  1. XMLによるUIはまだまだ残っている現状、XMLをComposeで利用できるようにすることは必要で、 XMLをComposeで利用するにはAndroidViewを利用する    2. AndroidViewを使って成熟したXMLによる画面レイアウトをComposeとともに利用するには、いくつかのコツが必要    3.
XMLによるレイアウトを、AndroidViewを用いてComposeで利用する際、状態を表現したオブジェクトを設定するだけでUIが更新されるような宣言的な構造にしておくことで、Composeとの親和性が高くなる    4. ComposeではないコードをCompose化するためには、現在の状態をオブジェクトにまとめ、UI構造へマッピングできるように整えておくことが肝要  64

ご清聴ありがとうございました！  connpassページ  Xアカウント  採用サイト  技術イベント  開催情報  エンジニア  最新情報  プロダクト組織は  仲間を募集中 
@VISIONAL_ENG https://d-cube.connpass.com/ https://careers.bizreach.co.jp/

ComposeではないコードをCompose化する case ビズリーチ / DroidKai...

ComposeではないコードをCompose化する case ビズリーチ / DroidKaigi 2025 koyasai

More Decks by Visional Engineering ＆ Design

Other Decks in Technology

Featured

Transcript