dip
【DroidKaigi 2026】「バイトル」リニューアルでの技術&アーキテクチャ選定の意思決定を全解説します!

【DroidKaigi 2026】「バイトル」リニューアルでの技術&アーキテクチャ選定の意思決定を全解説します!

# 設計# AI
モバイルアプリチーム
2026/09/03公開2026/09/03更新

はじめに

こんにちは。ディップ株式会社でバイトルのモバイルアプリを開発している吉本です。

2026年9月1日から3日間開催された DroidKaigi 2026 に、ディップはスポンサーとしてブース出展してきました。

この記事では、当日の様子とブースでの取り組み、そしてブースで来場者の皆さんに投げかけた問いへの、私たち自身の答えをご紹介します。

DroidKaigi 2026 イベント概要

DroidKaigi は、Android 開発者のためのカンファレンスです。技術情報の共有と開発者同士の交流を目的に、毎年開催されています。

DroidKaigi 2026 は、2026年9月1日(火)から3日(木)までの3日間、ベルサール渋谷ガーデンで開催されました。

  • Day1:ワークショップ
  • Day2・Day3:セッション、スポンサーブース

当日の様子紹介

当日は、協賛企業のブースやセッション、ネイル体験会やafter partyなどたくさんのコンテンツがあり、多くの人で賑わっていました。

ディップのブース紹介

ブースの紹介

私たちのブースでは、来場者の皆さんに付箋で答えてもらうボードを用意しました。テーマはこの 2 つです。

「フルリニューアルするとしたら、どこまで共通化しますか?」

「フルリニューアルするとしたら、一番取り入れたい技術は?」

バイトルはサービス開始から長く続いているプロダクトです。もしいまゼロから作り直すなら、どこまで共通化するのか。どんな技術を選ぶのか。エンジニアなら一度は考えたことがあるだろう問いを、付箋で自由に書いてもらいました。

ボードについて

テーマ1:フルリニューアルするとしたら、どこまで共通化しますか?

アンケート結果はこちらです。

結果を見ると、「一部を KMP を使って共通化する」という回答が一番多かったです。また、CMP や Flutter を使って全部共通化する、共通化せずそれぞれ実装するなどの回答もありました。

テーマ2:フルリニューアルするとしたら、一番取り入れたい技術は?

アンケート結果はこちらです。

KMP / CMP の回答が一番多かったです。また、VRT や Navigation3 などの回答もありました。

ディップではこうしました

実はこの問い、私たちにとって空想話ではありません。バイトルはいま、まさにフルリニューアルの真っ最中です。今回、DroidKaigiにて来場者の方の意見を聞いてみたいと思い、ブースでアンケートをとりました。

【Q1】どこまで共通化したか

ロジックは共通、UI はネイティブ

iOS/Android の共通化手段として Kotlin Multiplatform(KMP) を採用し、リポジトリを 1 つに統合しました。こちらは、ブースでも紹介した、リニューアル後のバイトルアプリアーキテクチャです。

私たちは、Presentation 層と OS 固有実装は各 OS ごと、Domain 層以下は両 OS 共通で実装しました。Domain 層以下を共通にするのは、ロジック部分を共通化させたかったからです。

この設計にしたいと思った背景には、リニューアル前のアプリで感じていた課題があります。iOS と Android を別のリポジトリで、別のチームが長く開発していくと、同じ機能のはずなのに振る舞いが少しずつずれていきます。ひとつひとつは、実装のときにその場で埋めた小さな判断です。それが何年も積み重なると、どちらが正しい仕様なのかを調べるところから始めないといけなくなります。

ロジックを共通側に置けば、このずれはそもそも発生しません。仕様がコード上の 1 か所にしかないので、そこを見ればどちらの OS でも同じ答えになる。Domain 層以下を共通にしたのは、工数を半分にしたいというよりも、この「仕様の正が 1 つである状態」を保ちたかったという理由が大きいです。

上から順に見ていくと、まず Presentation 層。ここは Android が Jetpack Compose、iOS が SwiftUI で、画面を描画する部分です。プラットフォームごとの作法が一番強く出るところなので、無理に揃えずに各 OS に任せています。

その下の Domain 層が共通化の本体です。UseCase や、ビジネスルールを持つドメインモデルがここにあります。さらに下の Data 層も共通で、API 通信、ローカル DB、キャッシュといった、データをどこから取ってくるかの部分を担っています。

線引きの基準は、「何をしたいか」は共通、「どう実現するか」が OS で違うものは各 OS に分けています。仕事に応募できる条件を判定するロジックはどちらの OS でも同じなので共通へ。一方でカメラの起動や位置情報の取得は OS ごとに作法が違うのでそれぞれ実装しています。

UI を共通化しなかったことは、OS 側の変化への追従でも効いています。分かりやすい例が、iOS 26 の Liquid Glass への対応でした。SwiftUI で素直に作っていた部分は、OS のアップデートに合わせて見た目が切り替わるのをそのまま受け取れます。ネイティブ UI を選んでいてよかったと思ったところです。

【Q2】一番取り入れたい技術は何か

Kotlin Multiplatform

アンケート結果と同じで、私たちもKMP です。選定時に期待していたのは、ロジックを共有できれば設計・実装・レビュー・修正がそれぞれ 1 回で済むはず、という点でした。実際に作り始めてみると、その効きが一番大きいのは修正のフェーズです。仕様の解釈がずれていたと分かったとき、直す場所が 1 か所で、片方の OS にだけ直し漏れが残ることがありません。一方で、共通側に置くか各 OS に置くかの線引きそのものは自動的には決まらないので、そこは都度チームで判断しています。

KMP 以外だと、デザインシステム、Jetpack Compose / SwiftUI、VRT も、ゼロから作り直すからこそ最初から入れられたものです。とくにデザインシステムは、色やサイズをトークンとして先に定義しておくことで、画面ごとに判断が必要になる場面をあらかじめ減らせてくれます。

AI が読める状態にしておく

もうひとつ、フルリニューアルのタイミングだからこそ入れられたものとして、AI が読める状態にドキュメントを整えておくことがあります。設計判断を ADR として残し、レイヤーごとのルールをファイルに切り出しておくと、AI は毎回同じ前提から書き始められます。「なぜこうなっているのか」がリポジトリの中に書いてあるかどうかで、AI の出力をある程度コントロールすることができています。

アフターイベントについて

ディップでは、10 月 8 日に、DroidKaigi・iOSDC のアフターイベントとして「大規模リニューアルの本音を語る会」を開催します。リニューアルを行うにあたって直面した悩みや壁、知見を共有する場にしたいと考えています。興味のある方はお気軽にご参加ください!

https://dip-dev.connpass.com/event/405334/

さいごに

ブースに立ち寄ってくださった皆さん、アンケートにご協力いただいた皆さん、ありがとうございました。

ディップは、iOSDC Japan 2026(9月11日〜13日) にもブース出展します。iOSDCのブースでは、今回とはまた違うアンケートを行う予定です。

そして、最終日には弊社の宮川がスポンサーセッションに登壇します。

Kotlin Multiplatformを軸にした求人アプリ全面リニューアルの技術戦略

20年を超える歴史を持つアルバイト求人サービス「バイトル」。
そのiOSアプリをKotlin Multiplatform(KMP)を軸に全面リニューアルしています。

開発チームがどう向き合い、どう乗り越えてきたかを実例を交えて紹介します。
KMPを軸にした大規模アプリリニューアルの、技術戦略と責務分担の判断軸を持ち帰っていただければ幸いです。

iOS エンジニアの皆さん、会場でお待ちしています。

執筆者

モバイルアプリチーム

モバイルアプリチーム

# モバイルエンジニア

iOSチーム4名、Androidチーム4名、パートナー2名の計10名体制。テックリードを筆頭に、新卒から中堅まで多様なバックグラウンドを持つメンバーが揃っています。アプリチームを核とし、直接的なコラボレーター(プロダクト・コア)が並走。最外周(ステークホルダー・ビジネス)がそれを取り囲む3層構造により、迅速かつ一貫性のある意思決定とプロダクト開発を実現します。