AI と一緒に Android → iOS 開発にチャレンジしたら iOS/Android チームが統合された半年間

published

author

authorDisplayName

Kazuho Hosoi

🌱 はじめに

こんにちは。令和トラベルで、旅行アプリ『NEWT（ニュート）』のアプリエンジニアをしている hossy です。

令和トラベルでは AIのさまざまな活用を推進しており、篠塚の記事でも、新規プロジェクトで AI ファーストな開発手法が紹介されましたが、NEWTアプリについては、AI Coding で一定高速化しつつも、まだまだ泥臭い開発が続いています。

<長文>生産性爆増、AI時代のプロジェクト推進実装マニュアル｜Takaya Shinozuka

※注意　この記事は私（人間）がかなり頑張って書きました👨‍💻画像はNanobanana、すごすぎ。面白かったシェアしてくれると嬉しいです。こんにちは、新しい旅行をデザインしたい令和トラベル篠塚です。久々の長文noteをお届けです。弊社はNEWTという満足度No.1の旅行予約アプリを提供してがんばっています！11月が締まり月次予約は夏を超えて過去最高、どんどん世代が拡がり伸びてるのでぜひご覧ください👏 海外旅行・国内旅行のツアーやホテル予約はNEWT（ニュート）かしこい、おトク、旅行アプリ「NEWT（ニュート）」。海外旅行・国内旅行をアプリでかんたんに予約できます。

https://note.com/shinojapan/n/n245594475b85

そんな中でも AI時代な開発に向けて、個人・アプリチームで、少しづつチャレンジしているので、その一部を紹介したいと思います。

💡

Androidアプリエンジニアの iOSアプリ開発への挑戦

iOS/Android チームの統合と、マルチスキル化に向けた体制づくり

統合した結果、iOSのリリース頻度が倍増

クロスプラットフォーム化ではなく、ネイティブでいく技術的決断

👨‍💻 個人の挑戦 (Android → iOS)

2025年6月、iOSアプリエンジニアの一人が育休に、一人がBackendエンジニアへの転向する話があり、iOSアプリエンジニアが一人しかいない状況になりました。

iOSエンジニアからバックエンドへ転向して見えた、AI時代のキャリアの可能性 | 令和トラベル Engineering Blog

https://engineering.reiwatravel.co.jp/blog/rick-ios-to-backend

iOSエンジニアからバックエンドへ転向して見えた、AI時代のキャリアの可能性 | 令和トラベル Engineering Blog

そうなると、iOS/Androidそれぞれにメンバーをアサインする従来の体制では、1レーンでしか施策を回すことができず、NEWTアプリの成長が鈍化してしまうという課題がでてきたのです。

ちょうど自分としても、Androidアプリ開発でAI Codingで生産性が上がってきたタイミングでもあり、AIに伴走してもらえる今であれば、iOSアプリ開発にチャレンジしてもいいかなと思っていました。

組織的にも AI活用によって、マルチスキル化や染み出しが求められはじめており、色々な状況が噛み合い、AndroidとiOSアプリ開発を両立することになりました。

AI による伴走

SwiftとKotlinの言語的な類似性や、GraphQL/Apolloなど共通する技術があったとはいえ、iOSで採用している TCA (The Composable Architecture) や、iOSフレームワーク等、キャッチアップが必要な技術は多量です。

iOSメンバーに一定フォローしてもらいつつも、あまりコストをかけてもらえる状況ではなかったため、AI をフル活用して学習と実装を進めました。

従来であれば、あたらしいプラットフォームを学ぶためには、ペアプログラミングやコードレビューを通じて、メンターの工数と時間をかける必要がありましたが、AI Codingを活用することで、学習や相談をある程度一人で進めることができ、限られたリソースの中でも前に進めることができました。

半年後の成長と現実

半年が経過したいま、自分がどの程度「iOSアプリエンジニア」と言える状態になったかを振り返ると、「iOSアプリの機能開発もできる」というのが適切な表現だと思います。

できるようになったこと

既存設計に沿った機能開発

軽微なリファクタリング

バグ調査

リリース作業

まだ難しいこと

iOSフレームワークやSwiftUI、TCAの深いところの理解

iOSアプリらしい仕様やUIの理解

Tech Leadのような技術的な意思決定や、難易度の高い技術課題解決

現状、「iOSコーダー」に留まっており、少なくともiOSの機能開発速度がAndroidレベルになるまでは、マルチスキル化を進めていく必要がありますし、iOSの深い技術的なところもキャッチアップしていかないといけません。

🧬 チームの統合

個人としての挑戦と並行して、2025年10月にチーム体制の変更が実施されました。

これまで、iOS/Androidそれぞれのチームに分かれていた体制を、一つのネイティブアプリチームとして統合し、アプリエンジニアが両プラットフォームを開発するチームへと変更しました。

統合の背景

2025年10月には、アプリ開発で手を動かせるメンバーが、iOSアプリエンジニア1人 + Androidアプリエンジニア2人 (自身含む) の体制になるのが見えていました。

この状況では、回せる施策のレーン数が少なく、iOSアプリエンジニアの負荷が高まる懸念があり、それを解決するために、統合を進める決断をしました。

🏗️ 統合チームの立ち上げ

チーム内の認識作り

統合を進めるにあたり、まず「iOS/Android統合とは何か」のチームでの認識を揃える必要がありました。そこで、ここ半年で目指すレベルを定義し、すり合わせを行いました。

両方できるようになりたいこと

まずは、小さい機能から一人で回してデリバリーできることや、差し込みで入るような作業をリソース状況に応じて分担できるような状態を目標にしています。

💡

小〜中規模の機能開発を一人で、プロジェクトの進行〜実装〜リリースまで完遂できること

実装難易度として、各プラットフォームやライブラリに強く依存しないが、仕様上複雑な画面の実装ができること

リリース作業や日々のルーティン作業

仕様確認や調査（難しければ、PrimaryスキルメンバーにDispatchできること）

Primaryスキルのメンバーがメインでやること

目標が手広くなりすぎても中途半端になってしまうので、緊急度が高いことや専門性が高いことに関しては、これまでどおりPrimaryスキルの強みを活かして対応していくことにしました。

💡

インシデント対応やカスタマーからの問い合わせ対応 (緊急・重要性が高い対応)

日々の技術的なキャッチアップ・改善

ライブラリアップデート、クラッシュレポートの確認

登壇やブログなど技術ブランディング

キャッチアップ合宿

認識を合わせただけでは動けないため、1.5日ほどの開発合宿を実施し、それぞれのアーキテクチャ説明やペアプロを通じてキャッチアップしつつ、ライトに質問できる空気作りも行いました。

開発基盤の整備

Secondaryスキルのメンバーでも迷わずリリースまでの作業ができるよう、GitフローやCI/CDの統一といった開発基盤の整備も併せて行っています。

Slackチャンネル・メンションの統合

これまで、iOS/Androidで分かれていたSlackチャンネルやメンションもアプリという括りのものに統合しました。

他職種のメンバーからの問い合せ先を一本化して迷わなくする意図もありましたが、アプリエンジニアが、iOS/Androidに囚われず対応していこう！という気概の表明にもなっています。

🧪 統合したことによる変化

はやくキャッチアップして、アウトプットできるように

小さくてもいいので作って・デリバリーのサイクルを回して成功体験を積み重ねたい、というのは当然思うところでした。

そのために、例として、レビューの基準を意識的に変えました。

Primaryスキルのメンバーのレビューであれば、「ついでにリファクタリングしておこう」などのコメントをすることもありましたが、SecondaryスキルのメンバーにはそれをMustにせず、学習や作ることを優先してもらうようにしています。

それによって技術負債になるのであれば、それはPrimaryスキルのメンバーが後からリファクタリングするなどしてカバーしていこう、という気概です。

また、「相談や質問はどんどんしてほしい」という文化も徹底しています。

もちろん応える側は、コストを一定払うことになりますが、質問を受けることで、自領域の「当たり前」を再考するきっかけになり、だれが見ても分かりやすい設計やコードを意識するようになるなど、双方にとって学びの機会となっています。

iOS先行A/Bテスト戦略

統合により変化したこととして、iOS先行A/Bテスト戦略の確立があります。

施策に対してA/Bテストを実施することが増えてきた中で、カスタマー母数の多いiOSで先行リリースし、A/Bテストの結果が出て有効なものだけをAndroidに展開する、という戦略を取れるようになりました。

現在、大型機能やカスタマー価値が高い施策を除くグロース施策については、ほぼ全てiOS先行 A/Bテスト戦略で実践しています。

これにより、限られたリソースを効率的に使いながら、効果的な施策だけを両プラットフォームに展開できるようになりました。

iOSリリース頻度の倍化

チーム統合前までは、週1回のリリースを基本としていたため、月のリリース回数は 4回程度でしたが、チーム統合後の10月は10回・11月は8回と単純な回数だけ見ると倍になりました。（緊急の対応も多かったので若干盛り気味ではありますが）

要因としては、チーム統合＋上記A/Bテスト戦略により、レーン数をiOSに全振りすることもできるようになったので、人数が少ない中でも複数の施策を並列して回すことができるようになったことが大きいと思っています。従来のリリース頻度では、実装完了した施策のリリース待ちが発生する状況になり得たので、リリースサイクルを見直し、できたものからリリースして、早くA/Bの検証サイクルを回すということができています。

その分、Androidのリリース頻度は低下していますが、A/Bテストで効率的に施策の取捨選択ができるため、総合的なカスタマーへの価値提供は確実にプラスになってると考えています。