ZOZO開発組織の2026年3月分の活動を振り返り、ZOZO TECH BLOGで公開した記事や登壇・掲載情報などをまとめたMonthly Tech Reportをお届けします。 ZOZO TECH BLOG 2026年3月は、前月のMonthly Tech Reportを含む計19本の記事を公開しました。特に次の3記事は反響も大きく、とても多くの方に読まれています。ぜひご一読ください。 techblog.zozo.com techblog.zozo.com techblog.zozo.com 登壇 【Flutter推し活】Flutter好きが集うLT会 Studyplus x Linc'well 3月13日に開催された「 【Flutter推し活】Flutter好きが集うLT会 Studyplus x Linc'well 」に、新規事業部の大野（ @junjun_1345 ）が登壇しました。 ZOZO フロントエンドMeetup 3月18日にZOZOで主催した「 ZOZO フロントエンドMeetup 」に、ZOZOTOWN開発3部の揚原、WEAR開発部の岩崎、ZOZOTOWN開発1部の佐藤、そしてZOZOTOWN企画開発部の片岡が登壇しました。 掲載 Apps in ChatGPT対応 OpenAIの対話型AI「ChatGPT」の新機能「Apps in ChatGPT」にファッション領域でいち早く対応し、アプリ連携を開始しました。このことが複数のメディアで取り上げられました。まだ試したことがない方はぜひ一度お試しください。 corp.zozo.com www.fashionsnap.com netkeizai.com ZOZOEDUCATION つくっちゃお！ ZOZO初となる、子どもが“つくって売る”に挑戦できる教育プロジェクト「ZOZOEDUCATION つくっちゃお！」を始動しました。本プロジェクトの一環として、Tシャツのデザインから販売までを、親子が自宅で気軽に体験できるTシャツづくりキットを3月25日より販売開始しています。このことが複数のメディアで取り上げられました。親子で体験できる楽しいキットですので、ぜひお試しください。 corp.zozo.com www.nikkei.com kosodate.mynavi.jp 以上、2026年3月のZOZOの活動報告でした！ ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 corp.zozo.com

はじめに モバイルアプリチームのリードを務めている北沢です。 myTOKYOGASは2022年5月から内製化に着手し、Webアプリについては2023年11月に内製化を完了しました。一方、モバイルアプリについては、さまざまな事情により内製化が先送りになっていました。myTOKYOGASの内製化の経緯については、以下の記事をぜひご覧ください。 tech-blog.tokyo-gas.co.jp 今回は、Web アプリの内製化以降に取り組んできたモバイルアプリの内製化と、2026年1月のリリースに至るまでの経緯についてお話ししたいと思います。 モバイルアプリ内製化の経緯 モバイルアプリ内製化チームの立ち上げ 先に述べた通り、myTOKYOGAS の Web アプリは 2023 年 11 月に内製化が完了しました。その後、Web アプリチームからのれん分けする形でモバイルアプリの内製化チームが発足し、私がリードエンジニアを務めさせていただくことになりました。 モバイルアプリの開発休止 myTOKYOGAS の開発チームは、「技術力を大事にしながらも自らが携わったプロダクトが事業や会社に貢献することを楽しむ」というプロダクト志向を大事にしています。 その中で、myTOKYOGASの開発チームのリーダーから「マイクロサービスの開発が最重要案件となったため、一度モバイルアプリの開発を停止し、マイクロサービスの開発に参画してほしい」との打診がありました。そのため、モバイルアプリ開発チームは一時解散し、メンバーは別の開発チームに一時移籍することになりました。 マイクロサービスの取り組みについては、以下の記事がございますので、ぜひご覧ください。 tech-blog.tokyo-gas.co.jp 設計を進めている最中であったこともあり、一度チームを解散することになるのは残念でしたが、この時マイクロサービスチームに入り、マイクロサービスの開発に関わったことは、技術面の成長はもちろんのこと、このあとお話するモバイルアプリチームの再結成とモバイルアプリ内製化再開時に、システム全体を見通し、設計を行うための貴重な経験となりました。 モバイルアプリチームの再結成とモバイルアプリ内製化の再開 マイクロサービスは2024年度に無事リリースされました。その間に、myTOKYOGASの開発チームに多くのメンバーが参画してくれました。そして、2025年度再度モバイルアプリチームが再結成され、内製化が再開されることになりました。私は、モバイルアプリチームに復帰し、再度チームのリードエンジニアを務めさせていただくことになりました。 新チームでの開発とリリースまで モバイルアプリチームの人数が増えたため、まず全員が同じ品質基準・設計思想で開発できるよう、アーキテクチャガイドラインやコーディング規約を整備しました。 その中でまとめていたアーキテクチャについて簡単にご紹介します。 ディレクトリ構成や Lint のような設計やコード品質を守る仕組みに関しては機会があれば別ブログで紹介させていただきます。 【システムアーキテクチャ】 システム全体の構成としては、モバイルアプリ（Flutter）が BFF（Backend For Frontend）と通信し、BFF がバックエンドのマイクロサービス群を束ねる形になっています。BFF との通信には主に GraphQL を採用していますが、一部の API では REST も併用しています。 この構成により、アプリ側は BFF が提供するインターフェースのみを意識すればよく、ビジネスロジックをサーバー側に寄せつつ、アプリは UI 表示と状態管理に集中できる設計にしました。 【モバイルアプリのアプリケーションアーキテクチャ】 フレームワークには Flutter を採用しています。アーキテクチャは Store パターンを採用し、単方向データフローによる状態管理を基本としています。 ローカルな UI 状態（例: トグルの ON/OFF）は Widget 自身が管理 API から取得するデータなどのアプリケーション状態は Store に集約し、Riverpod で管理 Store は状態の保持と更新を担い、API 呼び出し等の副作用もこの層で処理（責務を分離し、UI 層は UI 表示とユーザー操作に集中） 加えて先のシステムアーキテクチャで述べた通り、BFF がモバイルに最適化された API を提供してくれるため、アプリ側に持つビジネスロジックを最小限に抑えられ、表示の正しさ（VRT）やユーザー操作フローの検証（シナリオテスト）に注力できる設計としました。 この「設計」と「共通ルールづくり」を整備する際に、マイクロサービス開発へ参画した経験が良い効果をもたらしました。具体例として、アプリ内のスロット機能はマイクロサービス基盤と連携して動作しており、2024年度にマイクロサービスチームへ横断的に所属したことで、API の設計思想やエラー分類の考え方を理解した状態で BFF とアプリ側の設計に臨むことができました。この経験は、アプリと BFF 間のエラーハンドリングの整合性や、Store での状態管理ポリシーを決める際に大きな助けになりました。 こうして共通の土台と設計方針を持てたことで、開発方針も具体性を持って整理でき、規約やガイドラインの整備にもつながりました。その上で、チーム全員が構成を理解し、一丸となって開発に取り組み、無事リリースを迎えることができました。 当然ですが、これは私一人の力で達成できたものではありません。ガイドラインをもとに丁寧にコードを書き、レビューし合い、改善を重ねてくれたチームメンバーの貢献があってこそ実現できたものです。この場をお借りして、チームのみなさんに感謝を申し上げます。 myTOKYOGASモバイルアプリのこれから 無事に内製化が完了しましたが、内製化そのものは目的ではなく、日々変化するビジネス要望に柔軟に対応し、より大きな事業貢献をするためのスタートラインに立った状態だと考えています。Webアプリだけでなくモバイルアプリにおいても、お客さまに役立つ機能を積極的に実装していくことで、myTOKYOGASという東京ガスにとって貴重なお客さまとの接点を有効活用し、より大きな価値を提供していけると考えています。今後は内製化によって得たアジリティを活かし、お客さまに価値を感じていただける機能をスピーディーにリリースしていきたいと考えています。 おわりに 今回、モバイルアプリの内製化が完了したことで、myTOKYOGASというアプリケーション全体で迅速な開発が行える体制が整いました。今後はmyTOKYOGAS全体で、よりお客さまに価値を感じていただける機能を提供していきたいと考えています。 また、今回私自身は、モバイルアプリチームとマイクロサービスチームの両方に所属したことで、幅広い技術スタックやシステム構成を把握しながら、組織にとって最適な構成とは何かを考えて内製化を進めることができました。myTOKYOGASチームとしても、内製化が成熟してきた今、Webやモバイルといった区分けにとらわれず価値提供ができるフィーチャーチームや、全体最適を追求するLeSSのような開発体制への進化を目指しています。myTOKYOGASというプロダクトはもちろんのこと、エンジニア個人として、開発チームとしても、より大きな貢献ができるよう成長していきたいと考えています。 当チームは積極的な採用を行っています！もしこうした環境やチームに魅力を感じる方がいらっしゃいましたら、ぜひお気軽にお話をしましょう！ ソフトウェアエンジニア（プロダクトエンジニア）はこちらから！ tokyo-gas.snar.jp

こんにちは。ファインディ株式会社でモバイルエンジニアをしている加藤です。 先日、「 React Native Lunch Talk ～いま選ばれる理由とアプリの現在地～ 」にて、「新規サービス開発におけるReact Nativeのリアル〜技術選定の裏側と実践的OSS活用〜」というテーマで登壇しました。 本記事は、その発表内容を改めてテックブログとして書き起こしたものです。 発表では時間の都合で駆け足になった部分や、質疑応答で答えきれなかった論点もあったため、本記事ではそのあたりも含めて踏み込んで書いています。 背景：Findy Events β版の開発 前回の記事 でも少し触れましたが、昨年、Findy初のモバイルアプリ「Findy Events」をα版としてAndroidアプリのみリリースしました。 現在はα版から得た学びをもとにUI・UXをフルリニューアルし、技術カンファレンス向けのiOS/Androidアプリとしてβ版のリリースを目指して開発を進めています。 Findy Eventsが長期的に目指しているのは、「カンファレンスでの学びとつながりを、その場限りで終わらせず継続的な成長の資産に変える」ことです。 β版では、その第一歩として、カンファレンス当日の体験をスムーズにする次のような機能を提供予定です。 QRコードを提示してのチェックイン 予約済みセッションやタイムテーブルなど、カンファレンス情報の閲覧 カンファレンス前日やセッション開始前に届くリマインダーPush通知 本記事では、そんな新規モバイルアプリの立ち上げにあたって、なぜReact Nativeを選ぶに至ったのか、そしてOSS選定や実装で直面したリアルな所感について紹介します。 前回の記事 では技術選定の結論だけを紹介しましたが、本記事ではその判断に至るまでの比較過程やOSS選定の裏側までを踏み込んで書いています。 背景：Findy Events β版の開発 React Nativeの技術選定の背景 OSSモジュールの選定と活用事例 独自選定の事例1：Sign in with Apple 独自選定の事例2：UIライブラリ React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した OSS活用で感じたこと AI時代に、今からReact Nativeをやる意味 まとめ React Nativeの技術選定の背景 まず触れておきたいのは、「なぜ数ある選択肢の中からReact Nativeを選んだのか」という話です。 Findyにとって初のモバイルアプリ開発。しかも、技術選定を一から設計できる、エンジニア冥利に尽きる環境です。 ただ、自由度が高いということは、言い換えれば判断の重みも大きいということ。「モバイルアプリを開発する」と一言で言っても、その道筋はひとつではありません。 出発点として置いたのが、次の3つのアプローチの比較です。 最適な開発手法は、置かれた環境と考え方で変わる。これが私の基本スタンスです。 そして今回の前提は、「最小リソースで最速リリース」。この一点に照らして、まずCross Platformを選びました。 次に、Cross Platformの中から、国内外で実績が豊富なFlutterとReact Nativeの2つに絞って比較しました。 次の表は、iOSエンジニア出身である私の主観も踏まえて、2025年8月頃に整理したものです。 一見、表だけを見ればFlutterが優位に映ります。 正直なところ、私自身も最初はFlutterに馴染みを感じていました。 それでも最終的に選んだのは、React Nativeです。 決め手は、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」の掛け算。この2軸をかけ合わせることこそ、「最小リソースで最速リリース」という目標に最短で近づく道だと確信しました。 仮にFlutterを選べば、私だけでなく将来参画するメンバー全員に一定の立ち上げコストがのしかかります。特にモバイルエンジニア出身でないメンバーほど、負担は大きい。 対してReact Nativeなら、ReactとTypeScriptの素養を持つメンバーが多い今の組織にそのまま馴染みます。 自分さえ立ち上がってしまえば、その後の開発速度は中長期的に最も出せる。これが最終的な決め手です。 具体的に、「組織のアセット」と「モバイルエンジニアとしての自身のナレッジ」についてですが、「組織のアセット」としては、 社内の優秀なWebフロントエンドエンジニアからReactやTypeScriptの知識提供、レビュー協力を得られる React製の既存プロダクトの設計思想やソースコードを参考にできる という期待感がありました。 また、「モバイルエンジニアとしての自身のナレッジ」として、 iOS/Androidのプラットフォーム特性への理解 プッシュ通知などのモバイル固有の課題への対応力 を活かすことができると考えていました。 「社内のWeb資産をどこまで活かすことができたのか？」という部分が気になる方もいらっしゃるかもしれません。結果としては、次の技術スタックのとおり、組織のアセットをフル活用することができました。 実は、アーキテクチャに関しても、既存のWebプロダクトをほぼ流用する形で開発しています。 つまり、設計思想や実装パターンまで踏み込んで参考にできるほど、React NativeはReactと親和性が高いということです。 OSSモジュールの選定と活用事例 続いて、OSSモジュールの選定についてです。 iOSエンジニア出身の私がReact Nativeに触れて最初に感じたのは、「とにかくOSSが豊富」ということ。 ただ、裏を返せば「多過ぎて、どれを選べば良いか迷う」という別の課題が立ち上がってきます。 そこで採った方針は、 Expo公式ドキュメント を「羅針盤」として活用すること。 Expo公式ドキュメントは非常に充実していて、Expo公式モジュールはもちろん、推奨される3rd Party OSSも明記されています。第一候補をここに置くだけで、選定コストは大きく圧縮できるというわけです。 もちろん、これで100%をカバーできるわけではありません。その場合は、プロダクトのコンテキストに合わせて独自に選びます。 ここからは、その独自選定した2つのOSSを紹介します。 独自選定の事例1：Sign in with Apple モバイルアプリの認証では、GitHub・Google・Appleの3つのOAuth認証を新規に導入する方針を採りました。中でもSign in with Appleは、iOSの審査要件として必須の機能です。 そこで選定軸に据えたのは次の2点です。 審査で認証ボタンのデザインも厳格に確認されるため、iOS SDK標準の ASAuthorizationAppleIDButton を内部で利用していること iOSだけでなくAndroidでもSign in with Apple機能を提供できること Expo公式には expo-apple-authentication があるものの、Androidが対象外。今回は見送りました。 最終的に選んだのは、両OSに対応した react-native-apple-authentication です。 独自選定の事例2：UIライブラリ 冒頭で述べた通り、自社初のモバイルアプリということもあり、社内にモバイル用のデザイン資産はありません。「最小リソースで最速リリース」を実現するには、UIライブラリの活用が欠かせない要素になります。 選定軸に据えたのは次の2点です。 豊富なUIコンポーネントが提供されていること iOSエンジニア出身の自分にとって、学習コストが高すぎないこと 実はα版では Tamagui を採用していました。ただ、β版でUI・UXをフルリニューアルすることが決まり、より要件に合致するライブラリを改めて探すことに。 たどり着いたのが、選定軸2点をしっかり満たす HeroUI Native です。 ここで一つ頭を悩ませたのが、採用を決めた当時（2026年1〜2月頃）のHeroUI Nativeがまだβ版だったこと。利用によって課題が顕在化するリスクを抱えての判断になります（※現在はstable版が提供されています）。 そこで採った工夫が、「HeroUI NativeのWrapper Componentを実装し、画面側からは直接HeroUI Nativeに触れない構成」にすること。 影響範囲をWrapper層に閉じ込めておけば、将来の差し替えや仕様変更への耐性が確保できる。β版OSSを採用する際のリスクヘッジとして、有効な型の一つだと感じています。 React Nativeに対するリアルな所感 立ち上がりは、AI時代でも想像以上に苦労した React Nativeを選んだ結果として率直に感じたのは、「AI時代と言えど立ち上がりにはそれなりに苦労した」ということ。 実は10年ほど前に少しだけReactに触れたことがあったのですが、React HooksやLifecycleに相当する考え方はほぼ初学者の状態。概念の再学習が必要でした。 また、TypeScriptも「Swiftと似て非なるもの」であることを痛感します。 型による安全性という思想は近いものの、 as によるキャストや enum がベストプラクティスとしては非推奨とされている点など、Swift感覚で書くと足をすくわれる場面が少なくありません。 一方で、React Native自体に対するハードルはそれほど感じません。理由は次の2つです。 宣言的UIによるUI構築は、SwiftUIで経験していた プッシュ通知など、モバイル固有機能の仕組みそのものを理解していた LT会では「どうやってReact Nativeを勉強したか？」という質問もいただきました。取ったアプローチは、過去にSwiftで開発していた個人アプリをReact Nativeで書き直してみるというもの。 題材を一から考えずに済む上に、Swift版という答え合わせの対象がある状態で進められるため、SwiftUIとの共通点や差分を体感しながら学べます。 こうして実感できたのは、React Nativeを選んでも、モバイルエンジニアとしての経験や強みは十分に活かせるということです。 OSS活用で感じたこと OSS活用の面でも、幾つか印象的な気付きがあります。 1つは、OSSの更新速度の速さです。 React / React Native界隈は更新サイクルが早く、iOS Nativeとの文化の違いを肌で感じます。 加えて、脆弱性検知などのエコシステムが整っており、開発者体験として足かせになっていない点も心強いところです。 もう1つは、Expoの利便性への驚きです。 ExpoはReact Native界隈ではデファクトスタンダードと言える立場を確立しており、信頼性も高く、証明書やリリース周りといった「モバイルアプリ開発ならでは」の知識を手厚くカバーしてくれます。 これは、Webフロントエンドエンジニアがモバイルアプリ開発に参入するハードルを相当下げていると言って良いでしょう。 実際、Webフロントエンドエンジニアの方から「React Nativeって実際どうなの？」と聞かれた際は、Expoのおかげで「モバイルアプリ開発は想像以上に始めやすい」と答えることができています。 AI時代に、今からReact Nativeをやる意味 最後に登壇の中では時間の都合で踏み込めなかった論点について書いておきます。 それは、「AI時代に、今からReact Nativeをやることに意味はあるのか？」という問いです。 個人的には、少なくとも次の3点で意味があると考えています。 1つ目は、iOSとAndroidを同時に立ち上げる中で、OS間の差分に向き合う経験が積めることです。 Cross Platformと言えど、プッシュ通知や認証、OSの作法といった領域では差分が必ず顔を出します。 AIに任せれば書ける時代だからこそ、差分の勘所を自分の中に持っているかどうかが効いてくると考えています。 2つ目は、アーキテクチャ選定やOSS選定といった、プロダクトの土台を作る判断を経験できることです。 ゼロからモバイルアプリを立ち上げる機会はそう多くなく、「何を選んで、何を選ばなかったか」を自分の言葉で語れるようになる経験は、AI時代でも色褪せにくい資産だと感じています。 3つ目は、Webフロントエンドへの足掛かりになることです。 React NativeでReactやTypeScriptを書いている時間は、そのままWebフロントエンドの学習コストを前払いしていると言えるかもしれません。 そのため、モバイルエンジニアとしてWebフロントエンドへ領域を広げたい人にとって、React Nativeは自然な入り口になると思います。 （もちろん、Webフロントエンドエンジニアとして、モバイルアプリへ領域を広げたい人にとっても同様です。） まとめ Findy初のモバイルアプリ開発を通じて、React NativeやOSSの選定と実装で多くの知見を得ることができました。 初めは慣れないReact Nativeに四苦八苦することもありましたが、一度慣れてしまえば、モバイルエンジニアとしての強みを存分に活かすことができると実感しました。 AI時代においては、人がガードレールとしてソフトウェアの責任を背負う場面がますます増えていきます。 その観点で見ても、React Nativeは「AI時代に、人が責任を取れる技術」として十分に選定に耐えうると考えています。 モバイルアプリの技術選定に迷っている方や、iOS/Androidの経験を活かしてReact Nativeに踏み出そうとしている方は、ぜひ一度触ってみてください。 本記事がその一歩を踏み出すきっかけになれば幸いです。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers